This talk started out with a bang as Don and Doug collected a list of questions from the audience that they planned to answer throughout. The best part about this was that the questions were really great. For example: When should you use .NET Remoting vs. Enterprise Services? What will happen to COM+? When does COM matter? Should we use ASMX?.

After this, they proceeded to go through exactly 3 slides. Cool bullets…

• There is only one program and it is still being written.
• Choice is an illusion.
• Objective interpretation is an oxymoron.

The question is, what do the bullets really mean? Clearly, Don and Doug are great philosophers who enjoy abstracting the meaning of technology, where have we been, where are we going, how do we get there…all that. So, I’ll give you my interpretation (which we know from the bulleted list will not be shared by everyone).

First of all, the meaning of SOA (something the masses struggle with big time) is that we need to design systems (or, services) as well encapsulated, autonomous chunks of functionality that can be consumed by other systems, across departmental, enterprise, and possibly industry boundaries. This is one big program (the matrix anyone?)…metaphorically speaking…although of course not literally. If we design systems with the expectation that we cannot control where and who consumes them, we will fit within the SOA model. Contracts for these services, once published, must remain constant…because we have no idea who is consuming them, nor when.

In a related topic of discussion regarding the definition of service interfaces, we must consider that there can be many interpretations of a service schema. For example, if an industry like ACORD (for insurance) defines what XML looks like for a certificate of insurance, does that mean all systems following that standard will interpret EVERY element of the schema in the same way? Or, might there be different (valid) renditions of this schema? For example, could an xsd:int value be delivered as an xsd:string instead and still be meaningful? Sure it can. Could a subset of the schema be used by the destination endpoint? Absolutely. Thus, by definition we need extensibility and we need to be prepared for variant interpretations. In addition, the object model behind a service will rarely look exactly like xsd-generated classes. Services must be able to interpret XML payloads in their own way, and process them according to the needs of the system. What all of these competing Web service vendor platforms can agree on is the goals of SOA and the protocols (WS*) that are required to interoperate. Proof of this of course is in my recent experience with the Web Services Interoperability Education Day. This is exciting stuff, to see emerging standards work across platforms…we will continue on our quest there.

I enjoyed the philosophy shared during the talk, but must admit that the questions asked at the beginning were so compelling that I was really looking forward to their answer. I almost think they could have done two complete presentations. One for the philosophy, another for the Q&A. So, although there wasn’t a lot of time for answers at the end, here’s a summary of what I captured:

• COM will not disappear, it will be part of hybrid solutions, and transparent to the service interface.
• Remoting is useful for crossing app domains, but not for crossing machine boundaries. Use it for fault tolerance within a process (one app domain goes down, the main process stays alive).
• Crossing machines and processes, DCOM is fastest binary protocol, and can be secured, which means EnterpriseServices (ES). This also facilitates DTC transactions. Oh, and MSMQ is integrated here so you can also guarantee message delivery.
• On ASMX serialization vs. binary serialization with remoting, ASMX will be faster than .NET remoting, short term performance gains using remoting today will not position your applications for future releases (I.e., Indigo). You can expect better performance with ASMX in future as programming models change, and frankly what impacts performance most is usually bad architecture, including hardware choices and physical tier distribution. One thing that will also support performance improvement at a more granular level is also XML parsers…something the team is working on.
• How many WS* protocols do we need? Less. SOAP/XML is a great start. WS-Security is critical for end to end message integrity. We need standard protocols for interoperability, thus we need tools to assist with serialization, such as WSE 2.0.
• WSE 2.0 gives us a chance to work with WS* protocols now, while waiting for Indigo. The important thing is to realize it is taking you in the right direction. It keeps you in the game. These standards move fast, so does the WSE team. Indigo will just swallow it all making it even easier once standards are more stable.
• MTOM is the future of DIME.
• SAML will be supported, because WSE is extensible. Actually, Benjamin Mitchell and I worked on a SAML sample for our interoperability demonstration with Axis/SourceID…so we kinda already have a start on that!
• Your ES investment with COM+, MSMQ will be supported by the world of Indigo. Of course!