Technology Thoughts

Tuesday, November 07, 2006

The different levels of Service-Oriented Architectures

Yesterday I sent a message to the Service-Orientated-Architecture group of which I am still fond of, so I think it is worth to be published also here.

Key to any SOA is the Service Model - i.e. which services exist, what for, and which interfaces do they have. Indeed this is what most often is called "architectural design", which is key to the success of any information system, assigning responsabilities to parts of the system.

But to really have a running system these services must be deployed into something, which completes the architecture. And also SOA is more than the services; it is also the infrastructure surrounding them.

Without a defined architectural framework there is no real interoperability, which is the basis of the reuse, agility et al touted for SOAs. To make services work you need of some infrastructure for things like discovery, communications (both synchronous and otherwise), management, etc. I.e. the gap originally addressed by SOAP, WSDL and UDDI and being now incrementally filled by WS-*. For SOAs not based on web services, similar things must exist first in order to lay the ground for reuse in practice.

I think there are three levels of architectural detail in any SOA:
  1. The basic one shared by every SOA, i.e.: there are services (implementing the business/domain functionality without user interface) and applications (without business/domain functionality at all, but with user interface).

    I think there is a general agreement at least about these basics, although there may be still discussions on whether applications and services can invoke other services, or this is allowed only to ESBs (which would then be the third element of the basic architecture, of course). Or whether there is a need of a directory (e.g. UDDI) in order to consumers to locate services.

  2. The level addressed by the assorted Reference Architectures used nowadays by different software vendors, involving elements like "legacy services", "service buses" or "registries". There is some degree of convergence here but no consensus yet, at all.

  3. The concrete architecture of a particular running SOA which details what and which are these legacy services, buses or whatever, if any.
To have a running SOA you must first make a decision about the three levels, and this is architecture, because Service Models do not execute.


Post a Comment

Links to this post:

Create a Link

<< Home

Weblog Commenting and Trackback by