A Web Service Composition Method Based on OpenAPI Semantic Annotations

05/06/2020 ∙ by Andrei Netedu, et al. ∙ Alexandru Ioan Cuza University 0

Automatic Web service composition is a research direction aimed to improve the process of aggregating multiple Web services to create some new, specific functionality. The use of semantics is required as the proper semantic model with annotation standards is enabling the automation of reasoning required to solve non-trivial cases. Most previous models are limited in describing service parameters as concepts of a simple hierarchy. Our proposed method is increasing the expressiveness at the parameter level, using concept properties that define attributes expressed by name and type. Concept properties are inherited. The paper also describes how parameters are matched to create, in an automatic manner, valid compositions. Additionally, the composition algorithm is practically used on descriptions of Web services implemented by REST APIs expressed by OpenAPI specifications. Our proposal uses knowledge models (ontologies) to enhance these OpenAPI constructs with JSON-LD semantic annotations in order to obtain better compositions for involved services. We also propose an adjusted composition algorithm that extends the semantic knowledge defined by our model.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

In the current software landscape, Web services are the core elements of Service-Oriented Architectures (SOAs)[6] that has been already used for many years with vast popularity. A Web Service provides a straightforward functionality defined through a public interface. In the enterprise context, this interface was traditionally expressed in WSDL (Web Service Description Language) – a standardized XML (Extensible Markup Language) dialect. Nowadays, Web services are usually built according to the REST (REpresentational State Transfer) architectural style [8]. There are several pragmatic solutions able to describe their APIs (Application Programming Interfaces) by using lightweight formats such as JSON (JavaScript Object Notation), a well-known data-interchange format based on ECMAScript programming language. In order to compose REST-based Web services, the paper proposes a novel method able to select suitable services automatically by using a knowledge-based approach described in Section II. Without actually executing services, valid compositions are automatically generated depending on concepts from an ontology that denotes the semantics of input parameters, properties, and output (the result). The proposed algorithm – producing certain encouraging results – is presented, evaluated, and discussed in Section III.

We think that our proposal improves productivity and reduces costs within a complex (micro)service-based system. Additionally, the involved knowledge could be easily described, in a pragmatic way, by JSON-LD semantic constructs augmenting the OpenAPI description of each involved service, in order to offer the proper support for intelligent business operations – see Section IV.

For a motivating case study, several experiments were also conducted by using the proposed algorithm. From a pragmatic point of view, the popular schema.org model was chosen to convey Web services conceptual descriptions augmenting input parameters and expected results. Our approach added a suitable conceptualization that was necessary to discover compositions on cases where it could not be possible before, such as in the study presented in Section V.

The paper enumerates various related approaches (Section VI), and ends with conclusions and further directions of research.

Ii Problem Definition

Ii-a Preliminaries

A Web service represents a software system designed to support inter-operable machine-to-machine interaction over a network and can be viewed as an abstract resource that represents a capability of performing tasks that form a coherent functionality from the point of view of provider’s entities and requester’s entities.111Web Services Glossary, W3C Working Group Note, 2004 – https://www.w3.org/TR/ws-gloss/

From a computational point of view, a Web service is a set of related methods described by the same interface. This interface could be declared by adopting various specifications:

  • WSDL 2.0 – a classical Web standard222Web Services Description Language (WSDL) Version 2.0, W3C Recommendation, 2007 – https://www.w3.org/TR/wsdl20/ based on the XML meta-language,

  • OpenAPI 3.0 Specification – a modern solution declaring the public interface of a Web service (REST API) in different formats like YAML (Yet Another Markup Language) or JSON (JavaScript Object Notation).

In this paper, we refer to a Web service as a single method or the minimal endpoint that can be accessed or invoked at a time using some values as parameters – i.e. having some prior knowledge. In our context, we also work only with “information providing” Web services, or stateless services that do not alter their state and are not sensitive to the outside world states, time or any external factors.

The main focus of the proposed method is on improving the semantic description of services motivated by the lack of means of expressing several composition techniques on previously known models and software solutions mentioned in Section VI.

We enhanced the service composition problem by modeling semantics in the manner described below. It was inspired by our previous experience and the shortcomings we found on expressing certain natural cases of composition. More precisely, it was not possible to describe service parameters with properties or any relations/interaction between these parameters. Adding the new elements to the problem definition is also done with inspiration from the data model used by popular ontologies such as schema.org [10].

Using this approach, we managed to fix the issues that appeared in examples where the previous model failed. Our main addition is consisting of concept properties and how they are used for composition, allowing interaction between concepts and their properties based on simple constructions that increase the expressiveness.

Ii-B Proposed Formal Model

Service parameters are defined over a set of concepts. Let be the set of all concepts that appear in a repository of services, that are all possible concepts or the problem universe. As in the previous modeling, the concepts are first organized by using the isA or subsumes relation. This is a binary relation between concepts and can be considered somewhat similar to the inheritance in object-oriented programming. If a concept isA then can substitute when there is need of a . Also, for any concept in , there can be only one direct, more generic concept then , i.e. we do not allow multiple inheritance. Obviously, isA is transitive and, for convenience, reflexive: isA . This implies that together with the isA relation form a tree (a taxonomy) or, more generally, a forest (a set of taxonomies or a complex ontology).

However, the new element added to the problem are concept properties. Any concept has a set of properties, possibly empty.

Each property is a pair . The name is just an identifier of the property, and for simplicity, it can be seen as a string – for concrete cases, this identifier is actually an IRI (Internationalized Resource Identifiers)333IRI (Internationalized Resource Identifiers – https://tools.ietf.org/html/rfc3987, a superset of URIs (Uniform Resource Identifiers). The type is also a concept from the same set of concepts and can be considered as the range of a property.

From an ontological point of view [1], a property is defined as a relation between Web resources. The values of a property are instances of one or more concepts (classes) – expressed by property. Any resource that has a given property is an instance of one or more concepts – this is denoted by property.

Properties are inherited: if isA , and has some property then also has property . For example, if an apple is a fruit, and fruit has property expressing that fruit instances have a color, then apples also must have a color.

It is important that property names do not repeat for any unrelated concepts. For any concepts that are in a isA relation, all properties are passed to the specialization one by inheritance. This restriction is only imposed to avoid confusion and does not reduce the expressiveness, as properties can be renamed.

Syntactically, to define a property, the following are to be known: its name, its type, and the most general concept that the property can describe. For example, consider that the hasColor property can describe the apple concept, but also the more general fruit concept. If concept fruit isA physicalObject, the next more general concept than fruit – i.e., its parent in the concepts tree –, under the assumption that not all physical objects are colored, then we can say that hasColor can most generally describe fruit, but not any physicalObject or any other more general concept. However, it can describe other concepts in the tree, together with all their descendants. For simplicity, we consider further that all the properties are defined within , thus the concepts, isA relation and properties structure are in – the particular ontological model.

A partially defined concept denotes a pair (c, propSet), where is a concept from and propSet is a subset of the properties that

has defined directly or through inheritance from more generic concepts. At some moment of time (or in some stage of a workflow), a partially defined concept describes what is currently known about a concept. It does not refer to a specific concept instance, but rather generally to the information that could potentially be found for any instance of that concept.

A Web Service w is defined by a pair of input and output parameters: (w, w). Both are sets of partially defined concepts. All are defined over the same structure , so all service providers must adhere to , thus adding the requirement that is publicly available and defined ahead of time. In order to be able to validly call a service, all input parameters in w must be known together with their specified required properties. After calling the service, all output parameters w will be learned with the properties specified at output.

Parameter matching. Let P be a set of partially defined concepts, and w = (w, w) a Web service. The set P matches service w (or, equivalently, w is callable if P is known) if and only if partially defined concept pdc = (c, propSet) w, p = (, propSuperSet) P such that isA and .

We further define the addition of w to P as:

(1)
(2)

or the union of w with P under the constraint of P matching w (defined as parameter matching above). Also, by we refer to the fact that property is stated for directly or by inheritance. P w contains (1) new concepts that are in w and (2) concepts already in P possibly with new properties from w specified for corresponding concepts or their specializations.

In words, after a call to a service, all its output parameters are selected, and for each concept together with its selected properties (c, propSet) in w, propSet is added to c, cs parent in the concepts tree or the ascendants until we reach the first node that gains no new information or the root. More precisely, for each in we add to our knowledge base for , for the parent of , and so on until is no longer defined for the node we reached. The node where this process stops can differ from one property to another property, but once the process stops for all properties in there is no need to go further.

Chained matching. Let P be a set of partially defined concepts and an ordered list of services. We say that is a chain of matching services iff matches . This is the rather primitive model for multiple service calls, that is a requirement for defining the composition. For simplicity, we avoid for now more complex workflows that could handle parallel and sequential service execution constructs.

Web Service Composition problem. Given an ontology having a set of concepts and a repository of Web services , and two sets of partially defined concepts Init and Goal, all defined over , find a chain of matching services such that InitGoal.

The and are just short ways of writing the initially known and finally required parameters, by using mock services.

We can also imagine (Init, Goal) as a Web (micro-)service – in this context, the problem requires finding an “implementation” of a Web (micro-)service using the services available in a certain development environment (e.g., a public or private repository).

Iii Automatic Service Composition Algorithm

Iii-a Algorithm Description

The proposed algorithm is intended to describe a generic solution that generates a valid composition. Tough it considers some basic optimizations like special data structures and indexes, there are many ways in which it can be improved, so we shortly describe some of them after the basic algorithm description.

In a simplified form, considered main entities have the following structure:

class Concept {   // full or partial type
  Uri uri;        // unique identifier
  String name;    // a label
  Concept parent; // isA relation
  // proper and inherited properties
  Set<Property> properties;
}
class Property {
  Uri uri;        // unique identifier
  String name;    // a label
  Concept type;   // property’s range
}
class WebService {
  Uri uri;
  String name;
  // I/O parameters
  Set<Concept> in, out;
}

Global data structures that are most important and often used by the algorithm are presented below:

// knowledge: concepts, isA, properties
Set<Concept> C;
// repository of services
Set <WebService> webServices;
// user’s query as two fictive services
WebService Init, Goal;
// the known partially defined concepts
// known.get(c) = concept’s known properties
Map <Concept,Set<Property>> known;
// required.get(c).get(p) services that
// have property p of concept C in input
Map <Concept,Map<Property, Set<WebService>>> required;
// remaining.get(w).get(c) =
// properties of concept C
// necessary to call the W service
Map <WebService, Map<Concept, Set<Property>>> remaining;
// services for which all input is already known
Set<WebService> callableServices;

The algorithm described next uses the above structures, and is composed of three methods: initialization, the main composition search method which calls the last (utility) method, that updates the knowledge base with the new outputs learned form a service call.

Several obvious instructions are skipped for simplicity like parsing input data and initializing empty containers.

void initialize() {
 // read C, services, query as (Init.out, Goal.in)
 Init.in = Goal.out = ;
 webServices.add(Goal);
 for (WebService ws : webServices) {
  for (Concept c : ws.in) {
   for (Property p : c.properties) {
    required.get(c).get(p).add(ws);
    remaining.get(ws).get(c).add(p);
   } // container creation skipped
  }
 }
}

After reading the problem instance, the described data structures have to be loaded. Init and Goal can be used as web services to reduce the implementation size, if they are initialized as above. Then, for each parameter in service’s input, we add the corresponding concepts with their specified properties to the indexes (maps) that efficiently get the services that have those properties at input and the properties that remain yet unknown but required to validly call a service.

List<WebService> findComp(WebService Init, Goal) {
 List<WebService> composition; //result
 callService(Init); // learn initial
 while (!(required.get(Goal).isEmpty() ||
          callableServices.isEmpty())) {
  WebService ws = callableServices.first();
  callableServices.remove(ws);
  composition.add(ws);
  callWebService(ws);
 }
 if (!remaining.get(Goal).isEmpty()) {
   return null; // no valid composition
 } else {
   return composition;
 }
}

The main method that searches for a valid composition satisfying user’s query is findComp(). The result is simplified for now as an ordered list of services. As long as the Goal service is not yet callable, but we can call any other new service, we pick the first service from the callableServices set. Then we simulate its call, basically by learning all its output parameter information, with the help of callWebService() method below. We add the selected service to the composition and remove it from callableServices so it won’t get called again. If callableServices empties before reaching the Goal, then the query is unsolvable.

// ’discover’ and expand the output of a Web service
void callWebService(WebService ws) {
 for (Concept c : ws.out) {
  Concept cp = c; // concept goes up in tree
  // true if anything new was learned at level
  boolean added = true;
  while (added && cp != null) {
   added = false;
   for (Property p : c.properties) {
    if (cp.properties.contains(p) &&
        !known.get(cp).contains(p)) {
     added = true;
     // learn p at cp level:
     known.get(cp).add(p);
     for (WebService ws: required.get(cp).get(p)) {
      remaining.get(ws).get(cp).remove(p);
      if (remaining.get(ws).get(cp) .isEmpty()) {
       // all properties of cp in ws.in are known
       remaining.get(ws).remove(cp);
      }
      if (remaining.get(ws). isEmpty()) {
       // all concepts in ws.in known
       callableServices.add(ws);
      }
     }
    }
   }
   cp = cp.parent;
  }
 }
}

When calling a Web service, its output is learned and also expanded, i.e. we mark as learned properties also for more generic concepts. This improves the algorithm’s complexity, as it is better to prepare detection of newly callable services than to search for them by iteration after any call. This is possible by marking in the tree the known properties for each level and iterating only to levels that get any new information, as higher current service’s output would be already known.

The optimization also comes from the fact that all services with inputs with these properties are hence updated only once (for each learned concept and property). As it gets learned, information is removed from the remaining data structure first at the property level and then at the concept level. When there’s no property of any concept left to learn, the service gets callable. This can happen only once per service. The main loop might stop before reaching the tree root if at some generalization level, all current services’ output was already known, and this is determined by the added flag variable.

Iii-B Possible Improvements

There are several improvements that can be added to the algorithm. One important metric that the algorithm does not consider is the size of the produced composition. As can be seen from the overview description above, the solution is both deterministic and of polynomial time complexity. This is possible because the length of the composition is not a necessary minimum. Finding the shortest composition is NP-Hard even for problem definitions that do not model semantics. The proposed model introduces properties, but this addition does not significantly increase the computational problem complexity. Nevertheless, even if the shortest composition is hard to find, there are at least two simple ways to favor finding shorter compositions with good results.

One is based on the observation that when a service is called, it is chosen from possibly multiple callable services. This choice is not guided by any criteria. It is possible to add at least a simple heuristic score

to each service that would estimate how useful is the information gained by that service call. To take this even further, this score can be updated for the remaining services when information is learned.

Another improvement is based on the observation that services can be added to the composition even if they might produce no useful information – there is no condition check that they add anything new, or the information produced could also be found from services added later to the composition. To mitigate this, another algorithm can be implemented that would search the resulting composition backward and remove services that proved useless in the end.

Both of the above improvements can have an impact on the running time as well, as the algorithm stops when the goal is reached.

Iii-C Empiric Evaluation

To test the algorithm implementation, we first used some handwritten examples, including the one in Section V. Then, we implemented a random test generator to analyze the performance on larger instances.

The generator first creates a conceptual model (a dummy ontology) with random concepts and properties and then a service repository based on the generated ontology. Service parameters are chosen from direct and inherited properties. In the last step, an ordered list of services is altered by rebuilding each service input. The first one gets its input from Init, which is randomly generated at the beginning. Each other service in order gets its input rebuilt from all previous services outputs, or from valid properties of generalizations of those concepts. Finally, Goal has assigned a subset of the set of all outputs of the services in the list. The total number of services and the list size are input parameters for the generator. The intended dependency between services in the list is not guaranteed, so shorter compositions could potentially exist.

ontology size repository run time result composition dependency list
(#concepts + #properties) size: #services in seconds size: #services size: #services
10 (5 + 5) 10 0.002 3 5
20 (10 + 10) 20 0.003 4 10
50 (30 + 20) 20 0.007 12 20
20 (10 + 10) 50 0.011 6 20
TABLE I: Algorithm run times and resulting composition size on random generated instances.

Table I shows the algorithm performance. The first two columns briefly describe the input size, by the number of concepts and properties in the generated ontology and total number of services in the repository. The column result composition size measures the length of the composition found by the algorithm. The last column, dependency list size, measures the length of the composition generated by the tests generator algorithm. The dependency list constitutes a valid composition, hidden within the repository and may contain useless services as the dependency is not guaranteed.

Iv Extending Openapi With Json-Ld Constructs

Another aim of this research is to show how current OpenAPI specification444OpenAPI Specification – https://github.com/OAI/OpenAPI-Specification and our proposed extension to the JSON-LD model can be used for automatic Web (micro-)service composition.

Iv-a From Formalism to Semantic Descriptions

As a first step, we applied the above mathematical model and algorithm for a set of Web services defined with the help of OpenAPI specification expressed by JSON (JavaScript Object Notation)555JSON (JavaScript Object Notation) – https://json.org/ constructs.

OpenAPI specification is used to describe Web services (APIs) aligned to the REST (REpresentational State Transfer) architectural style [8]. This specification defines in a standardized manner a meta-model to declare the interfaces to RESTful APIs in a programming language-agnostic manner.

These APIs correspond to a set of Web services that forms a repository. For our conducted experiments, we considered an API as a collection of services where each different URI path of the API denoted a different service – this can also be useful in the context of microservices. Thus, we can group services based on information related to the location of the group of services. In practice, this is very useful as generally a Web server would likely host a multitude of Web services.

We used OpenAPI specification to describe the input and output parameters of each different service. Those parameters are Web resources that represent, in our mathematical model, partially defined concepts. OpenAPI also helps us match parameters on a syntactic level by specifying the data types of the parameters.

Example. As a real-life case, the public REST API (Web service) provided by Lyft666Lyft API – https://developer.lyft.com/docs is described. For the operation of getting details about an authenticated user (GET /profile), the result – i.e., w.out in our mathematical model and, in fact, output data as a JSON object composed by various properties – is the following:

  • id: string – Authenticated user’s identifier.

  • first_name: string – First name.

  • last_name: string – Last name.

  • has_taken_a_ride: boolean – Indicates whether the user has taken at least one Lyft ride.

Each property can have as a result – the mentioned in Section II – a datatype denoted by a concept, according to the proposed mathematical model. The Web resources processed by a service are then linked to assertions embedded into JSON-LD descriptions. All JSON-LD statements could be converted into RDF (Resource Description Framework) or OWL (Web Ontology Language) [1]

to be further processed, including automated reasoning.

For this example, the first_name property of the returned JSON object could be mapped – via JSON-LD annotations – to the givenName property of Person concept (class) defined by the schema.org conceptual model or – as an alternative – by FOAF (Friend Of A Friend) vocabulary777FOAF (Friend Of A Friend) Vocabulary Specification – http://xmlns.com/foaf/spec/. Additionally, the output parameter – i.e., the returned JSON object – could be seen as an instance of Person class. This approach could be further refined, if a Customer and Driver class are defined as a subclass of Person concept. The subclass relation from the (onto)logical model – formally written as Customer Person – is equivalent to the isA relation of the mathematical formalism presented in Section II. Using this taxonomy of classes, the algorithm could select the Web service as a candidate solution for Web service composition.

Secondly, we chose the JSON-LD model to describe the entities used by a group of services. For each different Web resource specified in the OpenAPI description of considered Web services, a corresponding semantic description could be stated. This semantic description attaches to each Web resource a URI specifying a concept in an ontology. Similarly, for each property of the corresponding Web resource.

Iv-B Generic Approach

Generally, considering an OpenAPI specification stored in a JSON document:

{
  ”openapi”: ”3.0.0”,
  ”paths”: {
    ”/resource”: {
      ”get”: {
        ”operationId”: ”service”,
        ”parameters”: [ {
          ”name”: ”parameter”,
          ”in”: ”query”,
          ”schema”: { ”type”: ”string” }
        } ],
        ”responses”: {
          ”200”: {
            ”description”: ”Success”,
            ”schema”: {
              ”$ref”:”#/definitions/Response”
            }
        }
     } /* a response object composed by properties and values, e.g. { response: string } */
   }
  }
 }
}

an abstract JSON-LD annotation has the following form, where the context is a knowledge model used to denote Web service entities and the Concept1 and Concept2 classes are used for each parameter instead of a generic JSON datatype (in this case, a string).

{
 ”@context”: http://ontology.info/,
 ”@id”: ”parameter”,
 ”@type”: ”Concept1” // w.in
 ”response”: {
  ”@type”: ”Concept2” // w.out
 }
}

Furthermore, a convenient mapping – a-priori given or automatically generated – between JSON datatypes (string, number, boolean, object, array) and ontological concepts could be attached as meta-data for the considered set of Web services in order to facilitate the matching process. This enhancement is inspired by ontology alignment strategies [23]. The mapping itself could be directly expressed in JSON-LD via @context construct used to map terms (in our case, datatype names and/or property names) to concepts denoted by URIs. The concepts, properties, restrictions, and related entities (such as individuals and annotations) form the knowledge base – usually, specified by using OWL and RDF standards [1].

V Case Study: A Transport Agency

To illustrate the benefits of our approach, we have considered the following example, according to the problem definition in Section II. Also, we have used concepts from schema.org. The services’ interfaces are stored in an OpenAPI compliant document. The resources (service parameters) are described via JSON-LD by using the method exposed in Section IV.

The case study specifies the car company operating processes via web services. The car company services are simplistic and perform small tasks that can significantly benefit from a web service composition solution. Describing the services using OpenAPI and JSON-LD, the approach showcases how easy it is to represent complex relations between resources by combining object-oriented concepts in both structure and semantics. On top of this, because the REST services are similar on an architectural level, the solution guarantees that the situation presented in the case study can easily be extended and applied in real-world scenarios. For the conducted experiment, our example contains six services, several resources, but also the query to be solved by a composition of all six services in the correct order.

The scenario is the following. We are supposing that a customer needs a vehicle to transport a given payload. This person knows his/her current GeoLocation(latitude, longitude) and a time frame Action(startTime, endTime) in which the transport should arrive. The Goal is to obtain the Action(location) where the vehicle will arrive. The six services – each of them implementing a single operation – are specified below:

getCountryFromLocation
 in  = GeoLocation(lat,lon)
 out = Country(name)
 
getTransportCompany
 in  = AdministrativeArea(name)
 out = Organization(name)
getClosestCity
 in  = GeoLocation(lat,lon)
 out = City(name)
getLocalSubsidiary
 in  = Organization(name), City(name)
 out = LocalBusiness(email)
getVehicle
 in = Vehicle(payload),
      LocalBusiness(email)
 out= Vehicle(
       vehicleIdentificationNumber)
makeArrangements
 in = Vehicle(
       vehicleIdentificationNumber),
      Organization(name,email),
      Action(startTime,endTime)
 out = Action(location)

In OpenAPI terms, a HTTP GET method is defined to obtain a JSON representation of the desired Web resource, for each getResource operation – i.e. using GET /country with GeoLocation as input parameter and Country as output. Without JSON-LD constructs, these parameters have regular JSON datatypes like string or number.

As defined by schema.org, LocalBusiness888LocalBusiness, a particular physical business or branch of an organization – https://schema.org/LocalBusiness isA Organization – or, equivalent, in (onto)logic terms: LocalBusiness Organization. Similarly, Country isA AdministrativeArea.

A valid composition satisfying the user request can consist of the services in the following order: Init getCountryFromLocation getTransportCompany getClosestCity getLocalSubsidiary getVehicle makeArrangements Goal. The order is relevant, but not unique in this case. This can be verified by considering all resources added by each service and also by the use of the isA relation. For example, LocalBusiness(email) can be used as Organization(email).

The Java implementation of the algorithm from Section III reads the OpenAPI specification document describing the above scenario and finds the highlighted composition based on schema.org conceptual model. We also validated the OpenAPI and JSON-LD files using available public software tools included in Swagger Editor999Swagger Editor – http://editor.swagger.io/ and JSON-LD Playground101010JSON-LD Playground – https://json-ld.org/playground/.

Vi Related Work

Various approaches [19, 16, 3] were considered to tackle the problem of Web service composition in the case of “classical” specification of Web services by using the old SOAP, WSDL (Web Service Description Language), and additional WS-* standards and initiatives [6]. Also, several semantic-based formal, conceptual, and software solutions are proposed by using DAML-S and its successor OWL-S111111OWL-S: Semantic Markup for Web Services – https://www.w3.org/Submission/OWL-S/ service ontologies (in the present, they are almost neglected by the existing communities of practice) and language extensions to Web service descriptions.

For instance, the following initiatives, methods, and software solutions could be mentioned:

  • A mathematical model of the semantic Web service composition problem considering AI planning and causal link matrices [12].

  • A linear programming strategy for service selection scheme considering non-functional QoS (Quality of Service) attributes 

    [4].

  • Automated discovery, interaction, and composition of the Web services that are semantically described by DAML-S ontological constructs [24].

  • A high-level conceptual architecture and model for Web service deployment, providing support for service interaction, mediation, and composition of services [18].

  • A process ontology (called OWL-S) to describe various aspects of Web services using SOAP protocol [15].

  • A service composition planner by using hybrid artificial intelligence techniques and OWL-S model 

    [11].

  • A hybrid framework which achieves the semantic web service matchmaking by using fuzzy logic and OWL-S statements [7].

  • An automated software tool using MDA (Model-Driven Architecture) techniques to generate OWL-S descriptions from UML models [25].

  • Various efforts for annotating SOAP-based Web service descriptions by using semantic approaches – e.g., SAWSDL (Semantic Annotations for WSDL and XML Schema) – within the METEOR-S system [22].

In contrast, there are relatively few recent proposals focused on resolving the problem of automatic service composition in the context of the new pragmatic way of describing the public REST APIs by using OpenAPI specification. Several solutions and tools are covered in [9] and [13]. From the modeling service compositions perspective, our formal model presents several similarities to the solutions proposed by [2] and [5].

Concerning enhancing Web services with semantic descriptions [27], several recent initiatives considering OpenAPI-based approaches are focused on:

  • Extending the OpenAPI specification with a meta-model giving developers proper abstractions to write reusable code and allowing support for design-time consistency verification [21]. This approach is not using any semantic descriptions and does not provide support for reasoning via JSON-LD annotations.

  • Using fuzzy inference methods to match services considering QoS metrics [28], or denoted by OpenAPI specifications [17].

  • Generating, in an automatic manner, the suitable GraphQL-based wrappers for REST APIs described by OpenAPI documents [29].

  • Using the RESTdesc121212RESTdesc – http://restdesc.org/ for service composition and invocation processes in the context of the Internet of Things – e.g., smart sensors [26].

  • Capturing the semantics and relationships of REST APIs by using a simplified description model (Linked REST APIs), to automatically discover, compose, and orchestrate Web services [20].

Vii Conclusion and Future Work

The paper focused on REST-based Web services composition by using a straightforward method that adopts a conceptual approach for modeling semantics of (micro)service parameters. Starting with a formal model described in Section II, an automatic service composition algorithm was proposed and evaluated – see Section III.

To prove the feasibility of the proposed formalism, we extended OpenAPI description of stateless services with JSON-LD constructs, in order to conceptually explain the involved entities (resources) of the service’s interface. This new method was detailed in Section IV.

For practical reasons, we adopted the popular schema.org model to quickly determine taxonomic relationships between concepts according to the described algorithm. This was exemplified by the case study presented in Section V. Our approach is general enough to choose convenient ontologies for each specific set of composable (micro-)services. We consider that our proposal is also a suitable solution for service-based business Web applications deployed in various cloud computing platforms.

An alternative approach is to use the SHACL (Shapes Constraint Language) model131313Shapes Constraint Language (SHACL), W3C Recommendation, 2017 – https://www.w3.org/TR/shacl/ to specify certain restrictions on RDF and, equally, on JSON-LD data – this direction of research is to be investigated in the near future in order to provide support for accessing semantically enriched digital content [14].

We are aware that the proposed method presents several shortcomings – e.g., lack of support regarding service meta-data such as quality of service, various restrictions, work and data-flows, and others. These aspects will be considered, formalized, and implemented in the next stages of our research.

References

  • [1] D. Allemang and J. Hendler (2011) Semantic Web for the Working Ontologist: Effective Modeling in RDFS and OWL. Elsevier. Cited by: §II-B, §IV-A, §IV-B.
  • [2] S. Baccar, M. Rouached, R. Verborgh, and M. Abid (2018) Declarative Web Services Composition using Proofs. Service Oriented Computing and Applications, pp. 1–19. Cited by: §VI.
  • [3] M. B. Blake, W. Cheung, M. C. Jaeger, and A. Wombacher (2006) WSC-06: the web service challenge. In The 8th IEEE International Conference on E-Commerce Technology and The 3rd IEEE International Conference on Enterprise Computing, E-Commerce, and E-Services (CEC/EEE’06), pp. 62–62. Cited by: §VI.
  • [4] V. Cardellini, E. Casalicchio, V. Grassi, and F. L. Presti (2007) Flow-based service selection for Web service composition supporting multiple QoS classes. In Web Services, 2007. ICWS 2007. IEEE International Conference on, pp. 743–750. Cited by: 2nd item.
  • [5] Cremaschi (2018) A Practical Approach to Services Composition Through Light Semantic Descriptions. In European Conference on Service-Oriented and Cloud Computing, pp. 130–145. Cited by: §VI.
  • [6] T. Erl (2007) SOA: Principles of Service Design. Prentice Hall. Cited by: §I, §VI.
  • [7] G. Fenza, V. Loia, and S. Senatore (2008) A Hybrid Approach to Semantic Web Services Matchmaking. International Journal of Approximate Reasoning 48 (3), pp. 808–828. Cited by: 7th item.
  • [8] R. T. Fielding (2000) Chapter 5: REpresentational State Transfer (REST). Architectural Styles and the Design of Network-based Software Architectures (Ph. D. Thesis). Cited by: §I, §IV-A.
  • [9] M. Garriga, C. Mateos, A. Flores, A. Cechich, and A. Zunino (2016) RESTful Service Composition at a Glance: A Survey. Journal of Network and Computer Applications 60, pp. 32–53. Cited by: §VI.
  • [10] R. V. Guha, D. Brickley, and S. Macbeth (2016) Schema.org: Evolution of Structured Data on the Web. Communications of the ACM 59 (2), pp. 44–51. Cited by: §II-A.
  • [11] M. Klusch, A. Gerber, and M. Schmidt (2005) Semantic Web Service Composition Planning with OWLS-xplan. In Proceedings of the 1st Int. AAAI Fall Symposium on Agents and the Semantic Web, pp. 55–62. Cited by: 6th item.
  • [12] F. Lécué and A. Léger (2006) A Formal Model for Semantic Web Service Composition. In International Semantic Web Conference, pp. 385–398. Cited by: 1st item.
  • [13] A. L. Lemos, F. Daniel, and B. Benatallah (2016) Web Service Composition: a Survey of Techniques and Tools. ACM Computing Surveys (CSUR) 48 (3), pp. 33. Cited by: §VI.
  • [14] O. Levina (2018) Towards a Platform Architecture for Digital Content. In Proceedings of the 15th International Joint Conference on e-Business and Telecommunications, ICETE 2018 – Volume 1: DCNET, ICE-B, OPTICS, SIGMAP and WINSYS, pp. 340–347. Cited by: §VII.
  • [15] D. Martin, M. Burstein, D. Mcdermott, S. Mcilraith, M. Paolucci, K. Sycara, D. L. Mcguinness, E. Sirin, and N. Srinivasan (2007) Bringing Semantics to Web Services with OWL-S. World Wide Web 10 (3), pp. 243–277. Cited by: 5th item.
  • [16] N. Milanovic and M. Malek (2004) Current Solutions for Web Service Composition. IEEE Internet Computing 8 (6), pp. 51–59. Cited by: §VI.
  • [17] C. Peng, P. Goswami, and G. Bai (2018) Fuzzy Matching of OpenAPI Described REST Services. Procedia Computer Science 126, pp. 1313–1322. Cited by: 2nd item.
  • [18] C. Preist (2004) A Conceptual Architecture for Semantic Web Services. In International Semantic Web Conference, pp. 395–409. Cited by: 4th item.
  • [19] J. Rao and X. Su (2004) A Survey of Automated Web Service Composition Methods. In International Workshop on Semantic Web Services and Web Process Composition, pp. 43–54. Cited by: §VI.
  • [20] D. F. Serrano Suarez (2018) Automated API Discovery, Composition, and Orchestration with Linked Metadata. Ph.D. Thesis. Cited by: 5th item.
  • [21] D. Sferruzza, J. Rocheteau, C. Attiogbé, and A. Lanoix (2018) Extending OpenAPI 3.0 to Build Web Services from their Specification. In International Conference on Web Information Systems and Technologies, Cited by: 1st item.
  • [22] A. P. Sheth, K. Gomadam, and A. H. Ranabahu (2008) Semantics enhanced services: Meteor-s, SAWSDL and SA-REST. Bulletin of the Technical Committee on Data Engineering 31 (3), pp. 8. Cited by: 9th item.
  • [23] P. Shvaiko and J. Euzenat (2013) Ontology Matching: State of the Art and Future Challenges. IEEE Transactions on knowledge and data engineering 25 (1), pp. 158–176. Cited by: §IV-B.
  • [24] K. Sycara, M. Paolucci, A. Ankolekar, and N. Srinivasan (2003) Automated Discovery, Interaction and Composition of Semantic Web Services. Web Semantics: Science, Services and Agents on the World Wide Web 1 (1), pp. 27–46. Cited by: 3rd item.
  • [25] J. T. Timm and G. C. Gannod (2005) A Model-driven Approach for Specifying Semantic Web Services. In IEEE International Conference on Web Services, pp. 313–320. Cited by: 8th item.
  • [26] D. Ventura, R. Verborgh, V. Catania, and E. Mannens (2015) Autonomous Composition and Execution of REST APIs for Smart Sensors. In SSN-TC/OrdRing@ ISWC, pp. 13–24. Cited by: 4th item.
  • [27] R. Verborgh, A. Harth, M. Maleshkova, S. Stadtmüller, T. Steiner, M. Taheriyan, and R. Van de Walle (2014) Survey of Semantic Description of REST APIs. In REST: Advanced Research Topics and Practical Applications, pp. 69–89. Cited by: §VI.
  • [28] P. Wang, K. Chao, C. Lo, C. Huang, and Y. Li (2006) A fuzzy model for selection of qos-aware web services. In 2006 IEEE International Conference on e-Business Engineering (ICEBE’06), pp. 585–593. Cited by: 2nd item.
  • [29] E. Wittern, A. Cha, and J. A. Laredo (2018) Generating graphql-wrappers for rest (-like) apis. In International Conference on Web Engineering, pp. 65–83. Cited by: 3rd item.