Service-Oriented Architecture Ontology Version 2.0 – System and Element

 

Introduction

System and element are two of the core concepts of this ontology. Both are concepts that are often used by practitioners, 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; for instance, an electrical system has very different kinds of elements than an SOA system.

In the ontology only elements and systems within the SOA domain are considered. Some SOA sub-domains use the term component rather than the term element. This is not contradictory, as any component of an SOA system is also an element of that (composite) system.

This chapter describes the following classes of the ontology:

  • Element
  • System

In addition, it defines the following properties:

  • uses and usedBy
  • represents and representedBy

The Element Class

<owl:Class rdf:about="#Element"> </owl:Class>

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, which is illustrated below.

The Element Class

In the context of the SOA ontology 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) described later in this ontology. Examples of such other kinds of elements are things like software components or technology components (such as Enterprise Service Bus (ESB) implementations, etc.).

The uses and usedBy Properties

<owl:ObjectProperty rdf:about="#uses">   <rdfs:domain rdf:resource="#Element"/>   <rdfs:range rdf:resource="#Element"/> </owl:ObjectProperty>   <owl:ObjectProperty rdf:about="#usedBy">   <owl:inverseOf>     <owl:ObjectProperty rdf:about="#uses"/>   </owl:inverseOf> </owl:ObjectProperty>

Elements may use other elements in various ways. In general, the notion of some element using another element is applied by practitioners for all of models, executables, and physical objects. What differs from domain to domain is the way in which such use is perceived.

An element uses another element if it interacts with it in some fashion. Interacts here is interpreted very broadly ranging through, for example, an element simply being a member of (used by) some system (see later for a formal definition of the System class), an element interacting with (using) another element (such as a service; see later for a formal definition of the Service class) in an ad hoc fashion, or even a strongly coupled dependency in a composition (see Section 5.2 for a formal definition of the Composition class). The uses property, and its inverse usedBy, capture the abstract notion of an element using another. These properties capture not just transient relations. Instantiations of the property can include “uses at this instant”, “has used”, and “may in future use”.

For the purposes of this ontology 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.

Element – Organizational Example

Using an organizational example, typical instances of Element are organizational units and people. Whether to perceive a given part of an organization as 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 in fact 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 the System class defined below).

The System Class

<owl:Class rdf:about="#System">   <owl:disjointWith>     owl:Class rdf:about="#Task"/>   </owl:disjointWith>   <owl:disjointWith>     <owl:Class rdf:about="#Service"/>   </owl:disjointWith>   <rdfs:subClassOf>     <owl:Class rdf:about="#Element"/>   </rdfs:subClassOf> </owl:Class>

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. The concept of system is captured by the System OWL class, which is illustrated below.

The System Class

This definition of System is heavily influenced by IEEE Std 1471-2000, adopted by ISO/IEC JTC1/SC7 as ISO/IEC 42010:2007: Systems and Software Engineering – Recommended Practice for Architectural Description of Software-intensive Systems.

In the context of the SOA ontology we consider 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 structures that have no defined boundary. From an SOA perspective this is not really a loss since all interesting SOA systems do have the characteristic of being possible to perceive from an outside (consumer) perspective. Furthermore, having System as a subclass of Element allows us to naturally express the notion of systems of systems – the lower-level systems are simply elements used by the higher-level system.

At the same time as supporting an external viewpoint (black box view, see above) all systems must also support an internal viewpoint (white box view) expressing how they are an organized collection. As an example, 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.

System – Examples

Organizational Example

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).

Service Composition Example

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 also below for a formal definition of the concepts of service and service composition (and a repeat of the example in that more precise context).

Car Wash Example

Consider a car wash business. The company as a whole is an organizational unit and can be instantiated in the ontology in the following way:

  • CarWashBusinessis an instance of System.
  • Joe (the owner) is an instance of Element and used by (owner of) CarWashBusiness.
  • Mary (the secretary) is an instance of Element and used by (employee of) CarWashBusiness.
  • John (the pre-wash guy) is an instance of Element and used by (employee of) CarWashBusiness.
  • Jack (the washing manager and operator) is an instance of Element and used by (employee of) CarWashBusiness.

The represents and representedBy Properties

<owl:ObjectProperty rdf:about="#represents">   <rdfs:domain rdf:resource="#Element"/>   <rdfs:range rdf:resource="#Element"/> </owl:ObjectProperty>   <owl:ObjectProperty rdf:about="#representedBy">   <owl:inverseOf>     <owl:ObjectProperty rdf:about="#represents"/>   </owl:inverseOf> </owl:ObjectProperty>

The environment described by an SOA is intrinsically hierarchically composite (see also Section 5.2 for a definition of the Composition class); in other words, 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 in that we can use these 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 as a substitute interaction point), an architectural building block representing an underlying construct (for instance, 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 illustrated below.

The represents and representedBy Properties

It is important to understand the exact nature of 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. A simple real-world example is the notion of a broker acting as an intermediary between a seller (that 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). See later sections for the definitions of Service, HumanActor, and Task.

Examples

Organizational Example

Expanding further on the organizational example, assume that 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, and P4, but the new organization really doesn’t know, and any member of O3 or 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, and P4 are all colleagues in the same new organization.

In this way the abstraction aspect of the represents 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 crisply define the implied semantics and lines of visibility/change.

Car Wash Example

Joe chooses to organize his business into two organizational units, one for the administration and one for the actual washing of cars. This can be instantiated in the ontology in the following way:

  • CarWashBusinessis an instance of System.
  • AdministrativeSystem is an instance of System.
  • Administration is an instance of Element that represents AdministrativeSystem (the opaque organizational unit aspect, aka ignoring anything else about AdministrativeSystem).
  • CarwashBusinessuses (has organizational unit) Administration.
  • CarWashSystem is an instance of System.
  • CarWash is an instance of Element that represents CarWashSystem (the opaque organizational unit aspect, aka ignoring anything else about CarWashSystem).
  • CarWash is a member of CarWashBusiness.
  • Joe (the owner) is an instance of Element and now used by AdministrationSystem.
  • Mary (the secretary) is an instance of Element and now used by AdministrationSystem.
  • John (the pre-wash guy) is an instance of Element and now used by CarWashSystem.
  • Jack (the wash manager and operator) is an instance of Element and now used by CarWashSystem.