SOA at the movies

After doing a bunch of deeper, technical posts, I wanted to zoom out a bit and talk about higher level concerns. I think I’ll start out by discussing “service partitioning”. A couple of days ago, after finishing a presentation on SOA and workflow, one guy came up to me and asked me some questions about a system he was working on. I don’t remember exactly what those questions were, but I answered something to the effect of “well, that means you’ve divided up your services wrong”. “Is there any example I can look at that shows a correct division of services”, he asked. I was sincerely surprised that I couldn’t think of a single one.

I’ve noticed this same problem popping up in discussions about SOA online. For instance, in the service-oriented-architecture Yahoo group there’s a heated discussion about REST’s application to SOA in the context of… a light bulb. Yes, it’s true. By analyzing the behavior of a light bulb, we will be able to reach valid conclusions about enterprise systems – won’t we?

So, I began thinking what example I could give that would be complex enough to demonstrate the value of SOA, yet familiar enough to be easily grasped by most practitioners. After expanding the scope from light bulb, to room, to building, eventually what I came up with was a movie theater – something that would warrant software to run it. I think that we can come up with some basic requirements for an automated movie theater that would make sense.

First of all, a movie theater has a number of screening rooms, each room with light bulbs that need to be dimmed and lit, a projector for showing the movie, curtains to show and hide the screen, etc. We’d want the ability to plan which movie would be shown in which screening room. When the time would come for a movie to show in a specific screening room, the lights should dim, the curtains open, the projector activated. There would also have to be some maintenance done on these rooms – cleaning after a movie’s over, and fixing equipment that breaks down.

If we were to perform a service-oriented analysis of this problem, we might come up with the following services:

A Movie Assignment Service, where someone would plan which movie would show in which room and at what times. They would probably take into account if its opening night and the popularity of the movie. The user would also want to create several alternatives for the same date, several days in advance. At the beginning of each day, a (possibly different) user would choose which plan to execute. This plan would be published by the service as the plan to be executed.

Each screening room would have an instance of the Screening Room Service to run it. This service would subscribe to the plan to be executed event published by the Movie Assignment Service. It would also control the lights and the projector, curtains, etc for the specific room. When the time would come for it to screen a movie, it would start dimming the lights, open the curtain, start the projector, etc and publish that its state is “now screening” (you wouldn’t want a janitor to come sweep the floors in the middle). It might also publish the status of each light bulb, but that seems kind of silly. What makes more sense is for it to publish if it has any burnt out light bulbs or other faulty equipment.

Finally, the Maintenance Service would subscribe to the above events and page janitors and service personnel as needed to handle cleaning and repairs of the screening rooms in such a way as not to interfere with the movie goers.

Obviously we could expand this to include billing and other interesting topics, but I think that this is enough to get a feel for good service partitioning.

Possibly the most important difference between service-oriented architectures and the still popular layered architectures is the primary level of decomposition. We don’t automatically separate out the presentation layer and go from there. Rather, we try to gain an understanding of the business processes that take place in the domain, and divide the system up by ownership of those processes. There is absolutely nothing wrong with using layered architectures within a service. It’s just that layers are the wrong top-level abstraction for complex, distributed systems.

One last thought: notice how all the technical concepts we’ve discussed so far fit into the above services. Pub/Sub communication between services; Transaction boundaries that don’t cross service boundaries; Workflow kept inside services; and so on.

Forget about the holy grail of IT/Business alignment. Use SOA to build higher-quality systems today.

Posted by Udi Dahan at 09:16 AM  Permalink