SOA is different from DOA

I cannot produce all that I need myself. Therefore, I rely on others for many things. I buy milk and bread from my grocer, newspaper from the newspaper agency close by, cooking gas from the Bharat Gas retailers and so on. In addition, I book my travel tickets through my travel agent, pay taxes through my accountant and visit my doctor when I fall ill.

It is very interesting to see the mechanism in which all these day-to-day activities progress. My cooking gas connection is distinctly different from the other services I avail of. I have a contract with the gas retailer. My retailer has handed me a gas regulator and a cylinder, the latter he promises to refill, the former I promise to preserve till I require his services. This contract is a tight relationship between me and my retailer. It is not easy to shift my gas connection from one retailer to other.

On the contrary, I can easily change my grocer, my travel agent or my accountant (changing my doctor often is not advisable) and we do not keep any entity such as the gas regulator to bind us tightly. Most of these service providers do have a substantial information about me, which they maintain on their own accord, but this is very different from a contract that says “I buy from you and you alone”. Nevertheless, these services still function efficiently since I fill out the required forms and my agents know how to interpret these forms. In the real world, these form exchange may be often verbal as is the case with the grocer or the newspaper  man.

By taking real world analogies, I have tried to establish that there are two models of interactions. Real businesses are not unlike these daily chores when we think about interactions. Businesses also depend on others for services, and frequently fill out forms to access such services. With computers proliferating the business, these interactions can be easily made machine to machine. Which of the two models of interactions will businesses prefer?

Distributed Objects Architecture

Closely related to the gas retailer model, we have the distributed objects architecture. Here, a machine belonging to one business will avail of services provided by the other by referencing objects from the other business’s interface. It will invoke a set of methods and gets its work done. To operate properly, this mechanism requires the “service user” to know what objects are exposed by the “service provider”. When accessed, the service provider must create these objects for its customer and execute the instructions given by the customer. The degree of interaction is such that effectively the customer gets the work done by micromanaging the object on the provider’s premises. Both the service user and the service provider would not want this. Consider for example a telecom company that uses the services of a retailer to ship handsets to its customers. If these two companies use a distributed objects architecture, the telecom company will have to establish an object reference with the handset retailer and maintain this reference till the transaction was complete (which can be several days). The handset retailer’s machine will have to maintain a real object all this time. Very few interactions really took place, but the object occupied memory on both machines for the entire duration of the transaction. Tight coupling and micromanaging is definitely not a good option for this type of requirement.

This model also assumes a lot of trust. The retailer exposed its interfaces, it maintained all the objects that the telcom company requested and executed the service required because it had a predefined contract with the telcom company (and also possibly wrote the entire application in a programming language that was previously agreed upon). When we are going to this length of coupling, there better be multiple interactions between the two entities, or else, all this was wasteful. This also implies that the telcom company cannot change its retailer overnight. It has to painstakingly negotiate a new protocol with the new retailer before its services can be availed of.

Since the service user was supposed to micromanage the provider, the user’s thread was blocked. It performed synchronous communication with the provider and spent lot of time waiting either for the provider to return a result or in establishing network connections with the array of objects it required. Everything had to suddenly also be tolerable to network disruptions; an entity that is neither controlled nor owned by the parties involved.

We have highlighted the following fallacies with the use of Distributed Objects Architecture:

1. Tight coupling and micromanaging objects leads to unnecessary reservation of resources.
2. Synchronous calls leads to blocking of execution control.
3. Elevated amounts of predefined contracts and trust needed.
4. Tolerance to network issues.
5. Possible constraints on the use of programming language.

Service Oriented Architecture

Coming closer to how services work in the real world, if we have a mechanism in which I ask for a service and then the service calls me back when done, we may find answers to the problems we face with distributed objects. To make the coupling loose, I would no more hold a reference to an entity belonging to someone else. The service user would rather send to the provider the entire set of requirements, maybe through a form of some kind and go ahead with other activities. We now need the two entities to understand only the forms that they exchange. The service user could avail of similar services from multiple providers simultaneously without being bound in a one-to-one contract with one provider. Of course, all the entities involved will still need to understand the same form, but that is much better than having to build applications in the same programming language!

In service oriented architecture, we expect the service users and the service providers to exchange documents in an universally understandable format. Implementation of the service can be done, after interpreting the document, in any language that the service provider deems fit. This more natural way of functioning paints a pleasant picture. We can now achieve loose coupling (no maintaining of each other’s entities), dynamic binding (freedom of selection of the service provider (with only the constraint that the new service provider also understands the document format)), asynchronous communication (no blocking for the code to return from a remote call), and independence of programming languages (you like Java, I like C and he likes Python)!

Caution

It is easy to be thrilled about this new technology. After all, it gave us all that we craved for. But surely there must be a downside. Yes, there is. I once read in a software engineering text how a team that had jelled together could get much more work done through much less formal interaction than  a team that was yet to jell. When I explain a concept to one of my old friends, I do not have to explain much. They understand more quickly than a new colleague. It is as if I have an unwritten protocol with my friends (they understand my body language, my usage of certain words, and my tone) that allows me to skip many verbosities in communication while explaining something to them. On the other hand, I have to mention all disclaimers, all auxiliary details to a new colleague. This is exactly what is happening in the document exchange mechanism in SOA. Both sides have to continually parse documents. The format of the document is fixed. These are much less optimizations possible. The telcom company in the above example may request the retailer to provision a thousand mobile phones per month and only a few broadband ADSL modems, but still, it has to use the complete document specification and the provider has to parse this entire document every time.

I am only raising a word of caution that SOA is not a silver bullet. There might be instances when DOA or some other mechanism is more suitable than SOA.

Conclusion

SOA is definitely different from distributed objects. Its underlying philosophy is different and, I feel, it is more human-centric than distributed objects. For most scenarios to which DOA is a solution, SOA offers a better, much simplified alternative. Documents prepared in universally accepted formats, such as the XML, allows us to overcome many of the shortcomings or awkwardness of distributed objects. Nevertheless, we must remember that there might be instances when SOA is not really the way to proceed–it is not a silver bullet.

Advertisement

Tags: distributed objects architecture, DOA, service oriented architecture, SOA