In an effort to bridge the communication gap between business and IT over service oriented architecture (SOA), The Open Group has released a new technical standard - Service-Oriented Architecture Ontology - which aims to help better define the concepts, terms, and semantics involved in SOA. The standard
... defines the concepts, terminology, and semantics of SOA in both business and technical terms, in order to:
- Create a foundation for further work in domain-specific areas
- Enable communications between business and technical people
- Enhance the understanding of SOA concepts in the business and technical communities
- Provide a means to state problems and opportunities clearly and unambiguously to promote mutual understanding.
The two core concepts of ontology are system and element, where:
An element is an opaque entity that is indivisible at a given level of abstraction. The element has a clearly defined boundary.
while:
A system is an organized collection of other things. Specifically things in a system collection are instances of element, each such instance being used by the system.
Both concepts are generic, and can be used to describe any implementation and allow to describe common concepts, including the notion that systems have elements and that systems can be hierarchically combined (systems of systems). What differs from domain to domain is the specific nature of systems and elements.
Another core concept of the ontology is service. It is a concept that is fundamental to SOA and always used in practice when describing or engineering SOA systems.
A service is a logical representation of a repeatable activity that has a specified outcome. It is self-contained and is a "black box" to its consumers.
The ontology’s definition omits the commonly used term "business" in their definition of service, stating that
... the notion of business is relative to a person’s viewpoint - as an example, one person's notion of IT is another person’s notion of business (the business of IT). Service as defined by the ontology is agnostic to whether the concept is applied to the classical notion of a business domain or the classical notion of an IT domain.
Although ontology defines a service as a subclass of element, it states that instances of higher level classes, for example, systems may provide capabilities that can be offered as services.
Other high-level constructs related to services, as defined by the ontology, are serviceContract, serviceInterface and informationType.
A service contract defines the terms, conditions, and interaction rules that interacting participants [service providers and consumers] must agree to (directly or indirectly). A service contract is binding on all participants in the interaction, including the service itself and the element that provides it for the particular interaction in question.
It represents specific agreements that are necessary for the correct use of a service. They can originate either from requirements necessary for the proper functioning of the service or from the desire to regulate the use of the service.
A service interface defines the way in which other elements can interact and exchange information with a service.
Well-defined service interfaces makes it easy to correctly interact with services, and enables other elements to use them in a structured manner. A service interface can enable another element to give information to or receive information from a service. Specific types of information exchanged with a service are defined by the informationType class.
One of the main advantages of SOA is service composability. This property of SOA is defined by two ontology concepts - composition and serviceComposition.
A composition is defined as a result of assembling a collection of things for a particular purpose. The SOA ontology defines a composition as a subclass of a system, thus emphasizing that while a composition is a system, a system is not necessary a composition. The ontology further distinguishes several composition patterns including the Orchestration Composition Pattern, the Choreography Composition Pattern and the Collaboration Composition Pattern.
A special case of composition is:
... service composition, the result of assembling a collection of services in order to perform a new higher-level service.
Finally the ontology adds events as a fundamental to SOA concept:
Events and the elements that generate or respond to them are important aspects of any event emitting system. SOA systems are in fact often emitting [and consuming] events.
The publication of the standard caused a lot of interest among SOA practitioners. According to Dana Gardner:
The SOA Ontology Technical Standard bridges different architecture, engineering, business and marketing domains, providing common terminology and concept mapping that business and technical people can use to discuss problems and opportunities. It will also serve as a foundation for further work in domain specific areas by supplying a consistent framework that can be reused as SOA projects evolve.
According to Heather Kreger:
[Ontology] be used simply to read and understand the key concepts of SOA, and more importantly, a set of definitions and UNDERSTANDING of key concepts that you can agree to use with others in your company and between organizations. Making sure you are ‘speaking the same language’ is essential for any architect to be able to communicate effectively with IT, business, and marketing professionals within the enterprise as well as with vendors and suppliers outside the enterprise.
Current proliferation of SOA terminology hurts SOA. A new Open Group standard that is trying to bring together and organize these definitions is a huge step in creation of a common SOA language. This common language can help ensure that you can ask the right questions and interpret the answers you get unambiguously.
