Alex Hoffman

Perspective on development, management and technology

Syndication

News

    Subscribe

    IASA Member

March 2004 - Posts

Whidbey/Yukon Dates Slip

Updated ...

See Whidbey/Yukon Release Date Summary

Posted Thursday, March 11, 2004 6:05 PM by Alex Hoffman

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

Posted Wednesday, March 10, 2004 5:00 PM by Alex Hoffman | 5 comment(s)

Filed under:

.NET Design Guidelines for Class Library Developers

Ken Brubaker is maintaining a useful list of new class library design guidelines as published by Brad Abrams [MS] on his weblog.

These are combined into the MSDN .NET Design Guidelines for Class Library Developers - part of the .NET Framework SDK - required reading in my opinion for all developers working with others.

Summary:

Posted Monday, March 1, 2004 1:26 PM by Alex Hoffman | 1 comment(s)

More Posts