In the World of SOA, the experts tell us that there are four core tenets of service-orientation to keep in mind:
- Service boundaries are explicit. Services are discreet units of operation. They perform a task and that task alone. Each service should be constructed to be able to stand alone with no external dependencies on other services. This is what is meant by loose coupling.
- Services are autonomous. Services are not to be confused with application workflow or business process. Those might incorporate multiple services, but a service operates independently from other services. Standards like BPEL4WS are being developed to orchestrate processes made of services. Products like Microsoft BizTalk 2004 Server 2004 also provide orchestration that may leverage many services and be a service itself. But each service should still be built with reuse in mind, and therefore be autonomous.
- Services share schema and contract, not class. This is a key message for industry standards. Many standards try to act like object technologies, mandating an "object's" time to live or describing when applications should delete or cancel or act in a certain way. Services, however, behave differently, sharing only a schema and contract, meaning that once the schema instance is sent, the service implementation or internals find out what to do with the data before sending back what is wanted for each contract. Service consumers and providers act independently of the internal implementations.
- Service compatibility is determined based on policy. This grossly overlooked standard enforcement mechanism is something that most standards have not tried to tackle at this time, even though so many wrangle with the concept of version compatibility, security considerations, and message granularity, incorporating quasi-policy structures into their standard, essentially creating non-standard policy enforcement. Instead, all of these elements can be shared by way of WS-Policy statements.
Now my point is that I don’t agree. Well let me give context for this first:– What is SOA?
Let me start with what is isn’t!
- SOA is not just web services and how we use them
- SOA most certainly is not BPEL
- and it most definitely isn’t ESB
- Its not a product
- Its not a religion
- Its not about process
- In fact SOA is not about technology at all
The bottom line is SOA is not the how….
SOA is really a single service or group or groups of services that represents a real world of ‘what we do’. So a SOA, a Service Orientated Architecture for a retail organisation is an architecture that is organised to support selling and buying and maybe manufacturing things in the retail space! The things that organisation does!! And that architecture does not have to have to a single web service to be a SOA!
Expanding this a little a recent definition that rings the bells for me is:
Service Orientated Architecture is a paradigm for organising and utilising distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with what the business does.
Simply but SOA is about:
So to the 4 tenants…
- Service boundaries are explicit. This unfortunately is looking at it from the wrong end. It is coming from the Web Services to support SOA world. Service boundaries are not explicit in the real world. An order service crosses multiple boundaries from Sales to Fiance to Manufacturing or procurement. True a service such as ‘Carry out a stock check’ may seem to be boundary explicit but is it? Do we just ‘Stock check’ the warehouse? We could look at ‘Replenishment Orders Pending’ as well to see if we are about to receive stock, we could even check our retail outlets to see if we can source stock there as well. Remember SOA should be about real services not web swervices!
- Services are autonomous. Confusion rains supreme. This one confuses Service with process. Services aren’t autonomous in the real world they are interwoven, they are the fabric of business. We can make web services autonomous and we can even make processes autonomous but not services in a real world. Take selling something. Is that an autoonomous service? No it isn’t it involves so many processes and other services such as replenishment, logistics, finance and on!
- Services share schema and contract, not class. Speaks for its self this one. Were talking techie not concept or real world! Services do not have to share schema unless thats how we are engineering them.
- Service compatibility is determined based on policy. Not true service compatibility is based on the needs of the business!!!
OK before everyone starts flaming me the point of this blog is to lift the SOA argument from the level of web service, xml and schema to the real world. Too many times I hear the words ‘we have decided on an SOA approach’ to support the business followed by ‘to that end the dev team have encapsulated 1400 ‘services’ in web services over a number of applications’ and ‘we have, of course, adhered to the 4 tennants of SOA!’. ‘We still have a few problems getting the business to work in conjunction with this new approach!’
My bottomline here is SOA is very important but only in getting businesses to understand what they do and allowing IT to help them do it better!