I was having a Twitter conversation with Brenda Michelson (@bmichelson) and Todd Biske (@toddbiske) about the tight coupling in peoples minds between BPM and SOA, and why I find that when people take a BPM centric approach to SOA, it usually ends up not delivering the goods. So today’s post is about how to properly layer your SOA to include BPM while still yielding all the flexibility and reuse that is the promise of a well done SOA.
For this discussion I will build on the terminology defined in the post entitled “Anatomy of a Service Oriented Architecture”. I will also use 2 simplified application examples to illustrate some of the pitfalls.
So here is our base example. Imagine that you need to build a very simplified Point of Sale System. It needs to be able to log people in, update customer records and perform a transaction, including updating inventory. For the sake of argument, I will propose it should look something like this (not 100% accurate but best I could do in 20 minutes). Sorry the pictures are a bit hard to read. I need to change templates to get something wider.
Furthermore, I will contend that people following a BPM centric approach to SOA are usually likely to design it like this:
and that too often with SOA design we see something like this (which is really bad)
So lets look at these starting from the bottom one which, sad to say represents about 75+% of “SOA” implementations I tend to see.
Point of Sale – Badly Done Case:
This last example is what you get when people decide they need to be SOA, but frankly have no idea how to decompose a problem or do component based design. It is also what you get when people decide SOA means you just slap a web service interface onto a monolithic legacy app so you can call it SOA to please senior management who have heard all the buzz, and decided they just have to have an SOA by next week to save cost, etc. This approach buys the company absolutely nothing and in fact only slows down the performance of the existing system and certainly provides no flexibility and reuse at all.
Point of Sale BPM Centric Case:
In the BPM case we will have identified our main processes:
- Customer Lookups, etc
- Authenticating a User
- Processing a Transaction
We would then set about to design service interfaces which align to those and they would look something like this:
1. Customer Service:
1.1 Create Customer
1.2 Update Customer
1.3 Lookup Customer
2. Authentication:
2.1 Create User
2.1 Update User
2.3 Delete User
2.4 Login
3. Transaction:
3.1 Record Transaction
3.2 Void Transaction
Each of those service interfaces more often than not end up being tightly coupled to a back end database which exposes stored procedures which are also tightly aligned to those process services. Its basically a client server design behind the service interfaces, and while I drew them as 3 separate databases supporting each service, more often then not I will see no decoupling under the covers and it will be one big database.
Now, in this case we have a better design (but still not good) which shows some process orientation and some componentization. This design will offer some reuse, albeit limited. In addition this system will suffer from some data duplication (consider Paul Michaud as User and Paul Michaud as Customer. This design would store the records twice for Paul Michaud) which is not desirable in a good SOA.
Point of Sale – Layered Case:
I will contend that this design is optimal (or at least as optimal as I could draw in 20 minutes). It provides for the same level of BPM support, but does not require any data duplication and allows for the maximum reuse. I am not going to go into details on how one would come up with this design in this post but I will come back to that in another post soon.
To prove the point, lets now consider the need to create a second application to do simple contact management. We would ideally like to reuse our SOA and layer the new application on top of what we already built. I will contend that for this second application only the layered design would offer any reusable components for this second application. I will propose the following simple design for the Contact Management Application using SOA.
Contact Management:
Notice that we are using the party service not a Customer Service or anything else. A contact may be a Company, Organization, Church, Personal friend, etc. If we had only build Customer Services as in design 2 & 3, which is what the BPM approach would have identified we would not have had a foundation on which to build this second application (unless that second application was very similar to the first one).
Anyhow, the point is that by focusing on the process we usually fail to identify the necessary Foundation Services or the Fundamental Data Objects on which the SOA should be operating. I will elaborate on this further in a later post.
As always feel free to leave comments here or on Twitter.com (@techmusings).
(Guest post by Paul Michaud, Global Executive IT Architect for the Financial Markets sector at IBM. Paul blogs @ Technology Musings)
Is there a case where your first (layered) model may be particularly slow? It seems obvious that are a considerable number of network calls which would quickly add up.
In my experience I’ve often seen layed designs like this which are essentially method calls over the network hiding a C.R.U.D. model.
Let me cross post the comment I made to a similar question on the original article on technologymusings.com.
The answer is it depends. Keep in mind that this is a logical architecture at this point. While we may choose to deploy it in a physical realization that matches this with each component on a separate server and every call being through a network hop, etc, it it not necessary. Also, we have not indicated that each service interface needs to be web services (which is slower, but not slow by most people standards (sub 1ms per call typically unless the interface takes big XML data objects in the call)). That said, you can do this message based and have very low latency per hop/call (as low as 3 microseconds with the latest high speed messaging). Either way, a single call to a traditional on disk database is going to swamp the Web Services and the layered network calls. If you want to be low latency the whole design end to end needs to account for that goal. You may put critical service components on a single box to minimize network hops. You may use a binary service interface for those high performance calls, etc. There are many ways to skin this. The key is to remember that SOA does not require statelessnes, SOAP or REST. SOA applies independent of the technologies we choose to use to implement it.
But your right if you have too many layers and you don’t choose your technology implementation well, you could slow it down. But it would take a lot to be noticeable vs the database calls or the internet hop costs themselves.
Hope that helps.
I really have to remember to uncheck that highlight box. Its very annoying.