Element and system are two of the core concepts of the SOA Ontology (SOA-O).
Here we will describe two classes:
and the following properties:
- uses and usedBy
- represents and representedBy
An element is an opaque entity that is indivisible at a given level of abstraction. The element has a clearly defined boundary. The concept of element is captured by the Element OWL class.
Figure 1. The SOA-O Element Class.
In the SOA-O, we consider in detail only functional elements that belong to the SOA domain.
There are other kinds of elements than members of the four named subclasses (System, HumanActor, Task, and Service). Examples of other kinds of elements are things like software components or technology components.
uses and usedBy Properties
Elements may use other elements in various ways. An element uses another element if it interacts with it in some fashion. Interacts here is interpreted very broadly:
- An element simply being a member of (or used by) some system
- An element interacting with (using) another element (such as a service) in an ad hoc fashion
- Strongly coupled dependency in a composition
The uses, and its inverse usedBy, capture the abstract notion of an element using another. These properties capture not just transient relations. Instantiation of the property can include “uses at this instant”, “has used”, and “may in future use”.
We have chosen not to attempt to enumerate and formally define the multitude of different possible semantics of a uses relationship. We leave the semantic interpretations to a particular sub-domain, application, or even design approach.
Using an organizational example, typical instances of Element are organizational units and people. Whether to perceive a given part of an organizational unit or as the set of people within that organizational unit is an important choice of abstraction level:
- Inside the boundary of the organizational unit, we want to express the fact that an organizational unit uses the people that are members of it. Note that the same person can be a member of (be used by) multiple organizational units.
- Outside the boundary, the internal structure of an organizational unit must remain opaque to an external observer, as the enterprise wants to be able to change the people within the organizational unit without having to change the definition of the organizational unit itself.
This simple example expresses that some elements have an internal structure. In fact, from an internal perspective, they are an organized collection of other simpler things (captured by Class System).
A system is an organized collection of other things. Things in a system collection are instances of Element, each such instance being used by the system. The concept of system is captured by the System OWL Class:
Figure 2. The SOA-O System Class.
The SOA-O considers in detail only functional systems that belong to the SOA domain. Note that a fully described instance of System should have by its nature (as a collection) a uses relationship to at least one instance of Element.
Since System is a subclass of Element, all systems have a boundary and are opaque to an external observer (black box view). This excludes from the System class any structure that has no defined boundary.
Having System as a subclass of Element allows us to express the notion of “systems of systems” – the lower-level levels are elements used by the higher-level system.
At the same time as supporting an external viewpoint (black box view), all systems must also support an internal viewpoint (white box view) expressing how they are an organized collection. E.g. for the notion of a service, this would typically correspond to a service specification view versus a service realization view (similar to the way that SoaML defines services as having both a black box/specification part and a white box/realization part).
It is important to realize that even though systems using elements express an important aspect of the uses property, it is not necessary to “invent” a system just to express that some element uses another. In fact, even for systems, we may need to be able to express that they can use elements outside their own boundary – though this in many cases will preferably be expressed not at the system level, but rather by an element of the system using that external Element instance.
System is defined as disjoint with the Service and Task classes. Instances of these classes are considered not to be collections of other things. System is specifically not defined as disjoint with the HumanActor class since an organization in many cases is in fact just a particular kind of system. We choose not to define a special intersection class to represent this fact.
Continuing the organizational example from above, we can now express that an organizational unit as an instance of System has the people in it as members (and instances of Element).
Using a service composition example, services A and B are instances of Element and the composition of A and B is an instance of System (that uses A and B). It is important to realize that the act of composing is different than composition as a thing – it is in the latter sense that we are using the term composition here. See below for a formal definition of the concepts of service and service composition.
represents and representedBy Properties
The environment described by an SOA is intrinsically hierarchically composite – the elements of SOA systems can be repeatedly composed to ever higher levels of abstraction.
One aspect of this has already been addressed by the uses and usedBy properties – we can use these properties to express the notion of systems of systems. This is still a very concrete relationship though, and does not express the concept of architectural abstraction. We find the need for architectural abstraction in various places, such as a role representing the people playing that role, an organizational unit representing the people within it (subtly different from that same organizational unit using the people within it, as the represents relationship indicates the organizational unit using the people within it, as the represents relationship indicates the organizational unit as a substitute interaction point, an architectural building block representing an underlying construct (e.g. important to enterprise architects wanting to explicitly distinguish between constructs and building blocks), and an Enterprise Service Bus (ESB) representing the services that are accessible through it (for instance, relevant when explicitly modeling operational interaction and dependencies). The concept of such an explicitly changing viewpoint, or level of abstraction, is captured by the represents and representedBy properties:
Figure 3. The SOA-O represents and representedBy Properties.
It is important to understand the distinction between using an element (E1) and using another element (E2) that represents E1. If E1 changes, then anyone using E1 directly would experience a change, but someone using E2 would not experience any change.
When applying the architectural abstraction via the represents property there are three different architectural choices that can be made:
- An element represents another element in a very literal way, simply by hiding the existence of that element and any changes to it. There will be a one-to-one relationship between the instance of Element and the (different) instance of Element that it represents. E.g. a broker acting as an intermediary between a seller (who does not wish to be known) and a buyer.
- An element represents a particular aspect of another element. There will be a many-to-one relationship between many instances of Element (each of which represents a different aspect), and one (different) instance of Element. A simple real-world example is the notion that the same person can play (be represented by) many different roles.
- An element is an abstraction that can represent many other elements. There will be a one-to-many relationship between one instance of Element (as an abstraction) and many other instances of Element. A simple real-world example is the notion of an architectural blueprint representing an abstraction of many different buildings being built according to that blueprint.
Note that in most cases an instance of Element will represent only one kind of thing. Specifically, an instance of Element will typically represent instances of at most one of the classes System, Service, HumanActor, and Task (with the exception of the case where the same thing is both an instance of System and an instance of Actor).
Assume a company wants to form a new organizational unit (O1). There are two ways of doing this:
- Define the new organization directly as a collection of people P1, P2, P3, and P4. This means that the new organization is perceived to be a leaf in the organizational hierarchy, and that any exchange of personnel means that its definition needs to change.
- Define the new organization as a higher-level organizational construct, joining together two existing organizations O3 and O4. Coincidentally, O3 and O4 between them may have the same four people P1, P2, P3, P4, but the new organization really doesn’t know, and any member of O3 and O4 can be changed without needing to change the definition of the new organization. Furthermore, any member of O3 is intrinsically not working in the same organization as the members of O4 (in fact, need not even be aware of them) – contrary to the first option where P1, P2, P3, P4 are all colleagues in the same new organization. In this way the abstraction aspect of the represent property induces an important difference in the semantics of the collection defining the new organization. Any instantiation of the ontology can and should use the represents and representedBy properties to define the implied semantics and lines of visibility/change crisply.
Previous: Service Oriented Architecture Ontology – SOA-O – Introduction
Next: SOA-O – HumanActor and Task Classes