Abdelhadi Belfadel
email: abdelhadi.belfadel@univ-lyon2.fr

Emna Amdouni
email: emna.amdouni@univ-lyon2.fr

Jannik Laval
email: jannik.laval@univ-lyon2.fr

Chantal Cherifi
email: chantal.bonnercherifi@univ-lyon2.fr

Nejib Moalla
email: nejib.moalla@univ-lyon2.fr

Ontology-based software capability container for RESTful APIs

Keywords: software reuse, capability container, software capability, ontology, Restful API, enterprise architecture, TOGAF, SOA, sustainability, business process, requirement analysis

Software reuse and REST-based Web Applications resulted from open initiatives become an interesting opportunity for companies to save effort, time and cost during the design and development of new business needs. Gather and qualify these services in a container helps to discover, match and reuse them in developing new business applications for companies. Our objective in this work is the design of a software capability container offering a wider view qualification for REST-based services. Moreover, we aim to enrich the designed container with semantic elements to ease the discovery and the selection of the qualified services. In this purpose, we define an ontology based on a proposed Enterprise Architecture Capability Profile offering a qualification covering business, operational and technical aspects for services. Ontologies are widely acknowledged as a means to specify explicitly the meaning of concepts in a domain of interest, and to facilitate consistent sharing of data and knowledge pertaining to them. The qualification profile is based on a proposed meta-model that helps to retrieve and gather initial requirements used to guide the development of existing REST-based Web Applications. Furthermore, a Framework is proposed to exploit the designed container in order to respond to users requirements for developing future business process and efficiently reuse the qualified services. Our contribution aims to upgrade technical components to the level of end-users requirements. This helps to accelerate business application development and improve the reuse and sustainability of existing services.

I. INTRODUCTION

Several open source REST-based Web Applications result from different initiatives as "Factories of the Future" from the European Union. On the one hand, these initiatives offer to Small and Medium-Sized Enterprises (SMEs) solutions to help them exploring new solutions, prototype new business needs, bring some evolution to their existing applications and add new functionalities quickly with lower cost. This helps to improve productivity, bring ideas to the market and increase their competitiveness. On the other hand these applications expose services through RESTful APIs offering to developers reliable functionalities which are easy to integrate. Therefore, many research works are motivated to alleviate the usage of these REST-based SOA Applications, by proposing methods and tools to allow developers or end-users to build new business applications by composing on existing APIs [START_REF] Benslimane | Services mashups: The new generation of web applications[END_REF], [START_REF] Nesa | Enriching api descriptions by adding api profiles through semantic annotation[END_REF]. This helps to reduce effort spent on coding and maintenance activities, and increase software quality [START_REF] Minhaz F Zibran | Useful, but usable? factors affecting the usability of apis[END_REF].

As mentioned, SMEs need to stay competitive therefore the modeling and prototyping of new business processes are required. The design and modeling of new business processes helps also to modernize existing systems and create new collaboration scenarios with other partners. As SMEs usually operate under limited resources, thus one design possibility is to maximize the reuse of existing solutions and services. This helps to control cost and quality, and moreover realize a prototype quickly to evaluate if the designed solution fits the specified requirements. But open source applications face some limits as they lack of documentation. As for instance description of business vision or requirements that helped in the realization of these application, as business goals and objectives. This can make the features of these solutions overlooked by the public due to difficulties to discover, to qualify quantitatively and qualitatively for reuse ends. Moreover, while user requirements lie in the problem area, software and service requirements lie in the solution area [START_REF] Pratap | Software Engineering[END_REF], it means more efforts are required to translate the user needs into software requirements.

The objective of this work is to increase software reuse through a software capability container, which offers a complete qualification with an adequate level of quality of service in design time and at runtime. In other words, we aim to retrieve and gather initial requirements and architecture knowledge from existing services in a software capability container. This helps to facilitate the decision making when choosing the suitable services that fit the users' requirements. The expected results from this work is a meta-model for software qualification, allowing to produce a qualification ontology gathering the qualified solutions in a repository for a future exploitation. This will improve the integration and usage of REST based web application for prototyping new business needs by offering more visibility on existing features for reuse ends.

However, answering to our research problematic was not a trival task given that we faced several problems that we can summarize as follows: the first problem is how to identify initial requirements and architecture knowledge used to guide the development of existing REST-based web applications? The second problem is how to structure the gathered knowledge in The reformulated research problem is how to improve the reusability and sustainability of REST-based web applications to meet specific business needs?

In our previous works [START_REF] Belfadel | Towards service orchestration through software capability profile[END_REF] and [START_REF] Belfadel | Capability profile for enterprise application integration[END_REF], we proposed a solution to respond to the specified research problem. We proposed an Enterprise Architecture Capability Profile (EACP) Framework that fits the problem and solution areas based on Enterprise Architecture Framework (TOGAF based) and Software Product Lines (SPL) paradigm. This helps to cover the two domains when qualifying an existing solution and offer higher-level of functional representations.

The EACP Framework proposed in our previous work is presented in Fig 1 . Composed by two main phases as for the Software Product Lines (SPL) paradigm [START_REF] Lee | Combining service-orientation with product line engineering[END_REF], [START_REF] Bashari | Automated composition of service mashups through software product line engineering[END_REF]. The first phase refers to the domain engineering phase where quality check is applied to the REST-based Web Applications. This phase ends with a first qualification of the functional aspects based on the ISO 1610 norm. This first qualification level is enriched with the second qualification that gather the business, operational and non-functional specifications of the component. This final and complete qualification is stored in a container that we introduce under the name of Entreprise Architecture Knowledge Repository (EAKR) gathering all software capabilities as will be presented in this work. The result of this first phase is a connection between the REST based services and its related qualifications.

To maximize the reuse of the qualified components, endusers identify their requirements using BPMN notation.In the second phase of the EACP framework (Application Engineering Phase), the exploitation process is performed. This phase fetches and matches user requirements with existing and qualified software components in the Enterprise Architecture Knowledge Repository. The result of this phase is a set of Architectural Building Blocks (ABBs) and Solution Building Blocks (SBBs) that respond to the expressed needs. These SBBs are composed in order to generate a prototype to deploy and ready to be used by end-users.

The main part in the previous work concerns the EACP profile. It offers a complete qualification needed for exploring and reusing features when developing new business applications. This in an objective to maximize the reuse, low costs and adaptation effort. In the following, we describe the proposed qualification meta-model depicted in Fig. 2 and the relation between its different parts:

1) Organizational part: it is composed by the organization unit, with its related business goals and objectives. 2) Business part: it represents the new business process to realize. It is linked to a set of activities that composes the targeted business process to create. Added to this, this part describes the roles and actors that are concerned by the selected activities, and the event that could be trigged by an actor with a specific role. 3) Platform part: it describes the execution environments on which the targeted business application will run. This part is composed by the resulted application, related to the platform where the application will be deployed and the related components needed in the execution environment. 4) Architecture Builing Blocks (ABBs): it qualifies the existing feature by describing: (i) the business function, (ii) related attributes, (iii) corresponding constraints, (iv) the ability to communicate and exchange information, Each part of the meta-model is instantiated with an adequate level of details. Due to paper length constraints, we present in this work we present only the ABB model that is depicted in Fig. 3.

The instantiated qualifications using the described model is saved in the EAKR container. The qualified services need to be enriched with semantic elements to ease the discovery and the selection of the most suitable service that fits the described user needs. The EAKR contains information that are associated to different levels (i.e., organization, business, functional, nonfunctional, http resource), and has a dynamic context with the continuous instantiation of the SBBs and related ABBs. Furthermore, we need a formal and explicit representation of these information. Due to these elements, we need an ontological modeling in order to construct this repository based on the meta-model and model already presented.

The main contribution of this work is: (i) the design of a wider view qualification for REST-based services, covering business, technical and organizational aspects; (ii) the proposal of a software capability container based on an ontology for service qualification.

The rest of this paper is organized as follows: Section II focuses on the Related work, and Section III presents the proposed qualification ontology. Section V presents the contribution and the targeted process for service discovery. Finally, conclusion and future work are drawn in Section VI.

II. RELATED WORK

As presented in the previous section, we need in this work to design a container of software capability by modeling the needed functional and non-functional aspects of REST-based services using an ontology. We believe that this will help to gather the desired qualification of REST-based services for discovery and reuse purpose.

Web service selection involves the discovery of services. It is the the process where the corresponding services meet the specific users' requirements [START_REF] Booth | W3c web services architecture[END_REF]. Many researchers have proposed solutions to characterize services by adding nonfunctional attributes as Quality Of Service [START_REF] Sophea Chhun | A multi-criteria service selection algorithm for business process requirements[END_REF], [START_REF] Iordache | Qos-aware web service semantic selection based on preferences[END_REF], [START_REF] Nanang | Multi-criteria decision making for selecting semantic web service considering variability and complexity trade-off[END_REF], or by adding semantics to functional attributes helping to realize ontology matching between requirements and services [START_REF] Boissel-Dallier | Mediation information system engineering based on hybrid service composition mechanism[END_REF].

In the context of software engineering and software life cycle phases, there is a growing interest in the use of ontologies [START_REF] Bhatia | Ontologies for software engineering: Past, present and future[END_REF], [START_REF] Jeff Z Pan | Ontology-driven software development[END_REF]. In [START_REF] María | An ontology to document a quality scheme specification of a software product[END_REF], the authors presented an ontology based on OWL-S that helps to describe quality properties defined in ISO 25010 and linked to software product. In [START_REF] Vasanthapriyan | An ontology-based knowledge sharing portal for software testing[END_REF] and [START_REF] Vasanthapriyan | An ontology-based knowledge framework for software testing[END_REF], the authors proposed an ontology in Software Testing domain to organize software testing knowledge, and provide context-specific information to software testers. In [START_REF] Rastgoo | Semantic web-based software engineering by automated requirements ontology generation in soa[END_REF], the authors proposed an automatic generation of software requirements in the form of an ontology using the UML diagrams. In [START_REF] Wen Too | Towards improving usability requirements elicitation and specification using ontology-driven approach[END_REF], the authors presented usability requirement elicitation and specification method by using ontology. Our work in this context of software life cycle could be considered as input to the existing ontologies. As for testing domain, requirement elicitation or software quality, our work offers a complementary qualification for REST-based services to the existing ontological models.

In what follows, we focus on web service description used to design the proposed meta-model and the related ontology.

A. APIs and Web Service description

The description of an API is important for its successful adoption. APIs expose services and data and should be conceptualized and designed in an understandable way for consumers or developers, enabling them to start using it easily and quickly. APIs should provide an understandable and a humanreadable description. The API description is also parsed by machine to make server-side code or client stubs to consume the APIs. To make API documentation efficient, it has to include the following aspects as described in [START_REF] De | API Management: An Architect's Guide to Developing and Managing APIs for Your Organization[END_REF]: title, endpoint, method, URL parameters, message payload, header parameters, response code, error code. Many technologies and tools are available for API documentation as API Blueprint1 or RESTful API Modeling Language (RAML) 2 . In our work, web service description is based on Open API Specification (known also as Swagger specification) designed for REST APIs.

Furthermore, several web service descriptions exist on literature and are based on the Web Service Description Language (WSDL) standard [START_REF] Chinnici | Web services description language (wsdl) version 2.0 part 2: Adjuncts[END_REF], which is often used in combination with SOAP and an XML Schema to provide Web services over the Internet. WSDL provides a machine-readable description, helping to know how the service can be called? what parameters does it expect? What response or data structures does it return? It specifies functional and non-functional properties of Web services. The functional specifications describe inputs, outputs and operations exposed by a service by their name and data type. For the non-functional specifications, they describe the location of the service, the protocol used and the data type and format.

Since WSDL lacks the semantic needed to represent services capabilities, other languages using semantic are proposed by ontologies to allow reasoning on service capabilities as Ontology Web Language for Services (OWL-S) [START_REF] Martin | Bringing semantics to web services: The owl-s approach[END_REF], WSDL-Semantic (WSDL-S) [START_REF] Akkiraju | Web service semantics-wsdl-s[END_REF], Semantic Annotation for WSDL (SAWSDL) [START_REF] Kopeckỳ | Sawsdl: Semantic annotations for wsdl and xml schema[END_REF]. Other languages as Unified Service Description Language (USDL) [START_REF]Handbook of Service Description[END_REF] aims to provide a general framework for services and offer some features for instance support pre-and post-conditions.

B. Ontologies for service reuse

Business process management and SOA architectures has allowed the expansion of web service matchmaking and composition. In [START_REF] Boissel-Dallier | Mediation information system engineering based on hybrid service composition mechanism[END_REF], the authors proposed a semantic profile covering the functional properties of Web Services that are used in a top-down approach for service matchmaking. Other projects as [START_REF] Tamm | How does enterprise architecture add value to organisations?[END_REF] and [START_REF] Antonio Parejo | Qos-aware web services composition using grasp with path relinking[END_REF] focused on quality of service (QoS) to choose the suitable service which fits the non-functional properties. In [START_REF] Sophea Chhun | A multi-criteria service selection algorithm for business process requirements[END_REF] the authors proposed an ontology to qualify services from non-functional point of view. A matching between BPMN process and inputs and outputs of the services is realized, and a string comparison between name and data-type of parameters is proposed by taking into consideration the variations in QoS of services when selecting services that matches the user needs. In [START_REF] Purohit | Web service selection using semantic matching[END_REF], authors propose a mechanism for web service selection based on input and output information over keyword based search.

C. Discussion

Most research works and practitioners used QoS for semantic web service selection [START_REF] Sophea Chhun | A multi-criteria service selection algorithm for business process requirements[END_REF], [START_REF] Iordache | Qos-aware web service semantic selection based on preferences[END_REF], [START_REF] Nanang | Multi-criteria decision making for selecting semantic web service considering variability and complexity trade-off[END_REF] , by comparing and matching QoS attributes annotated in the web service description with the help of ontology using OWL-S or SAWSDL. So far, no effort has been made toward the web service discovery and selection that consider the business goals and objectives of the users' needs, nor the reconciliation with the initial requirements that helped the realization of the existing services.

The challenge in this case is to select the suitable REST based services that fit users' requirements, by taking into consideration : (i) The functional aspect as operational description, business need, organization of the users. (ii) Non-functional specifications as the technical descriptions with dynamic QoS in run-time or the platform where services are executed.

Our model shares some elements with OWL-S, and we need to reduce ambiguities in matching between users' requirements and features. Therefore we decided to extend OWL-S ontology based on existing ontologies. This helps to improve the coverage of REST-based services qualification. The next section describes the design process of the EACP Ontology and introduces our developed ontology.

III. EACP ONTOLOGY

Our developed ontology is composed of two main components: the terminological component (TBox) that describes in a formal way the related vocabulary of software capabilities and the assertion box (ABox) that stores ontology statements. To build our ontology, we considered the Uschold's methodology [START_REF] Uschold | Towards a methodology for building ontologies[END_REF] and followed these steps: first, we defined the scope of the EACP ontology by formulating some competency questions (CQs) and extracting domain knowledge from the proposed meta-model (Fig. 2) and related model. Here, we cite only three CQS that we have identified:

• CQ 1 : Retrieve ABBs from end-users' requirements based on business goals and objectives, • CQ 2 : Retrieve SBBs related to selected ABBs, • CQ 3 : Retrieve related SBBs that respect end-users' constraints. Second, we identified existing ontologies that cover our domain needs and that are objective, modular, complete and coherent. We selected a top-level ontology called Basic Formal Ontology3 (BFO) and two domain ontologies namely, OWL-S 4 and Information Artifact Ontology5 (IAO). Third, we integrated and extended in a coherent way the selected ontologies into the EACP ontology using the Protégé Ontology Editor6 V4.3. We note that only a subset of IAO was reused in our developed ontology. We excluded obsolete classes and classes that do not correspond to our scope. Finally, we evaluated the internal consistency and inferences of the model using the Fact++ reasoner.

Our resulted ontology contains 160 classes, 184 object properties and 33 data properties. EACP ontology is a modular ontology and it defines its classes and relations under the BFO framework. BFO is a widely used ontology its main goal is the integration of knowledge from different semantic resources and the modeling of data about entities in the world (here, we refer to our meta-model). We followed the alignment methodology that is described in [START_REF] Arp | Building ontologies with basic formal ontology[END_REF] to map EACP to BFO. Based on our knowledge, the BFO ontology has not been used yet in the integration of service qualification meta-data. We resused IAO ontology to model data about information artifacts of the meta-model (e.g., conditional specification, objective specification, software application, etc.). In our work, we used the Web Ontology Language7 (OWL) in the design of the TBox and the Resource Description Framework (RDF) 8in the generation of the ABox's RDF triples.

Unlike the IAO ontology, OWL-S is not based on BFO. Thus, we realized a mapping work between IAO and OWL-S to integrate our three modules namely BFO, IAO and OWL-S into the EACP ontology. In Table II, we sumarize some toplevel mappings between IAO and OWL-S to cover data of our The use of BFO classes and object properties hepled us in the integration of data and the formalization of knowledge. We used for example, the class "BFO:information content entity" to denote the entity "resource", the class "BFO:material entity" to represent the entity "organizational unit" and the class "BFO:role" to describe the entity "user role". We employed for example, the object property "BFO:hasContinuantPartAtSomeTime" to express that an "EACP:architecture building block" refers to at least one "EACP:solution building block" or the fact that an "OWL-S:process" has some "OWL-S:output", etc. Some pivotal classes of the EACP ontology are shown in Figure 4. As illustrated in this figure, UML entities "business goals" and "business objectives" are described as subclasses of the class "IAO:objective specification" via the use of the relation "IsA". The SSB is described as a subclass of "IAO:software application" and the ABB is defined as a subclass of "IAO:software module". Table II illustrates some class mappings between our proposed meta-model and the EACP ontology.

We enriched the ontology with semantic axioms in order to improve it with reasoning capabilities. We added the following axioms:

• Necessary and sufficient conditions (i.e.,"OWL-S:process" "OWL-S:atomic process" or "OWL-S:simple process" or "OWL-S:composite process"); • Existential restrictions as "some" restrictions (i.e., OWL-S: process "BFO:hasContinuantPartAtSomeTime" some "OWL-S:condition"); • Universal restrictions as max restrictions (i.e., "OWL-S:process" "OWL-s:name" max 1 "Literal"); • Disjoint classes (i.e., "OWL-S:input" disjoint with "OWL-S:output").

To conclude, EACP ontology has two main benefits: first, it is easily extensible to respond to new business needs thanks to its modular structure. Second, it insures the coherence of data even if we integrate other existing ontologies thanks to the BFO framework. The process as presented in Fig. 5 reflects an example of requirement sequence requested by an industrial end-user. The process aims to receive a 3D point could which represents a scanned piece. The received data are visualized using a 3D visualizer, and sent to a quality check which compares the received piece with a CAD design figure. Finally, the quality control report is saved in a database. The company has no knowledge about the existing services that could be reused, their quality or the relevance of a specific service between several possible solutions that can meet their specific needs.

As first action, we have already qualified as presented in section 1 a web application called 3DScan from FITMAN9 project. A qualification of a REST service from this web application is realized using the proposed Enterprise Architecture Capability Profile and saved in the repository. In the following, we present an instance of the ABB model as depicted in Fig. 3. This instance is saved in the Enterprise Application Knowledge Repository and exploited in the second phase of our proposed Framework (Application Engineering Phase). Figure 6 illustrates an extract of the RDF graph of the ABB part concerning the web service "get 3D object". We note that ABB's meta-data are stocked in an RDF/XML format. The pivotal instance in our graph is the ABB value that is annoted as an "abbread3Dobject". This ABB value is contained in the description profile of the web service (i.e. "profileRead3DObject") and has two main parts namely "ob-jectiveRead3DObject" and "goalsRead3DObject". We used the object property "BFO:haspart" to decribe the composition between two instances and the data property "RDFS:label" to decribe the textual content of instances (e.g., the "goal-sRead3DObject" has as a label value the following content "achieve a high quality production without slowing down the production processes".).

Such an annotation work may help us to formalize and classify APIs' qualifications through i.e., the retrieval of ABB's from end-users requirements based on business goals and objectives or the selection of ABB's instances of a given SBB's parts. The main contributions of this work are: (i) the design of a wider view qualification for REST-based services, covering business, operational, technical and organizational aspects; (ii) the proposal of a software capability container based on EACP ontology for service discovery and orchestration; (iii) the proposal of a Framework that offers a complete qualification needed for exploring and reusing features when developing new business application; and (iv) upgrade technical components to the level of end-users requirements in order to accelerate business application development using service assets from existing SOA Web Applications.

The generated EACPOnto instances are saved in the Enterprise Application Knowledge Repository (EAKR) to be explored and exploited in the second phase of our proposed Framework (Application Engineering Phase) in Fig. 7. The process illustrates the actions that we aim to realize in order to exploit the EAKR. The end-user designs the required business process (in different level which concerns the design phase, implementation phase and deployment phase), with its organization constraints in BPMN format. We aim to evaluate as first action the business "wants" that must be delivered to meet the objectives and identify domain constraints. Then a reconciliation system based on Multi-criteria ABB selection between BPMN ontology and EACP Ontology will be proposed. This helps to match the suitable ABBs and related SBBs according to the defined business process and related constraints. A service orchestration is realized based on HTTP resources related to the SBBs in order to package the final application to the end-user and to deploy in the desired environment. In this work, we propose a software capability container and its related ontology which offers a wider view qualification to improve the discovery and reuse of REST-based services. This container lies on a proposed Framework called EACP Framework and a meta-model based on TOGAF which is the most used enterprise architecture reference frame. The metamodel is also combined with dynamic quality metrics needed for services selection. As future work, we intend to propose a multi-criteria Architecture Building Blocks selection algorithm based on BPMN ontology and our proposed EACP Ontology. This helps to find and match services that fits the requirements expressed by end-users. Moreover, it aims to improve the reuse of REST-based Web Application for the implementation and deployment of new business process.

Fig. 1 .

 1 Fig. 1. Proposed Framework

Fig. 2 .

 2 Fig. 2. Proposed meta-model

Fig. 3 .

 3 Fig. 3. Proposed Model for ABBs

Fig. 4 .Fig. 5 .

 45 Fig. 4. Main classes of EACP ontology (Protégé Ontology Editor)

Fig. 6 .

 6 Fig. 6. EACP Ontology instance

Fig. 7 .

 7 Fig. 7. Proposed Framework -Requirements Elicitation for the design phase

TABLE I MAIN

 I TOP-LEVEL CLASSES MAPPING TO ALIGN OWL-S TO IAO ONTOLOGY.WE NOTE THAT THE SYMBOL "⊆" DENOTES A SUBSUMPTION In the next paragraphs, Italics are used to denote semantic classes and relations of ontologies. Concerning the latter, labels are used (rather than actual IRI), for the sake of legibility.

		RELATION.
	OWL-S class	ISA Parent class IAO
	OWL-S:service profile	⊆	IAO:directive information entity
	OWL-S:service grounding ⊆	IAO:directive information entity
	OWL-S:service model	⊆	IAO:directive information entity
	OWL-S:service	⊆	IAO:software module
	OWL-S:variable	⊆	IAO:information content entity
	OWL-S:expression	⊆	IAO:information content entity
	OWL-S:condition	⊆	IAO:conditional specification
	meta-model.

TABLE II SOME

 II CLASS MAPPINGS BETWEEN OUR PROPOSED META-MODEL AND THE EACP ONTOLOGY

	Meta-model entity	EACP ontology class	Parent class in EACP ontology
	Business objectives	EACP:business objectives	IAO:objective specification
	Business goals	EACP:business goals	IAO:software module
	Application	EACP:software application	IAO:software
	Application component	ECAP:application component	IAO:software component
	Process	OWL-S:process	OWL-S:service model
	Role	BFO:role	BFO:realizable entity
	Actor	EACP:actor	BFO:material entity
	organizational unit	EACP:organizational unit	BFO:material entity
	Architecture building blocks	EACP:architecture building blocks OWL-S:software module
	solution building blocks	EACP:solution building blocks	OWL-S:software module
	Representation on media type EACP:request language	IAO:plan specification
	Parameters	OWL-S:parameters	IAO:information content entity

https://apiblueprint.org/

http://raml.org/

http://basic-formal-ontology.org/

https://www.w3.org/Submission/OWL-S/

www.obofoundry.org/ontology/iao.html

http://protege.stanford.edu

https://www.w3.org/OWL/

https://www.w3.org/RDF/

www.fiware4industry.com

ACKNOWLEDGMENT

This paper presents some results that are developed in the Vf-OS project. This project has received funding from European Unions Horizon 2020 research and innovation program under grant agreement no. 723710. The content of this paper does not reflect the official opinion of the European Union. Responsibility for the information and views expressed in this paper lies entirely with the authors.