WebServices dot org

The Problem of Service Description as Seen in the Pizza Shop Blueprint

The idea that underlies the idea of "loose coupling" – separating interface from implementation - is great. In fact, the notion of a service is fairly dependent on this separation, so that the service can be sufficiently abstracted by this layer. At this point, ideally, the implementation itself no longer matters.

The thing that's really interesting about this is that while the implementation doesn't matter (you can convince me of this if you try hard enough), the outcome matters a LOT.

Here’s a silly, but highly illustrative, example of separating interface from implementation. Let’s implement a pizza shop. So what is the interface to a pizza shop? The most compact interface would be a method that inputs currency and outputs pizza.

Lets implement this interface in the simplest way possible: a cardboard wall with one slot, through which you push money in and pizza out.

Now, lets add a slightly more sophisticated interface, which would involve a separate slot for money (lets make it about five inches wide and one inch high), and a separate slot for the pizza. This is a good best practice, because as transaction volume increases, we become increasingly concerned about collision of incoming money and outgoing pizzas.

So far so good! We've successfully separated the interface from the implementation-we are geniuses! If we had a crayon, we could scrawl the word "MUNNY" on the money slot with a nice arrow pointing to the slot and we could put "PIZZA" over the other slot. If we wanted to be all Web 2.0, we could even embed unstructured metadata by scrawling "Please wait for the pizza to come out" and "pizza Ten Dollars pleez" on the cardboard. Excellent, we are fully PSDL 2.0 compliant now!!! (Pizza Service Description Language).

Now, on to the implementation. We can put this interface up in front of any pizza shop, at any location around the globe. Great! The implementation no longer matters, because the interfaces are completely interchangeable, mission accomplished! You could even put this interface in front of a mail slot, and the money could be immediately grabbed and the pizza implementation could be outsourced to India. You would need Federal Express to ship the money to India, and you would need to ship the pizzas back. Hooray! Business process outsourcing!

Ok, I'm sure you've picked up my sarcasm. However, let’s take a look at some of the problems we’ve also created:

• Service levels: The India BPO implementation, of course, has a latency issue. Please allow 8-12 months for delivery of pizza. How do I know when the pizza will appear?
  

• Customization: This system does not account for different types of pizza for different consumers. Putting customization behind the service interface is a way of complicating the services and creating services that cant be reused
  

• Security implementation: How does the pizza provider know that the pizza consumer is the same identity who paid for the pizza?
  

• Currency translation: can you pay for a pizza using euros?
  

• Policy handling: how do you handle someone paying 5$ and walking away? Does half a pizza come out?
  

• Exception handling: what if the pizza slot is jammed?
  

• Compensating transactions: Can you push "change" back out the money slot?
  

• Choreography: this is more of a lower-level issue in this example, but do the pizza implementers put the cheese down first or the pepperoni? Clearly the pepperoni! Services must in some cases be consumed in sequence, but in other cases, sequence doesn’t matter as much or at all.
  

• Monitoring: Can I cut a peephole in the cardboard so customers can watch pizza being made? This would have the benefit of being more transparent, but in some cases may scare away the customers. Another issue is what conditions or events merit alerts? Should pizza-making systems send out an alert when the oven is broken? Should there be an “out of pepperoni” alert? (Perish the thought!)
  

• Pizza versioning: If you upgrade to "stuffed crust," how do you maintain service to customers who still prefer "original"? How do you deprecate original and manage the transition to stuffed? How do you handle the transition period?
  

• Transformation: Which pizzas are cut into squares? Which ones into triangles? There are a whole ton of attributes that make a service valuable, particularly in a business context, that are not described by the interface.

Two slots – one for "MUNNY" and one for "PIZZA" – is not a service description. Within any enterprise – even a simple pizza shop – there are plenty of implementation issues that are behind any interface.