interoperable service-oriented architecture for ambient

Interoperable Service-Oriented Architecture for Ambient Intelligence in the Networked Home

Nikolaos Georgantas

Joint work with Sonia Ben Mokhtar, Ferda Tartanoglu, Valérie IssarnyARLES group, INRIA-Rocquencourt

SMART University, 22/09/06, Sophia Antipolis

2

Outline

Ambient intelligence in the networked homeService- and semantics-orientation for interoperabilityA service-oriented architecture for the networked home

OverviewEfficient semantic service discoveryDynamic service composition

Conclusion

3

The open networked home environment

Personal computingMobile computingConsumer electronicsHome automation

DynamicsResource constraintsQoS and contextOpenness,heterogeneity

IST Amigo: Ambient intelligence (AmI) in the home (http://www.hitech-projects.com/euprojects/amigo/)

4

Service-oriented architecture (SOA)-based AmI environments

Networked nodes host services providing various functionalitiesMobile users need to perform tasks anytime anywhere, using functionalities of the AmI environmentAvailability of services is highly dynamicNo a priori knowledge of available servicesHeterogeneity of service infrastructures

ChallengesEnable users to perform tasks by composing “on the fly” available networked services Incorporate awareness of non-functional features concerning the users and the environment, i.e., QoS, context

5

Background solutions and open issues

Web ServicesWidely employed SOA infrastructureWeb Services employed in pervasive computing environmentsRelated process/workflow languages for orchestration-based composition of services

Semantic Web ServicesSemantic description of services

• Employs available ontologies• Enables common understanding without prior knowledge of available

services or agreement on a single syntactic standard• OWL, OWL-S

Related semantic reasoning and service matching tools

Still openEfficient, truly ad hoc service discovery and composition into user tasksQoS-awareness and context-awarenessHeterogeneity of service infrastructures

6

Outline



Conclusion

7

Architectural design approach

Key objectiveInteroperability

Base architectural paradigmService-oriented architectures

ApproachNot yet another homogeneous service architecture

To enable interoperabilitySemantics in system architectural design

8

Abstractservice-oriented architecture

heterogeneous middleware layer

heterogeneous platform layer

service communication

heterogeneous application layer

syntactic service descriptionfunctional specificationcontext specificationQoS specification

system & networkcapabilitiesresources

context

awareness

service discovery

QoS

awareness

middleware layer

platform layer


application layer

syntactic service descriptionfunctional specification

system & network

service discovery

9

Abstract interoperableservice-oriented architecture

Language for enriched semantic service description

heterogeneous middleware layer

heterogeneous platform layer


heterogeneous application layer

syntactic service descriptionfunctional specificationcontext specificationQoS specification

system & networkcapabilitiesresources

context

awareness

service discovery

QoS

awareness

middleware-levelinteroperability mechanisms

conformance relationsinteroperability methods

enriched semanticservice description

application-levelinteroperability mechanisms

conformance relationsinteroperability methods

describes based on

10

Amigo-S: Service description language

Based on OWL-SIncorporates OWL-S specificationExtends it by adding new classes and properties

New featuresModels both application-level and middleware-level service featuresAdequate specification abstractions enabling interoperabilityEnables any service infrastructure by supporting different groundings

• Grounding includes both service interaction and service discovery middleware protocols

Introduces QoS- and context-awareness into the service description both at application level and at middleware level

A service specification exampleA context-aware and QoS-aware Digital Media Server

11

Service capabilities and conversations

12

Underlying middleware

13

Context and QoS

14

Outline



Conclusion

15

Overview

Service semantic description, discovery, composition, adaptation & execution (SD-SDCAE) are very much interrelatedThese steps carried out in this order enable distributed, dynamic, ad hoc, complex user applications

The case of executing (invoking) a single service (no composition) is included

Introduce a comprehensive approach

16

Application/service description & coding

Remote deviceRemote device

User device

User application

Client-like functionalities

Declarative task:Required remote service functionalities- Capabilities- Orchestration- Context/QoS properties

Remote device

Service

Service functionalities

Provided service functionalities- Capabilities- Conversation - Context/QoS properties

Local service functionalities

A user application comprises a number of parts:• Client-like functionalities may do initialization and “glue” all the other parts• Task will compose, orchestrate and adapt to remote service functionalities• Local service functionalities may conveniently be used by task

Description in Amigo-S,employs vocabulary ontologies

Description in Amigo-S, employs vocabulary ontologies

17

Service discovery protocolRemote device

Remote device

SDCAE

Serviceregistration

User device

SDCAE

Selected device

SDCAE

Servicerepository

discover

Interaction over SOAP

repository discovery

Interaction over legacy discovery protocol (e.g., SLP, UPnP, WS-D)

User applicationRemote services

Service discovery

SDCAE user interface

register


repository discovery

18

Service discovery, composition & adaptation – functional architecture

SDCAE on remote deviceSDCAE- service repository

Registered services

Capability matching

Registration→ Ontology classification, ontology & service encoding, service grouping

Discovery

QoS-aware capability selection

SDCAE on user device

Service discovery, composition &

adaptation

Conversation matching and integration

(possibly QoS/context-aware)

Service registration

Functional relation: employs

Service description

Abstract task description

Functional relation: produces

Context-aware capability selection

Task adaptation

Concrete task 1

2

3

4

2

56

7

8

9

1 Steps of execution of functions9…

19

Service execution – functional architecture

Remote deviceRemote device

User device

User application

Client-like functionalities

Remote device

Service

Service functionalities

SDCAE

Orchestration execution engine


Concrete task

Local service functionalities


In BPEL

20

Amigo-S based process model for services and user tasks

ServiceWorkflow of provided capabilities –conversation

TaskAbstract workflow of required capabilities – orchestration

MatchingCapabilities (service discovery and selection)Workflows (service composition)

Browse

Browse

Browse

User Task

Networked Services

RequiredCapability

Provided Capabilities

21

Service discovery & composition – COCOA

Abstract user task orchestration

Service CompositionCOCOA-CI

?: Service DiscoveryCOCOA-SD

?

?

?

?

?

?

??

Service conversations

22

Outline



Conclusion

23



Registered services

Capability matching


Discovery




adaptation





Service description




Task adaptation

Concrete task 1

2

3

4

2

56

7

8

9


24

Semantic service matchingService Advertisement (Adv)

Inputs (Adv.In)Outputs (Adv.Out) Properties (Adv.P)

Service Request (Req)Inputs (Req.In), Outputs (Req.Out)Properties (Req.P)

Client Service

Ontologies

Input: Video TitleOutput: Video ResourceCategory: Video Server

Input: Resource TitleOutput: Digital ResourceCategory: Digital Server

25

Evaluating the degree of matching

Semantic distance between concepts d(c1,c2)Number of levels that separate c1 from c2 in the ontology if c1 subsumes c2Null otherwise

Match(Adv,Req)∀ out ∈ Req.Out, ∃ out’ ∈ Adv.Out : d(out’,out) ≥ 0 &∀ in’ ∈ Adv.In, ∃ in ∈ Req.In : d(in,in’) ≥ 0 &∀ p ∈ Req.P, ∃ p’ ∈ Adv.P : d(p’,p) ≥ 0

Semantic Distance (Adv,Req)∑ d(Adv.Outi,Req.Outi) + ∑ d(Req.Ini,Adv.Ini) + ∑ d(Adv.pi,Req.pi)

26

Semantic service matching –Example

Req Adv

Ontologies

Match (Adv, Req) holds because :• Outputs: d(Adv.DigitalResource,Req.VideoResource) =2 • Inputs: d(Req.VideoTitle,Adv.ResourceTitle) =0• Properties: d(Adv.DigitalServer,Req.VideoServer) =1

Semantic Distance (Adv,Req)=3



27

Semantic service matching –Performance evaluation

3 steps:Parsing one service request and one advertisement (10 inputs/outputs)Creating a memory model for the involved ontologies and classifying them (99 OWL classes, 39 properties)Matching the concepts in the ontologies

Experiment using 3 reasoners [Pellet, Fact++, Racer]

Average time around 4-5 sec for matching one request with oneadvertisementMost expensive step is the time to load and classify ontologies

Optimizations:Ontology classification done offlineOptimize matching between concepts

Time to parse a service advertisement and a service request (ms)Time to create a memory model and classify (ms) ontologiesTime to match concepts (ms)

28

Optimized semantic service matching

Encode service descriptionsClassify ontologies offline and encode them

Group “similar” service advertisements in the service repository

Optimize semantic service discovery

29



Registered services

Capability matching


Discovery




adaptation





Service description




Task adaptation

Concrete task 1

2

3

4

2

56

7

8

9


30

Encode service descriptions – 1

Each concept in a classified ontology is given a code (interval) [Constantinescu,WI’03]

The interval representing a concept is divided into subintervals to encode its child concepts

Semantic reasoning translates into numeric comparison of codesSubsumption between C1 and C2 holds if the interval of C1 includes the interval of C2

Versioning system to manage consistency of codes along with the evolution of ontologies

OntologyClassification

OntologyEncoding

31

Encode service descriptions – 2

Match (GetVideoStream, SendDigitalStream)http://www.inria.fr/Resource.owlVersion 1.0[0.1,0.15] ⊂ [0.1,0.2]


<Ontology: Resource.owlCode:[0.1,0.15]Version:1.0 >


<Ontology: Resource.owlCode:[0.1,0.2]Version:1.0 >

32

Group service advertisements in a repositoryTo improve the response time of service discovery

1. Group “similar” service advertisementsGrouping is based on matching• If Match(C1,C2) holds, we draw an edge from service C1 to

service C22. Index groups of services according to the ontologies that

they involve

Name: SendVideoStreamInput: Video TitleOutput: Video ResourceCategory: Video Server

Name: SendDigitalStreamInput: Resource TitleOutput: Digital ResourceCategory: Digital Server

33

Adding a new service advertisement

Let group G using (at least) the same ontologies as a new service CFind predecessors of C in G

If Match(RootNode,C) holds, C will have a predecessor in GFind the place to insert C by matching with successors of RootNode

Find successors of C in GIf Match(C,LeafNode) holds, C will have a successor in GFind the place to insert C by matching with predecessors of LeafNode

C1 C3 C5C7

C8

G4O4G1O3G2O2G1,G3O1

CUses ontologies{O1,O3}

G1

G2

G3

G4

• Match(C1,C) holds• Match(C3,C) holds• Match(C5,C) fails

• Match(C,C7) holds• Match(C,C5) holds• Match(C,C3) fails

Finding predecessors of C Finding successors of C

34



Registered services

Capability matching


Discovery




adaptation





Service description




Task adaptation

Concrete task 1

2

3

4

2

56

7

8

9


35

Matching a service request

Matching a service requestTake groups that use (at least) the same ontologies as the service requestMatch with root nodes of these groupsIf the matching holds, evaluate using the SemanticDistancethe advertisement that best fits the request

C1

C3

C4

C5

C6

C7

C8

C2

C9C10

C11

C

{O1,O3}

{O1,O3}

{O1,O3}Match(C9,C) holds and SD(C9,C)=3

Match(C10,C) holds and SD(C9,C)=1

36

Performance evaluationRuntime environment

Laptop 1.6 GHz Intel Centrino processor and 512 MB of RAMFrom 10 to 100 semantic services using 22 ontologies

Time to group service advertisements in an empty repository

Compared with the time to parse the service descriptionsTime to add a new service advertisement

Compared to the time to parse service descriptionsBenefit of grouping services

Time to match a service request in a repository with and without grouping

Comparison of matching a semantic service request in the organized repository with a syntactic service request in a classic repository

37

Time to group service advertisements in an empty repository

Time to create the groups is negligible compared to the XML parsing time of service descriptions

0

50

100

150

200

250

300

350

400

0 20 40 60 80 100

Tim

e (m

s)

No. of Services

Time to parse servicesTime to create graphs

Total time

Time to group service advertisements

Time to parse service descriptionsOverhead of grouping

38

Time to add a new service advertisement

Time to add a new service advertisementNegligible compared to the XML parsing time of service descriptionsAlmost constant despite the increasing number of services in therepository

0

20

40

60

80

100

120

140

160

0 20 40 60 80 100

Tim

e (m

s)

No. of Services

Time to insert a service in the graphs Time to parse the service request

Total Time

Time to add a new service advertisement

Time to parse service descriptions

Overhead of adding a new service

39

Time to match a service request

Time to match a service request without service grouping is 50% higher compared to matching the same request in an organized repository

In both cases, advertisements and requests are encoded

0

1

2

3

4

5

0 20 40 60 80 100

Tim

e (m

s)

No. of Services

Time for optimized matchingTime for non optimized matching

Time to match a service request in an organized repository

Time to match a service request without grouping

40

Comparison with a classic repository

Optimized semantic matching is more efficient and more scalable than classic syntactic matching

0

50

100

150

200

250

300

350

400

0 20 40 60 80 100

Tim

e (m

s)

No. of Services

AriadneS-Ariadne

Optimized semantic matching in an organized registry

Classic syntactic matching (WSDL-based)

41

Outline



Conclusion

42

Service discovery & composition – COCOA

Abstract user task orchestration

Service CompositionCOCOA-CI

?: Service DiscoveryCOCOA-SD

?

?

?

?

?

?

??

Service conversations

43



Registered services

Capability matching


Discovery




adaptation





Service description




Task adaptation

Concrete task 1

2

3

4

2

56

7

8

9


44

Modelling conversations as finite state automata

A model to map Amigo-S (OWL-S) conversations to finite state automataA mapping rule for each OWL-S control construct (e.g., Choice, Sequence, While, Split)Translate the problem of dynamic conversation integration to an automata analysis problem

45

COCOA-CI

11

2

2

3

3

4

4

5

5User task’s orchestration

46

Binding to concrete servicesEach composed capability corresponds to either an atomic or a composite process of a networked service

47

Properties of COCOA-CI

Flexible workflow integration

Service interleaving

The number of services to be composed is dynamicThe degree of involvement of each composed service is dynamic

1

COCOA- CI

2 3 4

1 3 2 41 2 3 4COCOA- CI

COCOA- CICOCOA- CI

Networked services

Networked services

Networked services-Env 2Networked services-Env 1

Service 1

Service 1 Service 2

Service 2

48

Performance evaluation – 1

Runtime environment Java, Linux platform running on an Intel Pentium 4, 2.80 GHz CPU with 512 MB of memory

Evaluation of the runtime overhead produced by integrating conversationsComparison with the XML parsing time of service and task descriptions

49


Task composed of a single required capabilityNumber of capabilities provided by networked services increasingfrom 10 to 100 capabilities that are semantically equivalentThe runtime overhead of COCOA-CI is negligible compared with the XML parsing time of service and task descriptions

50


100 semantically equivalentcapabilities provided by networked servicesTask has from 1 to 20 semantically equivalentrequired capabilities in sequenceThe runtime overhead of COCOA-CI depends on the number of intermediate paths assessed during the composition

Here: for a task composed of n capabilities, there are 100n possible composition schemes

51


Realistic case20 required capabilities 30 provided capabilitiesVarious control constructs32 ms for finding the 2 possible compositions among 36 intermediate compositions 152 ms for XML parsing of service and task descriptions

In realistic cases, the runtime overhead of COCOA-CI is small compared to XML parsing time

52

Outline



Conclusion

53

Conclusion

AmI environment based on service orientationIntroduced semantics in system architectural design for enablinginteroperability

Amigo-S: semantic service description languageComprehensive approach to service semantic description, discovery, composition, adaptation & execution (SD-SDCAE)COCOA-SD: efficient semantic matching of service capabilities

Perform reasoning on ontologies offlineEncode classified ontologiesGroup service advertisements for efficient service discovery in a repository

COCOA-CI: dynamic conversation-based service compositionFlexible approach for dynamically composing services to perform a user task

54

Ongoing & future work

Include non-functional properties (QoS, context) in COCOA

Semantic distance of the matching relationConversation composition

Integration of COCOA into a semi-distributed discovery protocol for mobile ad hoc networks [Sailhan, Percom’05]Adaptation to composed services and execution of user tasksIntegrated prototype implementation of SD-SDCAEunderway as a part of the Amigo projectSupport for dynamic reconfiguration of the composed user task

55

For more information

http://www-rocq.inria.fr/arles/

interoperable service-oriented architecture for ambient

Documents