Enterprise integration in your daily life…

Saturday, October 20, 2007

I was reading an old post by Simon Guest about removing the intimacy to create services and thought he had a great analogy comparing real life to SOA solutions.  I love these types of posts because they provide concrete examples which explain system interactions in a straightforward manner.  Gregor Hohpe posted something similar to this in Starbucks Does Not Use Two-Phase Commit post.  It’s a great read. 

I would like to take Simon’s post a few steps further.  Continuing on his example, let’s add a few more features such as:

1.  Message Correlation
2.  Message Expiration
3.  Concurrent Orchestration
4.  Policy-based security

When person A approaches person B to borrow $5, B must first make sure that he (1) knows who A is and (2) can trust A with this transaction.  Even though A looks like who he says he is, and he even knows B’s name and address, B has a strict “policy” that A must provide a state-issued ID (federated security) which B scans into his security manager to verify A’s identity. 

After his identity has been verified, B looks up A’s record and current outstanding balance.  B will check if his business rule stating that no one person can have an outstanding balance of more than $100 has been violated (business rules engine).  A promises to return B’s money in 7 days and that’s fine with B’s business rule. 

In B’s orchestration engine (his brain), he creates a new long running transaction where he listens, waiting for A to return his money, on or before today + 7 days.  He creates an alert in his process manager (his Blackberry) to send himself and person A an alert if he has not received the “money returned” message by that day.  If no message comes in by this time, a new process will be instantiated to mitigate the situation (the sendTonyToBreakLegs process) which receives a violatingEntityIdentifier message as its input message.

B is a very generous guy and let’s a lot of people borrow money.  He may have several long running transactions going on at any given time. In fact, person A could be going through some hard times and may have borrowed money several days in a row.  Each transaction is assigned a unique value so that when A starts paying back, he can start applying it the one closest to expiring.

When you look at daily life, it’s really one big integration project.  Orchestration, coordination, services, long-running transactions and asynchronous operations are all around us.  How well individuals deal with it is largely dependent on individual’s internal processing engines as well as accessibility to tools that specialize in the management of these processes (Blackberry, Outlook etc).

Leave a Reply