Removing the intimacy to create services

Ram is back from vacation has been blogging on the subject of SOA and OO.


While I agree with option C in Ram’s post, some of his comments took me back to the PDC talk where Don was explaining the difference between a service and an object.  One of his observations that resonated with me was that ‘services help remove the intimacy’ from distributed computing.  For those who didn’t see the talk, here’s my extended and modified analogy from this:


Imagine two entities, A and B.  A wants to borrow $5 from B in good faith.  A plans to return the money to B by the end of the day.


If these two entities were objects, the interaction may look like this: 


A walks up to B, goes into B’s pocket, promptly removes his wallet and the $5.  After he has the money, A leaves.  B is left wondering ‘Hey, what happened?  I was robbed!’  B doesn’t know if and when he’ll see his money again.


In this case, the interaction between A and B in the object world is very intimate.  B can of course use security to prevent A taking the money, but in general there is little to do to remove the intimacy of the interaction.  


To think like a service, you have to remove this intimacy.  One of the easiest ways to do this is to think about how a similar interaction would take place in the real world.  Going up to another person and trying to forcibly remove cash from their wallet in this way is likely to end you up in some trouble.  Instead, the interaction in the real world (and the model that we can adopt for a more service based approach) looks like this:


Again, A wants to borrow $5 from B in good faith. 


A walks up to B and asks ‘Hey, can I borrow $5?  I forgot my ATM card and need to buy lunch’.


B wants some reassurance about A.  B takes a quick look at A.  Assuming no breakthroughs in human cloning, B decides he can trust A as he has had previous interactions, and A still looks and sounds the same.   Despite this, B wants some validation that his money is going to be returned.


‘When will I get my money back?’ B enquires.


‘I’ll have it back to you by the end of the day, plus an extra $1 for your trouble’.                                        


B accepts the proposal, opens his wallet and gives A the $5.  The interaction is concluded and A walks away happy.


Although a simple analogy, I’ve found that removing the intimacy and thinking about how the interaction could occur in the real world can really help when defining services – and more importantly the types of interfaces that services expose.  Even if the technology promotes a service orientated approach, it’s this type of shift in thinking that helps define true services as opposed to merely exposing objects.



Comments (7)

  1. Christian Weyer: Web Services says:
  2. ramkoth says:

    Nice example that illustrates the ‘spritual’ difference between SOA and OO. SOA is all about autonomous and often non-trusting services interacting with each other to automate certain business capability.

  3. John says:

    I don’t really see a difference with the principle of data hiding in OO and the use of method invocation with the use of messages. Can you enlight me?

  4. I don’t know about you, but I consider my pockets private and generally don’t let other folks into them. Instead someone needs to ask me to borrow money, and even then I won’t appreciate their reaching into my pocket. I’ll get it for them. But, there’s an implicit contract in place in that I expect them to pay be back in a reasonable time frame. Maybe there’s a point about implicitly vs. explicitly defining the process of borrowing money?

Skip to main content