Web services vs. Business Component Specification

The use of web services is still growing fast. This isn’t very strange because the use of web services could have a lot advantages. If you read the websites of big vendors in this area (SOA, webservices), you mostly see promises like: increased flexibility, more reuse, etc. If you go a little deeper and look at the future visions you see in most of the cases a market separated in three parts: service platform providers, service directories and service aggregators.

In this picture service aggregators search for the right service in service directories and assemble them together forming a business solution. The service platform providers deliver the middleware through which the services can work together. This last part is already proven in practice, but mostly with in-house developed services. The real benefit you can get out of such an architecture should come from the smart selection of web services out of service directories by the service aggregators. To do this well we need standardized techniques for specifying this services. On this topic I want to elaborate a bit, because, in my opinion, a lot of work is needed to make this all work nice and smooth.

I want to make a comparison between the current web service specification standards and

the status of current research in the field of Business Component Specification.

Business Component Specification

First a definition of software components: a software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties [1]. Business components are software components that are designed to support specific business applications. With a couple of this business components you can build a company specific business application. I nice introduction in the specification of such a business component can be found in [2]. Seven contract layers are specified covering the whole spectrum between business related aspects and more technical related aspects. You can see the seven layers in the picture below. By the way, what do we have with the number seven in IT? Think about the seven layer OSI network model, etc. 😉

If all of these layers are specified we can, in principle, do everything we want. Of course we can still considerate some points. An important one is the language we should use specifying all these layers. For now no language exist in which we can specify all of them. You now need a combination of (from the highest layer to the lowest) tables, norm languages, dictionaries, QML (Quality (of service) Modelling Language), UML OCL (Object Constraint Language) extended with some temporal operators, UML OCL and OMG IDL (Interface Definition Language). But beside that it’s a nice model to start with.

Web service standards

Comparing this model to the current web service standards we see some gaps. I’ll compare with the most used web service standards, I’m saying this because the number of web service ‘standards’ is growing very hard, all covering a slightly different aspect or just launched by another company.

The lowest level, the interface level, is well specified by the well-known standard WSDL (Web Service Description Language).

The behavioural level is, as far as I know, not well covered by the current web service standards.

On the coordination level we of course first think about BPEL (Business Process Execution Language) and BPML (Business Process Modelling Language). But these are orchestration standards and they specify everything from a global viewpoint. They do not provide us with the toolset we need on this level. For each component we want to specify which dependencies exist between this and other components. Another standard, WS-Coordination, is more about the coordination of actions in a complex distributed environment. So this layer is also not very well covered.

The quality level can be specified in the WS-Policy standard.

The remaining three levels are more about the semantics of the service/component. The UDDI (Universal Description, Discovery and Integration) is a first step in that direction but a lot of research is needed (and done at the moment) to enable automatic discovery and selection of web services. WS-Discovery and WS-MetadataExchange are examples of work in this field.

The terminology and task level are, at this moment, not well covered, the marketing level however can be defined with UDDI.

Conclusion

As I mentioned research is needed to make the future promises of web services true, but it is already going into the right direction. It is remarkable that the academic world looks at all different standards, rather than the web service standards developed by the business companies. I hope we can see some merging in the near future. I’m personally very interested in that, triggered by my work at Mendix and my study at the Delft University of Technology. At Mendix we now mostly make a connection with an UDDI registry, after that users can select services and orchestrate them in an easy, graphical way (because our philosophy is to make it all model-driven, and yes, we’re really far in making that happen). But it should be nice to provide the users with functionality with which they can search a needed service all over the web, based on some requirements, like business and quality requirements.

[1] Szyperski, Clemens. Component Software – beyond Object-Oriented Programming, Addison Wesley, 2002.
[2] Keiblinger, A.; Turowski, K.; Zaha, J. M.: Component Market Specification Demand and Standardized Specification of Business Components. In: Assar, S.; Semmak, F.; Barkhi, R. (Hrsg.): 1st International Workshop on Component-Based Business Information Systems Engineering (CBBISE ´03) in connection with the OOIS ´03 conference – 9th International Conference on Object-Oriented Information Systems (OOIS ´03). Geneva 2003, S.10-23.