WSMO ~ current status and some open points ~

1
WSMO current status and some open points

• DERI Internal Research Seminar
• 17-03-2005
• Dumitru Roman
• DERI Innsbruck
• dumitru.roman_at_deri.org

2
Outline

• Introduction
• Starting point for a service specification
  language WSMO Ontologies, (Web) Services,
  Goals, and Mediators
• More on WSMO Choreography
• Current WSMO Choreography definition
• Some problems to be addressed
• Some existing work in the area (related to
  logical foundations)
• Conclusions and Further work

3
Introduction

• Why a service specification language?
• To allow automatic tasks (e.g. discovery,
  selection, composition, mediation, execution,
  monitoring, etc.) to be performed with respect to
  services in the context of web and grid.
• What is needed?
• A conceptual model that captures core elements of
  the problem that has to be solved.
• A formal language that reflects the conceptual
  model and allows for different proofs.

4
Starting points the overall context
WSMO/WSML/WSMX

WSMO WG
A Conceptual Model for SWS
WSMX WG
WSML WG
A Formal Language for WSMO
An Execution Environment for WSMO
A Rule-based Language for SWS
5
WSMO

• An ontology derived from and based on the Web
  Service Modeling Framework (WSMF).
• A meta-model for semantic web services and
  related aspects.
• Language for defining WSMO MOF M3.

MOF
meta-metamodel
M3 layer
metamodel
M2 layer
WSMO
model
M1 layer
WSMO Specifications
information
M0 layer
6
WSMO design principles

• Web Compliance
• Ontology-Based
• Strict Decoupling
• Centrality of Mediation
• Ontological Role Separation
• Description versus Implementation
• Execution Semantics

7
WSMO Top Level Elements

• Ontologies - provide the terminology used by
  other WSMO elements.
• (Web) Services - description of services that are
  requested, provided, and agreed by service
  requesters and service providers.
• Goals - user desires, for which fulfillment could
  be sought by executing a service.
• Mediators - deal with interoperability problems
  between different WSMO elements.

8
WSMO - Ontologies

• Define a common agreed upon terminology by
  providing concepts and relationships among the
  set of concepts.
• Provide a set of axioms to capture semantic
  properties of relations and concepts.
• Essential components which define an ontology

9
WSMO Concepts in Ontologies

• Concept definition
• Concept examples

10
WSMO Relations in Ontologies

• Relation definition
• Relation examples

11
WSMO Instances in Ontologies

• Instance definition
• Instance examples

12
WSMO Service Descriptions (1)
Capability (the functionality of the service)
Service Internal logic (not of interest in
Service Description)
How the service achieves its capability by means
of interactions with its user (communication).
How the service achieves its capability by making
use of other services (coordination).
Orchestration
Choreography
13
WSMO Service Descriptions (2)

• Non Functional Properties besides the common
  properties, contain also service specific
  properties security, reliability, performance,
  robustness, etc.
• Imported Ontologies import ontologies as long as
  no conflicts are needed to be resolved.
• Used Mediators deal with the ontology, behavior,
  protocol heterogeneity.
• Capability functional description of the
  service.
• Interfaces how the functionality of the service
  can be achieved
• Choreography - the interaction protocol for
  accessing the service
• Execution choreography
• Mata choreography
• Orchestration - how the service makes use of
  other services in order to achieve its capability.

14
WSMO Service Capability

• Capability definition
• Capability example

15
Another view on services - requested, provided,
and agreed services

• All service descriptions but with different
  owners (the service provider, requester, or both).

16
WSMO - Goals

• representations of an objective for which
  fulfillment is sought through the execution of a
  Web Service they can be descriptions of services
  that would potentially satisfy the user desires

17
WSMO - Mediators

• ooMediators - mediators that import ontologies
  and resolve possible representation mismatches
  between ontologies.
• ggMediators - mediators that link two goals.
• wgMediators - mediators that link a goals to
  services.
• wwMediators - mediators that link two services.

18
WSMO Non functional properties

• Which non functional properties apply to which
  WSMO element is specified in the description of
  each WSMO element.
• We do not enforce restrictions on the range value
  type, but in some cases we do provide additional
  recommendations.

19
WSMO Choreography based on ASMs (1)

• Abstract State Machines
• A practical method for rigorous system
  development which has been used successfully
  under industrial constraints for design and
  analysis of complex hardware/software systems.
• Formalism for modelling/formalising algorithms
• An attempt to bridge the gap between formal
  models of computation and practical specification
  methods.

ASM Model
Modeling What System are you building?
Refinement
Informal specification of the hardware/software
system
Implementation of the system (C, Java, etc)
Validation Are you building the right system?
Verification Are you building the system right?
20
WSMO Choreography based on ASMs (2)

• Abstract State Machines
• States can be viewed as (first-order) structures
  of mathematical logic
• Abstract Instructions for Changing States
• if Cond then Updates,
• where Updates consists of finitely many
  function updates f(t1,,tn) t which are
  executed simultaneously functions ca be static
  or dynamic (in, controlled, shared, out)
• forall x with Cond do R
• choose x with Cond do R
• ASMs runs

21
WSMO Choreography (2)

• Reasons for using ASMs in WSMO Choreography
• Minimality
• Maximality
• Formality
• Choreography definition
• For concepts, relations,
• the nfps are extended with
• the mode nfp.

Concept in choreography example
The mode can be Static, Controlled, In, Shared,
or Out
22
WSMO Choreography example (1)
23
WSMO Choreography example (2)

• The guarded
• transitions

24
Choreography and Orchestration

• WSMO Choreography models all visible interactions
  of the service (Orchestration shows how all the
  interaction are related).
• WSMO Choreography a special type of workflow,
  where the tasks in workflow represent
  sending/receiving (or reading/writing) of
  messages.

25
Workflow representation frameworksH. Davulcu, M.
Kifer, C. R. Ramakrishnan, I. V. Ramakrishnan
Logic Based Modeling and Analysis of Workflows.
PODS 1998 25-33

• Workflow modeling defining the control flow, the
  information flow and the global execution
  constraints among the network of tasks and
  provides constructs for exception management.
• The most common frameworks for specifying
  workflows control flow graph, triggers (also
  known as event-condition-action rules), and
  temporal constraints
• Temporal constraints (Kleins Constraints)
• AltB (If events A and B both occur, then A occurs
  earlier than B)
• A ? B (If event A ever occurs then B must occur
  as well, before or after A)

26
Some immediate challenges to be addressed

• Deadlock, termination, dead paths verification
• Verification of constraints consistency (i.e. are
  the constraints consistent with each other)
• Property verification (i.e. is a certain property
  assured by the workflow specification)
• ? constraint satisfaction (given a workflow and
  a constraint is there any execution that can
  satisfy the constraint)
• ? constraint verification (given a workflow and
  a constraint will every execution of the
  workflow satisfy the constraint)

27
Specifying workflows with Temporal Logic (1)

• Workflows are a set of inter-task dependencies
  (local and global) the control flow is not
  represented explicitly
• The tasks are described in terms of significant
  events (e.g. beginning or termination of a task).
• Dependencies are specified in Computational Tree
  Logic (CTL)
• CTL formulas are converted into automata
• Scheduler ensures that a sequence of events are
  accepted by all automaton
• Does not explicitly deal with verification issues

28
Specifying workflows with Temporal Logic (2)

• A dependency, D, specified in CTL, is compiled
  into a finite state automaton, AD which is a
  tuple lts0, S, ?, ?gt, where
• s0 - initial state,
• S a set of states,
• ? - a set of event expressions (i.e. a(e1,,en),
  r(e1,,en), ?1?n, ?1?n), where ?i ?
• ? S x ? x S the transition relation
• Examples

29
Specifying workflows withEvent Algebra

• Workflows are a set of inter-task dependencies
• Dependencies are specified in an expressive
  algebra (event expressions in the algebra)
• It uses denotational style semantics where an
  event expression represents a set of traces (a
  sequence of atomic events)
• Residuation operation of D/e If the state of the
  scheduler is D and event e arrives, the new state
  is D/e, which reflects what remains to be
  satisfied by the incoming events
• It doesnt support conditions on transitions
  between tasks.
• It is unclear whether it can model sub-workflows
  or be used to verify workflow properties such as
  whether a given set of constraints has redundancy
  in it or whether a constraint is implied by a set
  of constraints.

30
Specifying workflows withConcurrent Transaction
Logic (1)

• control flow graphs with transition conditions
  can be easily and naturally represented,
  triggers are easy to represent as well.
• CTR
• Atomic formulas p(t1,,tn)
• Complex formulas using classical /\, \/, , ,
  , and (serial conjunction), (concurrent
  conjunction), o (executional possibility) and ?
  (isolated execution)
• Database states and a collection of paths (a path
  is a finite sequence of states)
• Formulas assume truth values over paths (e.g. if
  ? is a true formula over the path lts1,..,sngt,
  then ? can execute starting at state s1)

31
Specifying workflows withConcurrent Transaction
Logic (2)

• CTR intuitive semantics
• a b execute a and then execute b
• a b execute a and b concurrently
• a /\ b a and b must both execute along the same
  path
• a \/ b execute a or b non-deterministically
• a - execute in any way, provided that this will
  not be a valid execution a
• o a - execute a in isolation, i.e. without
  interleaving with other concurrently running
  activities
• ? a - check if a is executable at the current
  state.

32
Specifying workflows withConcurrent Transaction
Logic (3)

• Example
• CTR representation

33
Specifying workflows withConcurrent Transaction
Logic (4)

• Global constraints in CTL
• Expressed in terms of events
• Use a constraint algebra (Constr)
• Reasoning tasks given G, a control graph (as a
  CTL formula), and a set of constraints C (as an
  expression in Constr algebra) then
• Determine that G is consistent with C
  (consistency)
• Determine whether every legal execution of the
  workflow satisfies some property defined in the
  set of constraints (verification)
• Find an execution path (or all paths) in G where
  C holds (scheduling)
• Liner time for the verification of these
  properties, but without treating loops.

34
Some other formalisms used for specifying
workflows

• Event Condition Action Rules
• Petri Nets
• Extended Transaction Models
• etc.
• Main problem no unifying logical framework for
  representing and reasoning about workflows
  (although CTR is the closest to this aim)

35
Conclusions

• WSMO conceptual model is far from being a
  complete conceptual model for semantic web
  services, but it is a starting point
• WSMO Choreography
• Needs to be complemented with a control flow
  language in order to be useful
• The current transition rules in WSMO Choreography
  can only represent local constraints.
• Needs to be formalized in order to allow
  reasoning/verification about it
• Existing solutions to workflow problems need to
  be analyzed and considered.

36
Future intentions

• Complement the WSMO Guarded Transitions with a
  graphical language to specify the control flow by
  adopting an existing graphical language (e.g.
  YAWL, BPMN)
• Take a sub-set of control patterns from this
  language that are relevant to interactions with
  one WSMO web service (sequences, conditions,
  loops, and maybe the parallel construct), and
  based on them
• Build a unifying logical framework to deal with
  deadlock, termination, dead paths verification,
  and constraint satisfaction and verification, and
  on a long term with exception handling.
• Integrate it in a more general framework (e.g.
  integrate it with service discovery, contracting,
  etc)
• More complex verification problems can be
  envisioned (e.g. capability/choreography
  consistency).
• Maybe see how all these problems relate to
  Ubiquitous Computing

37

• Questions and Answers