The theory of web services
Term Applied To Definition
Behaviour A web service’s behaviour is defined by the set of activities behind that service and
mapping those activities to message exchanges.
Choreography Choreography describes the collective message exchange among interacting Web Services,
providing a global, message-oriented view of the interactions (observing and controlling a
many to many relationship).
Composition A web service composition consists of an orchestration of web service interactions defined
in a local process (itself potentially a service). Static web service compositions are those
which use services known at design time and are bound to a composition at design time.
Dynamic web service compositions those which define web service interactions where the
services are not known at design time, and which are discovered or their properties
resolved based upon a criteria process set at design time.
Interface A service interface is the abstract boundary that a service exposes. It defines the types of
messages and the message exchange patterns that are involved in interacting with the
service, together with any conditions implied by those messages. A web service’s interface
describes the operations provided by that service and biographical information about where
the service may be referenced (e.g. network address).
Orchestration Describes the definition and the implementation of processes that drives the message
exchanges between one or more web services. The BPEL4WS standard refers to
participating services as composition Partners. Interaction is seen between one process and
many services (i.e. one to many).
Problem Domain The functional area of interest, or under control, by individual or groups of (web) services
hosted on the internet and accessible either locally or globally (to other service groups) to
fulfil a task or a series of tasks within the function area.
Service A web service is a software application identified by a URI, whose interfaces and binding
are capable of being defined, described and discovered by XML artefacts and supports
direct interactions with other software applications using XML based messages via
BPEL4WS is mostly the result of work undertaken previously by industry to build such
specifications, such as that from the XLANG (Microsoft Corporation) specification and Web
Service Flow Language (WSFL) by International Business Machines Corporation (IBM).
Whilst BPEL4WS provides an orchestration of web service interactions at a local (single
party) viewpoint, it does not provide a level of coordination between processes or manage
long-running transactions (LRTs). This additional level of specification is encompassed in
the term Choreography. Related specifications for this are still in an early stage of design,
however, the Web Service Choreography Description Language (WS-CDL) (Kavantzas,
Burdett et al. 2004) and Web Service Choreography Interface (WS-CI) (Cabrera, Copeland et
al. 2002) are being marketed as a response to this requirement.
A commonly used definition of a Web Service is taken from the W3C official Description
Working Group specification (W3C-WS 2002) is; “A web service is a software application
identified by a URI, whose interfaces and binding are capable of being defined, described
and discovered by XML artefacts and supports direct interactions with other software
applications using XML based messages via Internet-based protocols.”
Web services behaviour
Web Service Behaviour Analysis can be described as; “Web Service Behaviour Analysis
considers analysing the set of activities behind a service (a composition), and together with
service interactions (choreography), provides an end-to-end view that models the role of
each individual process in the choreography and the activities performed by each role.”
Figure 2-4 WSDL Structure
Web service composition
“A web service composition consists of orchestrated web services through a local process,
itself potentially a service. Static web service compositions are known at design time and
are bound to a composition at design time. Dynamic web service compositions are one or
many compositions in which web services are not known at design time, and which are
discovered or their properties resolved based upon a criteria process set at design time.”
Web Service Choreography
The W3C Web Services Architecture group describe general choreography as “…the
sequence and conditions under which multiple cooperating independent agents exchange
messages in order to perform a task to achieve a goal state.”
Web Service Choreography is more formally described by the W3C Web Services
Choreography Working group as; “….the external observable behaviour across multiple
clients (which are generally Web Services but not exclusively so) in which external
observable behaviour is defined as the presence or absence of messages that are exchanged
between a Web Service and it's clients” (Austin 2004).
Implementations for choreography standards are currently in the form of the Web Service
Choreography Description Language (WS-CDL) (Kavantzas, Burdett et al. 2004) and the
Web Service Choreography Interface (WSCI) (Arkin, Askary et al. 2002). Both of these
specifications have been introduced as part of a service-oriented model aligned with the same
W3C working groups.
The service oriented model
Figure 2-5. Elements and relationships of a Service Oriented Model
Figure 2-6 Elements of SOM for Verification and Validation of Services
A policy is applied to a goal state and a service. Policies are considered into two categories;
that of service permissions and obligations. Permissions are a type of policy that prescribes
the allowed actions and states of an agent or resource. A permission policy refers mainly to
security aspects of a service model, as it is presented as more of a technical constraint rather
than behavioural requirement. We therefore concentrate on the obligation category of policies
as the focus of our analysis context. There appear differing definitions of an obligation in
earlier work. In the PONDER language (Damianou, Dulay et al. 2001) an obligation is
summarised as “…the actions that must be performed by managers within the system when
certain events occur and provide the ability to respond to changing circumstances”, whilst
the W3C (WS-A SOM) defines obligations in terms of the goal states. For example, when a
service provider (or agent in W3C terminology) has an obligation to perform some action,
then it is required to perform that action. When the action is performed successfully, then the
agent can be said to have satisfied its obligations.