This post originated from an RSS feed registered with .NET Buzz
by Robert Hurlbut.
Original Post: SO Prescriptive Guidance
Feed Title: Robert Hurlbut's .Net Blog
Feed URL: http://www.asp.net/err404.htm?aspxerrorpath=/rhurlbut/Rss.aspx
Feed Description: Development with .Net, Rotor, Distributed Architectures, Security, Extreme Programming, and Databases
Aaron posts his notes from Richard Turner's talk on Service Orientation (SO -- notice the “A” has been dropped off now) Prescriptive Guidance.
Some key points I noticed (comments in red are mine):
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. (No surprises here)
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! (Interesting!)
Use ES if you need its rich services, want to re-use/extend existing ES/COM+ components, path to "Indigo" from ES.
(Notice: Remoting not mentioned ...)
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. (This is definitely true. Yet, ES can be difficult (today), so there may need to be trade-offs until Indigo)
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 (Yes!)
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
Previous Topic
