COM+ versus Web Services
I thought I would include my response to a question recently posted on the Australian .NET Developers mailing list ...
"How do you see COM+ versus Web Services. At this stage we can still choose to go Web Services or COM+?"
The two aren't competing technologies.
COM+ provides platform services to a component, while a "service" is simply a program that communicates through messages. In other words, the implementation of any service will include logic through objects that may, or may not, be serviced by enterprise services.
Servicing components through enterprise services can remain just as relevant (depending on your architectural scenario) today. That's especially the case when you need to "scale up" in a server type scenario.
Remember that orthogonal component plumbing provided by either the platform or yourself, is an implementation issue - one not relevant to a specific architectural technology. It applies equally to traditional business logic within a process, as to business logic that implements an "asmx" type web service.
The choice of whether you "scale up" or "scale out" will depend on your particular circumstance and requirements. If your business logic is simple, stateless and largely based on interacting with the data tier, you could scale through an application farm. But if your requirements are processing intensive and complex, the most performing solution is likely to be a long living logic block that maintains state - one to which you might apply enterprise services - one that might itself be the implementation for a service.
Microsoft does not propose that business logic call other logic in the same process through XML based messaging. How efficient would that be? Rather, a service oriented architecture remedies the failure of distributed object technologies (like COM, Corba or RMI) to provide seamless program integration outside of a process (or application domain).
But what about the future? .NET 1.0/1.1 ships with 3 service technology stacks - "asmx" web services, .NET Remoting and Enterprise Services. Those will be unified in "Indigo", in order to make it simpler to implement a secure/reliable/high performance message-centric service architecture. COM+ binaries will work without recompilation in Indigo, migration will be simple and mechanical, and transactions, security and lifetime management attributes are fully supported. But keep in mind the following caveats mentioned in one of the PDC 2003 presentations:-
Requirements
Use a TLB
Be installed in COM+
Declare all co-classes and all interfaces on each
co-class in the tlb
Declare explicit interface types as parameters
Avoid
Explicit use of COSERVERINFO
Let config decide where the service lives
Using interface pointers in custom UCPs
Marshal-by-value approach works better
Calling CoSetProxyBlanket after first use of proxy
Will not be supported
Proxy/stub marshalling