The Indigo road show has come and gone and I have to give it up to Microsoft for sending such incredible representitives to talk about the next generation of distributed systems. Rich Turner and Ami Vora were both incredibly knowledgeable and approachable about all the topics I have to deal with in my job today. I felt they were open-minded and genuinely interested in community feedback of all kinds.

So that's enough with the love fest, now let's see how Rich Turner stood up to my geurilla interview tactics. Him and I spent a lot of time talking about the existing features in WCF and how service-oriented design strategies will map to those new features. I think there are still a lot of questions about how the latest runtime environment for web services will be used (or in my opinion abused).

Please note that all of these answers are not meant to be Rich Turner's response verbatim, they are my interpretation of our conversations and this is by no means intended to be an official word from Microsoft or Rich. I had questions, he had opinions and I figured those of you who are interested in SOA would find my new opinions interesting.

Question #1: I have looked at all of the features being delivered with Indigo at least with Beta 1 and my key question to Microsoft is how is this really moving us any closer to "service orientation"?

After our conversation: I get the feeling that their is a consistent message (at least there is now) coming from the distributed systems group and that message is service-orientation is not a technology. In fact I believe one of the comments I heard was that service-orientaiton is snake oil. What WCF will do is make service oriented systems easier to build because of the careful attention paid to the four tenets of service orientation when delivering all of the features in WCF. This has actually inspired me to write an article that will go into much more detail on service-oriented design and development and how careful attention to business process identification and service boundary definition are the only way to get an enterprise to a true SOA.

Question #2: Having read the whitepaper "Developing Distributed Services Today" I can't help but think we're heading down a dangerous path of merging Indigo services as a technology with service orientation as a concept. Doesn't the idea of a service transcend technology and how does WCF help me design, develop, deploy and support these things once they get into the wild (beyond a simple new version of the SOAP tracer found in the old SOAP toolkit).

After our conversation: So this one was a bit harder to answer but as you can see the answer to the first question sort of flows right into this one. The feature set available within WCF (and any other system runtime environment for that matter) will rarely prevent you from doing bad things. What it will do once you move to WCF is make it an explicit decision by the implementer to violate a service tenet if that's what you want to do. If you understand the limitations of the profiles and bindings delivered within WCF then you will have to intentionally configure a service to exclude it from interoperable clients (for example don't use the NetProfileTcpBinding if you want to consume the service with a Java client). However, distributed systems still have their challenges, I think there are some subtle enhancements that will make runtime support easier (the flag that lets you return service errors for example) but distributed systems are still very challenging to build and are still only as good as the underlying design principals that are followed during envisioning and detailed design.

Question #3: I also recently came across a very interesting blog from Kirk Allen Evans that was apparently linked into your whitepaper (Kirk Allen Evans Blog On Developing Distributed Services Today). This discusses the utlization of ASMX as an appropriate way to distribute objects in from what I can tell a non-SOA way. True they defend it as being a comparable technology when it comes to performance but the more interesting point here is that the objects and code have been distributed for no logical reason. Once again we have a technology capable of letting us do bad things in an easy way. This probably is more of a design patterns and practices thing but I'll be interested in what Rich thinks.

After our conversation: We probably spent most of our night talking about this very issue. How do you help designers and developers introduce sound design strategies and utilize the technology in a way that showcases it. I mentioned above this has inspired me to write an article of my own on this very topic so I'll table going too deep into my opinion on it as it would only steal my own thunder for that article. This is however undoubtedly a soft spot in the minds of the technology evangelists.

Question #4: If we are expected to believe that ASMX is the best mechanism today for preparing for WCF/Indigo down the road in our enterprise how can we be expected to ignore things like flowing transactions, binary message structures, WS-Security, and Reliable sessions? If I have read David Pallmann's book correctly the Basic Profile binding will not allow you to do any of these things and existing ASMX converted applications will have to use this binding. Why wouldn't we look more carefully at building Enterprise service components that are later exposed via web services. Take the DCOM hit today to reap the WCF benefits tomorrow!

After our conversation: The answer here was consistent with Rich's whitepaper, if you need transactions today continue to build enterprise service components but if you are simply distributing your programming business logic ASMX is a programming model that more closely ties into Indigo/WCF. In my opinion the feature set available with WCF so incredibly trumps the existing first generation web services that if you're writing web services today with the hope that the upgrade to Indigo will be seamless then you're nuts. The capabilities available within WCF for versioning and multiple end point definition give you the facility to reuse code and preserve autonomy in ways that are all but impossible with ASMX. In my opinion if you're building web services today for anything other than Interop you'll be re-engineering them once you get a look at the feature set within WCF.

Question #5: Finally my favorite topic is that of the four quickly forgotten/ignored service orientation tenets. These are design concepts that when followed assure you some level of longevity in your enterprise SOA. My favorite is without a doubt the fact that "Services are Autonomous". In an application requiring high durability this couldn't be more critical. This also seems to be the most clearly defined and most often abused tenet. I say that because I believe it to be as self describing as any of the tenets. Autonomous means self governing. What makes services self governing? How about that they don't rely on other services or that they are designed with offline capabilities in mind. I would say that the WCF/Indigo bits are keeping this tenet close to their hearts as they've extended the MSMQ reliable messaging pieces to the services programming model but when I read through some of the literature I keep hearing about services as both end points and clients. But there are no warnings about how the design of these pieces should be such that a failure does not impact the consumer ... strange dichotomy isn't it?

After our conversation: Rich corrected me on some of my assertions above, I was in-correctly grouping durable design into autonomy. The idea of being self-governing doesn't really imply independence from other services or systems. If durability is a key design consideration then design with that in mind but what autonomy really means is that services can be versioned on their own and they are not built with an individual specification from another system in mind. They really need to be designed and delivered in isolation in order to ensure that level of autonomy. I have to admit to grossly mis-interpreting this issue but as a side effect I think I know what my key concern is about service orientation and that is that it has nothing to do with technology or feature set. The success of a service-oriented architecture depends almost exclusively on the strategic design of reusable durable application building blocks. How to get there is going to be more of a result of how service boundaries are identified, designed, and delivered and will have very little to do with the technology responsible for their implementation. Again I'll say I'm going to write something much more detailed on this issue in the very near future.

I'll quickly summarize by sending a huge thank you out to Rich, Ami, Joe Healy, and the other Microsoft professionals that made this meeting possible. I just recently finished the Indigo Beta 1 book and this couldn't have been more timely for me. I have material for a code camp session coming up in Jacksonville titled "Indigo: Steroids for your Enterprise SOA" and I will likely have two new articles written surrounding these topics. Microsoft has shown me an almost open door policy as it relates to how their technology is being used and what type of information might be useful moving forward as the service-oriented era continues to evolve.