SOA: No Referential integrity?…unacceptable!

People always seem to get excited and understand how SOA shapes the IT Architecture when any of the trainer/consultants at Trivera Technologies explain SOA. They appreciate there are components that shape the architecture which offer the services. They agree this kind of architecture creates strong boundaries (internal parts of one component are not to communicate with internal parts of another component). All seem to be wine and roses, until we start talking about the impact on the database….

Let’s assume in an airport movie rental system (where you can borrow a DVD on one airport and return it at another at special Borrow&Fly kiosks; you are also able to reserve a movie prior to your trip to be held at you 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 to business concepts such as Movie, DVD, Kiosk.
In an OO system (perhaps without architecture) it is very likely that the semantic associations (SBVR facttype) between Loan and a DVD 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 DVD 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 concept 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 (SID) for this use case (might as well have been BPMN/BPEL):

SID Reserve Movie

As you can see first a request is made on inventory with to hold a DVD of a particular movie at a specific kiosk. The DVD held is returned. This returned ID is then used on the request to the account service. Now when you take an isolated look at the service operation addReservation on the account service, you will notice that nothing is stopping you from reserving a DVD that does not exists! No check can and will be made inside the member component to assure the ID represents a valid and available DVD. 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 DVD. This at first often seems unacceptable to some people.
How to look into this is as follows. The whole rational 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 DVD”). It is the orchestration layer’s who is responsible for this process (the second life-line of the SID, LeaseDVD). As you can see this correctly implements this rule: the dvd returned from inventory is passed on the account service.
We are probably better off renaming the dvdID on the service data type for used by addReservation to something like itemID (as there is no relation between this id and a DVD). This opens a whole new world of possibility: we can no 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)