Saturday, August 06, 2005

Motivation behind Indigo and Service Orientation

Hello Friends, after a long hibernation I am back. Some time back I had promised about delivering content on services and Indigo. So now you should expect some good amount of content on services. This one is going to be on making of Indigo.

At this point I can expect one question from you. Why another technology from Microsoft with yet another fancy name? To describe the necessity of Indigo I would like to take you to early days of programming. Code-Reuseis a holy grail of software development. Even when people used to code in assembly, they were inclined towards code reuse. Jump statements used to accomplish code reuse. However this reuse is enough to make your code hard to maintain and gibberish. Thencame the age of procedural programming where emphasis was on reusing procedures. Did it make any good for business? It was pure code level reuse and it has nothing to do with business aspect of software. After this in 1980s object revolution came. It forced each and every developer to see his software piece as an object. It was great to think every noun in your software as an object, an object that has some properties, some functions, some private data and some public data to share with outside world. Encapsulation provided some way to create boundaries in your system. But it was very hard to maintain and needed religious OO developers.

In 1990s flaws of object oriented software development became clear. Objects were good to be reused within one application. But how another application can use object sitting inside one other application? Was it a trivial job? Object oriented programming relied totally on implementation inheritance and behavioral polymorphism as extensibility points. When developers tried to use these technologies to extend the functionality of existing system, they got interrelated type hierarchies those were tough to maintain and understand. Moreover from business perspective it was not adding any value. You can not have specific functionality of one application, being used by another application.From DLLs point of view, you had to share some kind of metadata (in form of C++ header files). Another point is cross library calling convention is still not standardized. DLL compiled through Microsoft C++ will not be callable in Borland C++ compiler. By 1990s it was clear that even objects are not the solution to the problem of code reuse. This gave the rise to Component Oriented technologies like OLE, COM and JavaBeans in the early 1990s.

Goal of component oriented software was simple: provide the common infrastructure to make binary object possible in general case.Fundamental behind COM is to provide one standard way so that component can be reused and be treated as object. Though COM is just the standard, the way a software piece should be developed, it was long time job of only and only C++ programmer. Later VB closed that gap and COM became one of the most successful technology out of Microsoft.Over the invasion of internet to normal persons life by mid 90s, COM became on hulk. At this moment enhancement like DCOM and some other similar solutions like CORBA and Java RMI came into picture. All of them shared a simple concept of invocating a method against a local object and stretch it across networks. Theoretically it sounds good but in actual life it turned out as a big flaw. The premise that local method invocation isnt all that different from remote method invocation gave rise to the great fallacy of distributed components: location transparency.

The idea of location transparency proved one fact that theory is very different than practical aspects. For example-
   foreach(User user in userCollection)
   {
      
Process user
   }

In theory it doesnt matter at all where userCollection is lying locally or in a remote machine. But in practice it was felt that location awareness is necessary. For instance think that code that is executing this loop is in Bangalore and userCollection is on a slow network in Mysore. Suddenly this turns out to be a nightmare. If this was the only technology problem, it could be solved out by employing better technology at place. Other issues were security and reliable messaging. How will you make sure that the other end whom you are communicating with is a reliable one? How will you make sure that message you sent to other end reached successfully? Efforts to solve these problems came into picture and paradigm sifted from Object orientation to Service orientation. Service orientation is all about passing message to a distant entity and let that entity to process it locally at its end and passing back the result back in form of another message. Service orientation is about composing loosely-couple entities to make complex distributed systems. It uses message-passing as its core metaphor and is implemented using standardized set of interoperable technologies:
  • A common data model (XML Infosets)

  • A common message format (SOAP)

  • A common way of describing message contents (XSD)

  • A common way of describing behavioral capability (WSDL)

  • A common way of describing infrastructure (WS-Policy)

So does this mean that Indigo solves all these issues with regard to code reuse and building complex system that can be used by business? Does this mean that employing Indigo gives you service orientated system? Even after all this preaching, what is Indigo all about? Hmmm, let me first think over first two questions. Meanwhile we can continue our journey to know Service Orientation in a better manner and then I will let you know what this new animal on planet "Indigo" is.

No comments: