COM+ with C# Client as well as C# ServicedComponent......

[Kedar Agarkar]

[SUMMARY]:

This is general query seeking opinions about COM+ Development wherein
Server [COM+ Components] is developed in C# [as ServicedComponent] and
Client accessing that across machines is also C#.

Wish to seek experienced words on issues of COM-.NET interop that is
playing major decisive role on both sides and is making decisions
complicated only based upon theory.

[IN DETAIL]:

We wish to develop numerious components for our middle tier in typical
3-tier application.

As our proposal for the Client layer is C# .NET, and due to in-general
assessment that developing and deploying the COM+ ServicedComponents
shall be faster than developing as C++ ATL based COM+ components, we
have decided to develop them in C#, as ServicedComponents.

As our clients applications shall be in C#, we believe that the
proxies that it shall be using [created out of the C#
ServicedComponents installed on Server machine] shall be also in C#
[i.e. MSIL, I guess]. Thus the client side shall also involve COM-.NET
interop as the call shall be propaged to COM+ Server on other end via
DCOM.

Considering the fact that the both of the ends are involving COM-.NET
interop in either direction, we have some concerns-cum-queries, and
kindly let us know your experienced words.

Queries:
1> Is it pragmatic to use such a deployment [as explained above] that
shall involve overhead of COM-.NET interop on both sides?
2> As our clients are not browsers [but only UI applications], we feel
that replacing the COM+ Components by We b Services shall not be a
practicble proposition. This is becasue we feel that making a HTTP
request to Web Service shall involve additional overhead of opening a
socket connection to the Server, creating the request programmtically
before making one. Are we thinking on correct lines?
3> Can you suggest an alternative [if any] approach for technology
selections [MS only] on both Server and Client ends of these client
and middle tier, so that we can fetch the best of both .NET and COM+
worlds?

Thanks for your time.
- Kedar Agarkar

 

[Nicholas Paldino [.NET/C# MVP]]

Kedar,

See inline.

[SUMMARY]:

This is general query seeking opinions about COM+ Development wherein
Server [COM+ Components] is developed in C# [as ServicedComponent] and
Client accessing that across machines is also C#.

Wish to seek experienced words on issues of COM-.NET interop that is
playing major decisive role on both sides and is making decisions
complicated only based upon theory.

[IN DETAIL]:

We wish to develop numerious components for our middle tier in typical
3-tier application.

As our proposal for the Client layer is C# .NET, and due to in-general
assessment that developing and deploying the COM+ ServicedComponents
shall be faster than developing as C++ ATL based COM+ components, we
have decided to develop them in C#, as ServicedComponents.

Good choice. =)

As our clients applications shall be in C#, we believe that the
proxies that it shall be using [created out of the C#
ServicedComponents installed on Server machine] shall be also in C#
[i.e. MSIL, I guess]. Thus the client side shall also involve COM-.NET
interop as the call shall be propaged to COM+ Server on other end via
DCOM.

This is true, however, if you are using a pure .NET solution, then I
would not use this option. Rather, I would expose the objects from the
server machine through remoting (if it suits you, there is no security with
remoting right now). The components would be serviced components residing
on a server machine, you just use a different mechanism to call them. If
you need the secure channel that DCOM provides, then yes, you will have to
use a proxy and COM interop.

Considering the fact that the both of the ends are involving COM-.NET
interop in either direction, we have some concerns-cum-queries, and
kindly let us know your experienced words.

Queries:
1> Is it pragmatic to use such a deployment [as explained above] that
shall involve overhead of COM-.NET interop on both sides?

Yes. You are going to incur some overhead with this kind of distributed
architecture anyways. I would recommend using remoting over the COM+
proxies. If you use remoting, then there is no COM interop, not on the
client, and not on the server either.

2> As our clients are not browsers [but only UI applications], we feel
that replacing the COM+ Components by We b Services shall not be a
practicble proposition. This is becasue we feel that making a HTTP
request to Web Service shall involve additional overhead of opening a
socket connection to the Server, creating the request programmtically
before making one. Are we thinking on correct lines?

What's the difference between creating a socket to speak with a web
server and creating a socket to speak with a machine that is holding COM+
components? If you have two separate machines and you need them to
communicate, then you will always have to establish a connection of some
kind and then package the request to be sent across the wire. Web Services
are just a different way of doing that. Depending on your application, it
might be a viable option.

3> Can you suggest an alternative [if any] approach for technology
selections [MS only] on both Server and Client ends of these client
and middle tier, so that we can fetch the best of both .NET and COM+
worlds?

Remoting or web services (I prefer remoting).

Hope this helps.

 

[Steffen Ramlow]

1> Is it pragmatic to use such a deployment [as explained above] that
shall involve overhead of COM-.NET interop on both sides?

Yes. You are going to incur some overhead with this kind of
distributed architecture anyways. I would recommend using remoting
over the COM+ proxies. If you use remoting, then there is no COM
interop, not on the client, and not on the server either.

Hm? Are you sure? I bet all the COM+ interception stuff on the server side
is still using interop.

What's the difference between creating a socket to speak with a
web server and creating a socket to speak with a machine that is
holding COM+ components? If you have two separate machines and you
need them to communicate, then you will always have to establish a
connection of some kind and then package the request to be sent
across the wire. Web Services are just a different way of doing
that. Depending on your application, it might be a viable option.

The diff is, that RPC is very compact compared to http and even more to WS.

 

[Steffen Ramlow]

1> Is it pragmatic to use such a deployment [as explained above] that
shall involve overhead of COM-.NET interop on both sides?

Yes. Compared to all the other things which happen (network latency,
database, file i/o, ...) this overhead is nothing.
Have you load tested your scenarios? Do they meet your needs? If so, fine.
If not, reconsider.

2> As our clients are not browsers [but only UI applications], we feel
that replacing the COM+ Components by We b Services shall not be a
practicble proposition.

WS have not very much to do with browsers.

This is becasue we feel that making a HTTP
request to Web Service shall involve additional overhead of opening a
socket connection to the Server, creating the request programmtically
before making one. Are we thinking on correct lines?

See above about http overhead. Yes, it needs more than RPC, but does it
matter?
WS are more for B2B, not intranet.

3> Can you suggest an alternative [if any] approach for technology
selections [MS only] on both Server and Client ends of these client
and middle tier, so that we can fetch the best of both .NET and COM+
worlds?

To achieve what?

 

[Kedar Agarkar]

Thanks Nicoles and Stephen...........both of you for contributing
valuable comments. Having developed Real-Time Middleware on my own and
comparing that with .NET Remoting details, I was feeling a bit
precarious with this option.

I shall have some more study and post again to you and this
newsgroups, this is our very pre-starting phase of a project.

Thanks again for your valuable time.

- Kedar Agarkar

1> Is it pragmatic to use such a deployment [as explained above] that
shall involve overhead of COM-.NET interop on both sides?

Yes. Compared to all the other things which happen (network latency,
database, file i/o, ...) this overhead is nothing.
Have you load tested your scenarios? Do they meet your needs? If so, fine.
If not, reconsider.

2> As our clients are not browsers [but only UI applications], we feel
that replacing the COM+ Components by We b Services shall not be a
practicble proposition.

WS have not very much to do with browsers.

This is becasue we feel that making a HTTP
request to Web Service shall involve additional overhead of opening a
socket connection to the Server, creating the request programmtically
before making one. Are we thinking on correct lines?

See above about http overhead. Yes, it needs more than RPC, but does it
matter?
WS are more for B2B, not intranet.

3> Can you suggest an alternative [if any] approach for technology
selections [MS only] on both Server and Client ends of these client
and middle tier, so that we can fetch the best of both .NET and COM+
worlds?

To achieve what?