Contract-based Web Service Composition Framework with Correctness Guarantees

sizzledgooseSoftware and s/w Development

Nov 3, 2013 (3 years and 8 months ago)

88 views

Contract-based Web Service Composition
Framework with Correctness Guarantees
Nikola Milanovic
Humboldt University,Berlin
milanovi@informatik.hu-berlin.de
Abstract.We present formal and practical foundations for Web service
composition framework with composition correctness guarantees.We intro-
duce contractual composition model based on two isomorphic description
models:Contract De¯nition Language (XML) and abstract machines (for-
mal notation).Composition operators (patterns) are used to performcompo-
sition which is then formally veri¯ed with respect to properties described in
service contracts.We also describe Java-based implementation of the system,
concentrated around Sun's Java Web Services Development Pack (JWSDP).
Indexed terms:Web services,composition,correctness,contracts
1 Introduction
Web services are emerging as a replacement and/or additional paradigm for the
component-based software development.However,Web services aim much further
to become not only a new Object Request Broker architecture,but a unifying par-
adigm for communication among heterogenous groups of software and hardware
entities.Therefore Web services assume that certain native capabilities are enabled
and standardized.Web service architecture has three layers:description and basic
operations (publication,discovery,selection and binding),composite services (co-
ordination,conformance,monitoring and quality of service) and managed services
(certi¯cation,rating,liability).Unfortunately,only the bottom layer has been stan-
dardized (WSDL,UDDI and SOAP).We are seeking a solution for the second layer
dealing with Web service composition.Several approaches for service composition
have distinguished the main research directions.In the next section we discuss the
ideas of existing approaches and then present formal foundations and implementa-
tion of a contract-based composition framework.
2 Related Work
The composition layer comprises four properties:coordination,conformance,moni-
toring and quality of service.Coordination determines which services participate in
composition and how they exchange messages.Conformance establishes composi-
tion correctness,while monitoring basically deals with error and exception handling.
Finally,quality of service o®ers metrics to compare di®erent compositions with re-
spect to nonfunctional properties.
We examined several approaches for Web service composition:Business Process
Execution Language for Web Services (BPEL4WS) [5],Semantic Web (OWL-S) [6,
11,17],Web component [19],¼-calculus [12],Petri Nets [10],model checking [9] and
¯nite state machines [3,4].Our detailed survey of these solutions and how they
relate to the four key composition properties can be found in [15].Here we present
only short overview and summarize the results (Figure 1).
The main problem with'industrial'approaches (BPEL,OWL-S) is the lack
of support for verifying composition correctness.Both approaches (and BPEL in
particular) o®er implementation languages that are simply too expressive for any
kind of formal validation.Yet we consider veri¯cation of correctness as the cru-
cial property of any composition framework.Service composition has been called
'programming in big',but it seems that industry prefers to be unaware that even
'programming in the small'is plagued by numerous problems when formal speci-
¯cation and veri¯cation methods are lacking.On the other hand,there are other,
more formal and abstract approaches (e.g.,¼-calculus or ¯nite state machines).
However,they are often di±cult to apply in real-world scenarios,and some of them
face serious scalability problems.
Fig.1.Approach comparison:service composition requirements
Our intention is to provide formal and practical foundations for a composition
approach based on contracts.
3 Contracts and Abstract Machines
The concept of design by contract was ¯rst introduced by Bertrand Meyer [13]
to facilitate component reuse.A contract describes,in a standard way,what a
component expects from its clients and what it delivers if those requirements are
met.We propose to use contracts as non-functional (QoS) extension of WSDL
description.
3.1 Contract De¯nition Language (CDL)
CDL is an extension of WSDL and redundant elements will not be de¯ned again.
Since WSDL deals with pure connectivity we assume that messages and port bind-
ings are already de¯ned,separate or as a part of the service contract.The contract
itself must provide information that is related to non-functional aspects of the ser-
vice execution.However the contract should not include implementation details but
semantic information only:what a service will deliver and under which conditions
it will execute correctly.
The root section of CDL schema is shown on Figure 2a,comprising organization,
types,location,method and event elements,as well as several basic attributes:
uri,name,description,price,state information,version and port.The organization
element is introduced to maintain backwards compatibility with Universal Descrip-
tion,Discovery and Integration (UDDI) directories.Therefore,every service must
belong to an organization that publishes it.For each organization it is possible to
de¯ne name,description (keywords),classi¯cation and primary contact.The types
element describes complex types that a service supports.It is used when a ser-
vice accepts or returns non-primitive types (e.g.,object of come custom class),and
clients should be able to construct/deconstruct them appropriately.The location
element is introduced to support location-based services.It allows for de¯nition of
country,city,street address and GPS coordinates.The event element declares all
events that a service supports.For each event,its native name is listed,along with
a reference and a common environment exception it is mapped into (if available).
Finally,the method element describes one or more service methods.
a)￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿b)
Fig.2.The root contract structure
Inside the method element we can specify information about parameters,per-
sistent resources,invocation,pre-conditions,post-conditions and invariants,events,
assertions,classi¯cation and method location.For each parameter it is possible to
de¯ne name,type,restriction and initialization.Furthermore,constants and sets
(complex types) that a method understands can be listed.Invocation information
is related to component creation and execution (synchronous or asynchronous).
Pre-conditions,post-condition and invariants share the same structure (Figure 2b).
Pre-conditions are linked to exported methods and determine obligations of a
client.A method is guaranteed to work correctly if and only if a client satis¯es
pre-condition.An exported method can turn pre-condition to its advantage,since
it can assume pre-condition,without having to check it.This type of interaction
is called generous speci¯cation,since we presume that client code is correct and
that it respects pre-condition.Post-condition describes what a method guarantees,
if precondition holds.Invariants are properties that must hold before and after
invocation of each exported method.They describe general,static properties of
a service.The properties that can be described are:rendering,logging,security,
dependability (transactions,replication,check-pointing,timeout and exceptions),
performance and parameters.
It can be argued that proposed speci¯cation is di±cult to write and maintain.
However,we shoved in [16] that it is possible,to some extent,to automate extraction
of de¯ned properties fromJava classes and Enterprise Java Beans.We also identi¯ed
the bene¯ts that early contract inclusion has on the typical software lifecycle.It is no
so much the issue of automatic extraction,as the point that contracts are inherent
in the way we design and write software.
3.2 Modeling Services as Abstract Machines
If our only goal was to add support for Design by Contract principles to the Web
service architecture stack,extending WSDL with CDL would be the end result.
However,our main task is to support not only reuse,but composition of Web
services.CDL syntax o®ers a richer set of description primitives compared to WSDL,
that can be used for specifying relevant non-functional properties.Veri¯cation of
composition correctness,however,requires a formal approach.
Since contracts,as we presented them so far,are just plain text (XML) ¯les,it
would be very di±cult,if indeed possible,to judge correctness of their composition.
The ¯rst problem we would be faced with is actual de¯nition of correctness.What
does it mean for a contract to be correct,apart from satisfying XML requirements
of being well-de¯ned and well-formed?How can we judge whether two or more
contracts are compatible or not con°icting with each other?How to de¯ne rela-
tions"compatible"and"con°icting"?Finally,how to perform actual composition
when working on text ¯les?In order to be able to answer these questions,we intro-
duce a second form for expressing Web service contracts:abstract machine notation
(AMN).We need the XML notation in order to transport contracts over a network
(interoperability),while AMN serves the purpose of giving contract elements formal
mathematical treatment.
Abstract machines are speci¯ed and proofed using Abstract Machine Notation.
Details on AMN can be found in [1].We give a short overview of AMN principles.
An element,which can be a class,a component,or a Web service,is represented
as an abstract machine.It is characterized by statics and dynamics.The statics
corresponds to the de¯nition of the state,while the dynamics corresponds to the
operations.The basic abstract machine elements are speci¯ed in the following way:
MACHINE M(X,x)
CONSTRAINTS C
CONSTANTS c
SETS S;T={a,b}
PROPERTIES P
COMPLEX Cx
VARIABLES v
INVARIANT I
ASSERTIONS J
INITIALIZATION U
OPERATIONS
u1 <- O1(w1) = PRE Q1 THEN V1 END
...
un <- On(wn) = PRE Qn THEN Vn END
END
This is a parameterized abstract machine having free dimensions X (set) and
x (scalar).CONSTRAINTS describes conditions on machine parameters.SETS contains
¯nite or named sets that the machine can use,while CONSTANTS describes constants
that the machine understands.PROPERTIES takes form of conjoined predicates spec-
ifying invariants involving constants and sets.VARIABLES lists state variables,and
INVARIANT describes static properties of the machine,that must be preserved before
and after each operation.ASSERTIONS is deducible from PROPERTIES and INVARIANT,
and exists purely to ease the proving of machine correctness.INITIALIZATION ini-
tializes state variables.OPERATIONS lists operations of an abstract machine,with
pre-conditions (PRE) and post-conditions (THEN).
Operation body of an abstract machine modi¯es a machine state.For express-
ing formally how such modi¯cation takes place,we will be using logical predicates
relating the values of state variables just before the operation is invoked to the
values just after the operation completes.The method we use is called before-after
predicate.By convention,the values of the variables after the operation has been
completed are denoted by priming variable identi¯ers.Let x be a state variable,and
a a scalar value.Then,before-after predicate is:
x
0
= x +a
This does not mean that after-value must be related to before-value in a func-
tional way.In general case,this relation can be non-deterministic:
x
0
< x
We now generalize before-after predicate by introducing substitution.Let P be
a formula,x be a variable and E an expression,then the following denotes the
formula obtained by replacing all free occurrences of x in P by E:
[x:= E]P
We show that each before-after predicate can be generalized using substitution.
Let us observe the implication involving before-after predicate and substitution:
x 2 N )8x
0
(x
0
= x +a )x
0
2 N)
Applying One Point Rule:
8x(x = E )P),[x:= E]P
we have:
x 2 N )[x
0
:= x +a](x
0
2 N)
Performing substitution,we get:
x 2 N )x +a 2 N
That is:
x 2 N )[x:= x +a](x 2 N)
This is a very important result,since it is clear that if we denote invariant x 2 N
with I and substitution x:= x +a with S we can rewrite the previous expression:
I )[S]I
This expression says that if the invariant I holds then the substitution S is
guaranteed to preserve the same invariant.We now generalize the concept of sub-
stitution,by showing di®erent ways to perform it,thus constructing more complex
abstract machine operations.
Pre-conditioned Substitution We saw how to denote before-after predicate of
the form x
0
= x +a as substitution,as well as how to express a substitution that
preserves a property (invariant) with S[I].We still do not knowhowto express a very
important part of CDL:pre-condition.For that reason pre-conditioned substitution
is introduced.
Pre-condition describes conditions under which a service operation will execute
correctly,that is,it will reestablish the invariant.Otherwise,the operation will not
establish anything.If P is the pre-condition,and S is the substitution guarded by
this pre-condition,than pre-conditioned substitution is de¯ned as:
[PjS]R ()P ^ [S]R
where R is a post-condition that this substitution has to establish.It is obvious
that when P does not hold,this substitution will not be guaranteed to establish
anything,since P ^[S]R will never be true in that case.This substitution can also
be presented in the following notation:
PRE P THEN S END
Multiple Simple Substitution Often we have to perform simultaneous substi-
tution,where the exact order is not known (can not or should not be known) in
advance.For that purpose multiple simple substitution is introduced:
[x;y:= E;F]P
where variables x and y are being substituted by expressions E and F respec-
tively,in predicate P.This substitution is performed simultaneously and can be
de¯ned in terms of simple substitutions:
[x;y:= E;F]P ()[x:= E][y:= F]P
If a substitution includes many variables,it can become unreadable.Therefore,
it can be expressed in the following (also vertical) notation:
x:= E || y:= F ||
z:= G
Bounded Choice Substitution Bounded choice substitution is used to express
a choice between two or more substitutions.It is nondeterministic in a sense that it
is not known which one of them will actually be performed.The results is,however,
bounded.That means that whatever the choice is made,the same post-condition
must be achieved.If we denote choice between substitutions S and T with S¤T,
then the following holds for a post-condition R:
[S¤T]R ()[S]R^ [T]R
This substitution can also be presented like:
CHOICE S OR T END
and is not limited to two substitutions only:
CHOICE S OR T OR U OR
V OR W END
Guarded Substitution Guarded substitution is similar to pre-conditioned sub-
stitution (PjS),as it is also guarded by a predicate.A substitution S guarded by
predicate P is denoted:
P =)S
Substitution S is performed under the assumption P and establishes a post-
condition R in the following way:
[P =)S]R ()(P =)[S]R)
When P is false,this substitution can establish anything (true or false),and
is said to be non-feasible.It should be noted how this substitution di®ers from
pre-conditioned substitution P ^ [S]R.When P does not hold in pre-conditioned
substitution,it is said to be aborted,since it cannot establish anything.In guarded
substitution,on the contrary,when P is false,the result of the substitution can
be anything,as we have shown.A shorthand (also vertical) notation for guarded
substitution is:
IF P THEN S END
Conditional Substitution Conditional substitution is de¯ned as combination of
bounded choice and guarded substitution in the following way:
IF P THEN S ELSE T END ()(P =)S)¤(:P =)T)
or,with post-condition R:
[IF P THEN S ELSE T END]R ()(P =)[S]R) ^ (:P =)[T]R)
Unbounded Choice Substitution The unbounded choice substitution is the
generalization of the bounded choice substitution.Let S be a substitution depending
on variable z.If we want to specify a substitution that can choose any value of z,
we write @z:S,where:
[@z:S]R =)8z ¢ [S]R
Then we can introduce a guard for S and have @z:(P =)S):
ANY z WHERE P THEN S END
Empty Substitution The empty substitution does nothing,or more precisely,
performs no substitution for the target post-condition.An empty substitution is
denoted with skip:
[skip]R ()R
Obviously,such a substitution is not very useful by itself,but we will use it to
de¯ne the while (loop) substitution.
Multiple Generalized Substitution Multiple simple substitution can be gener-
alized for all substitutions presented so far.We want to enable speci¯cation where
not only simple substitutions can be performed simultaneously,but where any pair
of substitutions can be performed concurrently.The notation remains the same (k),
and for any substitutions S,T and U,predicate P and variable z we de¯ne:
S k skip = S
S k (PjT) = Pj(S k T)
S k (T¤U) = (S k T)¤(S k U)
S k (P =)T) = P =)(S k T)
S k (@z ¢ T) = @z ¢ (S k T);if znS
Since multiple simple substitution k is commutative,so is the multiple gener-
alized substitution.Therefore we will not show the cases when S is the right side
operand (e.g.,(PjT) k S = Pj(T k S)).
While Substitution The while substitution checks for predicate P and if it holds
executes generalized substitution S.Then P is checked again,and if it still holds,
S is performed again.When P does not hold,the substitution does nothing and
resumes execution right after the loop.This substitution is denoted with:
WHILE P DO S END
In order to be able to reason about this substitution,we have to introduce
another construct that will describe repetitive substitution.For any generalized
substitution T,it is denoted
^
T and de¯ned:
^
T = (T;
^
T¤ skip)
Note that this is not a recursive de¯nition.Substitution T is performed com-
pletely,and then in the next iteration either the same substitution is performed or
nothing is done.Using this formalism,we can de¯ne while substitution:
WHILE P DO S END,(P =)S)^;(:P =) skip)
We will not be using this substitution to construct operation body.This makes
sense,since CDL description ought to deal with speci¯cation,and not implementa-
tion.We will use while substitution to construct looping composition pattern.
Mapping from CDL to AMN We have presented two notations for describing
Web service contracts.During service exploitation there will be times when we will
have to switch between them:
{ When composing two services,their CDL descriptions will be transferred into
abstract machines to allow for formal treatment of their properties.
{ When new service is composed it is constructed by merging abstract machines of
the constituent services,thus producing another abstract machine.In order to
make this service available to others and to be able to transport its speci¯cation
over a network,abstract machine has to be transferred into CDL description.
It can be seen that transformation between CDL and AMN has to be bidirectional.
However,since this transformation is linear,once we know how to do it one way,
the other way is trivial.The mapping algorithm works as follows:
1.Machine name is constructed from serviceName attribute of the contract ele-
ment.All other attributes of the contract element,as well as all child elements
and attributes of the organization and location elements are mapped into
CONSTANTS clause.
2.The types element is mapped into COMPLEX clause of abstract machine.
3.The event element is mapped into CONSTANTS clause.
4.For each method element,the following is performed:
(a) State variables are built from elements specifying properties in invariant,
precondition,postcondition elements.To this are added all method pa-
rameters.
(b) All sets de¯ned in the set element are added to the SET clause.
(c) Constants from the constants element are added to the CONSTANTS clause.
(d) The INVARIANT clause is de¯ned in term of conjoined predicates involving
state variables,and is mapped directly from the invariant element.The
INVARIANT clause must contain enough conjuncts to allow for the typing of
all state variables.
(e) The PRE clause is mapped directly from precondition element.State vari-
ables designating input parameters must have constraints (or types) de¯ned
in this clause.
(f) Operation body (postcondition,or THEN clause) is constructed by conjoining
substitutions fromthe postcondition element.All output parameters must
have properties (or types) described in this clause.
(g) All state variables that have initialization element de¯ned,are added to
the INITIALIZATION clause.Additionally,those that are de¯ned as"INOUT"
are added to the list of machine formal parameters.
(h) The content of assertion element (if exists) is added to the ASSERTION
clause in form of conjoined predicates.
(i) The resource,invocation and event-ref elements are of no interest for
composition semantics,and are thus not transferred into AMN.They are
used for maintaining internal consistency of composition process.
4 Service Composition
We are interested in examining the ways we can compose abstract machines that
specify services.The goal is to provide composition patterns that can be used to
specify di®erent composition scenarios,while being able to de¯ne and verify com-
position correctness for each of them.For each composition pattern,we provide
corresponding composition operators.Therefore,in the remaining text we will be
using terms composition pattern and composition operator interchangeably.Finally,
we want to de¯ne a composable service architecture and emphasize its bene¯ts.
We proceed by identifying four basic ways to compose services:sequence,choice,
parallel and loop.We show how to construct composite abstract machine clauses
for each case and then discuss properties of those patterns.
4.1 Sequential Composition
The sequence operator executes two (or more) services in an ordered sequence.We
denote sequential composition of services A and B with:
C = ABB
Outputs of the left operand (A) become inputs of the right operand (B).There-
fore,operation B is not commutative.Figure 3 shows this composition.The clauses
of the resulting abstract machine are calculated:
{ SETS,CONSTANTS,and VARIABLES clauses are concatenated
{ PROPERTIES,INVARIANT,and ASSERTION clauses are conjuncted
{ OPERATIONS clause is constructed by performing substitution of the left operand,
then substituting input state variables of the right operand with the output state
variables of the left operand,then performing substitution of the right operand,
while conjuncting preconditions:
OPERATION output
B
à C(input
A
)
PRE P
A
^P
B
THEN S
A
;input
B
:= output
A
;S
B
END
Here output
B
is a set of output state variables of the right operand,input
A
is a
set of input state variables of the left operand,C is the name of a new(composite)
operation,input
B
is a set of input state variables of the right operand,and
output
A
is the set of output state variables of the left operand.
{ INITIALIZATION clauses are concatenated,and multiple composed if needed
A
B
P
A
S
A
P
B
S
B
I
A
I
B
P
C
S
C
I
C
C
Fig.3.Sequence Pattern
4.2 Parallel Composition
Parallel composition executes two (or more) services concurrently.We allow two
subtypes of this pattern:parallel composition with and without communication.
In the former case,concurrent services can communicate with each other,for the
purpose of synchronization of some state variables.It can be used when a certain de-
cision has to be reached after parallel processing has been performed,e.g.,choosing
result of one service and discarding the other.Only operators of the relational alge-
bra are allowed for the state variables upon which the synchronization is performed.
We do not allow any kind of result aggregation,since it would needlessly complicate
composition pattern.If data aggregation needs to be performed,additional service
should be created and then sequentially composed to the parallel composition.In
the latter case (no communication),there is no communication/synchronization
between concurrent services.Figure 4a shows parallel composition without commu-
nication and Figure 4b shows parallel composition with communication.
Parallel composition with communication is denoted with k
P(c)
,where c are state
variables that are being used for synchronization and P is the predicate evaluated
upon them,while parallel composition without communication is denoted with k:
C = A k
P(c)
B
C = A k B
The clauses of the composed abstract machine are constructed:
{ SETS,CONSTANTS,and VARIABLES clauses are concatenated
{ PROPERTIES,INVARIANT,and ASSERTION clauses are conjuncted
{ OPERATIONS clause is constructed di®erently for composition with and without
communication:
² For parallel composition without communication,pre-conditions are con-
juncted and substitutions are performed simultaneously (using multiple gen-
eral substitution):
OPERATION output
C
à C(input
C
)
PRE P
A
^P
B
THEN S
A
k S
B
END
Here output
C
= output
A
[output
B
and input
C
= input
A
[input
B
.
² For parallel composition with communication,pre-conditions are conjuncted
and substitutions are performed simultaneously.Afterwards,predicate P is
evaluated on a subset of state variables c,resulting in choice of output of
only one service:
OPERATION output
C
à C(input
C
)
PRE P
A
^P
B
THEN S
A
k S
B
IF P
c
THEN output
C
= output
A
ELSE output
C
= output
B
END
{ INITIALIZATION clauses are concatenated,and multiple composed if needed
B
A
S
B
S
A
I
A
I
B
S
C
I
C
B
A
S
B
S
A
P
A
P
A
P
B
P
B
I
A
I
B
P(c)
P
C
P
C
S
C
I
C
a)￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿b)
Fig.4.Parallel Pattern
4.3 Choice Composition
The choice pattern represent a composition that behaves as either of its constituents
services.It is similar to parallel composition pattern with communication,but it
is non-deterministic.It is furthermore restricted to compatible services in sense of
input parameters,because it is used when it is known in advance that some of the
available services can perform the requested operation,without the need to know
which one will do so in a particular instance.The most general example is sending
the same request to many services and accepting the results from the one that ¯rst
completes its execution.This composition pattern is denoted with ¯:
C = A¯B
The composition is show on Figure 5.The machine resulting from applying choice
pattern is constructed as follows:
{ SETS,CONSTANTS,and VARIABLES clauses are concatenated
{ PROPERTIES,INVARIANT,and ASSERTION clauses are conjuncted
{ OPERATIONS clause is constructed by conjoining preconditions and connecting
substitutions by bounded choice substitution operator:
OPERATION output
C
à C(input
C
)
PRE P
A
^P
B
THEN S
A
¤S
B
END
Here output
C
= output
A
_output
B
,which is implied in S
A
¤S
B
.
{ INITIALIZATION clauses are concatenated,and multiple composed if needed
B
A
S
B
S
A
P
A
P
B
I
A
I
B
P
C
I
C
S
C
Fig.5.Choice Pattern
4.4 Looping
Looping pattern supports execution of the same service repeatedly,until a certain
condition is ful¯lled.Based on the condition controlling the loop,we de¯ne unary
and binary loop:
C =ª
P(e)
A(e)
C = W(e) ª
P(e)
A
In both cases,looping is controlled by predicate P evaluated on the variable
e.Service is executed until P(e) becomes false.In the unary pattern,e is a state
variable of service A,and is changed in every iteration by the execution of A.
Therefore,service A controls the loop exit condition.Since this is the loop with the
condition on top (exit condition is evaluated prior to execution),variable e must
be in the INITIALIZATION clause to enable the ¯rst loop iteration.In the binary
pattern,there is another service W that controls P(e).In this case we do not allow
service A to in°uence the loop exit condition.Here,service W is executed prior to
A
and will set value of
e
,which therefore does not have to be initialized.Unary (a)
and binary (b) pattern are shown on Figure 6.
A(e)
A
S
A
S
A
P
A
P
A
P
C
P
C
I
A
I
A
P(e) P(e)
S
C
S
C
I
C
I
C
a)￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿b)
1 1
skip skip
0
0
C C
W(e)
P
W
S
W
I
W
Fig.6.Loop Pattern
The composite machine is constructed as follows for the unary pattern:
{ The clauses SETS,CONSTANTS,VARIABLES,PROPERTIES,INVARIANT,ASSERTION,
and INITIALIZATION are kept unchanged.Variable controlling loop exit (e)
must appear in the INITIALIZATION clause.
{ Operation body is constructed by enclosing original substitution in a WHILE DO
block,controlled by P(e):
OPERATION output
C
à C(input
C
)
PRE P
A
THEN WHILE P(e) S
A
(e) END
END
Here ouptut
C
= output
A
and input
C
= input
A
.
For the binary pattern,another service W controls exit variable:
{ SETS,CONSTANTS,and VARIABLES clauses are concatenated
{ PROPERTIES,INVARIANT,and ASSERTION clauses are conjuncted
{ Operation body is constructed by conjoining preconditions,and enclosing both
substitutions inside a WHILE DO:
OPERATION output
C
à C(input
C
)
PRE P
A
^P
W
THEN S
W
(e)
WHILE P
e
S
A
;S
W
(e) END
END
{ INITIALIZATION clauses are concatenated,and multiple composed if needed
Operator priority,commutativity,associativity and distributivity are shown on
Figures 7a,7b and 7c,respectively.
a)￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿b)￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿c)
Fig.7.Operator Properties
4.5 Correctness Veri¯cation
Once an operator has been applied,composition result has to be veri¯ed.The whole
composition process then proceeds as follows:
{ Merging of two (or more) abstract machines using composition operator.
{ Type checking of the resulting abstract machine.
{ Proving correctness of the resulting abstract machine
{ Establishing correct termination of the resulting abstract machine
Type Checking Suppose that we have an expression E and a set s such that
E 2 s.Suppose further that there exists a set t such that s µ t.Then it follows that
E 2 t.We can continue by including t in a larger set u,and then E will also belong
to u.The purpose of type-checking of the abstract machine is to provide an upper
limit for such set containment for all predicates.This upper limit is called a super-
set of s and is at the same time the type of E.The function check is introduced like
ENV`check (P),and for the predicate P means that within the environment
(antecedent) ENV predicate P type-checks.Referring to the abstract machine from
Section 3.2,the type checking consists of the following requirements:
{ X;x;S;T;a;b;c;v are all distinct
{ Operation names of O
1
:::O
n
are all distinct
{ S;T;a;b;c;v are not-free in C
{ v;X;x are not-free in P
{ X;S;T;a 2 T;b 2 T`check (8x(C )8c(P )8v(I ^J )U ^O))))
The last expression means that ¯rst universally quanti¯ed scalar parameters
and their constraints are checked,then universally quanti¯ed constants and their
properties,then universally quanti¯ed variables and their invariant,and ¯nally ini-
tialization and operations.
Proof Obligation After type checking has been performed,the resulting machine
must be proved correct.The purpose of this is to establish the following:
{ Composite initialization must establish composite invariant
{ Composite assertion must be deducible fromcomposite properties and invariant
{ Composite operation must establish composite invariant
Formally,and again referring to the machine from Section 3.2 we can write it:
C ^P )[U]I
C ^P ^I )J
C ^P ^ I ^J ^Q )[V ]I
Correct Termination After proving machine correct,we have to see whether it
will terminate correctly and whether it is feasible.For a given substitution S the
construct trm(S) denotes the predicate that holds when substitution S terminates,
that is,establishes its post-condition.By requiring that all operations terminate,
we ensure elimination of deadlocks.Another construct is de¯ned,abt(S) which
denotes aborted substitution,that is,substitution that does not establish anything.
Therefore it can be said that abt(S) ´:[S]R for any predicate R,and accordingly
trm(S) ´:abt(S).We de¯ne correct termination as trm(S) () [S](x = x).
Correct termination for substitutions is established in the following way:
trm(PjS) ()P ^ trm(S)
trm(P¤T) ()trm(S) ^ trm(T)
trm(P )S) ()P )trm(S)
trm(@z:S) ()8ztrm(S)
We also check whether the composite operation is feasible,with respect to
the guarded substitution.The feasible operation will establish one,or none post-
condition.Non-feasible operation,on the other side,will be able to establish any
post-condition.We de¯ne feasibility as ¯s(S) ():[S](x 6= x).The feasibility of
the standard substitutions is calculated in the following way:
fis(PjS) ()P )fis(S)
fis(P¤T) ()fis(S) _ fis(T)
fis(P )S) ()P ^fis(S)
fis(@z:S) ()9zfis(S)
Correct termination for loop operator is outside the scope of this general paper.
Su±ce to say that we introduce two separate elements in the loop body:invariant
and variant (exit condition).We currently limit the evaluation of the exit condition
to natural number and observe its monotonicity:
trm(WHILE P DO S INVARIANT I VARIANT V END) ()
(8x ¢ (I )V 2 N)) ^(8x ¢ (I ^P )[n:= V ][S](V < n)))
The elements introduced allow us to de¯ne a composable service architecture.
The architecture is de¯ned as tuple A(E;O) where E is a set of initial (atomic)
services,and O is a set of composition operators.An operator o 2 O is a function
that maps two (or more) services to a new service:o:E £E £:::E!E.
Not all composed services are,however,valid members of the architecture.
Therefore we introduce a function correct:E £ E £:::E £ O!ftrue;falseg.
Function correct(e
1
;e
2
;::e
n
;o),where e
1
:::e
n
2 E and o 2 O,is true if the compo-
sition of elements e
1
:::e
n
using composition operator o is correct,and returns false
otherwise.The function correct is calculated for the composite element e(e
1
;:::;e
n
;o)
in the following way (proof(e) denotes proof obligation):
correct(e) ()check(e) ^ proof(e) ^trm(e) ^ fis(e)
5 Implementation
In previous sections we formed formal foundations needed for developing Web ser-
vice composition framework.Now we address some implementation issues,namely
system organization,communication,service directory and state management.
5.1 System Overview
General system overview is shown on Figure 8.Composition engine comprises four
main parts:client application,basic administrative services,database for storing
CDL contracts,one or more application servers/containers with deployed services.
admin
publish
modify/delete compose
search
invoke
cdl
directory
client
service/contract
swing swing
JAX-RPC
JAX-RPC JAX-RPC
JAX-RPC
JAX-RPC
JAX-RPC
JAX-RPC
JAX-RPC
JAXB
JAXB
JDBC
JDBC
JDBC
JDBC
JAX-RPC
composition
operators
client
basic￿services
middle￿layer
database
application￿server(s)
Fig.8.Implementation of the Composition Engine
Service descriptions are stored in a relational database.Client applications access
basic functionalities of the engine via Web service middle layer.This middle layer
connects to the underlying database,as well as to application servers in which
target services are deployed.Clients cannot access database or application servers
directly.Therefore,most of the engine's tasks are accomplished in the middle layer.
The engine is implemented using Java and Java-related technologies.
5.2 Client and Basic Administrative Services
Client part is realized as Swing application connected to the middle Web service
layer that provides administrative functions and operations.Middle layer o®ers the
following operations:publishing new service to directory,modifying and deleting
existing service from directory,searching for services,composing new services using
existing ones,invoking single or composed services.
In order to achieve these tasks,middle layer communicates with underlying
relational database (directory) and application servers hosting target Web services
that users want to invoke and/or compose.Since entire application is Web service-
based,the communication is realized using Sun's Java Web Services Developer Pack
(Sun JWSDP) [14].
CDL XSD
Schema
JAXB￿Binding
compiler
Content
classes
(CDL)
middle￿layer
compile
JAXB
publish￿proxy
publish A
JAX-RPC/
SOAP
JAX-RPC
service A service￿B
JAXB
unmarshal
instantiate
A content
CDL
directory
publish
compose￿(A,B)
JAX-RPC/
SOAP
JAX-RPC
compose
proxy
compose
JAX-RPC
JAX-RPC
JDBC/
JAX-RPC
A proxy
B￿proxy
result
write￿DB
JDBC
correct
Fig.9.JWSDP Runtime
We found two technologies provided within JWSDP very useful:Java Architec-
ture for XML Binding (JAXB) and Java API for XML-based Remote Procedure
Calls (JAX-RPC).They are essential for understanding how composition engine
works and we will cover both in more details.
Since CDL schema is very large,encompassing more than 50 complex entities,
we need a powerful yet °exible mechanism of translating XML document into Java
object representation.The problem can be solved partially using parsers like SAX
or DOM,but it would only account for the parsing.JAXB o®ers a complete solu-
tion for transferring XML content into Java object representation and vice versa.
JAXB operation is based on three actions:binding XML schema to Java content
classes,unmarshalling XML document into content classes and marshalling content
classes into XML document.At the beginning CDL schema is compiled with JAXB
binding compiler.This action produces a set of Java content classes that re°ect the
contract structure.The process of unmarshalling takes service contract as input and
produces set of instantiated Java content classes populated with data parsed from
XML document.During unmarshalling contract is optionally validated with respect
to schema.After this step we have in-memory representation of contract.The mid-
dle layer uses JAXB to publish and modify service contracts.When a contract is
published,Java content classes are persisted in database tables.When a contract
needs to be changed,tables are updated,and depending on the origin of update,
XML representation is synchronized (via JAXB marshalling).
JAX-RPC is used for communication with Web services.Since middle layer is
also realized as a Web service,clients use JAX-RPC to invoke basic functions of
the system,and middle layer uses JAX-RPC to invoke single or composite services.
In JAX-RPC a remote procedure call is represented by an XML-based protocol,
such as SOAP.Complex SOAP messages and their structure (envelope,encoding
rules,conventions for RP calls and responses) are hidden by JAX-RPC API.This
API supports development of server side (Web service implementation) and client
side (Web service invocation) infrastructure.On the server side,remote procedures
(Web methods) are speci¯ed by writing Java interface and one or more classes
that implement that interface.On the client side,a proxy object is created that
represents Web service.All Web methods are invoked on a proxy.Therefore,it is
not necessary to generate or parse SOAP messages.The JAX-RPC runtime converts
API calls and responses to and from SOAP messages.However,JAX-RPC is not
restrictive in any way:JAX-RPC client can access a Web service not running on the
Java platform,and JAX-RPC Web service can be accessed from non-Java client.
The functioning of JAXB and JAX-RPC runtime is shown on Figure 9.It shows
two typical use cases:publishing a new service to directory and composition of
two services that are already in directory.Prior to any client calls,XSD schema
describing Contract De¯nition Language is compiled with JAXB binding compiler,
and content classes are stored in the middle layer.Client publishes new service by
issuing SOAP or JAX-RPC call to the Publish Proxy,which delegates the call to
the Publish service in the middle layer.A service that is to be published is located,
and its CDL description is unmarshalled into precompiled content classes produced
by JAXB compiler.Finally,write to underlying database is performed via JDBC
which completes the publish process.
Composition is initiated by sending SOAP/JAX-RPCrequest to Compose Proxy,
and the call is then delegated to Compose service in the middle layer via JAX-RPC.
It processes composition request,retrieves partner service information from data-
base using JDBC,veri¯es composition correctness by calculating function correct,
and constructs required dynamic proxies that represent partner services using Dy-
namic Invocation Interface.Each proxy then connects to its implementation and
middle layer coordinates message passing in a manner that depends on the compo-
sition pattern used.Result is returned to the client via Compose Proxy.Figures 8
and 9 show that middle layer is completely accessible via SOAP/JAX-RPC,which
means that any Web service client can use functionalities that it provides.
5.3 Service Directory and Searching
Service directory is realized as MySql database,and is addressed by the middle layer
via JDBC.Therefore,any other relational database can be used instead.There are
several reasons why we used a relational database instead of a native XML database.
Current XML databases still do not support W3C XML schema which we use to
de¯ne CDL.Using native XML database could therefore lead to low data integrity.
Furthermore,XML databases use XPath as query language,and it o®ers no support
for grouping,sorting,cross document joins,and data types.Since service directory
requires complex queries,this is a very limiting implementation factor.Still another
downside is that updating requires retrieving an XML document,modifying it using
own API and then returning it to database.
Database was designed to take full advantage of rich descriptive options o®ered
by CDL in order to overcome UDDI limitations.The basic entity in UDDI is not a
service,but an organization.Services belong to organizations.UDDI o®ers searching
for organizations by name,descriptions (essentially keywords) and classi¯cation.
Only after adequate organization has been found,services belonging to it can also be
searched.There is no way to search for services directly.It is also possible to search
for services belonging to organizations by the names of their WSDL documents.This
all means that using UDDI it is impossible to search for services o®ering certain
operations,accepting certain parameter types or having some other property.
The underlying database schema still retains notion of organizations and services
belonging to organizations,but allows for searching for services directly,using any
combination of properties de¯ned in CDL.That means that it is possible to search
for services by locations,methods they o®er,classi¯cations,and all other properties
de¯ned in their pre-conditions,post-conditions and invariants.One example query
would be to ¯nd all services in the 1 km radius that accept postscript documents
and print them in color with 1200 dpi resolution,free of charge if we can supply
a security credential of certain type.Besides being a clear advantage compared to
UDDI when searching for single services,the ability to performsuch complex queries
is very important when searching for adequate composition partners.
5.4 State Management
Up to now we have been talking about modeling Web services using abstract ma-
chines comprising state variables.It is obvious that we have implicitly assumed
that some services can maintain their state between calls.However,Web services
are stateless and we need to introduce state management mechanism.
Although Web services are inherently stateless,many of them allow for the ma-
nipulation of the state,such as persisting data into databases,¯le systems,or coor-
dinating dependent messages.There is ongoing debate in the community whether
Web services should or should not support state management.One view is that
Web services are not another Object Request Broker architecture,and therefore
should have no notion of state [18],while the other view is that state management
plays the critical role in distributed computing and as such must be addressed at
the architectural level [7].The former point may be true at the fundamental level
of Web services (discovery,description,invocation),but our position is that for the
purpose of complex service interactions the latter view is correct.
Why is state management important?Let us observe a holiday booking scenario
implemented using Web services.One part of the holiday planing is °ight reserva-
tion.Suppose there is a Web service o®ering following Web methods:bookFlight,
modifyReservation and deleteReservation.Although all methods are stateless,
they all interact with stateful resource in the background,e.g.,with a relational
database.The method bookFlight will create a record in the database and return
booking id,modifyReservation will modify a record based on the id passed to
it,while deleteReservation will delete a record.State is implicit here,since all
methods change the underlying persistent resource.We identify two possible ways
to associate a state with a Web service:
{ A conversational service implements a series of operations where result of one
operation depends on the prior operations of the same or other services.The
state is maintained in the logical sequence of messages.
{ A service that acts upon one or more persistent resources (database,¯le),cre-
ating,modifying or deleting it based on the messages it sends or receives.
Since conversational state can be implemented using WS-Coordination and WS-
Context speci¯cations,we concentrate on the interaction with stateful resources.
Furthermore,we consider only relational database as a provider of background
persistent resource.Interaction with persistent resource is described within the
resource element of the CDL (Figure 10).
Fig.10.Description of underlying persistent resource
Resource is identi¯ed by its name,uri,and resource manager (in our case,re-
lational database driver).For each method acting upon a resource,one of the fol-
lowing actions can be de¯ned:CREATE,READ,MODIFY,DELETE.Methods that create
resources return resource identi¯er,while methods that read,modify and delete
resources require resource identi¯er.Finally,resource property de¯nes one or more
CDL elements (state variables) that are bound to the underlying resource.
Our e®orts in providing state management are compatible with the recent WS-
Resource proposal [8],with the main di®erence being that WS-Resource supports
broader range of persistent resources identi¯ed using WS-Addressing.Since we cur-
rently support only databases,resource identi¯er comprising name and uri (actually
server and database name) is enough.However,it will be possible to incorporate
WS-Resource elements into CDL once this speci¯cation is standardized.
6 Conclusion
If Web services are to become the dominant architecture of future distributed sys-
tems,after connectivity is established (standardized) at least two more issues need
to be supported at the architectural level:trustworthiness and automatic business
to business (B2B) interactions.We try to address both in our proposed framework.
We de¯ned trustworthiness not only as security,but as an aggregation of proper-
ties (including but not limited to security) that composition process must guarantee.
Therefore we adopted correctness as a term that best describes a"trustworthy"or
a"trusted"composite Web service.We also identify three roles in the proposed ar-
chitecture:architecture deployer,application developer,and client (user).The task
of architecture deployer is to make sure that all services have well-de¯ned contracts,
set-up contract directory,introduce composition operators,and de¯ne function cor-
rect.Architecture deployer thus sets rules on how to compose correct services and
abstracts notion of correctness from the application developers and clients which
do not need be concerned with it.That way we implement separation of domains
in which correctness is veri¯ed and transpose it from element (service) domain to
architecture domain,which is a desirable property as it both facilitates and en-
forces process of correctness veri¯cation.Application developers can use available
services and compose them in order to build applications while composition frame-
work (architecture) will transparently verify correctness.Finally,clients can search
and consume complex services.
However,composition has still to be performed manually by application de-
veloper,albeit much easier and more °exible than in case of the other existing
approaches as it now consists only of selecting appropriate services and applying
composition operator (pattern).The proposed framework o®ers possibility of true
automatic B2B interactions [2].Formal treatment of composition process enables
use of various search strategies for the purpose of e±cient allocation and veri¯ca-
tion in the process of automatic composition.We aim to provide a framework that
will let developers and users perform everyday chores using composite Web services
without having to worry whether the process will deadlock,eat all the memory,
disclose con¯dential corporate data or send a credit-card number to a villain.
References
1.J.R.Abrial.The B Book.Cambridge University Press,1996.
2.G.Alonso,F.Casati,H.Kuno,and V.Machiraju.Web Services:Concepts,Architec-
tures and Applications.Springer-Verlag,2004.
3.D.Berardi,D.Calvanese,D.G.Giuseppe,M.Lenzerini,and M.Mecella.Automatic
composition of e-services that export their behavior.In Proc.of the 1st Int.Conf.on
Service Oriented Computing (ICSOC 2003),2003.
4.T.Bultan,X.Fu,R.Hull,and J.Su.Conversation Speci¯cation:A New Approach to
Design and Analysis of E-Service Composition.In Proceedings of WWW2003,2003.
5.F.Curbera,R.Khalaf,N.Mukhi,S.Tai,and S.Weerawarana.The Next Step in Web
Services.Communications of the ACM,October 2003.
6.A.Ankolekar et al.DAML-S:Web Service Description for the Semantic Web.In
Proceedings of the International Semantic Web Conference (ISWC),2002.
7.I.Foster et al.Modeling stateful resources with web services.http://www.ibm.com/
developerworks/library/ws-resource/ws-modelingresources.pdf,2004.
8.K.Czajkowski et al.The WS-Resource Framework.http://www.globus.org/wsrf/
specs/ws-wsrf.pdf,2004.
9.X.Fu,T.Bultan,and J.Su.Formal Veri¯cation of E-Services and Work°ows.In Pro-
ceedings of Workshop on"Web Services,e-Business,and the Semantic Web (WES):
Foundations,Models,Architecture,Engineering and Applications",2002.
10.R.Hamadi and B.Benatallah.A Petri Net-based model for Web Service Composi-
tion.In Proceedings of the Fourteenth Australasian database conference on Database
technologies,2003.
11.S.McIlraith and T.C.Son.Adapting Golog for Composition of Semantic Web Ser-
vices.In Proceedings of the International Conference on the Principles of Knowledge
Representation and Reasoning (KRR'02),2002.
12.L.G.Meredith and S.Bjorg.Contracts and Types.Communications of the ACM,46,
No.10,pp 41-47,October 2003.
13.B.Meyer.Applying Design by Contract.IEEE Computer vol.25,no.10,Oct.1992.
14.Sun Microsystems.The Java Web Services Developer Pack.http://java.sun.com/
webservices/downloads/webservicespack.html,2004.
15.N.Milanovic and M.Malek.Current Solutions for Web Service Composition.IEEE
Internet Computing,November/December 2004.
16.N.Milanovic and M.Malek.Extracting Functional and Non-functional Contracts
From Java Classes and Enterprise Java Beans.In Proceedings of the Workshop on
Architecting Dependable Systems (WADS 2004),Florence,Italy,2004.
17.S.Narayanan and S.McIlraith.Simulation,Veri¯cation and Automated Composition
of Web Services.In Proceedings of the International WWW02 Conference,2002.
18.W.Vogels.Web Services are not Distributed Objects:Common Misconceptions about
the Fundamentals of Web Service Technology.IEEE Internet Computing,Novem-
ber/December 2003.
19.J.Yang and M.P.Papazoglou.Web Component:A Substrate for Web Service Reuse
and Composition.In Proceedings of 14th Conference on Advanced Information Systems
Engineering (CAiSE02),Toronto,2002.