Process modelling on the Web: from Service Oriented Architectures to

Research on the automation of business processes contributed to the development of a Service Oriented Architecture (SOA) approach to system design, leading to the development of a variety of

62_{Action CP: http://ontologydesignpatterns.org/wiki/Submissions:Action} 63_{AgentRole: http://ontologydesignpatterns.org/wiki/Submissions:AgentRole} 64_{Role: http://ontologydesignpatterns.org/wiki/Submissions:Role} 65_{BasicPlan: http://ontologydesignpatterns.org/wiki/Submissions:BasicPlan} 66_{BasicPlanExecution: http://ontologydesignpatterns.org/wiki/Submissions:} BasicPlanExecution 67_{Reaction: http://ontologydesignpatterns.org/wiki/Submissions:Reaction}

specifications and approaches to process modelling. Although service-orientation is a technology independent approach, it is usually implemented using Web Services technologies, in particular a family of XML based specifications: the SOAP protocol for communication, WSDL for description, and UDDI for discovery and integration [Curbera et al. (2002); Fielding and Taylor (2000); Nacer and Aissani (2014)]. WSDL/SOAP applications received extensive attention from the research literature as well as implementations from all major software producers, including both proprietary platforms (Microsoft SOAP Toolkit68, BEA Web Logic69) and open source ones (Apache Axis)70. However, their uptake as reference technology for the deployment of services on the Web has been significantly smaller than anticipated [Pedrinaci et al. (2011)], and replaced by plain Web technologies based on HTTP requests exchanging XML or JSON files. These services are called RESTful services, when they follow the REST principles [Fielding and Taylor (2000)], but more generally are referred to as Web APIs.

A variety of languages has been developed in the years to support automatic or semi-automatic Web service composition. In the XML world, the more prominent examples are WS-BPEL, WS- CDL, or ebXML (for a survey on Web service composition see [Sheng et al. (2014)]). Here we limit ourselves to the research done within the Semantic Web, by nature particularly interested in a semantic, knowledge-level description of the service, more than a functional, engineering-oriented one. Initially proposed at the beginning of the millennium [McIlraith et al. (2001)], Semantic Web Services (SWS) were envisaged as a means to enable agent-based programming capabilities for the development of intelligent systems capable to discover, compose and execute services with a high degree of autonomy. This vision initially presented as a DAML-like declarative layer to be developed as metadata of the functional services, put the basis for more than ten years of research [Nacer and Aissani (2014); Pedrinaci et al. (2011)]. Four types of semantics were identified for the description of web services:

1. Data semantics: the semantics about the data that is used or exposed by the service. 2. Functional semantics: a description of the functionalities offered by the service.

3. Non-functional semantics: the semantics of the aspects not directly related to the functionality, for example, the way security is implemented or characterising the reliability of the service, or pertaining the quality of the service (QoS).

4. Execution semantics: the description of the possible behaviours of the service, mostly related to unexpected events (runtime errors).

68_{Microsoft SOAP Toolkit: https://msdn.microsoft.com/en-us/library/ms897379.aspx}

69_{BEA Web Logic: https://www.oracle.com/middleware/weblogic/index.html}

2.7. REPRESENTATION OF PROCESS KNOWLEDGE 75 Research on SWS developed around the assumption that a language covering the various semantics of the Web service would allow intelligent agents to reason upon service descriptions and support tasks including discovery and selection of services, composition, orchestration, and execution (we refer to [Pedrinaci et al. (2011)] for a complete list of tasks related to Semantic Web Services). A primary objective was therefore to develop languages and frameworks for the support of the full life-cycle of an SWS [Burstein et al. (2005); Fensel and Bussler (2002); Norton et al. (2008); Preist (2004)]. In what follows we limit ourselves to illustrate the major approaches and languages for the description of SWS (following [Pedrinaci et al. (2011)]), leaving out the variety of tasks related to web services (discovery, composition, orchestration, etc...) and the framework developed, surveyed exhaustively in [Klusch et al. (2016); Moghaddam and Davis (2014); Nacer and Aissani (2014); Rao and Su (2004); Sheng et al. (2014); Strunk (2010)]. We first introduce two top-down approaches for representing the semantics of Web services, namely OWL-S and WSMO, and then we will spend some words on a set of bottom-up approaches mostly based on a semantic annotation of existing resources (like WSDL XML files or Web pages).

Top-down approaches. OWL-S [Martin et al. (2004)] is an ontology for the description of Web Services developed with the Web Ontology Language (OWL), and evolved from DAML- S [Ankolekar et al. (2001)]. The ontology permits to represent a Web service under three fundamen- tal dimensions:

– The Service Profile represents the functionality of the service in terms of input, output, preconditions and effects (IOPEs). Its objective is to advertise the service offering a high-level view of its operation. However, this is done mainly by representing its functional aspects, for example, its parameters, although the description can include a classification of the service under reference taxonomies, as well as an informal textual description.

– The Service Model describes the structure of the service (how it works), in terms of a process model expressing the semantics of a complex behaviour. This includes the sequence of operations to be performed, the type of requests, replies and the conditions under which they can occur. This level of descriptions is the one more similar to typical process modelling solutions. OWL-S identifies three process types: atomic, composite, and simple processes. Atomic processes can be directly invoked and require one single interaction to be used. Composite processes require several steps to be used, including multiple and conditional calls. Often, they are decomposable in other services. OWL-S supports the description of the composite process with constructs such as If-Then-Else, Sequence and Repeat-While. Simple processes are semantic abstractions over the first two types, permitting to expose their

capabilities to sophisticated reasoners, and they are not directly executable.

– The Service Grounding describes the way the service can be accessed, for example encoding its operational aspects in an XML/WSDL model. It includes the address of the service, the protocol to be used and the serialisation method.

The Web Services Modelling Ontology (WSMO) [Fensel et al. (2006); Roman et al. (2005)] has its roots in the Web Services modelling Framework [Fensel and Bussler (2002)], and applies an approach based on Problem-Solving methods - particularly the Unified Problem Solving Method Development Language (UPML) [Fensel et al. (2003)] - to support all the relevant aspects needed to support the discovery, selection, composition, execution and monitoring of Web services. This approach is based on a strict decoupling of the components involved and a strong focus on the role of mediators to orchestrate them. The four elements of WSMO are Ontologies, Web Services, Goalsand Mediators, all semantically described. Ontologies can be defined by using Concepts, Relations, and Functions. Concepts are meant to establish a shared terminology to be used in the applications. Relations can define dependencies between concepts and have a binary nature. Functions can express more complex associations allowing an N-ary domain with a unary range. Web Servicesare described by means of capabilities and service interfaces. Capabilities express

the functionality of the service declaring pre-conditions (logical constraints to be applied to the input of the service), assumptions (constraints about external facts that are assumed to be valid but cannot be directly checked), post-conditions (a set of logical constraints that express some properties of the output) and effects (statements about changes in the state of the world as consequence of the service execution). A Service Interface is a specification of how the service can be used, by means of a choreography and an orchestration. The choreography pertains to the client’s point of view. WSMO uses Abstract State Machines (ASM) to model the interface as a state signature and multiple possible transition rules. Orchestration pertains to the control flow and data flow, particularly to support the use of the service in combination with others. Goals are used by clients to express the desired behaviour, for example in the case of service brokering. Goals are meant to express capabilities related to an expected functionality or behaviour. This notion is inherited from the notion of Task in knowledge engineering frameworks like KADS, UPML and Generic Tasks [Bylander and Chandrasekaran (1987); Fensel et al. (1999); Schreiber (2000)]. Mediators are defined to handle heterogeneity between two components. Mediators are expressed in terms of source, target and a pointer to the actual mediation service.

Bottom-up approaches. WSDL-S is an approach based on enriching WSDL Web Service descrip- tions with semantic annotations [Akkiraju et al. (2005)]. This approach is considered light-weight

2.7. REPRESENTATION OF PROCESS KNOWLEDGE 77 (as it applies to an existing technology without requiring to adopt a specific framework) and en- countered some favour because of its extendibility [Pedrinaci et al. (2011)]. In WSDL-S, it is assumed that semantic models relevant to the service already exist and are external to the service specification. In this approach, the models are maintained outside of WSDL documents, which reference them via WSDL extensibility elements. The semantics of a web service is expressed as preconditionsand effects. Moreover, the specification allows the definition of mapping functions (the schemaMapping element) to translate data elements via XML based construct, with a role similar to WSMO mediators. Finally, WSDL-S includes a category element to classify the Web service under a shared taxonomy. The work on WSDL-S was adopted by the W3C working group that developed the Semantic Annotations for WSDL and XML Schema (SAWSDL) [Kopeck`y et al. (2007)]. The objective of the specification was to allow a semantic annotation of Web services without enforcing a specific ontological model for doing so. SAWSDL inherited the extendibility approach of WSDL-S, reducing the importance of preconditions and effects (not directly mentioned by the spec) and replacing the category element with a more generic modelReference element. Moreover, it supports referring to services to perform two operations: lifting - to translate some raw data to its semantic counterpart (using the liftingSchemaMapping), and lowering - to do the inverse, and extract raw data from a semantic representation (using the loweringSchemaMapping). However, SAWSDL does not advocate any specific language to implement (or specify) these mappings. The objective of WSMO-Lite was to exactly address this gap, providing a minimal RDFS ontology and terms to express four types of semantic annotations: Functional semantics, Non-functional semantics, Behavioural semantics, and Information model [Vitvar et al. (2008)]. Similar approaches have been developed to incorporate a semantic description of Web services in HTML pages, through Microformats (MicroWSMO [Lampe et al. (2010)]) or GRDDL and RDFa (SA-REST) [Sheth et al. (2007)]).