Enterprise
Services in .NET - COM+ is not dead
Host: Raj Chaudhuri, Developer Evangelist, Microsoft India
January
03, 2003
DeepakG_[MS]: Hi Everyone
DeepakG_[MS]: Today's chat topic is about Enterprise Services in .NET
DeepakG_[MS]: and how COM+ and all the cool features that it has to
offer are still available in .NET
DeepakG_[MS]: today's session is being conducted by Raj Chaudhuri,
who works as a developer evangelist at Microsoft
DeepakG_[MS]: Since we don't have any questions yet, could you please
start with an intro Raj..
Raj_MS: Hi. There is a lot of confusion today, about the
relationship between COM+ and .NET. I have had people ask me that
if COM has COM+, will .NET have .NET+ ?
Raj_MS: Actually, COM+, despite the name, is much more
than just COM. COM+ provides a services infrastructure for components.
Components are built and then installed in COM+ applications in order
to build scalable server applications that achieve high throughput
Raj_MS: Services such as transactions, object pooling
and activity semantics
Raj_MS: In the past, to take advantage of such services,
code had to be packaged as COM components. That is no longer true.
The COM+ services infrastructure can today host components written
using COM as well as .NET.
Raj_MS: Starting with Windows XP, it can even host non-components
such as ASP pages and arbitrary code blocks.
DeepakG_[MS]: (mganesh): how is developing .NET components for COM+
differ from developing COM Components for the same?
Raj_MS: Developing .NET components for COM+ is actually
simpler than developing COM components. It is also somewhat stricter,
and thus prevents some common mistakes.
Raj_MS: Under .NET, if a component is to be hosted in
COM+, it MUST inherit from a class called System.EnterpriseServices.ServicedComponent.
This base class provides all the plumbing necessary for the COM+ infrastructure
to interact with the component.
Raj_MS: Other than that, you write methods and expose
them, just the same as with COM
Raj_MS: There are some additional rules. A .NET component
which is meant to be hosted in COM+ MUST have a strong name.
Raj_MS: Also, as you are probably aware, there are two
kinds of COM+ applications: Library and Server. .NET components meant
to be used in Server applications MUST be registered in the GAC.
DeepakG_[MS]: (mganesh): Hi COM+ runtime basically works thru interception,
but in .NET component is this same (i mean does it have proxy and
stub?)
Raj_MS: Yes, .NET components also work through interception.
Raj_MS: The actual mechanism used is .NET remoting. Interception
is customized by writing custom real proxies.
Raj_MS: There are actually several scenarios which can
occur in COM+ activation of serviced components (which means a .NET
component hosted in COM+). A good explanation can be found in the
following MSDN article:
Raj_MS: A "real proxy" is a .NET remoting concept, essentially
a class which follows certain semantics. In the case of COM+ activation
of serviced components, it is already written. I was just explaining
how it is done.
DeepakG_[MS]: Raj, does using ServicedComponent imply interop overheads
?
Raj_MS: Yes and no. The COM+ infrastructure is unmanaged
code, so there is some interop involved (I am NOT necessarily taking
about the COM interop mechanism here).
Raj_MS: Some generic testing shows that if you write some
components with "do-nothing" methods in managed and unmanaged code,
the unmanaged ones are about twice to three times faster to activate
and invoke.
Raj_MS: But the moment you start using actual services
such as transactions or pooling, these differences just go away.
Raj_MS: The article I mentioned in response to Ganesh's
question, above, has some very nice info on this topic. Here is the
URL again:
DeepakG_[MS]: (mganesh): are the threading models of the .NET components
same as COM components ( I mean w.r.t. COM+)
Raj_MS: .NET components support just one threading model:
free. So all the COM hassles with the six different threading models
are now history.
DeepakG_[MS]: (mganesh): is it relevant to discuss, then, COM had
a reason to have other threading models (apartment) how is it solved
in .NET?
Raj_MS: Not really relevant in this topic. Briefly, Apartment
threading allowed for components, which had not been written with
threading/concurrency in mind, to be used by clients which were multithreaded.
Raj_MS: With just a registry setting, essentially.
Raj_MS: Under .NET, the underlying infrastructure makes
*every* component thread-ready, so the whole concept of apartments
is now redundant.
Raj_MS: We could have a chat dedicated to this topic someday.
DeepakG_[MS]: Do you have any insights to share - especially for people
coming from ATL world and now using .NET to do COM+ components..
Raj_MS: In general, it is much simpler to create COM+
components under .NET. Much of the plumbing work is taken care of
by simply deriving from the ServicedComponent class,
Raj_MS: and there are some very nice utilities for activation,
pooling, transactions etc. Transactions especially can be controlled
by using attributes with class or method definitions.
Raj_MS: As just one example, you can use the
attribute with any method of a component which supports transactions.
Raj_MS: If the method completes successfully, the infrastructure
will automatically call SetCommit. If there is an exception, SetAbort
will automatically be called.
DeepakG_[MS]: (mganesh): Is there any COM+ feature that .Net Components
cannot make use of (I am asking like, VB COM Components cannot be
pooled)?
Raj_MS: Nope. All COM+ features are accessible to .NET
components. Look under the topic "Available COM+ Services" in the
.NET Framework documentation for a full description.
Raj_MS: Done with the unavailable features question.
DeepakG_[MS]: Ok then.. this brings us to the end of this chat session
DeepakG_[MS]: Next Week's Chat is on Design Patterns in .NET..
DeepakG_[MS]: Friday, same time (4:00 PM IST)
DeepakG_[MS]: so do join in then...
DeepakG_[MS]: Thanks Raj for taking time out from your busy schedule..
