SOA and the clash of technocultures classes versus infosets versus business process

Abstract

There is just too much stuff in the SOA for most developers to absorb. It is difficult to understand what is real and what ishype. Beyond that, it is difficult to understand the performance and inter-operability of different implementations approaches. Developers need guidelines for when and where to use XML, Objects and BPEL and for how to make them play together. They need a sense of the relative performances of the technologies or, better yet, a small set of benchmarks that they can run to characterize their own environments. It is important to make sure developers are aware of the classic distributed design patterns. We recently talked to a company with a major web service performance problem, only to find out that their developers were using a naïve web service design to implement fine-grained computations between two processes on different machines. Many business processes, especially those which cross organisationational boundaries achieve transaction semantics through asynchronous services. This imposes a new currency paradigm on developers used to working in an RPC world. Expect to see a lot more UML interaction diagrams and a lot more tools for dealing with service deadlock. Services designers should have a strong background in protocol state machines and requires a new role of Service Architect in many organizations. Finally developers need to know how to design long running business processes and how to upgrade them. One major omission in many service definitions is versioning, which means that it is difficult to support legacy services and introduce new ones. At present I don't believe there is any accepted way for dealing with versions of a service. The promises of SOA are great but the latent complexity and the disruption created by pitting different technology proponents indicates one should tread carefully. Focus on service definitions of high value services well before adopting a major platform or toolset. Leverage best practices in interface design, and distributed system design. Make sure that service designers are properly educated in the use of protocol state machines. © JOT, 2007.