I just returned from a session titled "Pragmatic SOA: A Case Study." So what did I learn? I think I learned that SOA is doable today. That although there are still some significant gaps in the set of web services standards and technologies, and although there still aren't a lot of good tools for implementing an SOA approach, you can still build an effective SOA solution. But you have to do it "pragmatically."
The central presenter for this session was T.N. Subramaniam, Director of Technology for RouteOne LLC, a credit aggregation management company for the auto industry. RouteOne brings together credit information that can be accessed by auto dearships in auto financing applications. T.N. said that RouteOne is one of the largest web service providers in the world. In this talk he focused on an SOA-based credit aggregation system that RouteOne implemented. He did an overview of the solution. He also covered the technology options that were available, and why RouteOne chose a particular option. For example, for B2B message binding, they use Document/literal and RPC/literal for reasons such as WS-I compliance. For XML security, they use XML-DSig because it provides for message authentication, message integrity, and message non-repudiation in a standard way.
Other presenters for this talk were Ashesh Badani, Sun's Group Marketing Manager for SOA, and Ashok Mollin, an Enterpise Architect at Sun. Ashesh essentially was the M.C., and Ashock did a follow-up, best practices, summary.
While the presentation of RouteOne's solution and their design choices were interesting, I found what RouteOne learned from this experience about implementing an SOA the most interesting part of the talk. Ashok characterized this knowledge gained as "Pragmatic SOA." Here are the SOA kernels of knowledge that came out of this experience:
- Start simple. A short term effort of say 3-6 months is best because you can quickly see if things are working as planned, and you can quickly get a sense of the return on investment.
- Let the business identify the service. Don't let IT drive what services get built. These services should follow the busines processes.
- Think XML documents, not objects. T.N. said that initially they passed around objects, and it caused problems. Document-based messaging is a less fragile and more scalable approach.
- Use SOAP as an envelope, but not as a binding
- Use WSDL for descriptions, not code generation.
- Think asynchronous conversations. Synchronous conversations can create performance problems.
- Use BPEL to orchestrate services. It's standardized.
- Use JBI for integration. It provides satndardized, pluggable framework for service integration.
T.N. ended the talk by underscoring that this is still a work in progress. He advised "Keep learning, this is not finished."
I think a lot of folks who are interested in SOA are waiting for case studies like this so that they don't have to be "guinea pigs." One of the most reasuring things I heard in this session is that RouteOne was pleasantly surprised as to how many of their decisions actually worked well. So maybe being a guinea pig in this stage of SOA maturation isn't that much of a risk. In any case, the more case studies like this, the more best practices on the books, the better and faster the promise of SOA will turn into reality.