Dynamic Service Composition Using Semantic Information

1
Dynamic Service CompositionUsingSemantic
Information

• Keita Fujii and Tatsuya Suda
• kfujii,suda_at_ics.uci.eduSchool of Information
  and Computer ScienceUniversity of California,
  Irvine

2
Outline

• Introduction
• Our approach
• Component Service Model with Semantics (CoSMoS)
• Semantic Graph based Service Composition (SeGSeC)
• Implementation and measurement

3
Dynamic Service Composition

• Dynamic Service Composition
• Autonomously create complex services by combining
  primitive components on the fly based on user
  request and context
• More flexible and adaptable than statically
  deployed applications

Application
Application
Components (services, devices, resources)
Network with Distributed Components
4
Issue

• Existing dynamic service composition systems
• eFlow, ICARIS, SWORD, SHOP2 etc..
• Issue
• User request in strict syntax formats
• E.g. data types, workflows or logic formulas
• Difficult to generate and understand

5
Ideal Solution

• Semantics-based dynamic service composition
• User request in intuitive format
• E.g. natural language
• Service composition based on the semantics of the
  user request
• Example scenario

DirectionJPEG image
Print direction from my home to restaurant!
HomeAddress
RestaurantsAddress
User Request
6
Our Approach

• Semantics-aware component model
• Represents both function and semantics of
  component
• ? Component Service Model with Semantics (CoSMoS)
• Semantics-based dynamic service composition
  mechanism
• Composes a service based on the semantics of the
  user request and the semantics of the components
• ? Semantic Graph based Service Composition
  (SeGSeC)

7
Outline

• Introduction
• Our approach
• Component Service Model with Semantics (CoSMoS)
• Semantic Graph based Service Composition (SeGSeC)
• Implementation and measurement

8
Component Service Model with Semantics (CoSMoS)

• Idea
• Existing component models data type oriented
• CoSMoS semantic oriented
• Component Operations (methods) Properties
• Operation inputs outputs
• Inputs/outputs name data type
• Property name data type
• Name is just an ID, and does not represent any
  semantics
• Introduces an idea of concept
• An entity representing semantic meaning
• You can define a concept, just like defining a
  data type

concept
concept
concept
9
CoSMoS Data Model

• CoSMoS consists of several classes
• Classes are categorized in 4 domains based on
  their functionalities

Data Type domain
Semantics domain
Logic domain
Component domain
10
CoSMoS Defining Components

• Elements used in defining components
• Data type
• Primitive, Array, Structure, Binary
• Concept
• Noun, Predicate, Wildcard
• Relationship among concepts (ontology)
• Predicate logics
• E.g., Person.watch(movie) ? TV.play(movie)
• Used for semantic matching (inference) in SeGSeC

11

• Definition of components
• Component
• Set of data type, concept (and predicate logic)
• E.g. Component DirImage
• DataType Binary image/jpeg
• Concept Noun direction
• Operation
• A component may have operations
• Set of inputs, outputs, and concept
• Property
• A component may have other components as its
  properties
• E.g. Component Home has a property of Component
  address

12
CoSMoS Graph Representation

• A component a graph of nodes and links
• Nodes represent
• Data types, concepts, logics, components,
  operations
• Links represent
• Relationships among nodes
• A link has a label called link type
• E.g. represents, implements

Printer
13
CoSMoS Implementation

• Several description languages designed
• CoSMoS/XML, CoSMoS/Javadoc, CoSMoS/XSD,
  CoSMoS/OWL, CoSMoS/WSDL
• Implemented using Java
• Component Runtime Environment (CoRE)
• Converts different component implementations
  (e.g. Web Service, CORBA etc) onto CoSMoS
  representation
• Provides a unified interface (API) for
  discovering and accessing components

14
Outline

• Introduction
• Our approach
• Component Service Model with Semantics (CoSMoS)
• Semantic Graph based Service Composition (SeGSeC)
• Implementation and measurement

15
Semantic Graph based Service Composition (SeGSeC)

• Features
• Semantics-based service composition mechanism
• Allows a user to request a service using natural
  language
• Generate an execution path (i.e. workflow) of the
  requested service
• Based on the semantics of the user request and
  the semantics of CoSMoS
• Based on CoSMoS/CoRE

16
SeGSeC Architecture
Reasoner
4) Perform semantic matching
RequestAnalyzer
ServiceComposer
ServicePerformer
3) Generate an execution path
2) Convert the user requestinto CoSMoS semantic
graph
5) Execute the execution path
17
Service Composition Algorithm

• Step 1 Operation Discovery
• Given a predicate in the user request, find an
  operation that performs the predicate
• Assumption user request contains one predicate
  node

image/jpeg image
ltltPredicategtgt print
ltltPredicategtgt print
ltltConceptgtgt Home
from
performs
output
input
ltltOperationgtgt print
ltltConceptgtgt direction
ltltConceptgtgt Restaurant
to
Printer
User request
18
Service Composition Algorithm

• Step 2 Input Complement
• Given an operation, create an execution path by
  finding other components that can be used as the
  inputs of the operation
• I.e., find components that are compatible with
  the inputs
• The resulting execution path is executable, but
  may not satisfy the user request
• ? Semantic matching

Home
Address HomeAddress
image/jpeg DirImage
Address Origin
?
image/jpeg image
ltltPredicategtgt print
input
output
performs
input
Address Destination
ltltOperationgtgt generate
ltltOperationgtgt print
DirectionGenerator
Printer
19
Service Composition Algorithm

• Step 3 Semantic matching
• Given an execution path, check if the semantics
  of the execution path matches the user request
• Apply the semantic matching rules onto the
  execution path
• Derive semantics of the execution path through
  inference
• Compare the derived semantics with the user
  request

Derivedsemantics
Semantic matching rules
Home
Direction Generator
Printer
Restaurant
20
Outline

• Introduction
• Our approach
• Component Service Model with Semantics (CoSMoS)
• Semantic Graph based Service Composition (SeGSeC)
• Implementation and measurement

21
Implementation Demo

• Demo system of CoSMoS/SeGeC are implemented
• User can deploy components, type a user request,
  and compose and execute different services

22
Measurement

• We measured the performance of our implementation
  using different scenarios
• Current implementation can compose requested
  services in lt 1 sec

23
Conclusion and Future work

• We propose a semantics-based dynamic service
  composition architecture
• CoSMoS
• Integrates semantic and functional information of
  a component into a single semantic graph
  representation
• SeGSeC
• Generates the execution path of the requested
  service
• Future work
• More analysis
• Design of distributed SeGSeC
• Using heuristic information

24
Appendix
25
Static v.s. Dynamic Service Composition

• Static service composition
• Manually design a workflow of a service a priori
• Pros support complex interaction patterns (e.g.
  branch, loop)
• Cons No autonomy lack of adaptability
• Suitable for B2B applications
• Dynamic service composition
• Autonomously compose a service on the fly
• Pros Adaptive to different user / environment
• Cons hard to support complex interaction
  patterns
• Suitable for Ubiquitous / mobile applications

26
Example scenario

• Tom needs to print out a direction from his home
  to a restaurant he found on the web
• With current technologies

Tom
27
SeGSeC Example scenario

• Scenario Tom needs to print out a direction from
  his home to a restaurant he found on the web

Tom
28
Example of CoSMoS

• DirectionGenerator Component
• Generates a direction from a given address to
  another address

29

• OWL-S (semantic-aware component model)
• Does not allow a concept to have different data
  types
• Difficult to model a service in which input and
  output represent the same concept but have
  different data types
• E.g. Text-to-Speech converter
• If the input text represents a direction, the
  output sound also represents the direction
• If the input text represents a novel, the output
  sound also represents the novel

30

• CoSMoS can represent such service
• By separating the definition of data types and
  concepts
• By using wildcard concepts
• E.g. Text-to-Speech converter

ltltOperationgtgt Convert
input
output
ltltComponentgtgt InputText
ltltComponentgtgt OutputSound
type
type
represent
ltltPrimitivegtgt String
ltltConceptgtgt
ltltBinarygtgt sound/wav
31
Semantics of Operation

• Existing component models (including OWL-S) do
  not markup the semantics of operation
• Operation is only concerned as a set of input(s),
  output(s) (, precondition, postcondition)
• In CoSMoS, an operation may be associated with a
  predicate (subtype of concept) to represent its
  semantics
• Defines the semantics of an operation more
  precisely

32
Example of CoSMoS/XML

• DirectionGenerator component

ltcosmos targetComponent"DirectionGenerator" gt
ltstructure name"Address"gt lt/structuregt
ltnoun name"cosmos//englishdirection"gt ltlink
represents"cosmos//englishfrom"
target"cosmos//englishorigin"/gt ltlink
represents"cosmos//englishto"
target"cosmos//englishdestination"/gt lt/noungt
ltcomponent name"DirectionGenerator"gt
ltoperation name"generate" performs"cosmos//
englishgenerate"gt
ltinputgt ltAddress name"originComp"
represents"cosmos//englishorigin"/gt
ltAddress name"destinationComp"
represents"cosmos//englishdestination"/gt
lt/inputgtltoutputgt lt/outputgt
lt/operationgt lt/componentgtlt/cosmosgt
33
CoRE Features

• Component Runtime Environment (CoRE)
• Converts different component technologies onto
  CoSMoS representation
• E.g. Web Service, CORBA, UPnP ? CoSMoS
• Provides a unified interface (API)
• Discovery interface
• For discovering components from the network
• Access interface
• For accessing components (i.e., invoking
  operations and retrieving properties)

34
CoRE Architecture
SeGSeC
discover
invoke
propertyaccess
CoSMoS
Discovery Interface
Access Interface
CoRE
DiscoveryEngine
Invoker Engine
PropertyAccess Engine
DiscoveryEngine
Invoker Engine
PropertyAccess Engine
DiscoveryEngine
Invoker Engine
PropertyAccess Engine
Various Component Technologies
Various Component Technologies
Various Component Technologies
35
Step 2Input Complement

• Input complement
• Given an operation, create an execution path by
  finding other components that can be used as the
  inputs of the operation
• Components are compatible
• their data types and semantics are compatible
• Repeat until all the inputs in the execution path
  are complemented

ltltWildcardgtgt w1
ltltNoungtgt Direction
ltltComponentgtgt generate
input
input
output
ltltOperationgtgt printOp
ltltComponentgtgt Image
ltltComponentgtgt DirectionOut
ltltOperationgtgt generate
input
ltltBinarygtgt Image/jpg
ltltBinarygtgt Image/jpg
ltltComponentgtgt generate
Printer
DirectionGenerator
36
ServiceComposer step 2Input Complement

• Input complement
• Given an operation, find other components that
  are compatible with the inputs of the operation
  and create an execution path
• Components are compatible
• their data types and semantics are compatible

Home Component
ltltComponentgtgt OriginComp
ltltNoungtgt Origin
ltltWildcardgtgt HomeAddress
ltltComponentgtgt AddressOfHome
input
ltltStructgtgt Address
ltltOperationgtgt generate
ltltStructgtgt Address
ltltComponentgtgt AddressOfRestaurant
input
ltltComponentgtgt DestinationComp
ltltNoungtgt Destination
ltltWildcardgtgt RestaurantAddress
Restaurant Component
DirectionGenerator component
37

• Detail mechanism
• Discovers an operation (or a set of operations)
  that generates the input(s) of the specified
  operation
• Adds it into the execution path.
• Checks whether the discovered operation is
  executable
• If not, performs another input complement
• Continues the above procedure until all the
  operations become executable

hasPropertyOf
type
ltltComponentgtgt Home
ltltComponentgtgt AddressOfHome
ltltStructgtgt Address
DirectionGeneratorComponent
Home Component
type
ltltOperationgtgt generate
ltltComponentgtgt Destniation
in
38
Semantic Matching Rules
39
Semantic Matching Example

• Rule 1 If printOp performs print, and
  printOp outputs Paper representing w1, then
  print outputs w1.
• Rule 2 If DirectionOut is used as the value of
  Image, then w1 is equivalent to direction.
• Rule 4 If w1 is equivalent to direction,
  apply all the links towards w1 onto
  direction.

ltltWildcardgtgt w1
ltltNoungtgt Direction
ltltComponentgtgt Paper
equivalentTo
output
output
ltltOperationgtgt printOp
ltltComponentgtgt Image
ltltComponentgtgt DirectionOut
ltltOperationgtgt generate
input
output
performs
ltltBinarygtgt Image/jpg
output
ltltBinarygtgt Image/jpg
ltltPredicategtgt print
Printer
DirectionGenerator
40
Semantic Matching Example

• One link in the user request is derived

ltltConceptgtgt Home
from
output
ltltPredicategtgt print
ltltConceptgtgt direction
to
ltltConceptgtgt Restaurant
User request
ltltWildcardgtgt w1
ltltNoungtgt Direction
ltltComponentgtgt Paper
output
output
ltltOperationgtgt printOp
ltltComponentgtgt Image
ltltComponentgtgt DirectionOut
ltltOperationgtgt generate
input
performs
ltltBinarygtgt Image/jpg
output
ltltBinarygtgt Image/jpg
ltltPredicategtgt print
Printer
DirectionGenerator
41
RequestAnalyzer

• User request is given as a string value
• E.g., print a direction from Home to Restaurant
• Given a string request, RequestAnalyzer converts
  it into CoSMoS semantic graph
• Using simple syntactic parsing
• Request Predicate Noun (Preposition Noun)
• By discovering components through CoRE discovery
  interface

42
ServicePerformer

• After creating an execution path, ServiceComposer
  passes the execution path to ServicePerformer
• ServicePerformer asks the user if s/he wants to
  execute the path or not
• If yes, executes the path using CoRE
• Otherwise, asks ServiceComposer to create another
  path