SOA services != RPC

So where do services come from?

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.

Comments:

Well yes, true. However what you land up with depends on how you start - a top down vs bottom up approach. In a lot of organizations, existing functionality exists in vertical silos and the they land up interconnecting them or exposing that via "services". If you take the top down approach then you have a greater degree of control on the grannularity and level of abstraction exposed (ie the process view)in the services. I would argue that the real value is not code reuse - Increasing business agility doesnt come from reusing code libraries - it comes from reusing "services". Weather the underlying plumbbing is reused by the developer is irrelevant in the context of the bigger picture.

Posted by Sameer Tyagi on August 02, 2007 at 03:16 PM EDT #

I think we are in agreement; code reuse isn't the real value here. There is a danger, though, when services are created in the bottom-up fashion. Bottom-up tends to be based on existing code assets, exposing APIs in a very RPC-like fashion. This often fails to deliver any real value, as discussed in the blog entry. This failure, in turn, becomes an example of a SOA failure, often without any proper analysis of the underlying cause. We should learn from our mistakes.

Posted by Ron Ten-Hove on August 02, 2007 at 04:53 PM EDT #

An even better abstraction over business processes would be business capabilities as they provide a more stable view. See - http://msdn2.microsoft.com/en-us/architecture/aa479368.aspx

Posted by Sanat Gersappa on August 02, 2007 at 05:58 PM EDT #

On of the most surprising aspects of "SOA" as a discipline is that we are still having these types of discussions.

I believe the first time your arguement was made was in "Programming-in-the-Large Versus Programming-in-the-Small" back in 1976. Similarly many of these ideas are simply natural extrapolations of Parnas' Information Hiding principle from 1972.

While the technologies and standards we use in platforms to implement a SOA are relatively new, the design principles required to identify processes, services, etc have often been around for more than 30 years.

The question is, why don't we as a discipline remember these lessons?

Posted by Jason Baragry on August 02, 2007 at 08:31 PM EDT #

[Trackback] Ron Ten-Hove has two interesting blog entries, one talking about how SOA Services != RPC and another one about the relation to business process automation. In his view, the most important difference is the separation of business process logic from the ...

Posted by Stefan Tilkov's Random Stuff on August 02, 2007 at 09:40 PM EDT #

I don't think SOA fundamentally alters the landscape in this regard from traditional Object-Orientation. The best design approach has always been to create abstractions that reflect terms and concepts found in your requirements specification or customer vocabulary. All SOA is doing here is allowing you to build a bigger app in a more distributed environment across different technology sets.

Building a library just to "share some code" has always been a faulty approach. Just because two algorithms look the same doesn't mean they should share an implementation. If the abstraction they represent is fundamentally different you will end up building up cruft and spaghetti as the shared implementation is pulled in different directions over time.

SOA still suffers from the faults of Object-Orientation. It is fundamentally difficult to combine clients and servers written at different times against different versions of the communication specification. This is where REST in particular offers solutions, and why REST is a better approach to building systems that are going to be incrementally and partially upgraded over time.

Benjamin.

Posted by Benjamin Carlyle on August 04, 2007 at 10:10 PM EDT #

Post a Comment:
Comments are closed for this entry.
About

rtenhove

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today