Tuesday, August 23, 2005

Tenets of SOA

Last time we discussed some points about SOA. We analyzed what SOA really is from a laymans perspective. Today if you start you browser and search (obviously Google) for SOA, you will be inundated by numerous results. You just skim through some links or papers on SOA, and you will find yourself totally lost. Everybody who is in market of SOA and having some kind of product to support is, has his own definition and terms for SOA. So when already there are so many definitions, let me also make my own stance. Because I am not a big think tank who can propagate his own definition, so I will re-iterate Microsofts definition of SOA. Now you will ask, why only Microsoft. It is because, any way we are going to use Microsoft technologies (i.e. Indigo) so why not to follow what Microsoft says.

Backbone of SOA is Service. Service may be any thing from A-Z that provides any kind of Service to Consumers. Now what is this alien thing Service is? Service is a program you interact via message exchange. Another buzz word, Message? Message is any kind of data that is sent to a Service. You send some data to Service in form of Message and Service replies with result set in form of another message. Whenever you try to build up some kind of framework, you have to define the guidelines, you have to lay down some definition to recognize what comes under such framework and what not. When proposing SO (Service Orientation) to its developer camps, Microsoft laid out following four doctrines (MS says them as tenets):
1. Boundaries are Explicit
2. Services are Autonomous
3. Services share schema and contract, not class
4. Service compatibility is determined based on policy

Now some work of Ctrl-C and Ctrl-V. Richard Turner, Program Manager in Indigo team, explains these four doctrines in following way:

1) Services have explicit boundaries, that services, the only way to interact with a service or to obtain information or modify the state of the service is via the technology exposed in its out-of-boundary edge.
2) Services are autonomous. And what this means is that if I was to build an application that consumed a service that was outside of my boundary of control then I would not expect the service at the other end to implement its functionality in any particular way or manner. I wouldnt be able to influence it in any other way. I wont be able to connect my SQL Server database to directly to the SQL Server database or Oracle database or whichever inside the remote service. Im simply talking to that service through its boundary and it also automatically enforces an isolation layer between our two services. This allows us them to construct very flexible, very de-coupled applications.
3) Services share schema and contract, not class.And more accurately maybe, not objects. Services are about passing information back and forth between two entities such that those entities can communicate in a common fashion. This is not about remoting an object that actually runs on a service remote from me and controlling it from my environment because the other service maybe running on a platform completely different to mine and I may not have knowledge as to how to affect that component and how it runs in that environment. So services are all about passing information back and forth passed by a value if you will, or ratherthan by reference.
4) Services interoperate based on policy.And the policy can be information such as, for example, as a service if you want to speak to me you must support some kind of security mechanism. Or you must support TCP as a transport protocol. Orthat you must support transactions, for example. Now some of those capabilities are available today through things like COM+ or Enterprise Services in that I can mark a component as requiring transactions and if I state that transactions are required youmust interoperate with me using transactions fully supported through DTC. This isnt necessarily fully available through all technologies however and were working to make this a reality in the near future.

Are you still there or disappeared? I am re-iterating that this was not my explanation. Ok, let me create my own explanation. Do you like pizza? How many times a week you call for a pizza? Come, well try to understand these four tenets through pizza delivery process.

1) Services have explicit boundaries: There is no specific technical definition for this tenet. Lets try to understand it this way; you called up pizza corner in kormangala, but you stay in Jayanagar. When you tell pizza corner that you are calling from Jayanagar and wants pizza to be delivered there, then pizza corner representative may divert your call to Jayanagar branch or may express his inability to deliver pizza to there door step. Why so? He cant, because cost of delivering pizza from kormangala to jayanagar will exceed his benefit. The same lies with Services. Any service has its own boundary and it is assumed to be expensive to traverse.To balance this behavior service calls should chunky not chatty. Based on you should decide on what can be made as Service? Whether it would be a good candidate to make it as service? Does it do some good amount of processing that will equate the expense occurred due to traversing across boundary? At this point, we can alter first tenet of SOA to Services have explicit boundaries and are assumed to be expensive to traverse in order to make it more understandable and expressive.
2) Services are autonomous (I do, what I need to do): This is quite easy to understand. This means, I should not bother how one particular service did its job. My job is to just pass a messageand get back a message. I have explained it earlier also a bit. Suppose today pizza corner has only one phone line to receive your orders. But it doesnt matter to you. Right? Tomorrow due to satisfy he increases the no. of phone lines through internal extension or whatever for that sake. This way you are decoupled from implementation of this component or say service. Now that service may gradually enhance its implementation, but it doesnt affect you by any means. This is one beauty of Service Orientation.
3) Services share schema and contract not class: Again come pizza corner. They let you know what kind of pizzas do they have and how many people that particular pizza serves up to. This is your schema that what kind of pizza do they have. Based on this you decide whether to continue your talk further or not? Same way you will decide based on particular services schema, whether it is useful to you or not? Telephone no. of pizza corner is the contract between you and their service. Service says, you call me on such and such no. and I will let you know my services, yet it doesnt give you out its implementation.
4) Services interoperate based on policy: This is the last point. You may be well versed with this. Have you noticed that after taking your order for pizza that pizza corner girl asks you, Sir, would you like to pay cash or through card? This is policy. In case of pizza corner, human factor and hospitality is coming into picture that is why they asked about policy at the last. But in case of accessing any service both the points have to come to one consent that how they will talk to each other.Whether they will talk over TCP or HTTP? Whether their will be any kind of security implementation like handshaking or other kind of security implementation. These are the policies.

Hope due to this pizza corner example, I didnt worsen the situation. Happy journey to Service Orientation!

PS: Here is one good article on Service Orientation. No camping, nothing. In my openion it's a must read on SO: http://www.oracle.com/technology/oramag/oracle/05-may/o35design.html

Saturday, August 06, 2005

Little about SOA

You can say SOA is Service Oriented Architecture. But question comes is what is this Service Oriented or Service Orientation? I am not going to take you to any technical details here. We will simply discuss what can be service oriented environment. Service orientation is a means of building distributed computing system. At its most abstract service orientation views everything from a mainframe system to the printer to the clerk at RTO office to the shipping company - as a service provider. Service provider expose their capabilities through interfaces. Service Oriented Architecture maps all these capabilities and interfaces so that they can be orchestrated in a process. The key factor of service oriented model is the separation between interface and implementation. The invoker of service need not (or should not) know implementation. Invoker just has to understand the interface provided. Over the period of time implementation can evolve. For example - Citibank provides you with number of their call center. It is a service according to service orientation. You dial the number and receive the service. You need not to bother whether they use EPBAX system within the system or some other method. You need not to know whether 10 people are their to attend your call or 101. This loose coupling between interface and implementation gives freedom to implementor to change implementation (no. of people attending the call) at any time and retain the compatibility as long as interface (in this case phone number of call center) is not changed. Ok at this point you know what Service Orientation is. But what is it good for?

Ok, take a case with egg. To a farmer it would turn out to be a chicken. A cook might see it as omelet. A little kid may foresee one vibrant easter decoration. So, service orientation is an egg.

To developers and architects it could turn out to be a mans for creating dynamic collaborative system. Service orientation allows them to pick up specific capabilities and lay them down to make one system. To the IT manager it can be a means to effectively integrate the capabilities of different system to make one much better system. To CIO it may be a way to save organization investment on different system over a period of time. By encapsulating a business application behind capability-based interface the service model provides controlled access to mission critical application. To the business analyst service orientation is a means of bringing technological investment more in line with business needs.

Here I have just touched the generic view of SOA (much hyped word and everybody wants to have it now a days). I didn't go into any technical depth here. It was a layman's definition to SOA. You can try on your own to find out how big shots may describe service orientation (long live Google). You will find that every body is busy touting SOA according to their benefit. Will see how we can escape through this and learn some good points about SOA.

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.