WebServices are just an implementation of SOA

I am guilty. Too often I equate a WebService and its implementation with the overall definition of SOA. (For example here). In reality it is nothing more then an implementation. A good implementation, but just an implementation. Clemens Vasters gave a nice definition of the tenets of SOA called PEACE.

  • Policy-Based Behavior Negotiation
  • Explicitness of Boundaries
  • Autonomy
  • Contract Exchange

    • It is a nice acronym that attempts to summarize exactly what a service is. Much like ACID does for transations (Atomic, Consistent, Isolated and Durable...). There is some debate about this ACRONYM, but it is fair to say that most if not all agree with the 4 basic tenets...

    However, nothing in this definition speaks to platform independence. Does this mean that distributed system design and some of their implementations (e.g. think DCOM/CORBA/RMI/Remoting) and their platform dependence mean are OR are NOT SOA. They are. All these implementations do follow these tenets. I am not an RMI/CORBA expert but I did worked extensively with DCOM in a prior life. It did allow you to work in a more OO manner then a WebServices implementation. There were rules especially around transactions and how the state of your object could be affected, but you could do it. However, it's Contract followed a binary format that was not readily understood by other platforms. RMI had a similar flaw only working with the Java language.

    A WebService on the other hand is platform and language independent. It's use of Xml enables different platforms to communicate with one another. Additionally, a WebService is very procedural in nature. Some have argued that they are object based. Or that because methods are verbs they act as objects. Personally, I don't buy it...however, in the grand scheme of things this is more an argument of semantics.... Given that, there are also a number of rules about how client proxies are generated and this does effect how you construct your tiers. I discuss this here (same blog entry reference as above).

    In the end, I am guilty of confusing terms. A WebService is just an implementation of SOA. It is not the only implementation.

    -Mathew C. Nolton

    2 Comments

    • one way I think about this is to look at other stuff on the net and ask the question:



      Is this a Service? does it play well with different callers?



      examples of some forms of very common SOA:



      HTTP

      SMTP

      POP3

      DNS

      FTP

      IRC



      why them?



      the take requests and retrun a message.

      they have a standard format for the request and the reply.

      they work accross diffing systems.

      they tend to scale well for large numbers of clients / requests.



      so when someone says to me that SOA is new; not well known; it's a Microsoft thing etc....

      I describe what a "Service accross the network" is is general terms and then show them that the internet *IS* one big SOA we use everyday and we just got around to describing the thing better.

    • Agreed.



      I am just trying to add voice to the fact that SOA does not always mean a WebService implementation and that we use the term flippantly and we shouldn't.



      I don't agree with saying it requires scaleability to be a service. Good programming and system design requires this...but I don't agree that it be a defining attribute of a Service.



      -Mathew Nolton

    Comments have been disabled for this content.