3-tier now and then

  • Thread starter Thread starter John Lee
  • Start date Start date
J

John Lee

Hi, All

We had a lots of debate on how to use web services (in some extent I
think web service is miss used) - here is the scenario I really want all of
your opinion on the following issue:

before .net web service, we either build 2-tier app or 3-tier app and host
the com+ app remotely and all client using proxy to access the com+ app
remotely ...

now, we just the use web service to replace the com+ app, so every single
database call will be calling one of the web service method to get back data
from db or update back db so the dataset is heavily used to ship data
between client and web service ...the webservice is simply being used as a
way
to centralize database call method ...

What other best practice/alternatives if this is not right thing to do?

All genius, please tell me you opinion.

Thanks very much!
John
 
John,

I think that taking your COM+ app and then moving it to a web service is
a bad idea. Not everything that is in a web service is portable. For
example, it's easy to map objects that are marked as [Transaction] in COM+
to web services, but if they are not JIT activated (which you have by
default when using the Transaction attribute in COM+), then the model
becomes difficult to port.

Also, thinking long term, using Enterprise Services (COM+) now will
provide the easiest upgrade path later on when moving to Indigo. If you
design properly for COM+, it will be as easy as switching a few attributes.
With web services, it is not going to be anywhere near as easy.

I would recomment keeping your objects in COM+, and then letting COM+
expose the web service (this is possible in the recent versions of COM+ I
believe) if you really need that functionality.

Just remember, if you want a simple mapping from COM+ to web services,
then your objects should keep no state, and be JIT activated (which
re-initializes the object for every call).

Hope this helps.
 
John,

It is depends on how you use the web service and what you mean by saying
"use web service replace the com+ app".
The web service was designed for service oriented application. To take
advantage of it you might want to redesign your
COM+ applications in the service oriented way! The service is more usefull
if it is not only doing get/update database but
also perform the business logic of the application.

If your COM+ applications are designed to perform get/update database only
then when you "replace" it with your web service,
the web service will end up with just get/update database nothing more
nothing less.

Duy
CSDP/MCSD
 
John,

Yes a very good idea in my opinion to use that WebService.

This opens the possibility to use your applications in every part of the
world as long as there is an Internt connection. And that either for
webforms applications as for windowforms applications because you can take
the same approach for both.

Assuming you take the right security steps of course.

You would be in my opinion a fool when you don't take that great
opportunity.

Just my 2 eurocents.

Cor
 
Thanks very much for your reply!!!

the biggest concern is the performance - calling web service method is much
slower than calling a COM+, our Windows apps are all internal inside
firewall, I do not see the benefit web service gives us. How is .net
remoting fits in this scenario?

Thanks!
John

Nicholas Paldino said:
John,

I think that taking your COM+ app and then moving it to a web service
is a bad idea. Not everything that is in a web service is portable. For
example, it's easy to map objects that are marked as [Transaction] in COM+
to web services, but if they are not JIT activated (which you have by
default when using the Transaction attribute in COM+), then the model
becomes difficult to port.

Also, thinking long term, using Enterprise Services (COM+) now will
provide the easiest upgrade path later on when moving to Indigo. If you
design properly for COM+, it will be as easy as switching a few
attributes. With web services, it is not going to be anywhere near as
easy.

I would recomment keeping your objects in COM+, and then letting COM+
expose the web service (this is possible in the recent versions of COM+ I
believe) if you really need that functionality.

Just remember, if you want a simple mapping from COM+ to web services,
then your objects should keep no state, and be JIT activated (which
re-initializes the object for every call).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

John Lee said:
Hi, All

We had a lots of debate on how to use web services (in some extent I
think web service is miss used) - here is the scenario I really want all
of
your opinion on the following issue:

before .net web service, we either build 2-tier app or 3-tier app and
host the com+ app remotely and all client using proxy to access the com+
app remotely ...

now, we just the use web service to replace the com+ app, so every single
database call will be calling one of the web service method to get back
data
from db or update back db so the dataset is heavily used to ship data
between client and web service ...the webservice is simply being used as
a way
to centralize database call method ...

What other best practice/alternatives if this is not right thing to do?

All genius, please tell me you opinion.

Thanks very much!
John
Click to expand...
Click to expand...
 
John,

If everything is internal, then I would definitely keep it as a COM+
application. No need to hack a limb off if you don't have to.

I would not use remoting in this situation either. If you go from COM+
to remoting, you lose authenication, authorization, secure calls,
transaction support, queued calls, object pooling, just in time activation,
etc, etc. Now it might be that all you need is remote object calls, but I
doubt that is the case.

Remoting serves very little purpose IMO, except in very simple, well
defined, static cases where all you need is to have one object talk to
another object in an application domain, period.



John Lee said:
Thanks very much for your reply!!!

the biggest concern is the performance - calling web service method is
much slower than calling a COM+, our Windows apps are all internal inside
firewall, I do not see the benefit web service gives us. How is .net
remoting fits in this scenario?

Thanks!
John

Nicholas Paldino said:
John,

I think that taking your COM+ app and then moving it to a web service
is a bad idea. Not everything that is in a web service is portable. For
example, it's easy to map objects that are marked as [Transaction] in
COM+ to web services, but if they are not JIT activated (which you have
by default when using the Transaction attribute in COM+), then the model
becomes difficult to port.

Also, thinking long term, using Enterprise Services (COM+) now will
provide the easiest upgrade path later on when moving to Indigo. If you
design properly for COM+, it will be as easy as switching a few
attributes. With web services, it is not going to be anywhere near as
easy.

I would recomment keeping your objects in COM+, and then letting COM+
expose the web service (this is possible in the recent versions of COM+ I
believe) if you really need that functionality.

Just remember, if you want a simple mapping from COM+ to web services,
then your objects should keep no state, and be JIT activated (which
re-initializes the object for every call).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

John Lee said:
Hi, All

We had a lots of debate on how to use web services (in some extent I
think web service is miss used) - here is the scenario I really want all
of
your opinion on the following issue:

before .net web service, we either build 2-tier app or 3-tier app and
host the com+ app remotely and all client using proxy to access the com+
app remotely ...

now, we just the use web service to replace the com+ app, so every
single
database call will be calling one of the web service method to get back
data
from db or update back db so the dataset is heavily used to ship data
between client and web service ...the webservice is simply being used as
a way
to centralize database call method ...

What other best practice/alternatives if this is not right thing to do?

All genius, please tell me you opinion.

Thanks very much!
John
Click to expand...
Click to expand...
Click to expand...
 
SOAP Web Services are pretty much as you describe -- all the
maintenance difficulty of tight coupled com+ and all the security and
state issues of the Web in one package! As Nicholas Paldino says, if
everything is internal, just use com+. If you need to "Web enable" the
app, you might want to consider ReST (Representational State Transfer)
over HTTP as the architecture instead of SOAP.

Using ReST at least gives you the maintainability of loose-coupling.
http://webservices.xml.com/pub­/a/ws/2002/02/06/rest.html is
a good intro to the architecture.
 
Thanks very much, Nick!

Is there any performance issue if I put the .NET Serviced Component on
application server and access remotely from .net client? (in COM world you
would create a proxy and then distribute the proxy lib to client to access
COM+ app remotely - how would we do in .NET? is it .NET remoting?)

Another issue is the transaction attribute can only be defined as class
level so for every class I have split into 2 (one for transaction and one
for non-transaction) - this issue will be gone with .NET 2.0 though because
of the System.Transaction namespace. Web Service allows you to define
transaction attribute on method level - how it works internally? Can we
mimic that behavior using System.Enterprises?

Thanks again!
John

Nicholas Paldino said:
John,

If everything is internal, then I would definitely keep it as a COM+
application. No need to hack a limb off if you don't have to.

I would not use remoting in this situation either. If you go from COM+
to remoting, you lose authenication, authorization, secure calls,
transaction support, queued calls, object pooling, just in time
activation, etc, etc. Now it might be that all you need is remote object
calls, but I doubt that is the case.

Remoting serves very little purpose IMO, except in very simple, well
defined, static cases where all you need is to have one object talk to
another object in an application domain, period.



John Lee said:
Thanks very much for your reply!!!

the biggest concern is the performance - calling web service method is
much slower than calling a COM+, our Windows apps are all internal inside
firewall, I do not see the benefit web service gives us. How is .net
remoting fits in this scenario?

Thanks!
John

Nicholas Paldino said:
John,

I think that taking your COM+ app and then moving it to a web service
is a bad idea. Not everything that is in a web service is portable.
For example, it's easy to map objects that are marked as [Transaction]
in COM+ to web services, but if they are not JIT activated (which you
have by default when using the Transaction attribute in COM+), then the
model becomes difficult to port.

Also, thinking long term, using Enterprise Services (COM+) now will
provide the easiest upgrade path later on when moving to Indigo. If you
design properly for COM+, it will be as easy as switching a few
attributes. With web services, it is not going to be anywhere near as
easy.

I would recomment keeping your objects in COM+, and then letting COM+
expose the web service (this is possible in the recent versions of COM+
I believe) if you really need that functionality.

Just remember, if you want a simple mapping from COM+ to web
services, then your objects should keep no state, and be JIT activated
(which re-initializes the object for every call).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi, All

We had a lots of debate on how to use web services (in some extent I
think web service is miss used) - here is the scenario I really want
all of
your opinion on the following issue:

before .net web service, we either build 2-tier app or 3-tier app and
host the com+ app remotely and all client using proxy to access the
com+ app remotely ...

now, we just the use web service to replace the com+ app, so every
single
database call will be calling one of the web service method to get back
data
from db or update back db so the dataset is heavily used to ship data
between client and web service ...the webservice is simply being used
as a way
to centralize database call method ...

What other best practice/alternatives if this is not right thing to do?

All genius, please tell me you opinion.

Thanks very much!
John
Click to expand...
Click to expand...
Click to expand...
 
Hi John,

As far as I know, I don't think there will be any performance issue. A .NET
Serviced Component is same used as a common COM component on COM+ server.
We also need to get an .msi file from the server. However, we also need to
export a tlb library for the assembly to do interop. For more information,
please check tlbexp.exe for more information.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/htm
l/cpgrftypelibraryexportertlbexpexe.asp

As a support engineer, I'm not quite sure how does System.Transaction
namespace work internally. Also, since it is not released yet, we cannot
ensure any feature of it. Sorry that I cannot help on the second question.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
John,

....
Another issue is the transaction attribute can only be defined as class
level so for every class I have split into 2 (one for transaction and one
for non-transaction) - this issue will be gone with .NET 2.0 though
because of the System.Transaction namespace. Web Service allows you to
define transaction attribute on method level - how it works internally?
Can we mimic that behavior using System.Enterprises?
Click to expand...

Not with attributes, but with code inside methods, yes we can. .NET 1.1 on
XP or 2003 Server (i.e. COM+ 1.5) provides you with ServiceDomain class.
Look it up in the documentation.

I use it for rolling back my NUnit tests automatically:

[SetUp]
public void StartTransaction()
{
ServiceConfig cfg = new ServiceConfig();
cfg.Transaction = TransactionOption.Required;
cfg.TrackingEnabled = true;
cfg.IsolationLevel = TransactionIsolationLevel.RepeatableRead;
cfg.TrackingAppName = "BusiDO Tests";
cfg.TrackingComponentName = "BusiDO Tests";

ServiceDomain.Enter(cfg);
}

[TearDown]
public void RollBackTransaction()
{
ContextUtil.SetAbort();
ServiceDomain.Leave();
}


HTH,
Alexander
 
Back
Top