Automatic Composition of Web Service Workflows Using a Semantic Agent

economickiteInternet και Εφαρμογές Web

21 Οκτ 2013 (πριν από 3 χρόνια και 7 μήνες)

61 εμφανίσεις

Automatic Composition of Web Service Workflows
U
sing
a
Semantic Agent


Jarmo Korhonen, Lasse Pajunen, Juha Puustjärvi

Software business and Engineering Institute, Helsinki University of Technology

{jarmo.korhonen, lasse.pajunen, juha.puustjarvi}@hut.fi



Abstract

This paper presents a way to automatically
compose

web service

workflow that uses
component
web
services
.
The web services
workflows

are
described using our
transactional
workflow ontology.
The workflow ontology
can be used to describe both
compon
ent

web service
workflows and
master

web service

workflows.

We have
also implemented a workflow engine that
runs the

workflow

instances. Here we
analyz
e

using
our
ontology
and
some workflow
instances
with

a

reasoning agent to
automatically find a composed
workflow that fulfills all
given
constraints.
The result from the inference
is

a
workflow instance

t
hat
can

be executed using our
workflow engine.

We see that this kind of dynamic
composition is needed in dynamic heterogeneous
environments
with loosely cou
pled

web services.

1. Introduction

Web services architecture
uses XML
-
based messaging

to enhance interoperability of distributed software
systems.
Some proposals
, e.g. BPEL4WS

[12]
,

have been
presented for describing workflows of
composed

web
services

in
relatively stable environments.
We propose
that systems can be
made
more tolerant to changes by
reasoning

a

composed

workflow

automatically
.
We
present
a way to do this

using our transactional workflow
ontology

(TWFO)

and DAML
-
S

[11]
.

Web services workflow

is an ordered set of
messages

to individual web services operations

whose results
depend on each others
.
Composed web service workflows
combine operations from several web services

to one
combined workflow
, which may not show all internal
operations
. Comp
osed web service workflow includes
dependencies both between operations inside one w
eb
service and between

component
web services.

Transactional workflows are used to guarantee that all
services in the workflow either succeed or fail.

L
ong
-
term
transaction
s must be handled without locks.
Currently,
web service workflows are developed largely by hand.
[4]

Semantic Web is a vision of the next generation World
Wide Web, where all Web content is both machine and
human interpretable. Currently, the Web is largel
y a
presentation medium intended for human users. [1]
DAML+OIL is a
RDF
-
based language for ontology
specification.
We have used it for our ontology.
In this
paper, we are interested in
automated
reasoning
.

Automatic
composition

of web service workflows
re
quires a reasoning engine (pl
anner)
, a set of rules
,

and
semantic information about the services and workflows.
DAML
-
S ontology and our transactional workflow
ontology

(TWFO)
,
enable semantic level reasoning using
reasoning engine that supports DAML+OIL
, l
ike
DAMLJessKB
[2]
.

With dynamic automated

compos
ing

of web services,
there are less fixed dependencies between component
services.
We describe here a software agent that does
workflow planning based on the semantic information.
The
agent
offer
s

a single
interface to several services.
C
hanges in component services
cause
a

re
-
planning
.

2. Related work

Most research
concerning

web service workflows has
been about manual composition of services to provide
higher
-
level services.
BPEL4WS

[12]

is one recent
prop
osal for that
purpose.

Automatic composition of web services using situation
calculus and Petri nets has been presented in

[3]
.
They
have transformed a significant portion of DAML
-
S
semantics to first
-
order logic

and also
to
Petri nets. Petri
nets have be
en used to
simulate
and verify
the workflows.
Their work proves that translation of workflows to Petri
nets is possible, and that meaningful deduction can be
made. We extend
their research

by combining separate
workflow instances to one automatically gener
ated
workflow instance.

Self
-
Serv [4] is a peer
-
to
-
peer (P2P) approach to web
service workflow composition.
The overall workflow is
managed without a central planner or coordinator.
Instead,
Self
-
Serv has coordinating messages between state
coordinators.

SWORD [5] is a rule
-
based developer
toolkit for web service composition. It generates a plan
based on input/output conditions specified for all
component services
.
SWORD uses its own web service
platform.

SCET [9] is a tool for automatic

off
-
line

composit
ion and execution of web service workflows. It
generates Perl execution code for WSFL
(
Web Services
Flow Language
from IBM)
workflow specifications.

3.
Ontologies

By o
ntology
we mean
a specification of concepts and
their relations in a machine
-
understandab
le way.
We
con
centrate

on DAML+
OIL ontologies
.

3.1
DAML
-
S

DAML
-
S
[11]
i
s
a
DAML+OIL

ontology for web
services
.
It

describes a set of classes and properties,
specific to the description of web services. The upper
ontology of DAML
-
S comprises the
service pro
file

for
describing service advertisements, the
process model

for
describing the actual program that realizes the service, and
the
service grounding

for describing the transport
-
level
messaging information associated with execution of the
program. The serv
ice grounding is
similar

to the WSDL

language
.

We use
the service profile of DAML
-
S as part of the
reasoning
, but not the process model
.
We use our own
workflow ontology
to support

transactions
.

3.2
Transactional workflow ontology

We have defined
our
tran
sactional

workflow ontology
(TWFO)
for
standard

web services architecture.
It
improves the DAML
-
S process mode
l with transactional
concepts [5
].

Figure
1

presents the ontology basic
structure. Table
s

1

and 2 have

detailed list
s

of
task and
link
concepts

in the ontology
.



Figure
1

Transactional Workflow Ontology concepts

Task

is an atomic part of the workflow.
I
t may have
properties and parameters but no internal structure. On the
implementation level, it may have internal workflow or
transactions.
Task always either succeeds or fails.

Table 1
cont
ains a brief description of all task types
.

Control
l
ink
s

specify the execution order for the
t
asks

inside workflow engine
.
Table 2
con
tains a brief
description of
control link types
.

Data
l
ink
s

are used to describe how information flows
during workflow. A data link specifies that its source task
passes some named data to the workflow engine. The
target tasks are able to query and use tha
t named data as
for example attributes to web service
message
s
.

First four of the task types in Table

1

are based on
WSDL port types
.
These four are the messaging tasks that
contain the real work. All other tasks are in supporting
role.

Table 1. Task typ
es

Task type

Description

Send message

Send a message, no response

Receive message

Wait for a message
, no response

Request
-
response

Send a message and wait for response

Solicit
-
response

Wait for a message, send a response

Start transaction

T
ransaction
control

starts

End transaction

T
ransaction control

ends

Commit

All

Call commit operations for
all
services

Abort All

Call abort operations for
all
services

Notify error

Send an error message

Table 2.
Control
l
ink types

Link

type

Description

Go

P
rocee
d to next task, conditionally.

Start

Unique link to first task

End

No following task

Commit

After End Transaction task, conditionally if
all non
-
optional tasks succeeded

Abort

After End Transaction task, conditionally if
any

non
-
optional tasks
failed

Fork

Execute all next tasks in parallel

Join

Wait until all previous tasks are finished

Loop

Execute loop task until condition not satisfied

Control links connect tasks to each other. The number
of preceding and following tasks depends on the control
li
nk type.
Data links are separate entities that support the
data flow between tasks. The tasks must also be connected
with control links.

4. Workflow engine

We have implemented a workflow engine that reads
and executes an
ontology
-
based web servic
e workflow

instance
.
Figure
2

presents the overall system architecture.


Figure
2

W
orkflow engine system architecture

The core modules are Workflow Management,
Workflow Ontology, Workflow Engine and W
eb Service

Age
nt

(WS Agent)
.
Workflow Management module is
responsible for loading, creating, saving and retrieving
workflow instances.
Workflow Ontology module
implements reading, writing, updating and validating a
workflow instance.
Workflow Engine module holds the
wo
rkflow execution logic.

WS Agent module contains
an

agent that uses a workflow instance to
send messages to

web services as instructed by the workflow engine. WS
Agent module uses registry server to find the web
services.

The implementation uses Java Web
Service Developer
Pack
[13]
for web services. Jena toolkit
[6]
from HP

Labs

is used for DAML+OI
L ontology reading and writing.

In our experience, the workflow instance specifications
using DAML+OIL ontology offers the following benefits:



Tasks and other co
ncepts

can be ordered freely
.



Many c
onstraints can be made explicit in the
ontology,
instead of being in parser code
.



Integration of workflow ontology concepts and
semantic data is made easier

than using
XML



Class
-
based specification is easy to map to
impl
ementation classes.

Our main motivation for developing a
n

ontology
-
based
workflow engine was to enable sharing and combining
work
flows
using automated

reasoning.

5. Planning agent

Agent
here
is an autonomous software entity that acts
on behalf of the user
.
Planning agent’s role is to plan a
workflow that accomplishes the task user needs.
The
workflow is created at run
-
time, based on following:



S
hared registry information about web services



Shared w
orkflow
instances

for
component

web
services

(see WMA below
)



Master
Workflow
instance




User input parameters



R
ules

Workflow
instances

are
described using

our TWFO.
Using TWFO enables us to

also

reason about the
transaction models. We use DAML
-
S service and profile
ontologies

to describe the services
.

We have propo
sed
[8]
a separate
Workflow
Management Agent

(WMA)

that stores explicitly
registered workflow instances in the same sense as UDDI
registry

stores web service interface descriptions
.
WMA
registry enables planning agent to select services based on
their work
flow and transaction models.
The planning
agent can automatically make the composition based on
the stored workflows.



Figure
3
. Planning

agent


input and output

Figure
3

p
resents the inputs and output of the planning
agent.
Planning agent implementation
will be

based on
DAMLJessKB

[2]
.
It
forms a knowledge base from
DAML+OIL ontology and instances and it
is possible to
make logic queries.

DAMLJessKB

reads the TWFO
o
ntology
and workflow instances using Jena toolkit

[6]
.
The rules for composition are added to the DAMLJessKB
knowledge

base directly.

The implementation is not yet
able to produce an executable workflow instance

for our
workflow engine
.

One specific challenge is t
o select a
single workflow instance from the several possibilities.

6.

Composition

F
our workflow specification component
s
are needed
to
be able to compose the workflow [10]
.



Tasks



Transactional requirements



Data flow



Execution structure

The tasks specify
what component services are used.

Modular design of tasks helps reuse them in composed
master workflow.

Transactional requirements are
described for all web services in our ontology. Data flow
and execution structure are objectives of the composition.

Exe
cution structure

(composite workflow)

is composed
from the master workflow and the component work
flow
s,
as presented in
Figure
4
.
First, DAML
-
S
S
ervice
R
egistry
is used to find the correct services.
Second
, their
workflows are
read

from the
WMA W
orkflow
R
egistry.
Third, ordering constraints in the master workflow are
added to the
knowledge

base.

Fourth,
some
tasks are
added to the workflow. After this step, workflow has all
tasks and control links.
Finally, data links may be

added.



Figure
4
. Execution structure composition procedure

Order Tasks will create a partial ordering for the
tasks
in
component workflow
s
.
It is not necessary to order all
tasks separately, as the compon
ent workflows already
have ordered some tasks.
Data dependencies
specified in
the master workflow
need to be

used in planning as well
.

Add Tasks phase adds Fork/Join control links around
sets of concurrent tasks. If the master workflow specifies
that
comp
onent workflows

are executed in sequence,
a
Go
control link is

added

between
their tasks
.

Our workflow engine implementation supports name
d

d
ata
l
inks between tasks.
By default, all data links are
internal to component workflows only. Master workflow
can s
pecify some data links to be public and usable by
other component workflows.

In practice
d
ata
l
inks often
require filters or transformations.
[10]
There is some
research on ontology version contro
l and ontology
transformations that could be useful.


7
.
Sam
ple case

In this section we present a sample case how we see
automated reasoning should work
.
Figure
5

presents how
the master workflow and component workflows are
integrated.


Figure
5
.
Sample composite workflow

Master workflow contains two concurrent component
workflows. The component workflows contain two and
three sequential tasks.
The composite workflow could
contain two concurrent sequences of tasks, if there are no
dependen
cies between

the component
workflows
.
If there
is a data dependency between the two component
workflows, they
will

be executed in sequence.
This results
in many possible workflows; the general idea is to add
constraints until only
one or few

workflow
s

rema
in
.

8
. Conclusions

We have implemented a workflow engine that uses
current ontology languages and tools to execute
workflows.
This paper presents a way to use ontology
-
based reasoning to automatically combine component
workflow instances.

Our ontology is s
impler in many

ways
than DAML
-
S process model, which

lets

us to use
inference engines.
In future, we plan to develop the
composition framework with more complex features like
data flow integration. We think that to use ontology
-
based
reasoning in practice,

ontologies need to be focused.

9
. References

[1]
Tim Berners
-
Lee, James Hendler, and Ora Lassila
, “
The semantic
web
”,
Scientific American
,
May 2001
.

[2]
Joe Kopena and William C.Regli, “DAMLJessKB: A Tool for
Reasoning with the Semantic Web”
.


http://edg
e.mcs.drexel.edu/assemblies/software/damljesskb/articles/DA
MLJessKB
-
2002.pdf

[3] Narayanan, S. and McIlraith, S., "Simulation, Verification and
Automated Composition of Web Services",
Proceedings of the Eleventh
International World Wide Web Conference
, 200
2.

[4] Boualem Benatallah. and

Marlon Dumas, "The Self
-
Serv
Environment for Web Services Composition",
IEEE Internet
Computing
, Jan
-
Feb, 2003.

[5] Lasse Pajunen, Jarmo Korhonen, Juha Puustjärvi.
“Adaptive Web
Transactions: An Approach for Achieving the Ato
micity of Composed
Web Services”, Proceedings of EuroWeb conference, 2002
.

[6]

HP Labs,

Jena

Semantic Web toolkit
.

http://www.hpl.hp.com/semweb/jena.htm

[7] Shankar R. P. and Armando F.

SWORD: A Devel
oper Toolkit for
Web Service Composition
”,

Proceedings

of the Eleventh International
World Wide Web Conference
, 2002.

http://www2002.org/CDROM/alternate/786/

[8] Jarmo Korhonen, Lasse Pajunen, Juha Puustjärvi, “Using
Transactional Workflow Ontology in Ag
ent Cooperation”,
AIM
Workshop, First EurAsian

Conference on Advances in ICT
, 2002
.
http://www.iki.fi/jako/papers/twfo.pdf

[9]
Ruoyan, Z., Arpinar, B., Aleman
-
Meza, B., Automatic Composition
of Semantic Web Services, The 2003 International Conference on We
b
Services (ICWS'03), June 2003.

http://lsdis.cs.uga.edu/lib/download/composition_short_icws.doc

[10] Juha Puustjärvi, Henri Tirri, Jari Veijalainen.
“Reusability and
modularity in transactional workflows”.
Information Systems
, Vol 22,
No 2/3, pp 101
-
120,
1997

[11]
DAML
-
S:
Semantic Markup for Web Services
.
P
roceedings of the
International Semantic Web Working Symposium (SWWS)
, 2001
.
http://www.daml.org/services/SWWS.pdf

[12] BPEL4WS

Business process execution language for web services,

http://www.ibm.com/de
veloperworks/webservices/library/ws
-
bpel/

[13] JWSDP


Java Web Services Developer Pack.

http://java.sun.com/webservices/webservicespack.html