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 :-) ? 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 you liked the pizza corner example :-), Happy journey to Service Orientation!
Useful links:
http://msdn.microsoft.com/msdnmag/issues/04/01/Indigo/default.aspx
Regards, ~Neville (http://nevilledubash.blogspot.com/)
No comments:
Post a Comment