Hosting objects in COM+ vs IIS

[Guest]

Hi all,

@ my work place, we have been using COM+ for business objects for a while
even though our COM+ components are VB 6.0 components and as such we did not
make use of any of the COM+ features (except it being a host for our DLLs)

Now we are embarking upon .NET and have been debating b/w the following
options:

(1) Create .NET serviced components, host them in COM+ and access them using
DCOM
(2) Create .NET remoting objects and host them in IIS

I am all for the 2nd option for the following reasons:
* We will not be using any COM+ feature, such as object pooling, b/c it is
of no use in our scenario b/c object creation does not take time @ all (means
we don't do any initialization in object constructor)
* We can scale out IIS 6.0 easily; that would give us scalability.
* We would not have to open ports for client machines to access the .NET
remoting objects hosted in IIS (clients and servers are separated by
firewall).

Now my questions are:

(1) what do you guys think about it? any suggestions, comments about which
option is best?
(2) what if we were to go for the 2nd option? will old VB 6.0 clients be
able to talk to .NET remoting objects hosted in IIS? If yes, then how? SOAP
Toolkit?
(3) am I right when I say IIS 6.0 would be more scaleable than the
equivalent COM+ implementation?
(4) any other thoughts?

Thanks,
Stewart

 

[Eric]

(1) what do you guys think about it? any suggestions, comments about which

option is best?

You didn't explain how the clients will integrate. You've assumed that
the answer to question 2 is yes.

..net remoting is going to be much faster than com+ for .net clients.

For vb6 clients (or classic ASP clients) you will still need to play the
com+ game. You might be able to mix some .net remoting with com+, but I
don't think this makes sense unless you will have some .net clients.

(2) what if we were to go for the 2nd option? will old VB 6.0 clients be
able to talk to .NET remoting objects hosted in IIS? If yes, then how? SOAP
Toolkit?

SOAP is mostly for web services. It is possible to use SOAP formatting
with remoting, but this isn't efficent and probably isn't a good idea in
your case. COM+ interop with EnterpriseServices is your best bet for vb6
callers.

(3) am I right when I say IIS 6.0 would be more scaleable than the
equivalent COM+ implementation?

I personally don't think this would be true, but I haven't seen any
studies on this. You seem to dislike com+, but I don't think it's as bad
as you imply. The more important question is whether you've architected
the apps correctly to use com+ in the best way.

(4) any other thoughts?

You seem to have a requirement to have distributed processing. This is
never desireable unless it's needed, but if you need it then you have to
do it the best way possible.

Web services are a great way to do distributed processing if your
throughput needs are not too strict.

..net remoting makes sense with .net clients.

com+ really does make sense for vb6 clients. The trick is to architect
the components the right way. For example, you will need a com+
component to interact with vb6, but that component can call other .net
assemblies which may serve as business objects. This would be direct
calling on the same computer, or via remoting for distributed computing.
But, never make distributed calls if you don't need them. Also, don't
call other com+ components from a .net com+ component if you can avoid
it - that would be very slow.

Eric