All things service

My day job as clinical leader of a large children’s mental health centre in Ontario, Canada presents me with the constant challenge of working with other professionals to devise and resource treatment plans for children and youth with complex emotional, behavioral, and learning needs.

I have been trained formally in the philosophy of language, cognitive psychology, and experimental design and statistics, though at this stage of my life I would describe myself as self-taught. Most recently, I have been studying two domains connected to my professional work – the concepts of “service” and “network”  – with the  idea of specifying more clearly a popular but particularly slippery concept – the “service network”.

In one case study, I intend to examine a database of human services in Ontario that is maintained online at http://211ontario.ca – and explore the “meaning” embedded in this sort of database using semantic web technologies, e.g.  the evolving Core Public Service Vocabulary of the European Commission and an ontology of government services included in a recent release of schema.org.

This is a work in progress.

Originally I had thought about working away under these broad headings:

While these headings still represent reasonable divisions of labour for me, there are three distinct but just-close-enough-to-be-confusing senses in which the term “service” is used in the literature:

  • a software service, like the SSL/HTTPS service, that secures the transfer of data packets over the Internet
  • a “real” world service, like a banking service, that allows someone to pay a monthly utility bill at a local branch
  • a “real” world service that is mediated by a software service, like an online banking service, that uses the SSL/HTTPS service to allow someone to pay a monthly utility bill securely over the Internet

Early on, the metaphor “software as a service” inspired pioneers in computer science to explore and elaborate one concept (software) that was novel and abstract in terms of another concept (service) that was familiar and grounded in human experience.

In the past two decades, our understanding of the concept of software, the concept of service, and the metaphor “software as a service” have advanced tremendously. Indeed, an entire industry has emerged around “Software as a Service” (SaaS) in “cloud computing.”

Finally, in much the same way that humans have moved from using the metaphor “computer as a brain” to using as readily the metaphor “brain as a computer” – the metaphor “service as a software” is used as readily as the metaphor “software as a service” in our thinking.

Today the prime driver for clarifying the semantics of “real world” service comes from software engineering – and seeks to improve the design and deployment of Web services that are (somehow) meant to facilitate the delivery of “real world” services.

My original thought was to enlist the technologies of software services – e.g. service-oriented computing, service-oriented architecture, service-oriented semantics – to describe and model more clearly and formally the defining features of “real” world services – especially human services, like social assistance, mental health counselling, and so on.

I still believe there is great potential in this exercise – and in the closely related exercise of elaborating how software services can support “real” human services – though we are liable to miss the mark if we take the metaphor “service as a software” too literally.

 

Navigating the SOA Landscape

Source: OASIS – Navigating the SOA Open Standards Landscape Around Architecture , June 2009

Take-away for use:

  • OASIS – Reference Model for SOA (SOA-RM)
  • The Open Group – SOA Ontology (SOA-O)
  • Open Management Group – Service Oriented Architecture Modeling Language (SoaML)

Introduction

This document is written to provide guidance to readers of various Service Oriented Architecture (SOA) standards and specifications written by the Organization for the Advancement of Structured Information Standards (OASIS), The Open Group, and the Object Management Group (OMG), on how these standards and specifications relate to each other:

  • Reference models – e.g. the OASIS Reference Model for SOA.
  • Reference architectures – e.g. the OASIS Reference Architecture for SOA, The Open Group SOA Reference Architecture.
  • Ontologies – e.g. The Open Group SOA Ontology.
  • Maturity models – e.g. The Open Group Service Integration Maturity Model (OSIMM).
  • Modeling profiles – e.g. the Open Management Group SoaML, SysML.

Technical Products Related to Core SOA Concepts

The OASIS Reference Model for SOA (SOA-RM) is intended to capture the “essence” of SOA, as well as provide a vocabulary and common understanding of the SOA. The goals of the reference model include a common conceptual framework that can be used consistently across and between different SOA implementations, common semantics that can be used unambiguously in modeling specific SOA solutions, and definitions that should apply to all SOA. The reference model provides a normative reference that remains relevant for SOA as an abstract, power model, regardless of the inevitable technology changes that have influenced or will influence SOA deployment.

The Open Group SOA Ontology is similar to the OASIS Reference Model for SOA in that it captures a set of related concepts within the SOA space and explains what they are and how they relate to each other. The objectives are to facilitate understanding of these terms and concepts within the context of SOA, and potentially to facilitate model-driven implementation. The ontology is represented in OWL to enable automation and allow tools to process it; e.g. reasoning applications could use the SOA ontology to drive service consumer and provider matching, service value chain analysis, and impact analysis. The formal representation enables integration with other concerns such as business motivation modeling, business process modeling, operations modeling, portfolio management, etc.

Note that the OASIS Reference Model for SOA and The Open Group SOA Ontology are very closely aligned, although some terms may represent different views.

[skip: Technical products related to SOA Maturity; Governance]

Technical Products Related to Architecture

Modeling Profiles – Business and IT architects also employ methodologies for modeling and building architectures. As such, architectural methodologies have emerged with the advent of Model Driven Architecture (MDA), a product of the OMG. For working with SOA and using the Unified Modeling Language (UML) as the primary syntax, the OMG SoaML specification provides guidance to help architects and other strategic thinkers link the design of real world SOA-based systems into their architecture work.

The Service Oriented Architecture Markup Language (SoaML) is an OMG standard that defines extensions to UML for services modeling adn provides functional, object-oriented, and component modeling capabilities. SoaML extends UML in order to provide additional capabilities for managing cohesion and coupling afforded by an SOA style. SoaML is applicable across a broad range of domains and levels of abstraction from business services to detailed IT services. Using a common language for these different purposes simplifies systems modeling and integration of separate concerns in order to enable business agility. SoaML can be viewed as support instantiation of the OASIS Reference Model for SOA that provides a concrete platform for services modeling integrated with UML and supported OMG MDA.

The purpose of the SoaML standard is to address service modeling, not methodologies for determining what the services model should be, or how it would be used in any particular context. The standard is intended to be sufficiently detailed to define platform-independent SOA models (PIMs) that can be transformed into platform-specific models (PSMs) for particular technical architectures.

The fundamental element of SoaML is the participant, representing a service consumer and/or provider. Participants express their goals, needs, and expectations through requests for services as defined by service interfaces or service contracts. Other participants express their value propositions, capabilities, and commitments through services. Participants are then assembled into service value chains where participant requests are connected to the compatible services of other participants through service channels through which they interact. SoaML uses facilities of UML to define the services interfaces and method behaviors for carrying out and using services. SoaML also defines autonomous agents that can choreograph participants in a service value chain while adapting to the changing needs of the community of collaborating participants. SoaML provides a means of defining milestones that indicate the achievement of progress toward achieving the desired real-world effect of the services value chain, and for evaluating different approaches to achieving progress by different participants.

Since the OASIS Reference Architecture for SOA, The Open Group SOA Ontology, and the OMG SoaML were all based on the OASIS Reference Model for SOA with refinements and extensions, there is some natural affinity between these works.

How the Technical Products Fit Together

These technical products represent different perspectives and levels of discussion within the overall SOA landscape. A reference model, much like an ontology, is a high-level conceptualization of a domain but without formal semantics and rules to support automated reasoning that would be characteristic of an ontology. A formal ontology could be created for a particular reference model or a reference model could be formally described by an ontology. Both capture the core concepts within that domain and explain how they relate to each other devoid of implementation details. They are useful to capture and preserve knowledge that helps users to understand the “essence” of the domain. Reference models and ontologies guide architectures and reference architectures.

The OASIS Reference Model is the most abstract, with The Open Group SOA Ontology being slightly less abstract, since it provides a normative expression of the SOA Reference Model with extensions. The OASIS Reference Architecture for SOA is less abstract than the OASIS Reference Model for SOA and The Open Group SOA Ontology, since it provides significantly more detail on architectural components and their relationships, but provides a subset of the architectural views available. The Open Group Reference Architecture is less abstract than the OASIS Reference Architecture for SOA and provides more coverage of an enterprise architecture.

The open standards organizations referenced in this White Paper agree on the following fundamental concepts of SOA:

SOA – We agree that SOAs support thinking and organizing in terms of services with distributed capabilities which may be under the control of different ownership domains, and is an architectural style as well as a paradigm for business and IT architecture.
Service – We agree that services correspond to repeatable activities that can be characterized as capabilities or the access to capabilities, that capabilities satisfy specific needs, that services are self-contained, that services are described, and that access and interaction with services are constrained by policies and contracts. We agree that the service implementation is opaque to service consumers who interact with the service.
Effect (or real-world effect) – We agree that interacting with services has a purpose and therefore has some outcome which potentially provides exchange of value between consumers and providers.
Visibility – We agree that participants, more specifically providers with capabilities and consumers with needs, are able to interact with each other. We agree that availability of service descriptions and policies support these interactions.
Service Description – We agree that services are described with sufficient information in order to determine whether they meet the needs of prospective consumers as well as how to access and interact with them, including but not limited to interfaces, policies, and contracts.
Policies and Contracts – We agree that service policies represent some constraint or condition expectation on the use of services represented by a consuming participant or commitment of a providing participant, and that service contracts represent an agreement by two or more parties.
Execution Context – We agree that in order for services to be invoked, there must be an established path between consumers and providers. In other words, to realize described effects, consumers and providers must acknowledge and comply with a consistent set of agreements in order to have a successful service interaction.
Interaction – We agree that there is some activity involved in making use of capabilities offered by services in order to achieve desired effects.

Guidance and Usage of Architectural Products

Understanding SOA Core Concepts – The OASIS Reference Model for SOA provides a common vocabulary for understanding the “essence” of SOA. It is, by design, a highly abstract model targeting a large, cross-cutting audiences that includes non-technical readers as much as it does technical readers. The Open Group SOA Ontology builds on the OASIS Reference Model for SOA and provides additional SOA concepts and relationships taken from the viewpoints of different stakeholders as well as an enterprise-wide perspective. It also provides as a common language for formally describing SOA concepts that can be leveraged by abstract as well as solution-oriented reference architectures.

[skip Architectures; Maturity]

Modeling Languages – The SoaML provides a UML profile for modeling SOA artifacts and services for your SOA as part of the transformation from a reference architecture to your SOA solution architecture.

Conclusion

An abundance of specifications and standards have emerged from the open standards organizations OASIS, OMG, and The Open Group on the subject of SOA. Fortunately, there is a great deal of agreement on the foundational core concepts across the many independent open specifications and standards for SOA.

 

 

Reference Model for Service Oriented Architecture (SOA-RM) Introduction

Introduction

The notion of Service Oriented Architecture (SOA) has received significant attention within the software design and development community. The result of this attention is the proliferation of many conflicting definitions of SOA. Whereas SOA architectural patterns (or reference architectures) may be developed to explain and underpin a generic design template supporting a specific SOA, a reference model is intended to provide an even higher level of commonality, with definitions that should apply to all SOA.

A reference model is an abstract framework for understanding significant relationships among the entities of some environment. It enables the development of specific reference or concrete architectures using consistent standards or specifications supporting that environment. A reference model consists of a minimal set of unifying concepts, axioms and relationships within a particular problem domain, and is independent of specific standards, technologies, implementations, or other concrete details.

What is Service Oriented Architecture?

Entities (people and organizations) create capabilities to solve the problems they face in the course of their business; one person’s needs may be met by capabilities offered by someone else. SOA provides a framework for matching needs and capabilities and for combining capabilities to address those needs.

SOA is a means of organizing solutions that promotes reuse, growth and interoperability. It is not itself a solution to domain problems, but rather an organizing and delivery paradigm that enables one to get more value from use both of capabilities which are locally “owned” and those under the control of others.  It also enables one to express solutions in a way that makes it easier to modify or evolve the identified solution or to try alternate solutions.  SOA does not provide any domain elements of a solution that do not exist without SOA.

Service

The central concept of SOA is the service. The noun “service” is defined in dictionaries as “The performance of work (a function) by one for another.”  However, service, as the term is generally understood, also combines the following related ideas:

  • The capability to perform work for another
  • The specification of the work offered for another
  • The offer to perform work for another

These concepts emphasize a distinction between a capability and the ability to bring that capability to bear. In SOA, services are the mechanism by which needs and capabilities are brought together.

While a service brings together needs and capabilities, the provider of the underlying capability may not be the same entity that eventually provides the service which accesses that capability.  In reality, the entity with the domain expertise to create, maintain, and evolve a given capability may not have the expertise or the desire to create, maintain, and evolve its service access.

Visibility

Visibility refers to the capacity for those with needs and those with capabilities to be able to see each other.  Visibility is promoted through the service description which describes functions and requirements, related constraints and policies, and mechanisms for access or response.  The descriptions need to be in a form in which their syntax and semantics are accessible and understandable.

Interaction

Whereas visibility introduces the possibilities for matching needs to capabilities (and vice versa), interaction is the activity of using a capability.  Typically mediated by the exchange of messages, an interaction proceeds through a series of information exchanges and invoked actions. There are many facets of interaction; but they are all grounded in a particular execution context – the set of technical and business elements that form a path between those with needs and those with capabilities. The service description provides the information necessary to interact with the service and describes this in such terms as the service inputs, outputs, and associated semantics. This permits service providers and consumers to interact and provides a decision point for any policies and contracts that may be in force.

Effect

The purpose of using a capability is to realize one or more real world effects.  At its core, an interaction is “an act” as opposed to “an object” and the result of an interaction is an effect (or a set/series of effects). This effect may be the return of information or the change in the state of entities (known or unknown) that are involved in the interaction. The service description conveys what is accomplished when the service is invoked and the conditions for using the service.

We distinguish between public actions and private actions; private actions are inherently unknowable by other parties. On the other hand, public actions result in changes to the state that is shared between at least those involved in the current execution context and possibly shared by others. Real world effects are, then, couched in terms of changes to this shared state.

The expected real world effects form an important part of the decision on whether a particular capability matches similarly described needs.  At the interaction stage, the description of real world effects establishes the expectations of those using the capability.   Note, it is not possible to describe every effect from using a capability. A cornerstone of SOA is that capabilities can be used without needing to know all the details.

Service Providers and Service Consumers

In general, entities (people and organizations) offer capabilities and act as service providers.  Those with needs who make use of services are referred to as service consumers.  The service description allows prospective consumers to decide if the service is suitable for their current needs and establishes whether a consumer satisfies any requirements of the service provider.

Service providers and service consumers are sometimes referred to jointly as service participants.1

Figure 1 illustrates the principal concepts of the Reference Model of SOA:

Principle concepts of the Reference Model of SOA

Figure 1. Principal components in the Reference Model of SOA (SOA-RM).

The relationships between the principal concepts are developed as each concept is defined in turn:

Source: OASIS – Reference Model for Service Oriented Architecture – 2006

Previous: OASIS – Navigating the SOA Landscape Through Architecture
Next: SOA-RM – Service

  1.  In most discussions of SOA, the terms “loose coupling” and “coarse-grained” are commonly applied as SOA concepts, but these terms have intentionally not been used in the current discussion because they are subjective trade-offs and without useful metrics. In terms of needs and capabilities, granularity and coarseness are usually relative to detail for the level of the problem being addressed, e.g. one that is more strategic vs. one down to the algorithm level, and defining the optimum level is not amenable to counting the number of interfaces or the number or types of information exchanges connected to an interface.

SOA-RM – Service

A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.  A service is provided by an entity – the service provider –  for use by others, but the eventual consumers of the service may not be known to the service provider and may demonstrate uses of the service beyond the scope originally conceived by the provider.

A service is accessed by means of a service interface (see SOA-RM – Service Interface), where the interface comprises the specifics of how to access the underlying capabilities.  There are no constraints on what constitutes the underlying capability or how access is implemented by the service provider.  Thus, the service could carry out its described functionality through one or more automated and/or manual processes that themselves could invoke other available services.

A service is opaque in that its implementation is typically hidden from the service consumer except for (1) the information and behavior models exposed through the service interface and (2) the information required by service consumers to determine whether a given service is appropriate for their needs.

The consequence of invoking a service is a realization of one or more real world effects (see SOA-RM – Real World Effect). These effects may include:

  1. information returned in response to a request for that information,
  2. a change to the shared state of defined entities, or
  3. some combination of (1) and (2).

Note, the service consumer in (1) does not typically know how the information is generated, e.g. whether it is extracted from a database or generated dynamically; in (2), it does not typically know how the state change is effected.

The service concept distinguishes between a capability that represents some functionality created to address a need and the point of access where that capability is brought to bear in the context of SOA.  It is assumed that capabilities exist outside of SOA.

Source: OASIS – Reference Model of Service Oriented Architecture – 2006.

Previous; Reference Model of SOA (SOA-RM) – Introduction
Next: SOA-RM – Dynamics of Services

SOA-RM – Dynamics of services

From a dynamic perspective, there are three fundamental concepts that are important in understanding what is involved in interacting with services: the visibility between service providers and consumers, the interaction between them, and the real world effect of interacting with a service.

SOA-RM - Concepts around the dynamics of service

Figure 1. Concepts around the dynamics of service.

Visibility

For a service provider and consumer to interact with each other they have to be able to ‘see’ each other. This is true for any consumer/provider relationship – including in an application program where one software program calls another. In the case of SOA, visibility needs to be emphasized because it is not necessarily obvious how service participants can see each other.

SOA-RM - Concepts around visibility

Figure 5. Concepts around visibility.

Visibility is the relationship between service consumers and providers that is satisfied when they are able to interact with each other. Preconditions to visibility are awareness, willingness and reachability. The initiator in a service interaction MUST be aware of the other parties, the participants MUST be predisposed to interaction, and the participants MUST be able to interact.

Awareness

Both the service provider and the service consumer MUST have information that would lead them to know of the other’s existence. Technically, the prime requirement is that the initiator of a service interaction has knowledge of the responder. The fact of a successful initiation is often sufficient to inform the responder of the other’s existence.

Awareness is a state whereby one party has knowledge of the existence of the other party. Awareness does not imply willingness or reachability. Awareness of service offerings is often effected by various discovery mechanisms. For a service consumer to discover a service, the service provider must be capable of making details of the service (notably service description and policies) available to potential consumers; and consumers must be capable of becoming aware of that information. Conversely, the service provider may want to discover likely consumers and would need to become aware of the consumer’s description.  In the following, we will discuss awareness in terms of service visibility but the concepts are equally valid for consumer visibility.

Service awareness requires that the service description and policy – or at least a suitable subset thereof – be available in such a manner and form that, directly or indirectly, a potential consumer is aware of the existence and capabilities of the service. The extent to which the description is “pushed” by the service provider, “pulled” by a potential consumer, subject to a probe or another method, will depend on many factors.

For example, a service provider may advertise and promote their service by either including it in a service directory or broadcasting it to all consumers; potential consumers may broadcast their particular service needs in the hope that a suitable service responds with a proposal or offer, or a service consumer might also probe an entire network to determine if suitable services exist. When the demand for a service is higher than the supply, then, by advertising their needs, potential consumers are likely to be more effective than service providers advertising offered services.

One way or another, the potential consumer must acquire sufficient descriptions to evaluate whether a given service matches its needs and, if so, the method for the consumer to interact with the service.

Willingness

Associated with all service interactions is intent – it is an intentional act to initiate and to participate in a service interaction. For example, if a service consumer discovers a service via its description in a registry, and the consumer initiates an interaction, if the service provider does not cooperate then there can be no interaction. In some circumstances it is precisely the correct behavior for a service to fail to respond.

The extent of a service participant’s willingness to engage in service interactions may be the subject of policies. Those policies may be documented in the service description.

Willingness on the part of service providers and consumers to interact is not the same as a willingness to perform requested actions. A service provider that rejects all attempts to cause it to perform some action may still be fully willing and engaged in interacting with the consumer.

Reachability

Reachability is the relationship between service participants where they are able to interact; possibly by exchanging information. Reachability is an essential pre-requisite for service interaction – participants MUST be able to communicate with each other.

A service consumer may have the intention of interacting with a service, and may even have all the information needed to communicate with it. However, if the service is not reachable, for example if there is not a communication path between the consumer and provider, then, effectively, the service is not visible to the consumer.

Previous: SOA-RM – Service
Next: SOA-RM – Interacting with services

SOA-RM – Interacting with services

Interacting with a service involves performing actions against the service. In many cases, this is accomplished by sending and receiving messages, but there are other modes possible that do not involve explicit message transmission. For example, a service interaction may be effected by modifying the state of a shared resource. However, for simplicity, we often refer to message exchange as the primary mode of interaction with a service.

SOA-RM - Service interaction concepts

Figure 1. Service interaction concepts.

Figure 1 illustrates the key concepts that are important in understanding what it is involved in interacting with services; these revolve around the service description – which references a information model and a behavior model.

Information model

The information model of a service is a characterization of the information that may be exchanged with the service.  Only information and data that are potentially exchanged with a service are generally included within that service’s information model.

The scope of the information model includes the format of information that is exchanged, the structural relationships within the exchanged information and also the definition of terms used.

Particularly for information that is exchanged across an ownership boundary, an important aspect of the service information model is the consistent interpretation of strings and other tokens in the information.

The extent to which one system can effectively interpret information from another system is governed by the semantic engagement of the various systems. The semantic engagement of a system is a relationship between the system and information it may encounter. This is highly variable and application dependent.

Loosely, one might partition the interpretation of an informational block into structure (syntax) and semantics (meaning); although both are part of the information model.

Structure

Knowing the representation, structure, and form of information required is a key initial step in ensuring effective interactions with a service. There are several levels of such structural information; including the encoding of character data, the format of the data and the structural data types associated with elements of the information.

A described information model typically has a great deal to say about the form of messages.  However, knowing the type of information is not sufficient to completely describe the appropriate interpretation of data. For example, within a street address structure, the city name and the street name are typically given the same data type – some variant of the string type. However, city names and street names are not really the same type of thing at all.  Distinguishing the correct interpretation of a city name string and a street name string is not possible using type-based techniques – it requires additional information that cannot be expressed purely in terms of the structure of data.

Semantics

The primary task of any communication infrastructure is to facilitate the exchange of information and the exchange of intent. For example, a purchase order combines two somewhat orthogonal aspects: the description of the items being purchased and the fact that one party intends to purchase those items from another party. Even for exchanges that do not cross any ownership boundaries, exchanges with services have similar aspects.

Especially in the case where the exchanges are across ownership boundaries, a critical issue is the interpretation of the data. This interpretation MUST be consistent between the participants in the service interaction. Consistent interpretation is a stronger requirement than merely type (or structural) consistency – the tokens in the data itself must also have a shared basis.

There is often a huge potential for variability in representing street addresses. For successful exchange of address information, all the participants must have a consistent view of the meaning of the address tokens if address information is to be reliably shared.

The formal descriptions of terms and the relationships between them (e.g., an ontology) provides a firm basis for selecting correct interpretations for elements of information exchanged.  For example, an ontology can be used to capture the alternate ways of expressing the name of a city as well as distinguishing a city name from a street name.

Note that, for the most part, it is not expected that service consumers and providers would actually exchange descriptions of terms in their interaction but, rather, would reference existing descriptions – the role of the semantics being a background one – and these references would be included in the service descriptions.

Specific domain semantics are beyond the scope of this reference model; but there is a requirement that the service interface enable providers and consumers to identify unambiguously those definitions that are relevant to their respective domains.

Behavioral model

The second key requirement for successful interactions with services is knowledge of the actions invoked against the service and the process or temporal aspects of interacting with the service. This is characterized as knowledge of the actions on, responses to, and temporal dependencies between actions on the service.

The sequences of actions involved are a critical aspect of the knowledge required for successful use of the service.

Action model

The action model of a service is the characterization of the actions that may be invoked against the service. Of course, a great portion of the behavior resulting from an action may be private; however, the expected public view of a service surely includes the implied effects of actions.

Process model

The process model characterizes the temporal relationships and temporal properties of actions and events associated with interacting with the service.

Note that although the process model is an essential part of this Reference Model, its extent is not completely defined. Some process models MAY include aspects that are not strictly part of SOA – for example, in this Reference Model we do not address the orchestration of multiple services, although orchestration and choreography may be part of the process model. At a minimum, the process model MUST cover the interactions with the service itself.

The reason that orchestration (and choreography) are not part of the SOA RM is that the focus of the RM is on modeling what service is and what key relationships are involved in modeling service.

Beyond the straightforward mechanics of interacting with a service there are other, higher-order, attributes of services’ process models that are also often important. These can include whether the service is idempotent, whether the service is long-running in nature and whether it is important to account for any transactional aspects of the service.

Previous: SOA-RM – Dynamics of services
Next: SOA-RM – Real world effect

SOA-RM – Real world effect

There is always a particular purpose associated with interacting with a service. Conversely, a service provider (and consumer) often has a priori conditions that apply to its interactions.  The service consumer is trying to achieve some result by using the service, as is the service provider. At first sight, such a goal can often be expressed as “trying to get the service to do something”.  This is sometimes known as the “real world effect” of using a service. For example, an airline reservation service can be used to learn about available flights, seating and ultimately to book travel – the desired real world effect being information and a seat on the right flight.

A real world effect can be the response to a request for information or the change in the state of some defined entities shared by the service participants. In this context, the shared state does not necessarily refer to specific state variables being saved in physical storage but rather represents shared information about the affected entities.  So in the example of the airline reservation, the shared state  – that there is a seat reserved on a particular flight – represents a common understanding between a future passenger and the airline. The details of actual state changes – whether on the part of the passenger (e.g. fund balances required to pay for the ticket) or of the airline (e.g. that a seat is sold for that flight)  – are not shared by the other.

SOA-RM Real world effect and shared state

Figure 1. Real world effect and shared state.

In addition, the internal actions that service providers and consumers perform as a result of participation in service interactions are, by definition, private and fundamentally unknowable. By unknowable we mean both that external parties cannot see others’ private actions and, furthermore, SHOULD NOT have explicit knowledge of them. Instead we focus on the set of facts shared by the parties – the shared state. Actions by service providers and consumers lead to modifications of this shared state; and the real world effect of a service interaction is the accumulation of the changes in the shared state.

There is a strong relationship between the shared state and the interactions that lead up to that state. The elements of the shared state SHOULD be inferable from that prior interaction together with other context as necessary. In particular, it is not required that the state be recorded; although without such recording it may become difficult to audit the interaction at a subsequent time.

Previous: SOA-RM – Interacting with services
Next: SOA-RM – Service description

SOA-RM – Service description

In support of the dynamics of interacting with services are a set of concepts that are about services themselves. These are the service description, the execution context of the service and the contracts and policies that relate to services and service participants.

SOA-RM - About services

Figure 1. About services.

Service description

One of the hallmarks of a Service Oriented Architecture is the large amount of associated documentation and description.

The service description represents the information needed in order to use a service. In most cases, there is no one “right” description but rather the elements of description required depend on the context and the needs of the parties using the associated entity. While there are certain elements that are likely to be part of any service description, most notably the information model, many elements such as function and policy may vary.

SOA-RM  - Service description

Figure 2. Service description.

The purpose of description is to facilitate interaction and visibility, particularly when the participants are in different ownership domains, between participants in service interactions. By providing descriptions, it makes it possible for potential participants to construct systems that use services and even offer compatible services.

For example, descriptions allow participants to discriminate amongst possible choices for service interaction; such as whether the service provides required capabilities, how to access the service, and negotiate over specific service functionality. In addition, descriptions can be used to support the management of services, both from the service provider’s perspective and the service consumer’s perspective.

Best practice suggests that the service description SHOULD be represented using a standard, referenceable format. Such a format facilitates the use of common processing tools (such as discovery engines) that can capitalize on the service description.

While the concept of a SOA supports use of a service without the service consumer needing to know the details of the service implementation, the service description makes available critical information that a consumer needs in order to decide whether or not to use a service.  In particular, a service consumer needs to possess the following items of information:

  1. That the service exists and is reachable;
  2. That the service performs a certain function or set of functions;
  3. That the service operates under a specified set of constraints and policies;
  4. That the service will (to some implicit or explicit extent) comply with policies as prescribed by the service consumer;
  5. How to interact with the service in order to achieve the required objectives, including the format and content of information exchanged between the service and the consumer and the sequences of information exchange that may be expected.

While each of these items SHOULD be represented in any service description, the details can be included through references (links) to external sources and are NOT REQUIRED to be incorporated explicitly.  This enables reuse of standard definitions, such as for functionality or policies.

Other sections of this document deal with these aspects of a service, but the following subsections discuss important elements as these relate to the service description itself.

Service reachability

Reachability is an inherently pairwise relationship between service providers and service consumers. However, a service description SHOULD include sufficient data to enable a service consumer and service provider to interact with each other. This MAY include metadata such as the location of the service and what information protocols it supports and requires. It MAY also include dynamic information about the service, such as whether it is currently available.

Service functionality

A service description SHOULD unambiguously express the function(s) of the service and the real world effects (see Section 3.2.3) that result from it being invoked.  This portion of the description SHOULD be expressed in a way that is generally understandable by service consumers but able to accommodate a vocabulary that is sufficiently expressive for the domain for which the service provides its functionality.  The description of functionality may include, among other possibilities, a textual description intended for human consumption or identifiers or keywords referenced to specific machine-processable definitions.  For a full description, it MAY indicate multiple identifiers or keywords from a number of different collections of definitions.

Part of the description of functionality may include underlying technical assumptions that determine the limits of functionality exposed by the service or of the underlying capability.  If the assumptions are not valid, the user may need to use another service to access the capability.

Policies related to a service

A service description MAY include support for associating policies with a service and providing necessary information for prospective consumers to evaluate if a service will act in a manner consistent with the consumer’s constraints.

Service interface

The service interface is the means for interacting with a service.  It includes the specific protocols, commands, and information exchange by which actions are initiated that result in the real world effects as specified through the service functionality portion of the service description.

The specifics of the interface SHOULD be syntactically represented in a standard referenceable format. These prescribe what information needs to be provided to the service in order to access its capabilities and interpret responses.  This is often referred to as the service’s information model.  It should be noted that the particulars of the interface format are beyond the scope of the reference model. However, the existence of interfaces and accessible descriptions of those interfaces are fundamental to the SOA concept.

While this discussion refers to a standard referenceable syntax for service descriptions, it is not specified how the consumer accesses the interface definition nor how the service itself is accessed.  However, it is assumed that for a service to be usable, its interface MUST be represented in a format that allows interpretation of the interface information by its consumers.

The limits of description

There are well-known theoretic limits on the effectiveness of descriptions – it is simply not possible to specify, completely and unambiguously, the precise semantics of and all related information about a service.

There will always be unstated assumptions made by the describer of a service that must be implicitly shared by readers of the description. This applies to machine processable descriptions as well as to human readable descriptions.

Fortunately, complete precision is not necessary – what is required is sufficient scope and precision to support intended use.

Another kind of limit of service descriptions is more straightforward: whenever a repository is searched using any kind of query there is always the potential for zero or more responses – no matter how complete the search queries or the available descriptions appear to be. This is inherent in the principles involved in search.

In the case that there is more than one response, this set of responses has to be converted into a single choice. This is a private choice that must be made by the consumer of the search information.

Previous: SOA-RM – Real world effect
Next: SOA-RM – Policies related to a service

SOA-RM – Policies and contracts

A policy represents some constraint or condition on the use, deployment or description of an owned entity as defined by any participant. A contract, on the other hand, represents an agreement by two or more parties. Like policies, agreements are also about the conditions of use of a service; they may also constrain the expected real world effects of using a service. The reference model is focused primarily on the concept of policies and contracts as they apply to services.  We are not concerned with the form or expressiveness of any language used to express policies and contracts.

SOA-RM - Policies and contractsFigure 1. Policies and contracts.

Service policy

Conceptually, there are three aspects of policies: the policy assertion, the policy owner (sometimes referred to as the policy subject) and policy enforcement.

For example, the assertion: “All messages are encrypted” is an assertion regarding the forms of messages. As an assertion, it is measurable: it may be true or false depending on whether the traffic is encrypted or not. Policy assertions are often about the way the service is realized; i.e., they are about the relationship between the service and its execution context.

A policy always represents a participant’s point of view. An assertion becomes the policy of a participant when they adopt the assertion as their policy. This linking is normally not part of the assertion itself. For example, if the service consumer declares that “All messages are encrypted”, then that reflects the policy of the service consumer. This policy is one that may be asserted by the service consumer independently of any agreement from the service provider.

Finally, a policy may be enforced. Techniques for the enforcement of policies depend on the nature of the policy. Conceptually, service policy enforcement amounts to ensuring that the policy assertion is consistent with the real world. This might mean preventing unauthorized actions to be performed or states to be entered into; it can also mean initiating compensatory actions when a policy violation has been detected.  An unenforceable constraint is not a policy; it would be better described as a wish.

Policies potentially apply to many aspects of SOA: security, privacy, manageability, Quality of Service and so on. Beyond such infrastructure-oriented policies, participants MAY also express business-oriented policies – such as hours of business, return policies and so on.

Policy assertions SHOULD be written in a form that is understandable to, and processable by, the parties to whom the policy is directed. Policies MAY be automatically interpreted, depending on the purpose and applicability of the policy and how it might affect whether a particular service is used or not.

A natural point of contact between service participants and policies associated with the service is in the service description. It would be natural for the service description to contain references to the policies associated with the service.

Service contract

Whereas a policy is associated with the point of view of individual participants, a contract represents an agreement between two or more participants. Like policies, contracts can cover a wide range of aspects of services: quality of service agreements, interface and choreography agreements and commercial agreements. Note that we are not necessarily referring to legal contracts here.

Thus, following the discussion above, a service contract is a measurable assertion that governs the requirements and expectations of two or more parties.  Unlike policy enforcement, which is usually the responsibility of the policy owner, contract enforcement may involve resolving disputes between the parties to the contract. The resolution of such disputes may involve appeals to higher authorities.

Like policies, contracts may be expressed in a form that permits automated interpretation. Where a contract is used to codify the results of a service interaction, it is good practice to represent it in a machine processable form. Among other purposes, this facilitates automatic service composition. Where a contract is used to describe over-arching agreements between service providers and consumers, then the priority is likely to make such contracts readable by people.

Since a contract is inherently the result of agreement by the parties involved, there is a process associated with the agreement action. Even in the case of an implicitly agreed upon contract, there is logically an agreement action associated with the contract, even if there is no overt action of agreement. A contract may be arrived at by a mechanism that is not directly part of an SOA – an out of band process. Alternatively, a contract may be arrived at during the course of a service interaction – an in-band process.

Previous: SOA-RM – Service description
Next: SOA-RM – Execution context.

SOA-RM – Execution context

The execution context of a service interaction is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction, and thus forms a path between those with needs and those with capabilities.

SOA-RM - Execution context

 

Figure 1. Execution context.

As discussed in previous sections of this document, the service description (and a corresponding description associated with the service consumer and its needs) contains information that can include preferred protocols, semantics, policies and other conditions and assumptions that describe how a service can and may be used.  The participants (providers, consumers, and any third parties as noted below) must agree and acknowledge a consistent set of agreements in order to have a successful service interaction, i.e. realizing the described real world effects.  The execution context is the collection of this consistent set of agreements.

The consumer and provider can be envisioned as separate places on a map and, for a service to actually be invoked, a path must be established between those two places.  This path is the execution context.  As with a path between places, it can be a temporary connection (e.g. a tenuous footbridge of an ad hoc exchange) or a well-defined coordination (e.g. a super highway) that can be easily reused in the future.

The execution context is not limited to one side of the interaction; rather it concerns the totality of the interaction – including the service provider, the service consumer and the common infrastructure needed to mediate the interaction. While there may be third parties, for example, government regulators, who set some of the conditions for the execution context, this merely increases the conditions and constraints needing to be coordinated and may require additional information exchange to complete the execution context.

The execution context is central to many aspects of a service interaction. It defines, for example, a decision point for policy enforcement relating to the service interaction. Note that a policy decision point is not necessarily the same as an enforcement point: an execution context is not by itself something that lends itself to enforcement. On the other hand, any enforcement mechanism of a policy is likely to take into account the particulars of the actual execution context.

The execution context also allows us to distinguish services from one another. Different instances of the same service – denoting interactions between a given service provider and different service

consumers for example – are distinguished by virtue of the fact that their execution contexts are different.

Finally, the execution context is also the context in which the interpretation of data that is exchanged takes place. A particular string has a particular meaning in a service interaction in a particular context – the execution context.

An execution context often evolves during a service interaction. The set of infrastructure elements, the policies and agreements that apply to the interaction, may well change during a given service interaction. For example, at an initial point in an interaction, it may be decided by the parties that future communication should be encrypted. As a result the execution context also changes – to incorporate the necessary infrastructure to support the encryption and continue the interaction.

Previous: SOA-RM – Policies and contracts

End of series on SOA-RM.

Service Oriented Architecture Ontology (SOA-O) – Introduction

Sources

Service Oriented Architecture Ontology version 1.0 – 2010
Service Oriented Architecture Ontology version 2.0 – 2014

Overview

The purpose of the SOA Ontology (SOA-O) is to develop and foster common understanding of the SOA in order to improve alignment between the business and information technology communities, and facilitate SOA adoption:

  1. The SOA-O defines the concepts, terminology, and semantics of SOA in both business and technical terms, in order to:
    1. Create a foundation for further work in domain-specific areas.
    2. Enable communications between business and technical people.
    3. Enhance the understanding of SOA concepts in the business and technical communities.
    4. Provide a means to state problems and opportunities clearly and unambiguously to promote mutual understanding.
    5. The SOA-O potentially contributes to model-driven SOA implementation.

    The OWL ontology is available online.

    The SOA-O is designed for use by:

    • Business people, to give them a deeper understanding of SOA concepts and how they are used in the enterprise and its environment.
    • Architects, as metadata for architectural artifacts.
    • Architecture methodologists, as a component of SOA meta-models.
    • System and software designers for guidance in terminology and structure.

    This standard defines a formal ontology for SOA. The ontology is represented in the Web Ontology Language (OWL) – using OWL-DL, one of three sub-languages that provides the greatest expressiveness possible while retaining computational completeness and decidability.

    The ontology contains classes and properties corresponding to the core concepts of SOA. The formal OWL definitions are supplemented by natural language descriptions of the concepts, with graphic illustrations of the relations between them, and with examples of their use. For purposes of exposition, the ontology also includes UML diagrams that graphically illustrate its classes and properties of the ontology. The natural language and OWL definitions contained in this specification constitute the authoritative definition of the ontology; the diagrams are for explanatory purposes only.

    SOA Ontology - UML Class Diagram

    Figure 1. SOA-O – Graphical Overview.

    The class hierarchy is as follows:

    SOA Ontology Class Hierarchy

    Figure 2. The SOA-O Class Hierarchy.

  2. Applications

    The SOA-O was developed in order

    1. to aid understanding, and
    2. potentially to be a basis for model-driven implementation.

    To aid understanding, this specification can simply be read. To be a basis for model-driven implementation, it should be applied to particular usage domains and application to example usage domains will aid understanding.

    The SOA-O can be used as a core for domain-specific ontologies that apply to the use of the SOA in particular sectors of commerce and industry. The ontology is applied to a particular usage domain by adding SOA OWL class instances of things in that domain. This is sometimes referred to as "populating the ontology". In additional, an application can add definitions of new classes and properties, can import other ontologies into the SOA-O, and can import the SOA-O into other ontologies.

    The ontology defines the relations between terms, but does not prescribe exactly how they should be applied.

    Previous: SOA-RM Service Oriented Architure Reference Model – Introduction
    Next: SOA-O – Element and System Classes

SOA-O – Element and System Classes

Element and system are two of the core concepts of the SOA Ontology (SOA-O).

Here we will describe two classes:

  1. Element
  2. System

and the following properties:

  1. uses and usedBy
  2. represents and representedBy

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

SOA Ontology - Class Element

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.

Example

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

System Class 

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:

SOA Ontology - Class System

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.

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

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:

SOA Ontology - Properties represents and representedBy

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:

  1. 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.
  2. 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.
  3. 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).

Example

Assume a company wants to form a new organizational unit (O1). There are two ways of doing this:

  1.  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.
  2. 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

SOA-O – HumanActor and Task Classes

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 the SOA-O 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 SOA-O:

  • HumanActor
  • Task

In addition, it defines the following properties:

  • does and doneBy

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:

SOA-O - HumanActor Class

Figure 1. SOA-O 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.

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

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

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.

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

SOA-O - Task Class

Figure 2. SOA-O 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.

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.

uses and usedBy Applied to Task

In one direction, the most common case of a task using another element is where an automated task 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).

represents and representedBy 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.

Previous: SOA-O – Element and System Classes
Next: SOA-O – ServiceClass

SOA-O – Service Class

Service is another core concept of this ontology. It is a concept that is fundamental to SOA and always used in practice when describing or engineering SOA systems, yet it is not easy to define formally. The SOA-O is based on the following definition of service:

“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.”

This corresponds to the existing official Open Group definition of the term.

The word “activity” in the definition above is here used in the general English language sense of the word, not in the process-specific sense of that same word (i.e., activities are not necessarily process activities). The SOA-O purposefully omits “business” as an intrinsic part of the definition of service. The reason for this is 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.

Other current SOA-specific definitions of the term service include:

  • “A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.” (Source: OASIS SOA Reference Model)
  • “A capability offered by one entity or entities to others using well-defined ‘terms and conditions’ and interfaces.” (Source: OMG SoaML Specification)

Within the normal degree of precision of the English language, these definitions are not contradictory; they are stressing different aspects of the same concept. All three definitions are SOA-specific though, and represent a particular interpretation of the generic English language term service.

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 concept of service is captured by the Service OWL class:

SOA-O - Service Class

Figure 1. SOA-O Service Class.

In the context of the SOA-O we consider only SOA-based services. Other domains, such as Integrated Service Management, can have services that are not SOA-based and hence are outside the intended scope of the SOA ontology.

Service is defined as disjoint with the System, Task, and HumanActor classes. Instances of these classes are considered not to be services themselves, even though they may provide capabilities that can be offered as services.

performs and performedBy Properties

As a service itself is only a logical representation, any service is performed by something. The something that performs a service must be opaque to anyone interacting with it, an opaqueness which is the exact nature of the Element class. This concept is captured by the performs and performedBy properties as illustrated in The Service Class (Figure 1). This also captures the fact that services can be performed by elements of other types than systems. This includes elements such as software components, human actors, and tasks.

Note that the same instance of Service can be performed by many different instances of Element. As long as the service performed is the same, an external observer cannot tell the difference (for contractual obligations, SLAs, etc. Conversely, any instance of Element may perform more than one service or none at all.

While a service can be performed by other elements, the service itself (as a purely logical representation) does not perform other services.

Service Consumers and Service Providers

Terminology used in an SOA environment often includes the notion of service providers and service consumers. There are two challenges with this terminology:

  • It does not distinguish between the contractual obligation aspect of consume/provide and the interaction aspect of consume/provide. A contractual obligation does not necessarily translate to an interaction dependency, if for no other reason than because the realization of the contractual obligation may have been sourced to a third party.
  • The above are the reasons why the ontology has chosen not to adopt consume and provide as core concepts, rather instead allows consume or provide terms used with contractual obligations and/or interaction rules described by service contracts. In its simplest form, outside the context of a formal service contract, the interaction aspect of consuming and providing services may even be expressed simply by saying that some element uses (consumes) a service or that some element performs (provides) a service.
  • Consuming or providing a service is a statement that only makes sense in context – either a contractual context or an interaction context. These terms are consequently not well suited for making statements about elements and services in isolation.

uses and usedBy Properties Applied to Service

In one direction, it does not really make sense to talk about a service that uses another element. While the thing that performs the service might very well include the use of other elements (and certainly will in the case of service composition), the service itself (as a purely logical representation) does not use other elements.

In the other direction, we find the most common of all interactions in an SOA environment: the notion that some element uses a service by interacting with it. Note that from an operational perspective this interaction actually reaches somewhat beyond the service itself by involving the following typical steps:

  • Picking the service to interact with (this statement is agnostic as to whether this is done dynamically at runtime or statically at design and/or construct time)
  • Picking an element that performs that service (in a typical SOA environment, this is most often done “inside” an Enterprise Service Bus (ESB))
  • Interacting with the chosen element (that performs the chosen) service (often also facilitated by an ESB)

represents and representedBy Properties Applied to Service

Concepts such as service mediations, service proxies, ESBs, etc. are natural to those practitioners that describe and implement the operational aspects of SOA systems. From an ontology perspective all of these can be captured by some other element representing the service – a level of indirection that is critical when we do not want to bind operationally to a particular service endpoint, rather we want to preserve loose-coupling and the ability to switch embodiments as needed. Note that by leveraging the represents and representedBy properties in this fashion we additionally encapsulate the relatively complex operational interaction pattern that was described in the section above (picking the service, picking an element that performs the service, and interacting with that chosen element).

While a service being represented by something else is quite natural, it is harder to imagine what the service itself might represent. To some degree we have already captured the fact that a service represents any embodiment of it, only we have chosen to use the performs and performedBy properties to describe this rather than the generic represents and representedBy properties. As a consequence, we do not expect practical applications of the ontology to have services represent anything.

Exemplifying the Difference between Doing a Task and Performing a Service

The distinction between a human actor doing a task and an element (technology, human actor, or other) performing a service is important. The human actor doing the task has the responsibility that it gets done, yet may in fact in many cases leverage some service to achieve that outcome:

  • John is an instance of HumanActor.
  • WashWindows is an instance of Task and is done by John.
  • SoapWater is an instance of Service.
  • WaterTap is an instance of Element.
  • WaterTap performs SoapWater.
  • John uses SoapWater (to do WashWindows).

Note how clearly SoapWater does not do WashWindows, nor does WaterTap do WashWindows.

Previous: SOA-O – HumanActor and Task Classes
Next: SOA-O – ServiceContract and Effect Classes

SOA-O ServiceContract and Effect Classes

ServiceContract Class

In many cases, specific agreements are needed in order to define how to use a service. This can either be because of a desire to regulate such use or can simply be because the service will not function properly unless interaction with it is done in a certain sequence. A service contract defines the terms, conditions, and interaction rules that interacting participants 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. The concept of service contract is captured by the ServiceContract OWL class:

SOA-O - ServiceContract Class

Figure 1. SOA-O ServiceContract Class.

interactionAspect and legalAspect Datatype Properties

Service contracts explicitly regulate both the interaction aspects (see the hasContract and isContractFor properties) and the legal agreement aspects (see the involvedParty and isPartyTo properties) of using a service. The two types of aspects are formally captured by defining the interactionAspect and legalAspect datatype properties on the ServiceContract class. Note that the second of these attributes, the legal agreement aspects, includes concepts such as Service-Level Agreements (SLAs).

If desired, it is possible as an architectural convention to split the interaction and legal aspects into two different service contracts. Such choices will be up to any application using this ontology.

hasContract and isContractFor Properties

The hasContract property, and its inverse isContractFor, capture the abstract notion of a service having a service contract. Anyone wanting to use a service must obey the interaction aspects (as defined in the interactionAspect datatype property) of any service contract applying to that interaction. In that fashion, the interaction aspects of a service contract are contextindependent; they capture the defined or intrinsic ways in which a service may be used.

By definition, any service contract must be a contract for at least one service. It is possible that the same service contract can be a contract for more than one service; for instance, in cases where a group of services share the same interaction pattern or where a service contract (legally – see the involvesParty and isPartyTo properties below) regulates the providing and consuming of multiple services.

involvesParty and isPartyTo Properties

In addition to the rules and regulations that intrinsically apply to any interaction with a service (the interaction aspect of service contracts captured in the interactionAspect datatype property) there may be additional legal agreements that apply to certain human actors and their use of services. The involvesParty property, and its inverse isPartyTo, capture the abstract notion of a service contract specifying legal obligations between human actors in the context of using the one or more services for which the service contract is a contract.

While the involvesParty and isPartyTo properties define the relationships to human actors involved in the service contract, the actual legal obligations on each of these human actors is defined in the legalAspect datatype property on the service contract. This includes the ability to define who is the provider and who is the consumer from a legal obligation perspective.

There is a many-to-many relationship between service contracts and human actors. A given human actor may be party to none, one, or many service contracts. Similarly, a given service contract may involve none, one, or multiple human actors (none in the case where that particular service contract only specifies the interactionAspect datatype property). Note that it is important we allow for sourcing contracts where there is a legal agreement between human actor A and human actor B (both of which are party to a service contract), yet human actor B has sourced the performing of the service to human actor C (aka human actor C performs the service in question, not human actor B).

The involvesParty property together with the legalAspect datatype property on ServiceContract capture not just transient obligations. They include the ability to express “is obliged to at this instant”, “was obliged to”, and “may in future be obliged to”.

Effect Class

Interacting with something performing a service has effects. These comprise the outcome of that interaction, and are how a service (through the element that performs it) delivers value to its consumers. The concept of effect is captured by the Effect OWL class:

SOA-O Effect Class

Figure 2. SOA-O Effect Class.

Note that the Effect class purely represents how results or value is delivered to someone interacting with a service. Any possible internal side-effects are explicitly not covered by the Effect class.

Effect is defined as disjoint with the ServiceInterface class. (The ServiceInterface class is defined later in this document.) Interacting with a service through its service interface can have an outcome or provide a value (an instance of Effect), but the service interface itself does not constitute that outcome or value.

specifies and isSpecifiedBy Properties

While a service intrinsically has an effect every time someone interacts with it, in order to trust the effect to be something in particular, the effect needs to be specified as part of a service contract. The specifies property, and its inverse isSpecifiedBy, capture the abstract notion of a service contract specifying a particular effect as part of the agreement for using a service. Note that the specified effect can apply to both the interactionAspect datatype property (simply specifying what will happen when interacting with the service according to the service contract) and the legalAspect datatype property (specifying a contractually promised effect).

Anyone wanting a guaranteed effect of the interaction with a given service must ensure that the desired effect is specified in a service contract applying to that interaction. By definition, any service contract must specify at least one effect. In the other direction, an effect must be an effect of at least one service contract; this represents that fact that we have chosen only to formalize those effects that are specified by service contracts (and not all intrinsic effects of all services).

ServiceContract Examples

Service-Level Agreements

A Service-Level Agreement (SLA) on a service has been agreed by organizations A and B. It is important to realize that an SLA always has a context of the parties that have agreed to it, involving at a minimum one legal “consumer” and one legal “provider”. This can be represented in the ontology as follows:

  • A and B are instances of HumanActor.
  • Service is an instance of Service.
  • ServiceContract is an instance of ServiceContract.
  • ServiceContract isContractFor Service.
  • ServiceContract involvesParty A.
  • ServiceContract involvesParty B.

The legalAspect datatype property on ServiceContract describes the SLA.

Service Sourcing

Organizations A and B have agreed on B providing certain services for A, yet B wants to source the actual delivery of those services to third-party C. This can be represented in the ontology as follows:

  • A, B, and C are instances of HumanActor.
  • Service is an instance of Service.
  • C provides Service.
  • ServiceContract is an instance of ServiceContract.
  • ServiceContract isContractFor Service.
  • ServiceContract involvesParty A.
  • ServiceContract involvesParty B.

The legalAspect datatype property on ServiceContract describes the legal obligation of B to provide Service for A.

Previous: SOA-O – Service Class
Next: SOA-O- ServiceInterface and InformationType Classes

SOA-O ServiceInterface and Informationtype Classes

ServiceInterface Class

An important characteristic of services is that they have simple, well-defined interfaces. This makes it easy to interact with them, and enables other elements to use them in a structured manner. A service interface defines the way in which other elements can interact and exchange information with a service. This concept is captured by the ServiceInterface OWL class:

SOA-O ServiceInterface Class
Figure 1. SOA-O ServiceInterface Class.

The concept of an interface is in general well understood by practitioners, including the notion that interfaces define the parameters for information passing in and out of them when invoked. What differs from domain to domain is the specific nature of how an interface is invoked and how information is passed back and forth. Service interfaces are typically, but not necessarily, message-based (to support loose-coupling). Furthermore, service interfaces are always defined independently from any service implementing them (to support loose-coupling and service mediation).

From a design perspective interfaces may have more granular operations or may be composed of other interfaces. We have chosen to stay at the concept level and not include such design aspects in the ontology.

ServiceInterface is defined as disjoint with the Service, ServiceContract, and Effect classes. Instances of these classes are considered not to define (by themselves) the way in which other elements can interact and exchange information with a service. Note that there is a natural synergy between ServiceInterface and the interactionAspect datatype property on ServiceContract, as the latter defines any multi-interaction and/or sequencing constraints on how to use a service through interaction with its service interfaces.

Constraints Datatype Property

The Constraints datatype property on ServiceInterface captures the notion that there can be constraints on the allowed interaction such as only certain value ranges allowed on given parameters. Depending on the nature of the service and the service interface in question, these constraints may be defined either formally or informally (the informal case being relevant at a minimum for certain types of real-world services).

hasInterface and isInterfaceOf Properties

The hasInterface property, and its inverse isInterfaceOf, capture the abstract notion of a service having a particular service interface.

In one direction, any service must have at least one service interface; anything else would be contrary to the definition of a service as a representation of a repeatable activity that has a specified outcome and is a ‘black box’ to its consumers. In the other direction, there can be service interfaces that are not yet interfaces of any defined services. Also, the same service interface can be an interface of multiple services. The latter does not mean that these services are the same, nor even that they have the same effect; it only means that it is possible to interact with all these services in the manner defined by the service interface in question.

InformationType Class

A service interface can enable another element to give information to or receive information from a service (when it uses that service); specifically the types of information given or received. The concept of information type is captured by the InformationType OWL class:

SOA-O InformationType Class

Figure 2. SOA-O InformationType Class

In any concrete interaction through a service interface the information types on that interface are instantiated by information items, yet for the service interface itself it is the types that are important. Note that the constraints datatype property on ServiceInterface, if necessary, can be used to express constraints on allowed values for certain information types.

hasInput and isInputAt Properties

The hasInput property, and its inverse isInputAt, capture the abstract notion of a particular type of information being given when interacting with a service through a service interface.

Note that there is a many-to-many relationship between service interfaces and input information types. A given information type may be input at many service interfaces or none at all. Similarly, a given service interface may have many information types as input or none at all. It is important to realize that some services may have only inputs (triggering an asynchronous action without a defined response) and other services may have only outputs (elements performing these services execute independently yet may provide output that is used by other elements).

hasOutput and isOutputAt Properties

The hasOutput property, and its inverse isOutputAt, capture the abstract notion of a particular type of information being received when interacting with a service through a service interface.

Note that there is a many-to-many relationship between service interfaces and output information types. A given information type may be output at many service interfaces or none at all. Similarly, a given service interface may have many information types as output or none at all. It is important to realize that some services may have only inputs (triggering an asynchronous action without a defined response) and other services may have only outputs (elements performing these services execute independently yet may provide output that is used by other elements).

Examples

Interaction Sequencing

A service contract on a service expresses that the services interfaces on that service must be used in a certain order:

  • Service is an instance of Service.
  • ServiceContract is an instance of ServiceContract.
  • ServiceContract isContractFor Service.
  • X is an instance of ServiceInterface.
  • X isInterfaceOf Service.
  • Y is an instance of ServiceInterface.
  • Y isInterfaceOf Service.

The interactionAspect datatype property on ServiceContract describes that X must be used before Y may be used.

Previous: SOA-O – ServiceContract and Effect Classes
Next: SOA-O – Composition Class

SOA-O Composition Class

The notion of composition is a core concept of SOA. Services can be composed of other services. Processes are composed of human actors, tasks, and possibly services. Experienced SOA practitioners intuitively apply composition as an integral part of architecting, designing, and realizing SOA systems; in fact, any well structured SOA environment is intrinsically composite in the way services and processes support business capabilities. What differs from practitioner to practitioner is the exact nature of the composition – the composition pattern being applied.

A composition is the result of assembling a collection of things for a particular purpose. Note in particular that we have purposefully distinguished between the act of composing and the resulting composition as a thing, and that it is in the latter sense we are using the concept of composition here. The concept of composition is captured by the Composition OWL class:

SOA-O Composition Class

Figure 1. SOA-O Composition Class.

Being intrinsically (also) an organized collection of other, simpler things, the Composition class is a subclass of the System class. While a composition is always also a system, a system is not necessarily a composition in that it is not necessarily a result of anything – note here the difference between a system producing a result and the system itself being a result. A perhaps more tangible difference between a system and a composition is that the latter must have associated with it a specific composition pattern that renders the composition (as a whole) as the result when that composition pattern is applied to the elements used in the composition. One implication of this is that there is not a single member of a composition that represents (as an element) that composition as a whole; in other words, the composition itself is not one of the things being assembled. On the other hand, composition is in fact a recursive concept (as are all subclasses of System) – being a system, a composition is also an element which means that it can be used by a higher-level composition.

In the context of the SOA-O we consider in detail only functional compositions that belong to the SOA domain. Note that a fully described instance of Composition must have by its nature a uses relationship to at least one instance of Element. (It need not necessarily have more than one as the composition pattern applied may be, for instance, simply a transformation.) Again (as for System) it is important to realize that a composition can use elements outside its own boundary.

Since Composition is a subclass of Element, all compositions have a boundary and are opaque to an external observer (black box view). The composition pattern in turn is the internal viewpoint (white box view) of a composition. As an example, for the notion of a service composition this would correspond to the difference between seeing the service composition as an element providing a (higher-level) service or seeing the service composition as a composite structure of (lower-level) services.

compositionPattern Datatype Property

As discussed above, any composition must have associated with it a specific composition pattern, that pattern describing the way in which a collection of elements is assembled to a result. The concept of a composition pattern is captured by the compositionPattern datatype property. Note that even though certain kinds of composition patterns are of special interest within SOA, the compositionPattern datatype property may take any value as long as that value describes how to assemble the elements used by the composition with which it is associated.

The Orchestration Composition Pattern

One kind of composition pattern that has special interest within SOA is an orchestration. In an orchestration (a composition whose composition pattern is an orchestration), there is one particular element used by the composition that oversees and directs the other elements. Note that the element that directs an orchestration by definition is different than the orchestration (Composition instance) itself.

Think of an orchestrated executable workflow as an example of an orchestration. The workflow construct itself is one of the elements being used in the composition, yet it is different from the composition itself – the composition itself is the result of applying (executing) the workflow on the processes, human actors, services, etc. that are orchestrated by the workflow construct.

A non-IT example is the foreman of a road repair crew. If the foreman chooses to exert direct control over the tasks done by his crew, than the resulting composition becomes an orchestration (with the foreman as the director and provider of the composition pattern). Note that under other circumstances, with a different team composition model, a road repair crew can also act as a collaboration or a choreography. (See below for definitions of collaboration and choreography.) As the last example clearly shows, using an orchestration composition pattern is not a guarantee that “nothing can go wrong”. That would, in fact, depend on the orchestration director’s ability to handle exceptions.

The Choreography Composition Pattern

Another kind of composition pattern that has special interest within SOA is a choreography. In a choreography (a composition whose composition pattern is a choreography) the elements used by the composition interact in a non-directed fashion, yet with each autonomous member knowing and following a predefined pattern of behavior for the entire composition.

Think of a process model as an example of a choreography. The process model does not direct the elements within it, yet does provide a predefined pattern of behavior that each such element is expected to conform to when “executing”.

The Collaboration Composition Pattern

A third kind of composition pattern that has special interest within SOA is a collaboration. In a collaboration (a composition whose composition pattern is a collaboration) the elements used by the composition interact in a non-directed fashion, each according to their own plans and purposes without a predefined pattern of behavior. Each element simply knows what it has to do and does it independently, initiating interaction with the other members of the composition as applicable on its own initiative. This means that there is no overall predefined “flow” of the collaboration, though there may be a run-time “observed flow of interactions”.

A good example of a collaboration is a work meeting. There is no script for how the meeting will unfold and only after the meeting has concluded can we describe the sequence of interactions that actually occurred.

orchestrates and orchestratedBy Properties

As defined above, an orchestration has one particular element that oversees and directs the other elements used by the composition. This type of relationship is important enough that we have chosen to capture the abstract notion in the orchestrates property and its inverse orchestratedBy.

In one direction, a composition has at most one element that orchestrates it, and the cardinality can only be one (1) if in fact the composition pattern of that composition is an orchestration. In the other direction, an element can orchestrate at most one composition which then must have an orchestration as its composition pattern.

Note that in practical applications of the ontology, even though Service is a subclass of Element, a service (as a purely logical representation) is not expected to orchestrate a composition.

Previous: SOA-O ServiceInterface and InformationType Classes
Next: SOA-O ServiceComposition and Process Classes

SOA-O ServiceComposition and Process Classes

ServiceComposition Class

A key SOA concept is the notion of service composition, the result of assembling a collection of services in order to perform a new higher-level service. The concept of service composition is captured by the ServiceComposition OWL class:

SOA-O ServiceComposition Class

Figure 1. SOA-O ServiceComposition Class.

As a service composition is the result of assembling a collection of services, ServiceComposition is naturally a subclass of Composition.

A service composition may, and typically will, add logic (or even “code”) via the composition pattern. Note that a service composition is not the new higher-level service itself (due to the System and Service classes being disjoint); rather it performs (as an element) that higher-level service.

Process Class

Another key SOA concept is the notion of process. A process is a composition whose elements are composed into a sequence or flow of activities and interactions with the objective of carrying out certain work. This definition is consistent with, for instance, the Business Process Modeling Notation (BPMN) 2.0 definition of a process. The concept of process is captured by the Process OWL class:

SOA-O Process Class

Figure 2. SOA-O Process Class.

Elements in process compositions can be things like human actors, tasks, services, other processes, etc. A process always adds logic via the composition pattern; the result is more than the parts. According to their collaboration pattern, processes can be:

  • Orchestrated: When a process is orchestrated in a business process management system, then the resulting IT artifact is in fact an orchestration; i.e., it has an orchestration collaboration pattern. This type of process is often called a process orchestration.
  • Choreographed: For example, a process model representing a defined pattern of behavior. This type of process is often called a process choreography.
  • Collaborative: No (pre)defined pattern of behavior (model); the process represents observed (executed) behavior.

Examples

Simple Service Composition Example

Using a service composition example, services A and B are instances of Service and the composition of A and B is an instance of ServiceComposition (that uses A and B):

  • A and B are instances of Service.
  • X is an instance of ServiceComposition.
  • X uses both A and B (composes them according to its service composition pattern).

Note that there are various ways in which the service composition pattern can compose A and B, all of which are relevant in one situation or another. For example, interfaces of X may or may not include some subset of the interfaces of A and B. Furthermore, the interfaces of A and B may or may not also be (directly) invocable without going through X – that is a matter of the service contracts and/or access policies that apply to A and B. Finally, X may also use other elements that are not services at all (examples are composition code, adaptors, etc.).

Process Example

Using a process example, tasks T1 and T2 are instances of Task, roles R1 and R2 are instances of Element, and the composition of T1, T2, R1, and R2 is an instance of Process (that uses T1, T2, R1, and R2):

  • T1 and T2 are instances of Task.
  • R1 and R2 are instances of Element.
  • Y is an instance of Process.
  • Y uses all of T1, T2, R1, and R2 (composes them according to its process composition pattern).

Process and Service Composition Example

Elaborating on the process example above, if T1 is done using service S then:

  • S is an instance of Service.
  • T1 uses S.

Note that depending on the particular design approach chosen (and the resulting composition pattern), Y may or may not use S directly. This depends on whether Y carries the binding between T1 and S or whether that binding is encapsulated in T1.

Previous: SOA-O Composition Class
Next: SOA-O Policy Class

SOA-O Policy Class

Policies, the human actors defining them, and the things that they apply to are important aspects of any system, certainly also SOA systems with their many different interacting elements. Policies can apply to any element in a system. The concept of policy is captured by the Policy class and its relationships to the HumanActor and Thing classes.

A policy is a statement of direction that a human actor may intend to follow or may intend that another human actor should follow. Knowing the policies that apply to something makes it easier and more transparent to interact with that something. The concept of policy is captured by the Policy OWL class:

SOA-O Policy Class

Figure 1. SOA-O Policy Class.

Policy as a concept is generic and has relevance outside the domain of SOA. For the purposes of this SOA ontology it has not been necessary or relevant to restrict the generic nature of the Policy class itself. The relationships between Policy and HumanActor are of course bound by the SOA-specific restrictions that have been applied on the definition of HumanActor.

From a design perspective policies may have more granular parts or may be expressed and made operational through specific rules. We have chosen to stay at the concept level and not include such design aspects in the ontology.

Policy is distinct from all other concepts in this ontology, hence the Policy class is defined as disjoint with all other defined classes. In particular, Policy is disjoint with ServiceContract. While policies may apply to service contracts – such as security policies on who may change a given service contract – or conversely be referred to by service contracts as part of the terms, conditions, and interaction rules that interacting participants must agree to, service contracts are themselves not policies as they do not describe an intended course of action.

appliesTo and isSubjectTo Properties

Policies can apply to things other than elements; in fact, policies can apply to anything at all, including other policies. For instance, a security policy might specify which actors have the authority to change some other policy. The appliesTo property, and its inverse isSubjectTo, capture the abstract notion that a policy can apply to any instance of Thing. Note specifically that Element is a subclass of Thing, hence policies by inference can apply to any instance of Element.

In one direction, a policy can apply to zero (in the case where a policy has been formulated but not yet explicitly applied to anything), one, or more instances of Thing. Note that having a policy apply to multiple things does not mean that these things are the same, only that they are (partly) regulated by the same intent. In the other direction, an instance of Thing may be subject to zero, one, or more policies. Note that where multiple policies apply to the same instance of Thing this is often because the multiple policies are from multiple different policy domains (such as security and governance).

The SOA ontology does not attempt to enumerate different policy domains; such policy-focused details are deemed more appropriate for a policy ontology. It is worth pointing out that a particular policy ontology may also restrict (if desired) the kinds of things that policies can apply to.

setsPolicy and isSetBy Properties

The setsPolicy property, and its inverse isSetBy, capture the abstract notion that a policy can be set by one or more human actors.

In one direction, a policy can be set by zero (in the case where actors setting the policy by choice are not defined or captured), one, or more human actors. Note specifically that some policies are set by multiple human actors in conjunction, meaning that all these human actors need to discuss and agree on the policy before it can take effect. A real-world example would be two parents in conjunction setting policies for acceptable child behavior. In the other direction, a human actor may potentially set (or be part of setting) multiple policies.

The SOA ontology purposefully separates the setting of the policy itself and the application of the policy to one or more instances of Thing. In some cases these two acts may be inseparably bound together, yet in other cases they are definitely not. One such example is an overall compliance policy that is formulated at the corporate level yet applied by the compliance officer in each line of business.

Also, while a particular case of interest for this ontology is that where the provider of a service has a policy for the service, a policy for a service is not necessarily owned by the provider. For example, government food and hygiene regulations (a policy that is law) cover restaurant services independently of anything desired or defined by the restaurant owner.

Previous: SOA-O ServiceComposition and Process Classes
Next: SOA-O Event Class

SOA-O Event Class

An event is something that happens, to which an element may choose to respond. Events can be responded to by any element. Similarly, events may be generated (emitted) by any element. Knowing the events generated or responded to by an element makes it easier and more transparent to interact with that element. Note that some events may occur whether generated or responded to by an element or not. The concept of event is captured by the Event OWL class:

SOA-O Event Class

Figure 1. SOA-O Event Class.

Event as a concept is generic and has relevance to the domain of SOA as well as many other domains. For the purposes of this ontology, event is used in its generic sense.

From a design perspective events may have more granular parts or may be expressed and made operational through specific syntax or semantics. We have chosen to stay at the concept level and not include such design aspects in the ontology.

generates and generatedBy Properties

Events can, but need not necessarily, be generated by elements. The generates property, and its inverse generatedBy, capture the abstract notion that an element generates an event.

Note that the same event may be generated by many different elements. Similarly, the same element may generate many different events.

respondsTo and respondedToBy Properties

Events can, but need not necessarily, be responded to by elements. The respondsTo property, and its inverse respondedToBy, capture the abstract notion that an element responds to an event.

Note that the same event may be responded to by many different elements. Similarly, the same element may respond to many different events.

Previous: SOA-O Policy Class
Next: Service Oriented Architecture Modeling Language (SoaML) – Introduction

Service oriented architecture Modeling Language (SoaML) – Introduction

Overview

Service Oriented Architecture (SOA) is a paradigm for defining how people, organizations and systems provide and use services to achieve results.

The Service oriented architecture Modeling Language (SoaML) provides a metamodel for specifying and designing services within a service-oriented architecture. 1

The SoaML extends the capabilities of the Unified Modeling Language (UML) to support:

  • Identifying services, the requirements they are intended to fulfill, and the anticipated dependencies between them
  • Specifying services, including the functional capabilities they provide, what capabilities consumers are expected to provide, the protocols or rules for using them, and the service information exchanged between consumers and providers
  • Defining service consumers and providers, what requisition and services they consume and provide, how they are connected, and how the service functional capabilities are used by consumers and implemented by providers in a manner consistent with both the service specification protocols and fulfilled requirements
  • The policies for using and providing services
  • The ability to define classification schemes having aspects to support a broad range of architectural, organizational, and physical partitioning schemes and constraints
  • Defining service and service usage requirements, and linking them to related metamodels, e.g. the Business Motivation Model (BMM), the UML UseCase model

Previous: SOA-O Event Class
Next: SOA-3 Overview

Resources

Next: Identifying services

  1. The SoaML focuses on basic service modeling concepts. The intention is to use this as a foundation for further extensions both related to integration with other metamodels like the Ontology Definition Metamodel (ODM), the Organization Structure Metamodel (OSM), the Semantics of Business Vocabulary and Business Rules (SBVR), the Business Process Definition Metamodel (BPDM), and the Business Process Model Notation (BPMN).

SOA-3 Overview

We bring together our presentations of the SOA-RM, the SOA-O, and the SoaML under two categories:

  1. Conformance with the Reference Model
  2. Cross-coverage of core concepts

Conformance

The authors of the Conformance Guidelines of the Reference Model for Service Oriented Architecture (SOA-RM, section 4) expect that any design for a system that adopts the SOA approach will:

  • Have entities that can be identified as services as defined by this Reference Model;
  • Be able to identify how visibility is established between service providers and consumers;
  • Be able to identify how interaction is mediated;
  • Be able to identify how the effect of using services is understood;
  • Have descriptions associated with services;
  • Be able to identify the execution context required to support interaction; and
  • It will be possible to identify how policies are handled and how contracts may be modeled and enforced.

SoaML’s Conformance with SOA-RM

Be able to identify how visibility is established between service providers and consumer

SoaML defines a Service metaclass –  a kind of UML Port, which establishes the interaction point between service consumers and providers. A Service’s type is a ServiceInterface that provides all the information needed by a consumer to use a service. Mechanisms for discovering existing services and descriptions consumers would use to determine the applicability of availability of existing services for their needs (awareness) are out of scope.

Be able to identify how interaction is mediated

Interaction between a service consumer and provider connected through a service channel is mediated by the protocol specified by the service provider. The protocol is defined by the service interface used as the type of the service and may include a behavior that specifies the dynamic aspects of service interaction. The interfaces  realized and used by a service specification define the operations, parameters, preconditions, post conditions (real world effect), exceptions and other policy constraints that make up the static portion of the service specification.

Be able to identify how the effect of using services is understood

The effect of a service is specified by the post conditions of the provided service operations assuming the consumer follows the policies, preconditions, and protocols specified by the service interface.

Have descriptions associated with services

This specification includes a service interface for describing the means of interacting with a service. Service discovery and applicability are out of scope.

Be able to identify the execution context required to support interaction

The execution context is specified by the semantics for UML2 as extended by this specification.

It will be possible to identify how policies are handled and how contracts may be modeled and enforced

Policies are constraints that can be owned rules of any model element, including in particular service ports and service participant components. The actual form of these policies is out of scope.

The authors of the SoaML have also collected other definitions around services and SOA and are analyzing this with respect to further need for harmonization between the standardization groups, in particular for the use of the concept service.

SOA-O Conformance with SOA-RM

The Open Group SOA Ontology extends, refines, and formalizes some of the core concepts of the SOA RM. It is used for understanding of core SOA concepts and facilitates a model-driven approach to SOA development.

Cross Coverage of Core Concepts

The authors of the Service Oriented Architecture Modeling Language (SoaML, Appendix A) provided a table that compared the definition of the main concepts of the SOA-RM, the SOA-O (older version), and the SoaML:

Concept SoaML SOA-RM SOA-O
Service Oriented Architecture An architectural paradigm for defining how people, organizations and systems provide and use services to achieve results. A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. An architectural style that supports service orientation.  An architectural style is the combination of distinctive features in which architecture is performed or expressed.
Service Service is defined as a resource that enables access to one or more capabilities. Here, the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.  This access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. A service is provided by an entity—called the provider—for use by others.  The eventual consumers of the service may not be known to the service provider and may demonstrate uses of the service beyond the scope originally conceived by the provider. A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. A logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data, consolidate drilling reports). It is self-contained, may be composed of other services, and is a “black box” to its consumers.
Service Contract A ServiceContract is the formalization of a binding exchange of information, goods, or obligations between parties defining a service. A ServiceContract is the specification of the agreement between providers and consumers of service as to what information, products, assets, value, and obligations will flow between the providers and consumers of that service – it specifies the service without regard for realization or implementation. A contract represents an agreement by two or more parties. A service contract is a measurable assertion that governs the requirements and expectations of two or more parties. Adopts SOA-RM definition
Service Interface Defines the interface to a Service or Request. A ServiceInterface defines the interface and responsibilities of a participant to provide or consume a service. It is used as the type of a Service or Request port. A ServiceInterface is the means for specifying how to interact with a Service. Service Description The information needed in order to use, or consider using, a service. Description An information item that is represented in words, possibly accompanied by supporting material such as graphics. The Description class corresponds to the concept of a description as a particular kind of information item that applies to something in particular – the thing that it describes. It is not just a set of words that could apply to many things.
Collaboration Collaboration from UML is extended to describe ServiceContracts and ServicesArchitectures. Interaction: The activity involved in making using of a capability offered, usually across an ownership boundary, in order to achieve a particular desired real-world effect.
CollaborationUse CollaborationUse shows how a Collaboration (ServiceContracts and ServiceArchitectures) is fulfilled.
Capability Identifies or specifies a cohesive set of functions or capabilities that a service provides. The ability to act and produce an outcome that achieves a result. As such, capability involves the capacity, power, or fitness for some specified action or operation. This implies that the entity must have physical, mental, or legal power to generate an outcome that achieves a real world effect. (synonymous with capability). A Capability models the capability for providing, or provided by, a service specified by a ServiceContract or ServiceInterface.
Participant The type of a provider and/or consumer of services.  In the business domain a participant may be a person, organization, or system.  In the systems domain a participant may be a system or component. Not explicitly defined
Request Port (port stereotype) A request port defines the port through which a Participant makes requests and uses or consumes services.
Service Port (port stereotype) The service port stereotype of a port defines the connection point the point of interaction on a Participant where a service is actually provided or consumed.
ServiceChannel A communication path between Requests and Services.
Real World Effect Defined as “service operation post condition.” The actual result of using a service, rather than merely the capability offered by a service provider. Defined as Effect. Comprises the outcome of performance of the service, and is the value delivered.

Previous: SoaML – Introduction
Next: SOA-3 Service

SOA-3 – Service

Definitions of Service

Service Oriented Architecture (SOA) is, above all, an approach that specifies how entities can best work together to meet a set of objectives. SOA separates what needs to get done from how it gets done, where it gets done, and what or who gets it done.

Current SOA-related standards stress different aspects of the meaning of “service”:

  • “A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.” (OASIS SOA Reference Model – SOA-RM)
  • “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 Open Group: Service Oriented Architecture Ontology – SOA-O)
  • “A service is value delivered to another through a well-defined interface and available to a community (which may be the general public). A service results in work provided to one by another.” (Object Management Group: Service Oriented Architecture Modeling Lanaguage – SoaML)

A consumer accesses a service by means of a service interface, comprising the specific of how to access an underlying capability offered by the .

A consumer may be unknown to the provider.

A service is opaque, that is, its implementation is typically hidden from the service consumer (“black box”) except for the information required by service consumers to determine whether a given service is appropriate to their needs, and for the behavior model exposed through the service interface (“white box”).

The consequence of invoking a service is a realization of some real world effect that may include:

  1. information returned in response to a request for that information,
  2. a change to the shared state of defined entities, or
  3. some combination of (1) and (2).

Typically the consumer does not know how the information in (1) is generated, or how the state change in (2) is effected.

A consumer may demonstrate uses of a service beyond the scope originally conceived by the provider (“co-creation of value”).

Representations of Service

In addition to these discussions of “service” in (more or less) plain English, we have two formal means of representing “service” – an OWL ontology (SOA-O) and a UML2 Profile (SoaML):

[code language=”xml”]</span>
<owl:Class rdf:about="#Element">
</owl:Class>
<owl:Class rdf:about="#Service">
<rdfs:subClassOf>
<owl:Class rdf:about="#Element"/>
</rdfs:subClassOf>
</owl:Class>
<owl:ObjectProperty rdf:about="#performs">
<rdfs:domain rdf:resource="#Element"/>
<rdfs:range rdf:resource="#Service"/>
</owl:ObjectProperty>

<owl:ObjectProperty rdf:about="#performedBy">
<owl:inverseOf>
<owl:ObjectProperty rdf:about="#performs"/>
</owl:inverseOf>
</owl:ObjectProperty>
<span style="color: #ffffff;">[/code]

and
SOA-O Service Class

Domains of Service

A service may apply (1) to a “real” world (e.g. social or business) domain or (2) to an IT domain. There is also a third (hybrid) sense of service:

A service [IT domain] may be provided in the service of another service [business domain].

Our concern is primarily in “real” world services – though, undoubtedly, software services will play an increasing role in service requests and service provisions.

At this point, we need to incorporate more “real” world thinking and technologies into our (so far deliberately abstract) description and model of service.

Previous: SOA-3 Overview

Next: SOA-3 XXX or SOA-3 Service + Supplementary Ontologies

Jim Amsden – Service oriented architecture Modeling Language (SoaML)

Jim Amsden is Senior Technical Staff Member, IBM. His papers provide a nice introduction to SoaML – a technology I’ll be using to visualize a vocabulary of Government Services derived from Schema.org.

Modeling with SoaML (2010)

Using SoaML Services Architecture (2012)

Integrating BPMN and SoaML (2014)

 

SoaML – Identifying services

Overview

SOA strives to be business-relevant – driven by the business and implemented to support the business. SOA solutions need to be connected to the business requirements that they fulfill. We need a way to formalize business requirements so that SOA can more closely resemble business services and how those services might meet business objectives – this ties the deployed SOA solution to its intended business value. We also need a way to isolate business concerns from the evolving SOA platforms that support them.

Models allow us to abstract away from the implementation details and focus on the issues that drive business and architectural decisions.

Usually one begins by describing the business motivation that establishes the business objectives. One then models high-level business processes that are business requirements to meet the objectives. We are now ready to create a model to meet these requirements – by identifying capabilities, exposing appropriate candidate capabilities as services, and then defining the architecture for how the services interact.

To identify services, one treats the business process as a Service Requirement contract – then service specifications and service providers are designed and connected together in a manner that fulfills the business requirements while addressing software architectural concerns.

This process of identifying candidate services from a business model is also known as domain decomposition.

SoaML provides several ways of identifying services. The requirements from the business process could be viewed as a service architecture, thus indicating the participants in the business processes, the service contracts that specify how they interact, and the choreography of their services and requests.

A service architecture is a formal specification of the business requirements that are performed by interacting service participants.

The example we will use in our series on SoaML is based on the Purchase Order Process example taken from the OMG SoaML standard, and it is based in the BEPL 1.1 specification.

Scenario: A consortium of companies has decided to collaborate to produce a reusable service for processing purchase orders. These are the goals of the project:

  • Establish a common means of processing purchase orders
  • Ensure that orders are processed in a timely manner and deliver the required goods
  • Help minimize stock on hand and inventory maintenance costs
  • Minimize production and shipping costs

We will skip over the discussion of how to identify services in Amsden’s original article, as our primary interest is using SoaML to model a vocabulary of government service, including a vocabulary derived from schema.org.

There are five main packages in the PurchaseOrderProcess model:

  1. org::ordermanagement – contains elements concerned with order management
  2. org::crm – contains the data model and common interfaces for some envisioned customer
  3. com::acme::credit – contains elements concerned with invoicing and credit management
  4. com::acme::productions – contains elements that are concerned with productions and scheduling
  5. com::acme::shipping – contains elements concerned with shipping

These packages divide the problem domain into different functional areas. This helps manage complexity, establishes required name spaces, facilitates reuse, and keeps separate concerns in different packages. Here’s the package dependencies diagram for our service model:

SoaML - package dependencies in service model of processing purchasing orders

This organization could be called the dominant organization of the service model. Perspective packages can be used to document other ways of organizing the same model elements.

Service identification consists of determining which capabilities should be exposed as services. The IBM SOMA method provides a Service Litmus Test that can be applied to capabilities to determine which ones should be exposed as services. The Service Litmus Test examines each capability and applies various configurable metrics to determine which one(s) should be exposed as services. See RUP for SOMA for details.

We close with Amsden’s figure that shows the service architecture for processing purchase orders at the end of the exercise of identifying services:

Service architecture for processing purchase orders

 

Summary

SoaML may be used to identify services that are connected to business requirements:

  • capture the business objectives necessary to realize the business mission
  • model the business processes that are necessary to meet the business objectives
  • use the business requirements and business processes to identify the required capabilities and the potential relationships between them

Capabilities are treated as candidate services. The capabilities that passed the service litmus test were used to identify the required service interfaces. This ties the service interfaces back to the business requirements.

The result is a formal structure for identifying business-relevant capabilities that are linked to the business objectives that that they are intended to fulfill.

Previous: Service oriented architecture Modeling Language

Next: SoaML – Specifying services

SoaML – Specifying services

In a previous post, we outlined an approach for identifying services that are connected to the business requirements of an enterprise.

Here we will model the specification of each service in detail. These specifications define the interfaces between consumers and producers of the service. These contracts include the provided and required interfaces, the roles that those interfaces play in the service specification, and the rules or protocols for how those roles interact.

Overview of service specifications

A service interface must specify everything that a potential consumer of the service needs:

  • to decide whether they are interested in using the service
  • to know how to use it

A service interface must also specify everything that a provider of the service needs:

  • to know to implement the service successfully

At the heart of SOA is the construction of service value chains that connect user needs with compatible provider capabilities.

A service interface defines the goals, needs, and expectations of user participants (i.e. consumers) as well as the value propositions, capabilities, and commitments of provider participants. Therefore, they provide the information necessary to determine compatible needs and capabilities.

A service interface includes:

  • The name of the service, suggesting its purpose
  • The provided and required interfaces, thereby defining the functional capabilities that are provided by the service and those that it requires of its users – Note: this is not about how the service is implemented, but rather the interaction between the consumers and providers of this service. Each functional capability includes:
    • Its name, which is often a verb phrase indicating what it does
    • Any required or optional service data inputs and outputs
    • Any pre-conditions that consumers are expected to meet before using the capability
    • Any post-conditions that consumers can expect and that providers must provide upon successful use of the capability
  • Any communication protocol or rule that specifies rules for how the functional capabilities are used or in what order
  • Any capabilities that consumers are expected to provide to be able to use or interact with the service
  • Requirements that any implementer must meet when providing the service
  • Constraints that reflect what successful use of the service is intended to accomplish and how it will be evaluated
  • Qualities that service consumers should expect and that providers are expected to provide, such as cost, availability, performance, footprint, suitability to the task, competitive information, etc
  • Policies for using the service, such as security and transaction scopes for maintaining security and integrity or for recovering from the inability to successfully perform the service or any required service

Qualities that service consumers should expect and policies for using a service may be specific to particular providers of a service, not the interface of a particular service itself.

A service interface tells you everything you need to know about a service – including the requirements that you have to meet to use the service (sometimes called the Use or Usage contract (see Daniels and Cheesman article), plus the requirements that an implementer of the service has to meet (sometimes called the Realization contract). This is the same information that we needed to capture for the business requirements, except that the subject area and level of detail are different.

Example

Returning to our example, Figure 1 shows the service interfaces that expose the capabilities required for processing purchase orders:

SoaML Specifying services - Capabilities

 

Figure 1.

Let’s elaborate on each of the identified service specifications in Figure 1. The presentation order is from a very simple service interface that has no protocol, to a service interface that represents a simple request-response protocol, to a more complex service interface that involves a multi-step protocol and interaction between the user and provider.

Scheduling service interface

The Scheduling service interface shown in Figure 2 is very simple.

SoaML Specifying services - Scheduling service interface

Figure 2.

The service provides two operations: the ability to respond to a production schedule request and the ability to create a shipping schedule. These operations were created by examining the functions of the capabilities the service interface is exposing. As far as we know, in this situation there is no protocol for using these operations. Either can be used in any order.

The Scheduling service interface is a simple UML interface defined in the productions package. It provides two service operations. Each of these operations can have pre-conditions and post-conditions, and they can raise exceptions. The parameters of the service operations are required to be either service data (DataType or MessageType) or primitive types. This ensures that the parameters make no assumptions about call-by-reference or call-by-value, where the service data is located (in what address space), whether the service user or provider is operating on a copy of the data or some persistent data source, and so on. All of this is required to ensure that the service is not constrained by where it can be deployed in relation to other services. The service data is defined below.

Shipping service