Consolidating Service Engineering Ontologies : Building Service Ontology from SOA Modeling Language (SoaML)

As a term for characterizing a process of devising a service system, the term ‘service engineering’ is still regarded as an ‘open’ research challenge due to unspecified details and conflicting perspectives. This paper presents consolidated service engineering ontologies in collecting, specifying and defining relationship between components pertinent within the context of service engineering. The ontologies are built by way of literature surveys from the collected conceptual works by collating various concepts into an integrated ontology. Two ontologies are produced: general service ontology and software service ontology. The software-service ontology is drawn from the informatics domain, while the generalized ontology of a service system is built from both a business management and the information system perspective. The produced ontologies are verified by exercising conceptual operationalization of the ontologies in adopting several service orientation features and service system patterns. The proposed ontologies are demonstrated to be sufficient to serve as a basis for a service engineering framework.


I. INTRODUCTION
IVEN its nature as a multidiscipline endeavour, establishing a common paradigm is quite problematic in the service science field. Varying perspectives emerged from different contributors with their own set paradigm influenced by particular academic backgrounds. Despite the research contribution over two decades, service science still experiences a lack of standard ontology for 'service', and 'service system' concepts [1]. Therefore, one of the challenges in service science is to consolidate the perspectives into a shared and cohesive perspective [2].
Within the research context of "Service Engineering Framework" [3], a series of ontology is developed. Three ontologies are presented in this paper: (1) Service Oriented Architecture (SOA) Ontology, (2) General Service Ontology, and (3) Software Service Ontology and. The first ontology is built from the SOA stream, which is later adapted and generalized to cover non-technical perspectives originated from classic service engineering into the second ontology. The third ontology is an adjustment and refinement of the first ontology as a special case for software service.
The term 'ontology' is defined as a set of structured (abstract) concepts and relationship between concepts within a defined domain [4]. Ontology serves a basis for a language, to be used as a communication tool to share an understanding regarding a specific domain. Therefore, ontology definition is often linked with a modelling activity.
A 'model' is defined as representation of a reality within a definite purpose. To facilitate a common understanding between multiple parties, a model is usually built based on a specific modelling language, i.e. a metamodel. The metamodel specifies a palette of concepts and constraint rules for a valid model for a specific modelling language [5]. Fig. 1 shows the relation between ontology and model. Ontology is an explicit and formal specification of a shared conceptualization, in both model and metamodel level. Two types of ontology are involved: (1) ontology of meta models, and (2) ontology of problem domain, or a 'domain ontology' [6]. A model is an instantiation of a 'meta model' and similarly, a 'domain ontology' is an instantiation of a 'meta model ontology'. Both are semantically interpreted by their respective ontology. Ontologies presented in this paper are in the category of 'metamodel ontology'. Fig. 1 Model, metamodel, and ontologies [6] II. RELATED WORK Several ontology propositions of 'service' emerged from IS/IT contributors. One of early attempts in defining a service ontology is found as a 'service system metamodel' within the context of a SOA methodology [7]. While the focus is on software-service, it already relates to one non-IT concept: 'business process'. As visualized in Fig. 2, service is differentiated based on participant type: (1) For service consumers, a service is a unit of expected functionality with a service level agreement as 'Target Service'. (2) For service providers, a service is a unit of deployed functionality as 'Publishable Service'. 'Service Interface' serves as a front-end for 'Service Component', which can be in an atomic or a composite form.  [7] Another ontology proposition from software serviceorientation perspective is found in [8]. It defines three successive abstractions of a service: (1) single interaction, (2) multiple interactions (choreography), and (3) multi-provider (orchestration). Five overlapping aspects of a service model were also defined: (1) structure, (2) behaviour, (3) information, (4) goal, and (5) quality. The structural aspect of a service is conceptualized as a metamodel in Fig. 3, covering 12 concepts entirely from a SOA perspective.
From these previous works, selected concepts that can be considered as a potential component for targeted ontology are: (1) architecture, mostly for software level abstraction, (2) binding, related to 'role' concept, (3) capability, as user perspective of business function, (4) composition, related to atomicity or composite nature of service, and (5) contract, as terms and conditions agreement of a service. Additionally, [9] suggests that service structural model is consisted of: (1) service operation, (2) service component, and (3) service interface.
To produce an integrative perspective, a more practical approach is hence taken to use collaborative SOA conception as the source for ontology building. Over the years, several standard groups have produced SOA open standards: OASIS, The Open Group, The International Organization for Standardization (ISO/IEC) and Object Management Group (OMG).
The standards published are not always compatible to each other, and actually competing in its overlapping terminology [10]. As illustrated in Fig. 4, two products can be considered as the state-of-the-art: (1) OMG's SoaML [11], as the definitive SOA metamodel originated from OASIS stream, and (2) ISO/IEC's SOA Reference Architecture [12], as the definitive SOA ontology definition originated from The Open Group stream. Unfortunately, these two are not semantically related.

III. SOA ONTOLOGY
SoaML is one of many specifications produced by OMG. SoaML was first formalized in 2009, with minor updates later in 2012 [11]. SoaML is conceived based on the limitations of UML in representing SOA concepts [13]. While its popularity in the industry is very limited, SoaML is consistently referenced in academic publication as the definitive metamodel for SOA.   While providing a formal specification of its stereotyping extension from the original UML specification, SoaML specification document is surprisingly lacks an ontological definition. The specification actually offers two types of service modelling approaches: (1) Interface-based and, (2) Contract-based [11], and therefore multiple forms of service abstraction is permissible [14]- [16].
A peculiar feature of SoaML is the absence of specific abstraction for 'service'. Three abstractions are offered superimposed to service description components [11], as: 1. Interface, accommodating atomic services containing only self-contained operations. 2. Service Contract, accommodating atomic services and composite services by combining interfaces into a service contract. 3. Service Interface, accommodating atomic services and composite services by combining interfaces Consequently, there are three versions of an ontological structure that can be inferred from the specification: (1)

Interface-based, (2) Service Interfaced-based, and (3)
Contract-based. These versions are elaborated in the following paragraph.
To highlight the differences between these versions, a special visualization technique is employed where: (1) Compositional relationship is visualized in the form of a Venn diagram, in which member components are placed inside a container representing its compositional parent, (2) a service abstraction is symbolized inside a thick border around the superimposed service description components. Fig. 5 represents the first version, in which the 'service' abstraction is superimposed to the (UML) 'interface' concept. The approach is used for simple SOA where the whole architecture is composed of flat atomic services without the possibility of a service composition. Each interaction is synchronous and involving exactly two participants with an interface embedded with a specific role; either as a service requester in a consumer role or as a service responder in a provider role. Fig. 6 shows the second ontological version where a 'service' is abstracted with the 'service contract' concept. Service contract is equipped with an interaction protocol as an internal logic that governs invocation sequences, both synchronous and asynchronous, between participants. The approach is able to accommodate a service interaction with more than two participants. Service composition is possible in the form of a composite participant or compound service contract [11], [15].   Fig. 7 shows the third version in which a 'service' is abstracted as both 'interface' (for atomic service) and 'service interface' (for composite service). Service interface has an interaction protocol as an internal logic to govern invocation sequencing in both synchronous and asynchronous invocation between participants. Service interface can also accommodate an interaction service with more than two participants.
The ontology structure in Fig. 8 is built based on the third version of the ontology (service interface-based). It sufficiently covers all of the components emerged in the related works section. Most of the components are an abstract design concept, except for three components denoted with darker shade in Fig. 8: (1) participant, to become a software component, (2) simple interface, and (3) service interface to be implemented as an atomic or a composite software service, e.g. web service and WSDL interface. . The ontology produced is quite simple, and its coverage is superficial if compared to SoaML ontology [12]. The coverage is lacking in a detailed level of (software) service abstraction, i.e. port, operation, role, and interaction protocol. The ontology is also missing some of the concepts defined in the terminology part, i.e. Capability, Service Architecture, and Role.

IV. GENERAL SERVICE ONTOLOGY
Despite the fact that the adoption of service-oriented concepts is not apparent beyond the technological sphere, its conception always strives to provide a generalized abstraction covering both IT-based and non-IT-based systems. While in reality the distinction for IT and non-IT context of a service system needs to be made, the generality feature of SOA conceptions is useful to build the General Service Ontology.
The goal is to generalize and enlarge the coverage of the Software Service Ontology. The generalization is achieved by applying the concept from a software-service context to the general context of a service system, which includes the physical and the manual system. The objective of the enlargement is to cover concepts included in the classic service engineering context but missing in informatics service engineering, such as (1) 'value', (2) 'business process', (3) 'business model' and (4) 'capability'. These four concepts are the target components to be integrated with concepts already covered within the Software Service Ontology.
The general ontology is built based on the available standard documents published by ISO/IEC and OMG. Sixteen standard documents were identified to cover the definition of targeted concepts. The identified documents are originated from both business and technical domain, including IT domain.
Some of the source documents contain a partial ontological view of concepts covered in the document, i.e. ISO 18384 (SOA-RA), ISO 19505 (OMG-UML), ISO 19510 (OMG-BPMN) and OMG-BMM. In these cases, the targeted concept definition is extracted, along with the available defined relation between them. For other documents, only the concept definitions were extracted. If available, the definitions were captured from the formal terminology definition section. In the other cases, the implied definition is extracted from the descriptive narration. Table II lists the source document for building the consolidated ontology. A total of 74 concept definitions are identified. These concepts are arranged and grouped based on similarity. Concepts observed to be covering similar idea are merged into a single representative label. Table III collects the merged concepts into a hierarchy of 17 concepts as the components of the ontology.
The ontological relation between each merged concept is visualized in Fig. 9. For ease of reference, the numbering in the figure is correlated with the number in Table III. As defined in Table III, service is a container for Interface and its Operation. In Fig. 9, these service components are also aggregated with the underlying process component, i.e. Activity and Task, to form a larger abstraction of Service, between the front-end interface and the back-end supporting activities. This also reflects a SoaML perspective of the relation between 'process' and 'service' as different views of a similar object. 'Process' view focuses on the how and why of the whole interaction, while 'service' focuses on participant activities in provision and consumption of services [11].
A shaded background is introduced in Fig. 6 to define an ownership boundary. Three components are extended beyond the boundary: (1) Collaboration, as an abstraction of atomic or composite interaction, (2) Choreography, where the arrangement of interaction sequence is an agreement with outside entity, and (3) Message, which is exchanged with party outside ownership boundary.
A pair of concepts is merged in the ontology visual: Choreography (7b) and Contract (7c). This merger is not only implemented for visual simplification, but also to show the strong intersection between the two related to an interaction arrangement. To be precise, choreography refers to the  A definition of messages consumed and, optionally, produced when called.

Capability
Participant ability to act and produce an outcome 6. Value A measurable factor of benefit to a recipient, in association with a business item 7. Collaboration Predefined set of activities and/or processes initiated to accomplish a shared goal 7a. Role A defined set of activities assigned to an entity to performs a specific function 7b. Choreography An ordered sequence of message exchanges between two or more entity 7c. Contract Explicitly stated rule, that prescribes, limits, governs or specifies transaction 7d. Message The contents of a communication between two participants The type of service encounter is a factor in differentiating software and non-software service. Two types of service encounters are defined in [17]: (1) Physical, and (2) Virtual. If an interaction of an encounter is mediated by technical devices, the encounter is categorized as a virtual encounter. In this typology, technology may facilitate the encounter in various forms, e.g. from e-mail to website. The softwareservices context resides in a specific situation, in which a software component offers service consumables by other software components.
To focus on the software context, the ontology is trimmed to only include software related concepts. Excluding the three business analysis level components, i.e. (1) values, (2) capability, and (3) business model, the 17 components in the general context of Table III are reduced to 14 components for  software-service context, as listed in Table IV. To achieve a uniformity and as a form of triangulation, SoaML ontology (Fig. 8) is juxtaposed and adapted with the structure of the consolidated general-service ontology (Fig. 9) into the resulting ontology in Fig. 10.
The term 'service' represents an abstraction of externally accessible software components in the software service context. Therefore, it covers both, the underlying software component behaviour (3a and 3b) originated from the 'process' context, and the related published description (4a and 4b). Similarly, the term 'service contract' merges the two aspects of: internal process rule (3c), with the externally shared and agreed rule (7c). These characteristics are derived from SoaML's feature in superimposing a service component with its description. This merging is also coherent with SoaML perspective that views 'process' and 'services' as different perspective of the same object [11].
Two additional SoaML components are not represented in this context: (1) Capability, and (2) Service Architecture. The two are considered to be residing in the business analysis level of service engineering.

VI. ONTOLOGY VERIFICATION
Components decoupling and its binding mechanism is an important principal in SOA conception [18]. It is also the underlying motive in introducing SoaML over UML limitation [13]. Conceptual exercises for decoupling, binding and service consumption is narrated in this section to demonstrate and evaluate the capability of the software service ontology ( The ontology visualization structure is not only describing a service providing software component. In a case where a component requires services from other component within its own composite behaviour (component 3a), it follows the previously described role binding mechanism. The difference To demonstrate the feasibility of the general service ontology (Fig. 6), several patterns of a service interaction are applied to it. The patterns of service interaction are implied in three abstraction level of service modelling: (1) simple interaction, (2) business-to-business (B2B) interaction, and (3) complex interaction [15]. These exercises can be seen as a proto-operationalization of the metamodel ontology toward domain ontology (Fig. 1).
In the first pattern, a simple interaction is occurred between a service provider and a service user, e.g. individual end-user consumer. Here, the whole ontology is positioned as the service-providing entity. To illustrate the first pattern, the ontology is paired with the existence of a simple consumer outside the entity boundary in Fig. 11.
The resulting pattern covers the concepts of: (1) capability offered by the service provider, (2) value offered and requested by the consumer, (3) value brought by the consumer (e.g. in the form of monetary asset), (4) choreographed activity between the two entities, and value exchanged during the transaction.
In the second pattern, choreography level of abstraction, a service is modelled as a process with multiple interactions between two entities. A B2B arrangement between a company and its supplier is an example of this pattern. The pattern is formed by pairing two ontology sets as two interacting entities.   Fig. 12 shows a model of the second pattern which visualizes pairs of external behaviour requested and offered by each participant in the pattern. This pattern specifies and analyses interoperability between two service participants. The model structure also introduces the concept of 'collaboration space' in which the interactions take place. It may reside (i.e. owned) within one of the participant boundaries, or in independent third-party location. In the software-service context, the 'collaboration space' relates to the operator and controller of software-service repository, i.e. service registry and service publication.
In the third pattern, orchestration abstraction, an offered service is modelled as a composition of other services. Fig. 10 illustrates this pattern by combining the first and second pattern approaches with the introduction of both a simple customer, and a partnering service co-provider.
The third pattern is related with indirect type of service encounter in the typology of service encounter [17], where an external party is involved in the service process, as coprovider or intermediary, and may make a direct contact to the service-consumer. In a more complex pattern, multiple coproviders may form service architecture over a set of services. Consequently, this model can be used to analyse and specify possible implementation of the offered service.
The model also raises the issue of 'collaboration spaces'. It relates to the existence of a service coordinator, with the central role of interacting and orchestrating other providers. While the arrangement can be made to be in equal term (distributed and federated), each particular of collaboration tends to require a dominant participant role as the main operator. Other types of service system patterns and combinations may exist, related to elaboration of provider role and components of collaboration space, but the three illustrated patterns adequately demonstrate the feasibility and flexibility of the produced ontology in covering various types of service system. Fig. 13 Model of a multi-provider service pattern VII. CONCLUSION This paper introduces an ontological basis for 'Service Engineering' [19] by describing a process of ontology building of a series of ontologies; service-oriented architecture ontology, general service ontology, and software-service ontology. Two final sets of ontologies were produced: general service ontology (Fig. 9) and software-service ontology (Fig.  10). The two are correlated in which the software service ontology is a specialization of general service ontology.
As conceptual models are composed from literature study approach, the ontologies were verified with its ability to represent features of service concepts. In another part of the research, these defined ontologies are to be used to assess the completeness of a service engineering framework in covering on the aspects of a service system. The mapping of framework artefacts with the ontology structure also serves as a bridge to characterize the artefacts format.