SOA Ontology

The working group ‘Ontologies for SOA’ of the Open Group released their
SOA Ontology Draft 2.0 today. This ontology has two main purposes:

1. It defines the concepts, terminology and semantics of SOA in both business and technical terms,
2. It potentially contributes to model-driven SOA implementation.

I think they did a nice job in creating a common understanding for SOA terminology. However, they stay at a fairly high level. The implementation part of the document only touches some basic concepts.

From a technical perspective I miss the focus on reuse and change. The main difference between an application-centric architecture and a service-oriented architecture is that the functionality in a SOA is build to change and for being reused by other services.

Their second objective, to potentially contribute to Model-Driven SOA implementation, is very ambitious. A stated a year ago in my article on Model-Driven SOA I believe that model driven technology is essential for making the promises of SOA come true. I also stated that the SOA ontology working group of The Open Group can play an important role: "If their work can become mature fast enough they can play a big role in vendor-independent modeling formats". Although I believe in the use of ontologies for defining DSL’s, the current state of the document doesn’t directly set a step into that direction.

They tackle the basic implementation/programming concepts like messages, orchestrations and assemblies (compositions), but they don’t mention by example the different service types needed for implementing a SOBA (Service-Oriented Business Applications). A distinction can be made between infrastructure services and application services. Infrastructure services can be further divided into:

• Communication services, which are mainly used for message transportation, and
• Utility services, which deliver generic (non-application-specific) infrastructural functionality. Examples of utility services are:
  • Analytics services, analyzing the exchanged messages between services for, by example, Complex Event Processing (CEP);
  • Technical services, supporting the operations of other services by offering, by example, logging and transaction capabilities; and
  • Security services, delivering single sign on capabilities and identity propagation that enable services to operate on the behalf of the user.

Application services, on the other hand, can be divided into:

• Entity services, exposing and managing business entities;
• Activity services, implementing a specific application-level business capability;
• Capability services, implementing a generic value-add business capability;
• Process services, implementing a business process by orchestrating other services;
• Decision services, supporting the externalization and reuse of complex en critical decision points within a task, process or business object; and
• Delivery services, enabling user interactions with the system, which are always performed within a task.

I think it is important to create a common vocabulary (ontology) on these kinds of services, their interaction and their implementation elements. A nice metamodel approach for abstract SOA implementation is the WSPER project. While WSPER focusses on implementation details an ontology should be created focussing on the different services, thereby bridging the gap between high-level SOA reference models and the technical vocabulary of WSPER.

Don’t get me wrong. I really appreciate the work of the SOA ontology working group. However, I hope they will go on and add more details, thereby directly helping in a practical way with Model-Driven SOBA implementations.