The first consumer world is unbounded - web 2.0 world and a bounded world - B2B/EAI world . By bounded world we mean the fact that "each component service which talks to each other is constrained by the way businesses currently operate; surely businesses innovate, but for application integration this is generally a fixed-cost problem that maintains current business relationships with some return on investment and cost-savings rather than an enabler of hyper- growth. These additional enterprise and business-centric assumptions will eventually make a difference later on." By Unbounded world - this is the brave new world of web 2.0 where there are no constraints on how the service is used. This aspect of architecture requires support which is native to the web itself - the URI referencable world which REST is best at doing and has proven to do it over the years.
Then after going through details of REST theory, eventually they come back to the big picture of how they think the world will operate in bounded and unbounded worlds:
The picture looks like following:
Now note the following:
1. The SOA reference model is still the underpinning - capabilities being automated and modeled by software service still exist.
2. The service interfaces can be exposed in two ways (bindings for technically inclined) - REST style for unbounded problem and SOAP stype for bounded style. Even more specifically the picture suggests that in case you need heavy duty transaction support, protocol brokering, reliability and publish/subscribe framework - stick to SOAPy style. REST style is suited for stateless interactions and security will typically be handled at transport level.
3. The consumers for REST style services are browsers, custom REST apps (mashup builders, presentation layer frameworks, web 2.0 technologies etc) whereas the consumers for SOAP style services include similar functions excluding pure play web 2.0 technologies.
Our Views:
Heavy discussions followed in our group. Our reference architecture for service layering is available on the link here. (http://soaitilitsmdebate.blogspot.com/2008/04/exampes-of-business-service-in-brave.html)
Our view with reference to our service model is as follows:
a) REST has 4 operations - C R U D - which are suitable for Core Business service as well as UI services and Utility services. It is pointless to create a CRUD interface for business process or core capability services in our reference model.
b) In case of core business services, unfortunately the simplicity of C R U D operations (i.e. binding operations) will imply a shift of complexity to nouns within the REST model - but it is still worth it.
c) we still dont see use of WS-Heavy across all enterprise services - the web model of services work very nicely for several types of services in our portfolio - so we have to be smart about it.
d) WSDL 2.0 supports natively both SOAP and HTTP/ rest style bindings natively. One of the implications of supporting both REST and SOAP bindings will be that we may need to generate two implementations to front end the core service. This will be an issue especially when the ESBs and the BPEL engines that do not support HTTP bindings by default. We see this happening with Core business and Utility services a lot (as UI service by itself is geared for presentation and not really reusable within the context of a process or capability).
e) It is pointless to have UI services exposed with SOAP bindings in our service framework.
e) There is a reasonable way in which we think mediation can be done so that same/similar implementation for Core business and utility services can deliver both SOAP and HTTP bindings without resorting to too much right click generate SOAP/WSDL - which should be possible with SCA. However it requires investigation and we will come back to it later on.
