Comp-O is an extension of OWL-S that we have proposed to describe the semantics of component-based services. Based on a proof-of-concept prototype, this demonstration shows how Comp-O is used to support assistance to developers of component-based services and automatically generate their descriptions for publication and discovery purposes1.
Component-based software engineering [
Software components [
Developing composite services is a challenging task as it requires identifying components and services that are compatible, binding them to implement the service, and describing it semantically for discovery by third parties. The semantics of a component-based service depend on the semantics of the services that are required by the provider component. Since the latter are abstracted in the provider component, the actual semantics depend on the semantics of the provided services they are bound to. In a way, the semantics of a composite service are distributed among the components. Therefore, they must be synthesized from the semantics of the components that compose the assembly. 1 Copyright © 2020 for this paper by its authors. Use permitted under Creative
Commons License Attribution 4.0 International (CC BY 4.0).
The problem is to describe the services provided by components that have
required services, both to enable assistance to service developers when they
assemble components and to combine such descriptions to automatically
generate composite service descriptions. For that, the vocabulary used to describe
component-based services must take into account the required services, and these
atomic descriptions must be combinable. State of the art shows that considering
ontologies when describing services improves their discoverability [
The next section presents the ontology we propose, called Comp-O. Then, Section 3 introduces a proof-of-concept implementation and shows how CompO supports the building of composite services and the automatic generation of their semantic descriptions. 2
Comp-O, an OWL-S extension for component-based
services
The development of our ontology, compliant with the NeOn methodology [
Comp-O8, the extension of OWL-S we have proposed, is available on line at https://comp-o.github.io/comp-o. It allows representing service required interfaces. This representation can be exploited when de ning composite services. Comp-O consists of { three new classes: comp-o:ComponentBasedService, comp-o:RequiredPerform, comp-o:ServiceContract, { and one object property comp-o:requiredPerformContract.
The class comp-o:RequiredPerform is de ned to describe the required interfaces of a component-based service. It specialises owls-process:Perform. This control construction references a comp-o:ServiceContract represented by a service pro le that does not reference any process (a black-box). The class compo:ServiceContract specialises owls-pro le:Pro le. It is used to de ne the types of inputs and outputs and pre/post-conditions speci ed by a required interface. The class comp-o:ComponentBasedService specialises owls-service:Service. It is de ned to describe a service that can have no or several comp-o:RequiredPerform (required interface) in its process, and that is not operational until all its compo:RequiredPerform are replaced with an actual perform referencing another process.
Finally, the comp-o:requiredPerformContract predicate is used to link a compo:RequiredPerform with the comp-o:ServiceContract it requires. 3
To demonstrate our solution, we have developed a proof-of-concept implementation. It is available at https://github.com/comp-o/comp-o-poc. In practice, a command line interface helps the user to select and assemble components, and outputs its OWL-S description.
A demonstration video is available online at https://www.irit.fr/~Sylvie. Trouilhet/demo/iswc2020.mp4. It brie y introduces the concepts of software components and component-based services using a simple example in the eld of ambient systems. It sets out service description and discovery issues. Then, the above example is used to illustrate what can be done using Comp-O: relying on service descriptions as inputs, the developer is assisted when building a component-based service and its description is automatically generated. 8 The pre xes used are comp-o: https://comp-o.github.io/comp-o#, owlsservice: http://www.daml.org/services/owl-s/1.2/Service.owl#, owls-process: http://www.daml.org/services/owl-s/1.2/Process.owl#, owls-pro le: http:// www.daml.org/services/owl-s/1.2/Profile.owl#
The building process is described below and summarized in Fig. 2. A list of the available component-based services is rst presented. To do this, all that is needed is to retrieve the set of resources typed by the service:Service class. Then, the developer must choose the \root" service, i.e., the service to implement. Comp-O helps to determine whether the component that provides it has any required interface, i.e., if one of the control constructions of the process of the service it provides is a comp-o:RequiredPerform. This property can be comprehensively checked considering OWL-S vocabulary using a SPARQL query.
If the component providing the service does not require any service, it can be described and published as an OWL-S service. If the component has one or more required services, the latter must be bound to external component-based services. If so, to ease the binding decisions, it can be determined whether a provided service matches a required one. This requires checking that the types of the inputs and outputs, the preconditions and the post-conditions match. This task must be repeated as long as there are unbound required services in the assembly. Then, the component-based implementation of the chosen service is operational, and its OWL-S description can be generated.
To generate the semantic description, the rst step consists in replacing every comp-o:RequiredPerform by an owls-process:Perform referencing the process associated in the assembly, using the owls-process:process predicate instead of referencing a comp-o:ServiceContract via the comp-o:requiredPerformContract predicate. The process of a component-based service can reference as variables the inputs and outputs of a comp-o:ServiceContract it requires. For each service, the second step is therefore to replace the references to these variables by references to the equivalent variable of the associated service. This step can be accomplished by processing all the owls-process:fromProcess predicates having as object a resource of the type comp-o:ServiceContract. Once these two steps are complete, the component-based services are then described as OWL-S services. In this work, we have experimented Semantic Web technologies in the eld of component-based software engineering. This paper has introduced Comp-O, an extension of OWL-S for component-based services which are services provided by software components, and the use of Comp-O to support the design of component-based services. Our proposal contributes to the state of the art in terms of assistance to component-based software developers and automated description of component-based services.
In a near future, we plan to use Comp-O in an ongoing project which aims to
make user-oriented services emerge at runtime in ambient environments. There,
an intelligent engine builds on the y component-based services from software
components that are present at the time in the environment, without having been
required by the user. As a consequence, emerging services must be semantically
described to the user [