• SOA Source Book
• Service-Oriented Architecture
• The Open Group Service Integration Maturity Model (OSIMM) Version 2
• SOA Reference Architecture
• Service-Oriented Cloud Computing Infrastructure (SOCCI) Framework
• Using TOGAF to Define and Govern Service-Oriented Architectures
• SOA Governance Framework
• Service-Oriented Architecture Ontology Version 2.0
• Introduction
• System and Element
• HumanActor and Task
• Service, ServiceContract, and ServiceInterface
• Composition and its Subclasses
• Policy
• Event
• Complete Car Wash Example
• Internet Purchase Example
• The OWL Definition of the Ontology
• Relationship to Other SOA Standards
• Class Relationship Matrix
• Referenced Documents
• Acknowledgements
• Legal
• Legacy Evolution to SOA
• Microservices Architecture
• SOA for Business Technology
• Navigating the SOA Open Standards Landscape Around Architecture
• SOA in the Digital Age

SOA Work Group

SOA Standards Discussion Forum

SOA Work Group Members Page

Service-Oriented Architecture Ontology Version 2.0 – HumanActor and Task

Introduction

People, organizations, and the things they do are important aspects of SOA systems. HumanActor and Task capture this as another set of core concepts of the ontology. Both are concepts that are generic and have relevance outside the domain of SOA. For the purposes of this SOA ontology we have chosen to give them specific scope in that tasks are intrinsically atomic (corresponding to, for instance, the Business Process Modeling Notation (BPMN) 2.0 definition of task) and human actors are restricted to people and organizations.

This chapter describes the following classes of the ontology:

• HumanActor
• Task

In addition, it defines the following properties:

• does and doneBy

The HumanActor Class

A human actor is a person or an organization. The concept of human actor is captured by the HumanActor OWL class, which is illustrated below.

The HumanActor Class

HumanActor is defined as disjoint with the Service and Task classes. Instances of these classes are considered not to be people or organizations. HumanActor is specifically not defined as disjoint with System 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.

HumanActor – Examples

The uses and usedBy Properties Applied to HumanActor

In one direction, a human actor can itself use things such as services, systems, and other human actors. In the other direction, a human actor can, for instance, be used by another actor or by a system (as an element within that system such as a human actor in a process).

The represents and representedBy Properties Applied to HumanActor

As mentioned in the introduction to this section, human actors are intrinsically part of systems that instantiate SOAs. Yet in many cases as an element of an SOA system we talk about not the specific person or organization, rather an abstract representation of them that participates in processes, provides services, etc. In other words, we talk about elements representing human actors.

As examples, a broker (instance of HumanActor) may represent a seller (instance of HumanActor) that wishes to remain anonymous, a role (instance of Element) may represent (the role aspect of) multiple instances of HumanActor, and an organizational unit (instance of HumanActor) may represent the many people (all instances of HumanActor) that are part of it.

Note that we have chosen not to define a “role class”, as we believe that using Element with the represents property is a more general approach which does not limit the ability to also define role-based systems. For all practical purposes there is simply a “role subclass” of Element, a subclass that we have chosen not to define explicitly.

Organizational Example

Continuing the organizational example from above, we can now express that P1 (John), P2 (Jack), P3 (Joe), and P4 (Mary) as instances of Element are in fact (people) instances of HumanActor. We can also express (if we so choose) that all of O1 (CarWashBusiness), O3 (CarWash), and O4 (Administration) are (organization) human actors from an action perspective at the same time that they are systems from a collection/composition perspective.

Car Wash Example

See Section 8.1 for the complete organizational aspect of the car wash example.

The Task Class

A task is an atomic action which accomplishes a defined result. Tasks are done by people or organizations, specifically by instances of HumanActor.

The Business Process Modeling Notation (BPMN) 2.0 defines task as follows: “A task is an atomic Activity within a Process flow. A task is used when the work in the process cannot be broken down to a finer level of detail. Generally, an end-user and/or applications are used to perform the task when it is executed.” For the purposes of the ontology we have added precision by formally separating the notion of doing from the notion of performing. Tasks are (optionally) done by human actors, furthermore (as instances of Element) tasks can use services that are performed by technology components (see details in Section 4.3; see also the example in Chapter 9).

The concept of task is captured by the Task OWL class, which is illustrated below.

The Task Class

Task is defined as disjoint with the System, Service, and HumanActor classes. Instances of these classes are considered not to be atomic actions.

The does and doneBy Properties

Tasks are naturally thought of as being done by people or organizations. If we think of tasks as being the actual things done, then the natural cardinality is that each instance of Task is done by at most one instance of HumanActor. Due to the atomic nature of instances of Task we rule out the case where such an instance is done jointly by multiple instances of HumanActor. The cardinality can be zero if someone chooses not to instantiate all possible human actors. On the other hand, the same instance of HumanActor can (over time) easily do more than one instance of Task. The does property, and its inverse doneBy, capture the relation between a human actor and the tasks it performs.

Task – Examples

The uses and usedBy Properties Applied to Task

In one direction, the most common case of a task using another element is where an automated task (in an orchestrated process; see Chapter 5 for the definition of process and orchestration) uses a service as its realization. In the other direction, a task can, for instance, be used by a system (as an element within that system, such as a task in a process).

The represents and representedBy Properties Applied to Task

As mentioned in the introduction to this section, tasks are intrinsically part of SOA systems. Yet in many cases as an element of an SOA system we talk about not the actual thing being done, rather an abstract representation of it that is used as an element in systems, processes, etc. In other words, we talk about elements representing tasks.

As a simple example, an abstract activity in a process model (associated with a role) may represent a concrete task (done by a person fulfilling that role). Note that due to the atomic nature of a task it does not make sense to talk about many elements representing different aspects of it.

Organizational Example

Continuing the organizational example from above, we can now express which tasks that are done by human actors (people) P1, P2, P3, and P4, and how those tasks can be elements in bigger systems that describe things such as organizational processes. Chapter 5 will deal formally with the concept of composition, including properly defining the concept of a process as one particular kind of composition.

Car Wash Example

As an important part of the car wash system, John and Jack perform certain manual tasks required for washing a car properly:

• Jack and John are instances of HumanActor.
• WashWindows is an instance of Task and is done by John.
• PushWashButton is an instance of Task and is done by Jack.