The SOA case of the missing bag – a Service Oriented Analysis

Though I did not particularly liked it, not having my bag returned by the conveyor belts of New Orleans Airport as I arrived yesterday for the ODTUG 2008 Kaleidoscope conference only slightly dented my good spirits. And after a short night’s sleep I saw the Service Oriented side of things. What is the – not hugely interesting – story: I landed at Washington DC Dulles airport en route to New Orleans. I took my bag through customs and dropped it at the transfer luggage drop off point. After a thunderstorm inspired delay I left for New Orleans and once arrived in the deep south, my suitcase had not seen fit to accompany me. Here I entered the services world of United Airlines, the courier service and the Sheraton hotel. The process put into motion with my report of the ‘missing bag’ can be described from a service oriented point of view. Which makes for a nice analogy with what we typically are doing in SOA, largely with automated process steps and interfaces.....

This scribble describes – illegible though it may be – in a crude way the entities, interfaces and services involved in getting the bag back to me.

The SOA case of the missing bag - a Service Oriented Analysis lostluggagesoa

There is a number of actors involved in this process. First of all, there is me. Off to the left, contemplating the fact that I am without toiletries and night gown in rather philosophical way. Then there is United Airlines, the culprit, with several departments and sub entities, such as the lady at the ‘I do not handle complaints but only polite requests’ at the booth next to the baggage carousel at New Orleans airport, the crew handling the luggage down there and the bag tracking system they use at UA – that probably communicates with the central airport handling systems at Dulles and New Orleans airport. There is also the courier service, located at the airport next to the booth I just mentioned – and probably getting a lot of business from United Airlines for delivering missing pieces of luggage. Since I am staying at the Sheraton Hotel, they get involved too. The Bell Desk is external interface that will accept drop offs of goods destined for hotel guests. The reception desk will be able to provide guest information – such as the room where I am staying. The hotel voice mail system is engaged as is the little flashlight on top of the phone sitting on the desk in my hotel room.

Process instantation


The event setting of the whole process is kind of a non-event: the non-appearance of my bag on the carousel  eventually triggers me to report to ‘the lady in the booth’. This must be a new architectural pattern: NEDA or non-event driven architecture. At the booth I ran into a second pattern: trickle feed. A sign on the booth said: to efficiently serve our customers we allow only one person inside. A binary thinking person – such as myself – would argue that with the lady in the booth, this one person limit is already reached and no customers would be served at all. Fortunately, that was not the intention. The sign was meant to prevent a batch of (potentially angry) customers to come in at once, flooding the service resources of TLITB. Eventually my non-event could be handled. The input to her service was by baggage claim tag (one could consider it an identity token) that the UA system had provided me with during check in at Schiphol Airport.

The lady in the booth consulted the UA bag tricking system – oops, that should read tracking system – to find out the whereabouts of my suitcase. The tag id was the input for this consultation, the location – Washington DC Dulles Airport – the output. Fortunately the service did not return faults like ‘tag unknown’ or ‘bag not in our care (customs now has it)’. TLITB then informed me about the next steps: she started a process instance for my bag that would start with an asynchronous call into the luggage handling system in the New Orleans terminal. This call requested the bag to be delivered to the booth as soon as a later flight from Dulles would have brought it to New Orleans. The process instance had been fed with my name and address details, using the Yellow Pages as a service to turn my incomplete information into the appropriate address format, and would now sit and wait for an answer to the asynchronous call. An additional (onmessage) event handler – TLITB – could accept my phone calls – correlated based on the tag id – to report on the status of the bag process and potentially escalate.

I could do nothing at that point then accept the puny overnight bag with some toiletries and leave for the hotel.

Hydration on receiving of the asynchronous response 

During the night, the response came from the luggage handlers in New Orleans – the bag had been recovered. The process instance came back to life and TLITB invoked the Courier service – instructing it to deliver my bag (one part of the request message) to the hotel specified by the address details (the second part in the request message). She may have asked for a delivery receipt (asynchronous response, since I doubt she has sat in her booth, doing nothing but wait for confirmation that my bag had been delivered), but I am not sure she cared that much. So it may have been a simple fire-and-forget (one way) request. For which an SLA probably exists (deliver within this time frame and for a fee of X dollar).

Another fire-and-forget service call was made when the courier dropped off the bag at the bell desk of the Sheraton hotel. The courier probably stopped the car, but I am sure he went as fast as he came. Of course he was not allowed to approach the reception desk, let alone bring the bag up to my room. He knew nothing about such implementation details – he only dealt with the Sheraton’s side entrance where the bell desk can be approached.

After this fine example of B2B, the bag was now in the capable hands of the bell desk. I wonder whether at which point United Airlines will have considered the transaction complete. They probably did not coordinate this transaction with the Sheraton, holding of closing of my bag’s file until the bag was actually in my possession. So the question arises whether they have compensation handlers in place that I could have invoked if somewhere between the courier and my hotel room the bag had been lost.

Well, that did not happen. The bell desk invoked the reception desk’s ‘get guest room number’  service. A service that requires guest identification details and can only be invoked by authorized parties. Other hotelguests and external parties can get their phone calls rerouted to the guest room, but will not get the room number itself. However, the bell desk is a trusted party and I take it that the bell desk only had to provide last night’s password – MERLIN13 – to convince the reception desk that they really were the bell desk.

Once they had my hotel room number, they used a sophisticated queuing system, to decouple their call from my availability. Given the fact that they used the voice mail instead of calling me directly at 4AM I can only applaud this action. The voice mail system then communicated a signal to the telephone in my room – I take it this is the result of a pull operation, a poll by the telephone – to start flashing the light, indicating new voice mail messages. The next poll event then was my eye observing the flashlight and communicating to my brain, which at that time clearly was decoupled. Only much later did I actually register the flashlight and its significance.

A quick call to the voice mail system let me in on the information that the bag had arrived. With a subsequent call to the bell desk, I invoked the ‘ please bring my bag up to my room’  service, for which my name was the input and the promise of speedy del
ivery the synchronous response.
The arrival of the bag itself was an activation of the onmessage event handler that I had started parallel to my early morning process of reading email.

One thing still highly unclear to me is the SLA for receiving a bag in your room from the bell service. How much do you tip?