SOA services != RPC
By rtenhove on Aug 02, 2007
That's actually a more profound question than it appears at first blush, especially if you are a hands-on, code-first sort of developer like me. Profound, for it goes directly to the value (potential value, perhaps) of a system built using a service-oriented architecture.
What is the value of SOA? Reuse. That has always been its strength, or at least its promise. But this is not the same as code reuse, the holy grail of software design since the invention of the subroutine.
Where then, do services come? We must look not to code, or other artifacts of service implementation. Instead, we must look to business processes. The elements of reuse in a business process are business functions. Reusable business functions are what enable the quick, reliable creation (or modification) of business processes possible. Business agility (I hate the phrase; it sounds like market-speak) depends on such services. Shorter time to market, high quality, avoiding any code creation: all things that help create business value.
How do you create such services? Simply by looking at business processes, mining the common activities that comprise them. Do some processes involve a credit check of a customer? Sounds like a candidate for a service. Notable SOA thinkers have developed nuanced models of services in a layered fashion (John Crupi's "lasagna" model, for instance), but the basic principle applies: the high-value reuse occurs at the business process level. It's what makes modern SOA worthwhile, and not simply a language-neutral way of packaging libraries: reuse at the service composition level.
This is in sharp contrast to how a lot of services are identified and implemented today. Many developers, with a very code-centric world view, very naturally look to their available reusable code assets (libraries, APIs to useful applications, and the like) when then look to service creation. After all, these are proven candidate for reuse already, and wrapping them with more technology-neutral interfaces (web services and the like) should make them even more reusable. Very logical.
Logical, but off target. This completely misses the value of reusable services, as discussed above. Repackaging code assets is really an exercise in RPC. Does it create the benefits of reusable services that can be used for process composition? No, for such code assets are the fine-grained stuff from which such business functions \*may\* be created, but aren't those business functions themselves. It is rather pointless to use a lot of RPC to write somethng that is more easily, and efficiently, realized in native languages (C++, Java, etc.).
So what is the lesson here? As the title of this piece says, RPC is not equal to SOA services. Services must be designed from a different centre than code reuse. Process composition is the proper centre of service design.
This is, in many ways, what the business process automation folks have been telling us for years, but that is for another entry.