Project Topics
Get Complete Project Material File(s) Now! »
Semantic Service Description Languages: State Of The Art
OWL-S (previously named DAML-S)1, is an ontology defined using the Ontology Web Language (OWL)2 to describe Web services capabilities. Using OWL-S, a service descrip- tion is composed of three parts: the service profile, the process model and the service grounding. The service profile gives a high level description of a service and its provider and is generally used for service publication and discovery. It includes: (1) An informal description of the service oriented to a human user; (2) A description of the service’s ca- pabilities, in terms of Inputs, Outputs, Pre-conditions and Effects (IOPE); and (3) An extensible set of attributes describing complementary information about the service, like the service type, category, etc. The process model describes the service conversation as a process, while the service grounding specifies the information necessary for service invoca- tion. There have been efforts for formally specifying OWL-S conversations using process algebra [Narayanan and McIlraith, 2002].
Semantic Service Specification Model
The UML diagram depicted in Figure 3.1 shows a graphical representation of our semantic service model. This diagram introduces the various elements of our model and the key relationships between these elements.
Provided and Required Capabilities
At the heart of our model is the concept of Service, which is defined as an aggregation of a non-empty set of independent Capabilities and a possibly empty set of Non-Functional Properties. A capability is defined as an aggregation of a potentially empty set of In- puts, a non-empty set of Outputs, an optional Category, an Automaton for describing its Conversation and a possibly empty set of properties. Capabilities having a conversation that involve other capabilities are said to be composite capabilities, whereas the others are said to be elementary capabilities. Elementary capabilities correspond to the unit of interaction with the service, i.e., service operations. The inputs and outputs of a service capability describe respectively the information necessary for the execution of the capability and the information resulting from the execution of the capability. A capability is also characterized by its category, which is a description of the functionality provided by the capability. Each input, output and category of a capability is defined with a Name, and a possible Semantic Annotation which is used to express the semantics underlying the input, output or the category to which it is associated. The semantic annotation of service elements is optional in order to support both semantic and syntactic-based languages. A Semantic annotation is a reference to an existing ontology concept. It is defined with the Name of the concept, a reference to the Ontology in which the concept is defined, and the Annotation type associated with the semantic annotation. The annotation type is used to specify what is intended by the employment of a semantic concept when annotating an entity. Two annotation types associated with a concept are supported in our model: all-values-from and some-values-from noted ⊗ and ⊕ respectively. For instance, if a pro- vided capability has an output information annotated with a concept associated with the all-values-from annotation type, this means that the latter output can have as type the concept itself or any of its sub-concepts. On the contrary, if an output is annotated with a concept having a some-values-from semantics, this means that it can have as type the con- cept itself or some of its sub-concepts. In contrast with existing approaches that assume one of the two annotation types, our model supports both types in order to allow service providers and service requesters to give more accurate annotations of their provided and required capabilities.
Formalizing the Semantic Service Model
We introduce in this section a formalization of our semantic service model, which serves as a basis for defining our proposed conformance relations and service composition algorithms presented in Chapters 4 and 5, respectively.
Consider a finite set of services S, a finite set of capabilities C, a finite set of non- functional properties P, a finite set of ontologies O, and a finite set of concepts N across the set of ontologies O. A service s in S is defined as a set of capabilities and non-functional properties as follows: (s ∈ S) ⇔ (∃C ⊂ C, ∃P ⊂ P : s =< C, P >).
Matching Semantic Service Capabilities
A number of research efforts have been conducted in the area of matching semantic Web services based on the signatures of their provided capabilities. Signature matching deals with the identification of subsumption relationships between the concepts describing inputs and outputs of capabilities [Zaremski and Wing, 1995]. The subsumption relation allows relating concepts to more generic concepts in an ontology based on their formal definitions given in description logics. After subsumption reasoning on an ontology, the resulting ontology hierarchy is referred to as the classified ontology. This reasoning is performed by a description logics reasoner.
A base algorithm for service signature matching has been proposed by Paolucci et al. in [Sycara et al., 2003, Paolucci et al., 2002]. This algorithm allows matching a required capability, described as a set of provided inputs and required outputs, with a number of provided capabilities, described each as a set of required inputs and provided outputs. Inputs and outputs are semantically annotated with ontology concepts using the all-value- from annotation type. Specifically, the algorithm defines four levels of matching between a provided and a required ontology concept representing an input or an output. These four levels are:
• exact : if the concepts are equivalent or if the required concept is a direct subclass of the provided one.
• plug in: if the provided concept subsumes the required one and the latter is not a direct subclass of the former.
• subsumes: if the required concept subsumes the provided one.
• fail : if there is no subsumption relation between the two concepts.
Table of contents :
1 Introduction
1.1 Towards Service-Oriented Pervasive Computing
1.2 Thesis Contribution and Document Structure
2 Middleware for Service-Oriented Pervasive Computing: Vision and State Of The Art
2.1 Pervasive Computing Environments
2.2 Service-Oriented Pervasive Computing
2.3 Middleware for Pervasive Computing Environments: State of The Art
2.3.1 Proprietary Middleware
2.3.2 Interoperable Middleware
2.3.3 Semantic-aware Middleware
2.3.4 Discussion
2.4 Semantic, Service-Oriented Middleware for Pervasive Computing
3 Semantic Specification of Pervasive Services
3.1 Semantic Service Description Languages: State Of The Art
3.2 Semantic Service Specification Model
3.2.1 Provided and Required Capabilities
3.2.2 Conversation Specification
3.2.3 Non-functional Properties
3.3 Formalizing the Semantic Service Model
3.4 Concluding Remarks
4 Efficient Semantic Service Registry for Pervasive Computing Environments
4.1 Efficient Semantic Service Matching: State Of The Art
4.1.1 Matching Semantic Service Capabilities
4.1.2 Cost of Semantic Service Matching
4.1.3 Optimizations to Semantic Service Matching
4.1.4 Discussion
4.2 Efficient Semantic Service Registry
4.2.1 Service Matching
4.2.2 Efficient Semantic Service Matching
4.2.3 Registry Service Index
4.2.4 Service Publication
4.2.5 Service Location
4.3 Assessing the Efficiency of the Semantic Service Registry
4.4 Concluding Remarks
5 Service Composition in Pervasive Computing Environments
5.1 Service Composition: State Of The Art
5.1.1 Interface-Based Service Composition
5.1.2 Conversation-Based Service Composition
5.2 Semantic-, QoS-aware Conversation-driven Conversation Integration: Overview
5.3 Service Discovery Client
5.4 Service Conformance
5.4.1 Data Flow and Data Constraints
5.4.2 Ordering Constraints
5.5 Service Coordination
5.5.1 Problem Definition
5.5.2 Integrating Service Conversations
5.5.3 Support of Conversation Interleaving
5.5.4 Support of Adaptive User Tasks
5.6 Matching Global Non-Functional Properties of Composed User Tasks
5.7 On the fly User Task Realization for Meeting Pervasive Computing Requirements
5.8 Assessing the Efficiency of the Composition Model
5.9 Concluding Remarks
6 PERSE: Pervasive Semantic-aware Middleware
6.1 Baseline MUSDAC Middleware for Multi-Network, Multi-Protocol Service
Discovery in Pervasive Computing Environments
6.2 The PERSE Middleware Architecture
6.2.1 Multi-Network Management
6.2.2 Service Discovery in PERSE
6.2.3 Service Composition in PERSE
6.2.4 Service Access in PERSE
6.2.5 Interoperable Service Description Language
6.3 Prototype Implementation and Performance Evaluation
6.3.1 Performance of the Prime Number-Based Ontology Encoding Algorithm
6.3.2 Cost of Legacy to ISDL Translation
6.3.3 Performance of the Interoperable Service Matching
6.3.4 Efficiency of the PERSE Service Registry
6.3.5 Performance of the QoS-Aware, Conversation-Based Service Com- position
7 Conclusion
7.1 Contribution
7.2 Perspectives
A Proofs
A.1 Proof of the property [Prop 1]
A.2 Proof of the property [Prop 2]
A.3 Proof of the property [Prop 3]
A.4 Proof of the transitivity of the relation FunctionalCapabilityMatch()
A.5 Proof of transitivity of the relation ConceptMatch()
A.6 Complexity of the ConversationMatch() relation
Bibliography
