Protocols for Web Service Invocation

Christopher D. Walton ∗
Centre for Intelligent Systems and their Applications (CISA),
School of Informatics, University of Edinburgh, UK.
[email protected]

Abstract issues of discovery and invocation of web services. These

The automatic invocation of a web service by an agent is a issues are analogous to the search for, and retrieval of text-
complex task which is currently being addressed by semantic based web pages. Currently, the most popular solution is
markup techniques. However, it is difficult to define the com- the use of a centralised registry, e.g. UDDI or ebXML. The
putational aspects of a web service in this approach. In this registry stores the location of the WSDL specification, and
paper we propose a protocol-based formalism which appears a text-based categorisation of the service. However, the reg-
better suited to a representation of these issues. We define istry must be actively maintained by the owner of the web
the syntax and semantics of a protocol language which ex- service, and the current systems are prone to stale and mis-
press precisely how the interaction with a service should be categorised entries.
performed, and how the service should be invoked. We also
sketch an architecture for the execution of our protocols.
To address the problems of the registry-based approach
to discovery and invocation, there is significant research in-
terest in the use of semantic web techniques in conjunc-
Introduction tion with web services. The semantic web aims to create a
A web service is a software system which utilises machine-readable web, allowing the integration of informa-
inter-operable mechanisms for distributed processing and tion from disparate sources to achieve the goals of end users.
machine-to-machine interaction on the World-Wide-Web. The intention is that this will be achieved through a pro-
Web services are an increasingly important software tech- cess of semantic markup of information. The term semantic
nology. This is evident in the adoption of web services as web service has recently been coined to denote a web ser-
the key programming paradigm for the Grid and the Seman- vice with such semantic markup. This markup is performed
tic Web, and in the implementation of Multi-Agent Systems. using formalisms such as OWL-S (OWL Services Coalition
A web service is essentially a software component which 2004), or WSMO (Roman, Keller, & Lausen 2004).
resides at some fixed location on the web, typically inside a A semantic web service has associated ontological infor-
container on a web server. Interaction with web services is mation which defines properties of the service. For example,
accomplished by remote procedure call (RPC) mechanisms. OWL-S defines three main kinds of properties: the service
The advantage of web services over previous component- profile; the service model; and the service grounding. Infor-
based middle-ware technologies (e.g. CORBA and DCOM) mally, these properties define the description of the service,
is that the protocols are web-oriented and lightweight. Web the task performed by the service, and the concrete reali-
services are principally defined using two key standards: sation of the service respectively. WSMO extends this list
web service interfaces are specified in the Web Service De- with non-functional properties which define features of the
scription Language (WSDL), and communication between service, and goals which define the objectives of the service.
web services is defined by the Simple Object Access Pro- The intention is that the semantic information will be used
tocol (SOAP). In addition, there are many complementary to automate the processes of web service discovery, invo-
standards which extend web services into different domains. cation and composition. Nonetheless, significant challenges
For example, the Open Grid Services Architecture (OGSA- remain in the realisation of these goals.
DAI) extends web services with facilities specific to the In this paper, we focus on the challenges associated with
Grid, such as life-cycle management and Quality-of-Service the automatic invocation of a web service. This automation
guarantees. Similarly, the Business Process Execution Lan- is necessary if the services are to be used by agents which
guage for Web Services (BPEL4WS) extends web services are not under direct human control. We will assume that the
with facilities to support business transactions. appropriate web service has already been discovered, e.g.
In concert with the proliferation of web service technol- through a registry service. Our approach is based on the use
ogy, there has been an increasing focus of attention on the of interaction protocols which define how to interact with
∗
This work is sponsored by the UK Engineering and Physi- a service. Our protocols are intended to be complementary
cal Sciences Research Council (Grant GR/N15764/01) Advanced to the use of both WSDL interface definitions and semantic
Knowledge Technologies (AKT). markup techniques.
 Related Work the web service. Nonetheless, this does not preclude the use
The approach presented in this paper is derived from our ear- of out protocols in conjunction with a service ontology, as
lier work on protocols for performing coordination in Multi- we describe later in the paper.
Agent Systems (Walton 2004b). This work was heavily in-
fluenced by the Electronic Institutions (Esteva et al. 2001) Interaction Protocols
framework for expressing social norms in Multi-Agent Sys- At an intuitive level, the automated invocation of a web ser-
tems, and the π-calculus (Milner 1989) used in the formal vice by an external agent does not appear to be an overly
specification of concurrent systems. The outcome of this complex task. However, there are a surprising number of is-
work was the definition of an executable specification lan- sues that must be addressed to achieve the desired result.
guage of Multi-Agent Protocols, called MAP. This can be demonstrated by considering the example of
The provision of techniques for coordination and chore- a job scheduler interface in Figure 1, which we will use
ography between web services is currently a very active area throughout the paper. The name and argument types of each
of research. We have previously shown how MAP can be operation are specified in the interface, where unit denotes
adapted to perform coordination between groups of web ser- an empty argument list. The information contained in the
vices (Walton & Barker 2004). In this work, our use of pro- interface is in effect the same as in the WSDL definition,
tocols for defining coordination is similar to that of (Singh though we do not use XML syntax here for readability.
et al. 2004). However, by basing our language on the π
calculus, we do not restrict our attention to finite-state mod- initJob : unit → id
els. The π calculus has been previously used as the basis for setSchedule : id × sched → unit
the formalisation of web service choreography (Brogi et al. getSchedule : id → sched
2004), though the focus of this work is on the Web Service setScript : id × script → unit
Choreography Interface (WSCI) proposal. getScript : id → script
One of the key reasons for providing a formalisation of getStatus : id → status
web service interactions it to allow verification to be per- commitJob : id → unit
deleteJob : id → unit
formed. We have previously demonstrated the use of model
checking techniques to ensure the correctness of our proto-
cols (Walton 2004a). A similar approach has been demon- Figure 1: Job Scheduler Interface
strated for web service flows in (Nakajima 2004). Consis-
tency checking for web service interfaces has also been ad- In order to invoke the operations of the job scheduling
dressed in (Beyer, Chakrabarti, & Henzinger 2005). service, we must consider (at least) the following issues. We
In this paper, we take a different view on the coordina- need an intuition as to what each of the operations in the in-
tion problem from before. In our previous work, we defined terface are for, and how they affect the state of the service.
protocols which specified all of the interactions between a There is an implicit ordering of the operations, for example,
group of web services. However, we now focus our at- initJob must be performed at the beginning of the inter-
tention on a single web service, and define the interaction action with the service, and commitJob at the end. We
pattern for this service in isolation. The resulting protocol must also consider the different types which are used by the
can then be used by an external agent to automatically in- operations, for example, what a sched actually comprises.
voke the service. These protocols are considerably simpler There are relationships between the arguments, for example,
to execute and verify than those in the full MAP language. the id returned by initJob is used in the remaining op-
Automatic invocation of services has also been addressed erations. Finally, we need to understand how to obtain and
by planning techniques (Pistore et al. 2004), and by logic- construct appropriate data for each of the arguments.
programming (McIlraith & Son 2002), though we are aim- Many of these issues can be addressed by the use of se-
ing for a more general solution that does not make specific mantic markup. For example, we can specify the task per-
requirements on the underlying technology. formed by each operation, and the knowledge contained in
The main alternative to the approach presented in this pa- the different arguments, through an appropriate ontology.
per is the specification of data flows and parameter bindings However, the issues relating to computation, such the re-
which have recently been included in the OWL-S service lationships among arguments, cannot readily be represented
model. These definitions are intended to express the flow of owing to the lack of variables in the underlying description
data from one process component to another. In principle, logic. For example, in an OWL-S profile we can define the
this should allow invocations patterns to be inferred. How- input of a service with hasInput declarations, but it is
ever, the current definitions are rather cumbersome in nature. not a straightforward process to define the order of these
In particular, the use of continuous data flows, makes it dif- inputs, or distinguish between different inputs of the same
ficult to express dynamic behaviours or discrete events. By type. These issues suggest that a complementary approach
contrast, the definitions that we present in this paper are con- would be desirable for the representation of the computa-
cise and lightweight, and can be readily validated. It is our tional aspects of a service.
opinion that these aspects of a web service are best defined An ideal complement to semantic markup, which spec-
separately from the service ontology, using a more appro- ifies the external behaviour of a service, would be the use
priate formalism. On particular, we can express the func- of algebraic specifications. In this approach, the algebraic
tional dependencies between the operations which comprise specification would define the internal behaviour of a ser-
vice in terms of first-order formulae. Reasoning could then service. For example, Figure 3 illustrates one possible way
be performed on the specification to infer the correct inputs to schedule a job with our interface. In this instance, we
to the service, the dependencies between operations, and the schedule the script alarm.sh to be executed on Monday at
expected outcome. However, this is not the technique that 11:00. The example makes clear the order of the operations,
we adopt in this paper. The primary reason for rejecting this and the dependencies between variables.
approach is the difficulty of generating the specifications. In The real power of the protocol language is in the specifica-
essence, the construction of a specification requires a reim- tion of all possible interactions with a service, rather than a
plementation of a service in a first-order representation. This single interaction. Figure 4 defines a protocol for all possible
would be a difficult and error-prone task for non-trivial ser- interactions with our job scheduler. The protocol expresses
vices. the ordering of the operations and the relationship between
The approach that we adopt in this paper has many of the the arguments. For example, the same variable name s is
advantages of algebraic specification, but does not require used in both setSchedule and getSchedule, indicat-
the laborious construction of first-order specifications. In- ing that they have the same value. The protocol resolves
stead, we take a functional modelling view which is a pop- many ambiguities in the service. For example, initJob
ular approach for the formal description of distributed sys- must be called before any other operations can be used, and
tems. The basic idea is to characterise the input and out- the schedule and script cannot be set after the job is commit-
put relationships of the system without specifying the in- ted. The final step is a choice between deleteJob and the
ternal behaviours. This is commonly called the black-box empty operator e, which makes the deletion optional.
behaviour of a system. We define the input and output be-
haviour of the system using interaction protocols, which are {job:id} = initJob() then
easy to specify and understand. These protocols go far be- setSchedule(job:id, s:sched) then
yond the simple typing information which is present in a setScript(job:id, r:script) then
WSDL specification. commitJob(job:id) then
do ( {s:sched} = getSchedule(job:id) or
p ∈ Protocol ::= {φn = } op(φk ) (Invocation) {r:script} = getScript(job:id) or
| p1 then p2 (Sequence) {t:status} = getStatus(job:id) ) then
| p1 or p2 (Choice) ( deleteJob(job:id) or e )
| do p (Repetition)
|  (Empty) Figure 4: Job Scheduler Protocol
φ ∈ Term ::= c (Literal)
| v (Variable)
It is important to note that the protocol gives us extra in-
formation that cannot simply be inferred by examining the
Figure 2: Interaction Protocol Syntax
interface types of the service. For example, there are five
operations in our job scheduler which take a single id as
Our interaction protocols represent the ordering and de-
input, but there is nothing to distinguish one from another.
pendencies between the operations of a web service. Fig-
In principle, it would be possible to introduce extra types, to
ure 2 defines the abstract syntax for our protocol language,
distinguish between different sequences. However, it is not
which is a simplified dialect of our MAP language for ex-
possible to express iterations in this approach.
pressing web service coordination (Walton 2004a). The lan-
guage describes patterns of invocations, expressed as a pro- We can represent the control flow on a protocol as a non-
tocol p. There are three kinds of control flow in the lan- deterministic finite-state system. Figure 5 illustrates the con-
guage. The then operator expresses a sequential compo- trol flow in our example. This graph is a useful aid to under-
sition of p1 followed by p2 . The or operator expresses a standing the structure of a protocol. However, it should be
non-deterministic choice between p1 and p2 . Finally, the do noted that the graph does not define the dependencies be-
operator expresses zero or more iterations of p. The  op- tween the variables in the protocol. These variables give the
erator is a convenience which expresses an empty protocol system a memory capability and extend the power of the ap-
step. The invocation of an operation op defines the input proach to the expression of infinite-state systems.
arguments φk and the (optional) output arguments φn . The
arguments are terms φ, which are either literal constants c, Protocol Execution
or variable names v.
To illustrate how a protocol can assist in the automatic invo-
{job:id} = initJob() then cation of a web service, we will now outline an architecture
setSchedule(job:id, {mon, 11:00}:sched) then for this purpose. The main components of the architecture
setScript(job:id, {˜/alarm.sh}:script) then are presented in Figure 6. We assume that each web service
commitJob(job:id) then has an associated interface (e.g. WSDL) which defines the
{s:status} = getStatus(job:id)
types of the operations, an ontology (e.g. OWL-S) which re-
lates these types to concepts, and a protocol which defines
Figure 3: Interaction Sequence how the service should be invoked. The web service is in-
voked by an agent which has its own local knowledge base,
A protocol can express a single interaction with a web and can interact with an environment.
 Environment
initJob Protocol 5
1

2
setSchedule Interface Agent
3
4
setScript Ontology

6 KB
Web Service
commitJob

e Figure 6: Execution Architecture

protocol language. The purpose of this semantics is to for-

getSchedule getScript getStatus mally describe the meaning of the different language con-
structs, such that interaction protocols can be interpreted in
a consistent manner. The semantics can also serve as a basis
for the verification of the interaction protocols.
e We have chosen to present this in a relational operational
semantics formalism called natural semantics, so called be-
cause the evaluation of the relations is reminiscent of nat-
deleteJob e
ural deduction. The natural semantics style is convenient
because the entire evaluation can be captured within a (semi-
)compositional derivation that can be reasoned about induc-
Figure 5: Protocol Graph tively. The rules of the semantics can be implemented di-
rectly (e.g. as Prolog Horn-clauses) and a derivation can be
performed incrementally, in a depth-first manner, from the
The automatic invocation process comprises six steps root to the leaves.
which are performed by the agent. The invocation process ∆ ∈ Environment ::= (PE , VE )
is driven by the protocol, which is retrieved in the first step. PE ∈ Operations ::=
map
op 7→ (φkin , φn
out )
The agent follows the protocol until some parameters are re- map
VE ∈ Variables ::= v 7→ φ
quired, at which point (step 2) a lookup is performed on the
interface definition to obtain the types for the parameters.
Subsequently, the ontology for the service is referenced to Figure 7: Evaluation Environment ∆
obtain the concepts relating to these types (step 3). At this
point, the agent consults its own knowledge base to deter- In natural semantics, we define relations between the ini-
mine if it can provide appropriate values for the parameters tial and final states of program fragments. For our proto-
(step 4). If the agent fails to obtain the necessary informa- cols, a program fragment is a part of a protocol p. The state
tion from its own knowledge, the agent will consult the en- is captured by an environment ∆, defined in Figure 7. The
vironment (e.g. other agents) to find an appropriate source environment contains a definition of the operations in the
of knowledge (step 5). If either step 4 or 5 is successful, service PE (i.e. the service interface), and the bound vari-
then the agent can proceed to invoke the service (step 6). ables VE . For brevity we omit the rules for constructing the
However, if appropriate values for the parameters cannot be initial environment, and for checking well-formedness of the
found, the agent must backtrack through the protocol and at- environment from our definition. However, we note that the
tempt a different interaction. If no further interactions can be initial environment will simply contain the input/output pa-
performed, then the protocol execution fails. The behaviour rameters taken directly from the WSDL interface.
of the agent upon protocol failure is beyond the scope of our We define the evaluation rules for the protocols in Fig-
architecture. However, in an implementation, it is likely that ure 8. The form of these rules is ∆ ` p ⇒ ∆0 , where
the agent would refer back to a human user to supply the ∆ is the state at the start of evaluation, p is the proto-
necessary knowledge. col fragment under consideration, and ∆0 is the state on
We now discuss the execution of our protocols at a more completion. We also define a substitution function, ∆ `
formal level. The provision of a clean and unambiguous se- subst(φ) ⇒ φ0 which substitutes variables for terms, and
mantics was a primary consideration in the design of our the unification function ∆ ` unif y(φ1 , φ2 ) ⇒ ∆0 which
 ∆ ` p ⇒ ∆0 φkin with the arguments list φn3 . The unification ensures that
the arguments are a proper match for the input parameters,
and binds any parameter variables to the arguments. The re-
∆`⇒∆ sult of the unification is a new environment ∆0 containing
the newly bound variables. We then evaluate the operation
∆ ` p 1 ⇒ ∆0 op in the new environment, which yields a result environ-
∆0 ` p2 ⇒ ∆00 ment ∆00 . In we have specified any output parameters, then
∆ ` p1 then p2 ⇒ ∆00 another unification step is performed. The end result is the
initial environment composed with any output variables.
∆ ` p 1 ⇒ ∆0
It should now be clear that the semantics define precisely
∆ ` p1 or p2 ⇒ ∆0
the way in which a protocol should be interpreted by an
∆ ` p 2 ⇒ ∆0 agent. This is important as it allows a protocol to be imple-
∆ ` p1 or p2 ⇒ ∆0 mented in a consistent manner. The semantics can also be
used to check an interaction sequence for validity. We can
∆ ` p ⇒ ∆1 · · · ∆k−1 ` p ⇒ ∆k simulate the execution of a protocol execution using these
∆ ` do p ⇒ ∆k rules, without actually invoking any operations. If the pro-
cess terminates, then we know that the sequence is valid.
∆(op) = (φkin , φnout )
∆ ` subst(φk2 ) ⇒ φk3 Conclusion
∆ ` unif y(φkin , φk3 ) ⇒ ∆0
∆0 ` eval(op) ⇒ ∆00 In this paper we have presented a novel protocol based for-
{ ∆00 ` unif y(φn n
out , φ1 ) ⇒ ∆
000
} malism which can represent the computational aspects of a
∆ ` {φn1 = } op(φ k
2 ) ⇒ ∆{∪ ∆ 000
} web service, such as invocation order, and inter-argument
dependencies. It should now be apparent that the protocol
language is a powerful tool for expressing interactions with
∆ ` subst(φ) ⇒ φ0 a web service. A protocol defines the interaction at a level
of detail that goes beyond that currently provided by WSDL
∆ ` subst(c) ⇒ c interface definitions, or semantic markup techniques. How-
∆ ` subst(v) ⇒ ∆(v) ever, our approach is intended to be used in concert with ser-
∆ ` subst(φk ) ⇒ (subst(φ1 ), . . . , subst(φk )) vice ontologies and interface definitions. Through the use of
protocols, we have sufficient information to allow an agent
to invoke the operations of a service in the correct order. Fur-
∆ ` unif y(φ1 , φ2 ) ⇒ ∆0 thermore, given data of the correct type, in the knowledge-
base of the agent, we can readily invoke the service in an
∆ ` unif y(c, c) ⇒ ∆ automatic manner. Our current work is on the automatic
∆ ` unif y(v, c) ⇒ ∆[v 7→ c] generation of protocols using planning and machine learning
∆ ` unif y(φk1 , φk2 ) ⇒ techniques on the services, and the verification of protocols
unif y(φ11 , φ12 ) ∪ · · · ∪ unif y(φk1 , φk2 ) by automated means.

Figure 8: Operational Semantics. References

Beyer, D.; Chakrabarti, A.; and Henzinger, T. 2005. Web
Service Interfaces. In Proceedings of the 14th International
matches terms and binds matching variables. We note that World Wide Web Conference (WWW 2005), 148–159.
the ∆ ` eval(op) ⇒ ∆0 function evaluates the underlying
Brogi, A.; Canal, C.; Pimentel, E.; and Vallecillo, A. 2004.
operation op in the service.
Formalizing Web Services Choreographies. In Proceedings
The majority of the evaluation rules are straightforward. of the 1st International Workshop on Web Services and For-
For example, there are two rules for the or operator, which mal Methods (WS-FM 2004).
express a non-deterministic choice between the first and sec- Esteva, M.; Rodrı́guez, J. A.; Sierra, C.; Garcia, P.; and Ar-
ond protocol fragments in the definition. However, the rule cos, J. L. 2001. On the Formal Specification of Electronic
for invocation requires further explanation. A service invo- Institutions. In Agent-mediated Electronic Commerce (The
cation is defined syntactically as {φn1 = } op(φk2 ), which European AgentLink Perspective), number 1991 in Lecture
means that an operation op is invoked on the arguments φk2 , Notes in Artificial Intelligence, 126–147.
and optionally returns the arguments φn1 . This process is ex-
pressed semantically as follows. In the first step, we lookup McIlraith, S., and Son, T. 2002. Adapting Golog for Com-
the operation op in the environment ∆ to obtain the input and position of Semantic Web Services. In Proceedings of the
output definitions φkin and φnout . We then perform a substitu- 8th International Conference on Principles of Knowledge
tion on the input arguments which yields a new list φn3 . This Representation and Reasoning (KR2002), 482–493.
substitution replaces any variables with their current values Milner, R. 1989. Communication and Concurrency.
from the environment. We then unify the input parameters Prentice-Hall International.
Nakajima, S. 2004. Model-Checking of Safety and Se-
curity Aspects in Web Service Flows. In Proceedings of
the Fourth International Conference on Web Engineering
(ICWE), 488–501.
OWL Services Coalition. 2004. OWL-S: Semantic
Markup for Web Services (Version 1.1). Available at:
www.daml.org/services/.
Pistore, M.; Barbon, F.; Bertoli, P.; Shaparau, D.; and
Traverso, P. 2004. Planning and Monitoring Web Ser-
vice Composition. In Proceedings of the 14th Interna-
tional Conference on Automated Planning and Scheduling
(ICAPS 2004).
Roman, D.; Keller, U.; and Lausen, H. 2004. Web
Service Modelling Ontology (WSMO). Available at:
www.wsmo.org.
Singh, M.; Chopra, A.; Desai, N.; and Mallya, A. 2004.
Protocols for processes: programming in the large for open
systems. ACM SIGPLAN Notices 39(12):73–83.
Walton, C., and Barker, A. 2004. An agent-based e-science
experiment builder. In Proceedings of the 1st International
Workshop on Semantic Intelligent Middleware for the Web
and the Grid.
Walton, C. 2004a. Model Checking Multi-Agent Web Ser-
vices. In Proc. of the 2004 AAAI Spring Symposium on
Semantic Web Services.
Walton, C. 2004b. Multi-Agent Dialogue Protocols. In
Proceedings of the Eighth International Symposium on Ar-
tificial Intelligence and Mathematics.