The Laundry Model for SOA
A common analogy for SOA is to describe it as lego blocks. At one level that works reasonably well, but the same analogy holds for object orientation or structured programming, so there must be something more. The CBDI site suggested the analogy of laundry
, and I have to confess I really like this model and have used it with several customers as well as internal people here at Oracle. Let me expand on the laundry model.
SOA is about Services
It might seem obvious but service orientation is about changing your thinking (orienting yourself) to think about IT systems as a collection of well defined collaborating components (services). A service has some sort of contract implying that the consumer of the service will provide X and in return will get Y. A laundry is a great example of this. A laundry defines an interface, I prefer to think of it as a basket, that says you give me a basket of dirty laundry and some money and I will give you a basket of clean laundry.
The Service Interface
The basket interface, defines that laundry is passed in a basket or a bag, and has various options (lets call them parameters) that allow the client to specify if they want stain removal on particular items, or if they want their laundry starched, or repaired or any of a number of different options. Note that these parameters specify what is to be delivered, not how it is to be done. In SOA we may use WSDL and XSDs to define the interfaces.
Our laundry service provider may decide to sub-contract part of the work to other companies, for example sending velvet clothing to a specialist velvet cleaning service that employs gnomes to pick out the dirt from the fabric. This use of other services makes our laundry a composite service, because it is built out of other services. The client of the laundry service is unable to tell that the service provider uses other services, hence there is no difference between composite services and atomic services. Often BPEL will be used to create composite services from existing services.
Virtualising the Service Interface
We may want to change our laundry provider, and as long as they provide the same service we don't really care who does it. We may change the provider based on cost, or service level. In any case we don't want to have to change the way we work with the laundry service just because it is a different provider. Many companies provide their employees with a laundry drop off service. The employee (client of the service) does not care who actually provides the service, he just drops off his dirty washing at the drop-off point and picks up the clean washing later. This virtualisation of the location of the service makes it easy for the service provider to be swapped out without changing the clients using the service.
In the SOA world we may use an ESB to virtualise the endpoint by providing a fixed address for the service. In addition to providing a fixed address we may also compensate for slight differences in the interface by using a mediator to map between the format the client wants to use and the format the new laundry service uses.
Personalising the Service
If we are a regular customer then the laundry may decide to offer us better rates or some other additional service. This type of customisation may need to be accessed from several different places, for example the laundry may automatically iron shirts for premium customers, this impacts both the process of processing the laundry (the process flow) and also the billing engine, which should not charge for certain services based on the value of the customer. Within a service oriented architecture a rules service will enable us to centralise common business rules, such as the free ironing service. Centralising business rules in a rules service allows them to be applied consistently across an organisation, and managed in a single location, making changing them much easier. In the SOA world a rules engine can provide this.
Finding a Laundry
Where to find a good laundry. One option is to look in yellow pages for a laundry convenient to yourself. The equivalent in the SOA world is to look it up in a service registry.
Protecting Your Smalls
An obvious concern is that you don't want your personal clothing stolen on the way to the laundry or tampered with in any way. You expect the transport mechanisms and the procedures at the laundry to be such that your privacy will be protected and your smalls kept private. You don't view this as part of the service interface but as a more fundamental attribute of the service.
In the SOA world we can use declarative security to confirm who is sending the message, and also to encrypt all or part of the message to prevent tampering with it. Within the Oracle stack this functionality can be provided by the Web Services Manager.
A Clean Solution
I hope the suggestions above show why I like the laundry model and why I feel it relates better to SOA than does the lego model. If you have other suggestions for extending the model please let me know. Similarly if you have better models then let me know as well.
In the meantime may your whites stay clean and starched.