Archive for March, 2006

Services vs Web Services

March 31, 2006 1 comment
A comon misconception¬† is that SOA == Web Services or Services == Web Services. As clemens puts it, Web Services provide the P, E & CE of PEACE. If we design a web service with A then it becomes a Service. So simple isin’t it. Provided you understand Autonomy ūüėČ
Categories: Architecture

SOA Tenets – Contract Exchange

March 31, 2006 1 comment
Services exchange Schema and Contract. This one is easier to grasp like the Policy based negotiation one. Services could be implemented and a variety of platforms and consumed in a varierty of platforms. So when it comes to sharing the contract or the data to be exchanged between them, which "type system" should one use.
Type System??? Should it be the Provider’s or should it be the Requester’s? Should it be System.DateTime or should it java.Utils.Calendar.
SOA means that use contracts and schmea instead of assemblies / types etc. WSDL / XSD help in this area. 
Categories: Architecture

SOA Tenets – Service are autonomous

March 31, 2006 1 comment
  • Services should be deployed, managed and versioned independently of other services and / or applications that depend upon them.¬†
  • Services should not trust any incoming messages. All messages should be validated for integrity and appropriate credentials.
  • High availability of services should be ensured using a fully redundant network infrastructure that supports automatic failover etc.¬†
  • Careful consideration for capacity planning should be made to ensure appropriate provisioning of resources necessary to support services.
  • Services expect that the consuming application can fail without notice and often without any notification. To maintain system integrity techniques such as transactions, durable queues, and redundant deployment and failover should be utilized. (The same applies to services used by the service as well)
Does Autonomy mean that a service should never depend on other service (Isolated). The very idea of services is colloboration, this tenet seems to contradict it. But actually it doesn’t
Turner says it all here:
Say a service that you use is down, you should be able to use an alternate service which could do the job for you. Or you could queue the requests till the service is up etc. In other as Truner puts it "services wont be welded together, they are better of if they are plugged together".
Categories: Architecture

SOA Tenets – Service Boundaries are Explicit

March 31, 2006 1 comment
Well this one is slightly harder to understand, anyway here is my take:
One interpretation is, Crossing service boundaries may be costly, depending upon geographic, trust, or execution factors. This is mainly due to
  • The physical location of the targeted service may be an unknown factor.
  • Security and trust models are likely to change with each boundary crossing.
  • Marshalling and casting of data between a service’s public and private representations may require reliance upon additional resources‚ÄĒsome of which may be external to the service itself.
  • While services are built to last, service configurations are built to change. This fact implies that a reliable service may suddenly experience performance degradations due to network reconfigurations or migration to another physical location.
  • Service consumers are generally unaware of how private, internal processes have been implemented. The consumer of a given service has limited control over the performance of the service being consumed.

Since crossing service boundaries is explicit, services should make this explicit by using messages for communication instead of trying to hide the boudary crossing by imitating a distributed RPC. RMI, Remoting, DCOM take the later route.

A message style communication looks like this (via Rich Turner):

Channel chan = new ChannelFactory.CreateChannel(endpointAddress);
ActionInvocationMessage msg = new ActionInvocationMessage();
msg.Action = "SayHello";
msg.Parameters.Add(new StringParameter("Forename", "Rich"));
msg.Parameters.Add(new StringParameter("Surname", "Turner"));
Console.WriteLine(chan.SendMessageSync(msg, new SayHelloCallback(HandleResponse)));

An RPC Style communication looks like this:

HelloWorldProxy proxy = new HelloWorldProxy(endpointAddress);
Console.WriteLine(proxy.SayHello("Rich", "Turner"));

Obviously a hello world doesn’t need to be a service and hence the messaging style communication looks awkward. But you should understand explicit message passing now ūüėČ

A corrollary to this tenet or another interpretation of the tenet is "A service with well defined boundaries should provide no visibility to the internal implementation of the service. This allows a services implementation to be versioned without breaking external systems."

For Example "Service implementation details such as internal database row identifiers commonly found within a dataset should not leak outside the boundary of the service. "

More stuff here:

Categories: Architecture

SOA Tenets – Policy based negotiation

March 31, 2006 1 comment
Today as you develop components which are going to used by others lot of the assumptions are implicit or they communicated by out of the band techniques.
Suppose your component requires Kerberos authentication it is an implicit assumption most of the times.
Or in most of the cases it is spread through the word of the mouth or stated some where in the documentation.
Say your app server exposing the components is down today midnight 12:00 till tomorrow morning 12:30 AM, you probably send out an e-Mail to the users of the component stating the fact. This works if you are using the component within the organization and you know all the users of your component.
If your service is hosted on the WWW and you don’t know who the hell is using it. How do you communicate such an information to all the users of the service. How do you make it clear to the service users that your service requires Kerberos authentication tickets.
These need to be negotiated using standard means if you are thinking services.
WS-Policy* specs are trying to fill this void.
WSPL by OASIS and WSDL 2.0 Properties and Features are other approaches to fill the void. Soon the Service community will converge on to a single standard.
So WS-Policy helps the Service Provider and the Requester to negotiate stuff like:
  • The endpoint is down for maintenance each Sunday morning from midnight until 2:00 AM.
  • Orders must be received within 30 minutes of their timestamp. Orders delayed in transmission more than 30 minutes will be discarded, and the application may return a Fault.
  • US dollars and euros are the currencies supported by the service.

Hope this makes the ‘P’ of PEACE clear. Bye till we talk about the ‘E’ in the PEACE.

Categories: Architecture

SOA Tenets

March 31, 2006 1 comment
The core tenets of OOP are
Likewise the core Tenets of SOA are
Policy based negotiation
Explictness of service boundaries
Autonomous services
Contract Exchange
PEACE – Easy to remember. The PEACE acronym was coined by Clemens.
We’ll see each these tenets in the coming entries.
Categories: Architecture

SOA, The next stage in the evolution

March 31, 2006 8 comments
Well SOA is one topic which you cannot keep away from long enough, if you are blogging on technology.
SOA is a natural evolution in the mainstream development.
Early days: When systems were seldom connected and used to function in isolation
Ad Hoc programming
Structured Programming
Object Oriented Programming
And then:
When systems were connected through LANs and applications used to colloborate within organization boundaries. The systems made a lot of assumptions about each other. Most these assumptions were implied and not stated explicitly.
Component Based Programming – MTS/COM+, EJB etc
The future:
When systems are connected through the WWW and aplications colloborate across orgranization boundaries, It is natural that Services hit the mainstream.
Service Oriented Architetcure:
Service Oriented Architecture is an architectural style which provides the ability to provide functionality in the form of services. These services communicate by messages and contracts, and implement business functionality, policy and hold state.
Well that’s so abstract isn’t it. We’ll refine this as we go along.
The SOA shift was explained by Don Box using a very simple example. Simon Guest has blogged Don Box’s words in a nice blog entry. Instead of going through it all over again, lemme just link to it.
So SOA is all about removing the intimacy between systems and  making assumptions and boundaries explicit.
Categories: Architecture