People always seem to get excited about understanding how SOA shapes the IT Architecture when any of the trainers/consultants at EDC4IT explains SOA. They appreciate that there are components that shape the architecture which offers the services. They agree that this kind of architecture creates strong boundaries (internal parts of one component are not to communicate with internal parts of another component). All seems to be wine and roses until we start talking about the impact on (their often precious) database….
Let’s assume you are working on an airport movie rental system where you can borrow a DVD/blu-ray disc from one airport and return it to another at a special Borrow&Fly kiosk. You are also able to reserve a movie prior to your trip to be held at your airport of origin.
Let’s assume further that within its service architecture there are two components: MemberManagement, with Registration and Account services, and InventoryManagement with Inventory services. The MemberManagement owns business concepts such as Member, Loan, Reservation; Inventory is responsible for business concepts such as Movie, Disc, Kiosk.
In an OO system without a component architecture it is very likely that the semantic associations (SBVR facttype) between Loan and a Disc will evolve into a class association (it is plausible to think that they will need to collaborate). However, with the SOA in mind this association will never exists (the Loan and the Disc belong to different architectural domains). You will only see this when you take a holistic view on the architecture. The modeller of the MemberManagement component does not know the business concepts of the InventoryManagement component, so this is not a real issue.
Let’s assume the following service operations for a use case “Reserve Movie” depicted on a Service Invocation Diagram for this use case (might as well have been BPMN/BPEL):
As you can see, first a request is made on inventory with to hold a Dics of a particular movie at a specific kiosk. The Disc held is returned. This returned ID is then used on the request to the member service. Now when you take an isolated look at the service operation reserveItem on the member service, you will notice that nothing is stopping you from reserving a disc that does not exists! No check can and will be made inside the member component to assure the ID represents a valid and available disc. It goes even further: these two components have their own database, so there is also no referential integrity between the two tables that eventually will represent the business concepts Reservation and Disc. This at first often seems unacceptable to some people.
The way to look into this is as follows. The whole rationale of only being able to reserve something that exists and is available lies within the process of reserving a movie (part of a business process “Lease Disc”). It is the orchestration layer which is responsible for implementing and guarding this process (the second life-line of the diagram above). As you can see, this correctly implements this rule: the discId returned from inventory is passed on the account service (highlighted in red).
Notice we did not name the service operation "reserveDisc" with an argument "dvdID". There is no relation between this id and a disc!). This opens a whole new world of possibility: we can now start reserving flowers, books, laptops, what have you and still use the account service. We can outsource inventory without having to deal with entangled IT services (entangled by some sort of relation like: class associations, database relation dependencies on service data types, etc.)