lustratus LiteBytes

For the longest time I have been a strong advocate of focusing on the data within SOA.

Too many of the early SOA advocates seemed to focus on the functionality exposed through a service and regard the data of secondary importance (almost as a side-effect of the function).  This tendency is not surprising as it comfortably fits within the way much code is written – sequencing function calls to achieve the goal.  However extending this into SOA undersells the value of good service design.  As Steve Jones puts it (talking about the same phenomenon of using services as BPM steps) :

“To be 100% crystal clear. If you are doing BPM and then just saying “step = service” then you are doing VISUAL Cobol and replacing function calls with service. The fact that you are using WS-* or XML does not make these elements services.”

It is probably fair to say that data modelling is now accepted as a normal mainstream SOA activity (I have previously written about data modelling in SOA here).  How to balance between the data and functional perspectives will depend on your organization as I said here:

“the balance between focus on the data exposed through the service and focus on the functionality exposed through the service depends on the type of organization and type of integration you require. If you business tends towards business processes which are primarily multi-step coordinations across applications which are self contained and transmit little data between them – then the predominantly functional approach suits. However, if your business shares and exchanges large amounts of data between the applications – then that emphasis on data must be incorporated within your SOA.”

If yours is a very data centric architecture, is the “classic” SOA approach suitable as it is often very function centric?  A recent Burton Group report suggested that a different approach may be needed:

“Because the REST style, unlike object oriented programming styles, is all about naming things with Uniform Resource Identifiers (URIs) so they can be retrieved, it is uniquely suited for creating data services applications, he said”

I do believe that it is necessary to bring an open-mind to the selection of architectures and technologies when implementing SOA and in particular moving beyond only using the often very function centric approaches provided by some SOA software vendors.  However, I would dispute that “Data Services” can be seen as truly distinct from whatever the alternative is (“Function Services” perhaps?).  All services exist somewhere along a gradient between function and data and in most cases the final implementation must deal with a range of services along that gradient.  With regard to the specific of REST as an alternative to SOAP and Web Services in general, my conclusion is you can use both to achieve many goals and both have there pluses and minuses (shock) -  there have been great discussions on the issue in the Integration Consortium web-site.

And finally, quoting again from the article on the Burton report …

“While acknowledging that everyone is “up to here” with buzzwords, Lacey offered yet another one, resource-oriented architecture (ROA), for data services using REST. ‘If REST is a style then a resource-oriented architecture is an implementation of that style in the same way that if object-oriented programming is a style, then Java is an implementation,’ Lacey said. ‘resource-oriented architecture is REST applied to the real world.’”

If anybody attempts to use ROA (Resource Oriented Architecture) as an acronym again, I will be onto fellow analysts MWD to start a new petition as we did last time for SOA2.0!

Ronan