One can describe Web-service interactions in two ways: as
executable business processes and as abstract business processes.
A executable business process: models an actual behavior of a
participant in a business interaction.
An abstract business process: is a partially specified process
that is not intended to be executed. Contrary to Executable Processes, an
Abstract Process may hide some of the required concrete operational details.
Abstract Processes serve a descriptive role, with more than one possible use
case, including observable behavior and/or process template.
WS-BPEL aims to model the behavior of processes, via a language
for the specification of both Executable and Abstract Business Processes. By
doing so, it extends the Web Services interaction model and enables it to
support business transactions. It also defines an interoperable integration
model that should facilitate the expansion of automated process integration
both within and between businesses. Its development came out of the notion that
programming in the large and programming in the small required different types
WS-Coordination is a Web Services specification developed by BEA
Systems, IBM, and Microsoft and accepted by OASIS Web Services Transaction TC
in its 1.2 version. It describes an extensible framework for providing
protocols that coordinate the actions of distributed applications. Such
coordination protocols are used to support a number of applications, including
those that need to reach consistent agreement on the outcome of distributed
The framework defined in this specification enables an application
service to create a context needed to propagate an activity to other services
and to register for coordination protocols. The framework enables existing
transaction processing, workflow, and other systems for coordination to hide
their proprietary protocols and to operate in a heterogeneous environment.
Additionally WS-Coordination describes a definition of the
structure of context and the requirements for propagating context between
However, this specification isn't enough to coordinate
transactions among web services. It only provides a coordination framework, and
other specifications like WS-Atomic Transaction or WS-BusinessActivity are
needed for this purpose.
Service choreography is a form of service
composition[clarification needed] in which the interaction protocol between
several partner services[clarification needed] is defined from a global
perspective. The intuition underlying the notion of service choreography can be
summarised as follows:
―Dancers dance following a global scenario without a single
point of control"
That is, at run-time each participant in a service choreography
executes its part of it (i.e. its role) according to the behavior of the other
participants. A choreography's role specifies the expected messaging
behavior of the participants that will play it in terms of the sequencing and
timing of the messages that they can consume and produce
Service choreography is better understood through the comparison
with another paradigm of service composition: service orchestration.
On one hand, in service choreographies the logic of the
message-based interactions among the participants are specified from a global
perspective. In service orchestration, on the other hand, the logic is
specified from the local point of view of one single participant, called the
In the service orchestration language BPEL, for example, the
specification of the service orchestration (e.g. the BPEL process file) can be
deployed on the service infrastructure (for example a BPEL execution engine
like Apache ODE).
The deployment of the service orchestration specification
creates the composed service.
In a sense, service choreography and orchestrations are two
flips of the same coin.
On one hand, the roles of a service choreography can be
extracted as service orchestrations through a process called projection.
Through projection it is possible to realize skeletons, i.e.
incomplete service orchestrations that can be used as baselines to realize the
web services that participate to the service choreography.
On the other hand, already existing service orchestrations may
be composed in service choreographies.
Web Service Choreography (WS-Choreography) is a specification by
the W3C defining an XML-based business process modeling language that describes
collaboration protocols of cooperating Web Service participants, in which
services act as peers, and interactions may be long-lived and stateful.
(Orchestration is another term with a very similar, but still different
The main effort to get a choreography, The W3C Web Services
Choreography Working Group, leaving WS-CDL as a Candidate Recommendation.
"Many presentations at the W3C Workshop on Web services of
pointed to the need for a common interface and composition language to help
address choreography. The Web Services Architecture Requirements Working Draft
created by the Web Services Architecture Working Group also lists the idea of
Web service choreography capabilities as a Critical Success Factor, in support
of several different top-level goals for the nascent Web services
The problem of choreography was of great interest to the
industry during that time efforts such as WSCL (Web Service Conversation
Language) and WSCI (Web Service Choreography Interface) were submitted to W3C
and were published as Technical Notes. Moreover complementary efforts were
WS-Policy is a specification that allows web services to use XML
to advertise their policies (on security, quality of service, etc.) and for web
service consumers to specify their policy requirements.
WS-Policy is a W3C recommendation as of September 2007.
WS-Policy represents a set of specifications that describe the
capabilities and constraints of the security (and other business) policies on
intermediaries and end points (for example, required security tokens, supported
encryption algorithms, and privacy rules) and how to associate policies with
services and end points.
If both provider and consumer specify a policy, an effective
policy will be computed which usually consists of the intersection of both
The new policy contains those assertions made by both sides
which do not contradict each other. However, synonymous assertions are
considered incompatible by a policy intersection.
This can easily be explained by the fact that policy
intersection is a syntactic approach, which does not incorporate the semantics
of the assertions. Furthermore it ignores the assertion parameters.
Opposed to what the name might suggest, a policy intersection is
(although quite similar) not a set-intersection.
Web Services Security (WS-Security, WSS) is an extension to SOAP
to apply security to Web services. It is a member of the Web service
specifications and was published by OASIS.
The protocol specifies how integrity and confidentiality can be
enforced on messages and allows the communication of various security token
formats, such as Security Assertion Markup Language (SAML), Kerberos, and
X.509. Its main focus is the use of XML Signature and XML Encryption to provide
2 Use cases
Alternative transport bindings
Reverse proxy/common security token WS-Security
describes three main mechanisms:
How to sign SOAP messages to assure integrity. Signed messages
also provide non-repudiation.
How to encrypt SOAP messages to assure confidentiality. How to
attach security tokens to ascertain the sender's identity.
The specification allows a variety of signature formats,
encryption algorithms and multiple trust domains, and is open to various
security token models, such as:
X.509 certificates, Kerberos tickets,
User ID/Password credentials,
SAML Assertions, and custom-defined tokens.
The token formats and semantics are defined in the associated
WS-Security incorporates security features in the header of a
SOAP message, working in the application layer.
These mechanisms by themselves do not provide a complete
security solution for Web services. Instead, this specification is a building
block that can be used in conjunction with other
Web service extensions and higher-level application-specific
protocols to accommodate a wide variety of security models and security
technologies. In general, WSS by itself does not provide any guarantee of
security. When implementing and using the framework and syntax, it is up to the
implementor to ensure that the result is not vulnerable.
Key management, trust bootstrapping, federation and agreement on
the technical details (ciphers, formats, algorithms) is outside the scope of
If a SOAP intermediary is required, and the intermediary is not
or is less trusted, messages need to be signed and optionally encrypted. This
might be the case of an application-level proxy at a network perimeter that
will terminate TCP connections.
The standard method for non-repudiation is to write transactions
to an audit trail that is subject to specific security safeguards. However, if
the audit trail is not sufficient, digital signatures may provide a better
method to enforce non-repudiation. WS-Security can provide this.
Alternative transport bindings
Although almost all SOAP services implement HTTP bindings, in
theory other bindings such as JMS or SMTP could be used; in this case
end-to-end security would be required. Reverse proxy/common security token
Even if the web service relies upon transport layer security, it
might be required for the service to know about the end user, if the service is
relayed by a (HTTP-) reverse proxy. A WSS header could be used to convey the
end user's token, vouched for by the reverse proxy.
WS-Security adds significant overhead to SOAP processing due to
the increased size of the message on the wire, XML and cryptographic
processing, requiring faster CPUs and more memory and bandwidth.
An evaluation in measured 25 types of SOAP messages of different
size and complexity processed by WSS4J with both WS-Security and
WS-SecureConversation on a Pentium 4/2.8 GHz CPU. Some findings were:
Encryption was faster than signing.
Encryption and signing together were 2–7 times slower than
signing alone and produced significantly bigger documents.
Depending on the type of message, WS-SecureConversation either
made no difference or reduced processing time by half in the best case.
It took less than 10 milliseconds to sign or encrypt up to an array
of 100 kilobytes, but it took about 100~200 to perform the security operations