Against the usage of "logical" and "phisical"

Once upon a time, the terms "logical" and "physical" meant something absolute, at least in specific contexts inside IT. In databases, the physical layer was the actual files and other containers of data, while the logical one was the fields and records immediately on top of them. In networks, the physical layer was the actual wire, and logical referred to the protocol governing the actual bits sent over it.

But nowadays, when there are so many layers in any IT system, the terms physical and logical have lost these absolute position and have only a relative meaning. Logical means just "less detailed", (i.e. abstracting some details out), and physical means just "more detailed" (i.e. with more concrete details). Nowadays, something termed as logical (or physical) in a context is just the physical (or logical) layer of another context.

Thus, when any of these is used without a reference (e.g. "the logical layer" or "a physical diagram"), in many cases the communication is difficulted because the person saying them may have one idea of what they mean, while the others may well have a different one. Then, misunderstanding comes and also time wasted realizing it and trying to sort it out.

Because of this I advocate to either using them only in a relative way (e.g. "this is a logical view of this"), or even better not to use them at all, and using instead other clearer terms.

soapUI: a very good tool for invoking and testing web services

Today I have known of a very good open source tool to work with SOAP web services: soapUI. It isa kind of small IDE which allows to define web services out of its WSDL, generate sample requests,send them to the services (including attachments), perform functional or load testing, WS-I validations,and other operations from other tools it integrates with, like TCPMon, Axis, GSoap or .Net, likegenerating stubs and deployment descriptors.

I would have liked to know it before, but it is better late than never. More information: http://www.soapui.org/.

BEA microService Architecture (mSA)

When I saw the announcement of the future SOA 360 product initiative from BEA I focused on the Workspace 360 idea, which sounds nice (I think the SOA killer application will be something allowing Excel-capable users to compose applications and services). But I overlooked the microService Architecture (mSA). And it looks very interesting, too.

For start, it seems to be a SOA not based on a central ESB, as popular in software vendors and as it was now with BEA. It looks more like Jini, but based in OSGi. It is a federation of containers of small services, which discover and communicate between them dynamically. It seems to follow the view of SOA as a galaxy of free services, instead of having them orbiting around a central broker. They talk about "infrastructure services" providing composite service capabilities, but this does not look like a central ESB anyway.

The services are Java or bound with Java, but I guess they will be able to interoperate with others at least by WS-* . mSA seems mostly protocol-agnostic, so it should support both WS-* and other (I do not see the point of being more abstract than WS-*, but OK, many people does).

I am curious to see which will be the method to discover services, and how will they handle the actual communication. We'll see.

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.

IBM has abandoned UDDI

One of the original proposers of UDDI, has in fact abandoned it. I have read in IBM people blogs that UDDI will be superseded. In the some 5 papers I have seen about its upcoming Websphere Registry and Repository, I have seen no mention of it. And this later paper about "Web service standards for Service Registry and Repository" confirms this: they mention UDDI, but only as some kind of legacy technology than, if cannot be superseded, has to be kept along with the Service Registry and Repository.

I do not know what happened to UDDI. Since the start, very few people used it. I agree in that it has several clumsy things and several other things that have yet to be added to it, but I think it deserved better destiny.

Now that I come to it, while UDDI was for service registries, WebDAV was for document repositories and it has come to a similar fate. Few people use it and many loath it.

At any rate, some standard way of accessing a registry and repository is badly needed in SOAs, and I reckon also for a service WWW. So something will come up, I guess. We'll see.

The legacy ESB

3-5 years in the future from now on, many companies who thought that they bought a SOA by buying an ESB will be faced with the issue of buying some new infrastructure, maybe a new ESB, packed with new features. But they won't want to replace their old one, full of cranky old orchestrations who nobody in the corporation does any more how were done and that nobody want to touch because they just work...

Then the company will realize that they will have a legacy ESB. And if they buy something new, it will run just as fine, being integrated in the new infrastructure. Hopefully they will learn, then, that the ESB is not the center of a SOA at all, but just another provider of services, just as so many other things in a SOA.

The typical three-tier SOA (legacy-orchestration-frontend) is not a reference Service-Oriented Architecture; it is just a way of building integration services / applications.

SOA and reuse

There seems to be a debate about the true extent of reuse in SOAs. E.g. David Chappel, Joe McKendrick, or Theo Beack have blogged about it.

I think that inside an organization reuse is perfectly possible, because in many cases there is only a single context. E.g. inside of a company there should be room for only one logic for a Purchase_Order_service.

The problem for reuse is across a large market of organizations, or for larger organizations with different context. E.g. to be able to buy a "generic" Purchase_Order_service and adapt it for your context.

Theo Beack says that "the context should be elevated to the process layer and NOT encapsulated within the service". But I think this would result in services doing tasks of very limited usefulness, since the actually valuable business logic would be inside business processes, which would create the context by linking services. One can envision these business processes being traded across companies (the context changing thanks to using different services), but I think there is not yet a framework for this. But one for services is emerging, so it may be better to use it.

I think that the key to reuse may be to factor out funcionality as much as possible: create many small services doing concrete things, and relying themselves on other small services. Then all these small services can have a particular implementation inside a particular context. E.g. Purchase_Order_service would rely on Product, Customer, Invoicing etc services which would be specific for the context of an organization. Interface-oriented design is key to this.

This would make services to depend on other services, resulting in more thigt-coupled services, but in exchange they would deliver much more business value than isolated services.