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.