The following is a summary of a talk given by Richard Turner from the Indigo team that provides guidance on choosing between the various options for building SO applications today including ASMX, WSE2, Remoting, DCOM, ES, MSMQ, and the future path to Indigo.

Why is SO important?

  • Services are meant to last. Microsoft is betting the farm on services being everywhere. Indigo is the is one of the most fundamental rewrites in a long time.
  • A common tongue is needed for services to interact: boundary, schema, contract, and policy.
  • An SO environment extends only as far as we agree on the expression onf the boundary.
  • SO systems that want boroadest possible interop will build on the WS-I protocol family.

Which technology should I use and where?

At the service boundary:

  • Build services using ASMX (default). Use ASMX at boundaries.
    • Components should stay within your service boundaries.
    • Closely aligned to SO tenets.
    • Closest alignment with Indigo.
    • Great interop support.
  • Use WSE for advanced Web services (WS-* protocols)

Inside the service boundary:

  • Consider using ASMX within the service boundary too!
  • Use ES if you need its rich services, want to re-use/extend existing ES/COM+ components, path to "Indigo" from ES.

Asynchronous communications:

  • Use System.Messaging if you need asynchronous messaging, reliable messaging and queing, "first and forget" messaging. MSMQ is not going away. It's going to be the underlying engine in Indigo.
  • The System.Messaging API and namespace does not move forward to Indigo. Indigo navtively supports queing semantics.

Remoting:

  • Use remoting where it's absolutely appropriate. Only use it within the service. Great for getting close to the wire. Inproc cross appdomain communications, handling custom wire protocols.
  • Remoting is not the fastest for cross machine access, DCOM is the absolute fastest.
  • Avoid exposing remoted components at service boundaries.
  • Remoting is an object technology, not aligned with SO principles.
  • Limited interop (e.g., only does SOAP rpc/encoded style).
  • Limited future migration to Indigo.
  • Remoting is not going away. It is moving forward, but there will be better solutions in Indigo.

Caveats:

  • ASMX - avoid using low-level extensibility such as the HTTP context model.
  • ES - avoid passing objrefs inside of ES
  • Native COM+ and MSMQ - use System.EnterpriseServices and
  • System.Messaging, do not use native COM+ and MSMQ APIs
  • Remoting - avoid low-level extensibility such as sinks and channels

Distributed technology performance:

Will ASMX slow my app down? What % of your method calls are work?

  • More work than call - probably minimal impact
  • More call than work - possible impact

Will ES slow down my COM+ components?

  • ES requires more work to create and destroy objects.
  • Use JIT activation and pooling to amortize cost over many calls.
  • Done the right way, ES *can* match COM+ perf.
  • See ES perf whitepapers on MSDN.

Remoting vs. ASMX performance:

  • Remoting tcp/binary wins.
  • Binary remoting hosted in IIS next fastest.
  • ASMX is faster than remoting for SOAP.

Component technologies often obscure service boundaries. Design assumptions don't match deployment realities.