The current set of Web service specifications [WSDL] [SOAP 1.1] [SOAP 1.2] define protocols for Web service interoperability. Web
services increasingly tie together a number of participants forming large
distributed applications. The resulting activities may have complex structure
and relationships.
The WS-Coordination [WSCOOR] specification
defines an extensible framework for defining coordination types.
This specification provides the definition of two Business Activity
coordination types used to coordinate activities that apply business logic to
handle exceptions that occur during the execution of activities of a business
process. Actions are applied immediately and are permanent. Compensating
actions may be invoked in the event of an error. WS-BusinessActivity defines
protocols that enable existing business process and work flow systems to wrap
their proprietary mechanisms and interoperate across trust boundaries and
different vendor implementations.
To understand the protocols described in this specification,
the following assumptions are made:
·
The reader is familiar with the WS-Coordination [WSCOOR] specification which defines the framework for the
Business Activity coordination protocols.
·
The reader is familiar with WS-Addressing [WSADDR]
and WS-Policy [WSPOLICY].
Business activities have the following characteristics:
·
A business activity may consume many resources over a long
duration.
·
There may be a significant number of atomic transactions
involved.
·
Individual tasks within a business activity can be seen prior to
the completion of the business activity, their results may have an impact
outside of the computer system.
·
Responding to a request may take a very long time. Human
approval, assembly, manufacturing, or delivery may have to take place before a
response can be sent.
·
In the case where a business exception requires an activity to be
logically undone, abort is typically not sufficient. Exception handling
mechanisms may require business logic, for example in the form of a
compensation task, to reverse the effects of a previously completed task.
·
Participants in a business activity may be in different domains
of trust where all trust relationships are established explicitly.
The Business Activity protocols defined in this
specification have the following design points:
·
All state transitions are reliably recorded, including
application state and coordination metadata.
·
All non-terminal notifications are acknowledged in the protocol
to ensure a consistent view of state between the coordinator and participant. A
coordinator or participant may solicit the status of its partner or retry
sending notifications in order to achieve this.
·
Each notification is defined as an individual message. Transport
level request/response retry and time out are not sufficient mechanisms to
achieve end-to-end agreement coordination for long-running activities.
Business Activity coordination protocols provide the
following flexibility:
·
A business application may be partitioned into business activity
scopes. A business activity scope is a business task consisting of a
general-purpose computation carried out as a bounded set of operations on a
collection of Web services that require a mutually agreed outcome. There may be
any number of hierarchical nesting levels. Nested scopes:
–
Allow a business application to select which child tasks are included in
the overall outcome processing. For example, a business application might
solicit an estimate from a number of suppliers and choose a quote or bid based
on lowest-cost.
–
Allow a business application to catch an exception thrown by a child
task, apply an exception handler, and continue processing even if something
goes wrong. When a child completes its work, it may be associated with a
compensation that is registered with the parent activity.
·
A participant task within a business activity may specify that it
is leaving a business activity. This provides the ability to exit a business
activity and allows business programs to delegate processing to other scopes. The
participant list is dynamic and a participant may exit the protocol at any time
without waiting for the outcome of the protocol.
·
The Business Activity coordination protocols allow a participant
task within a business activity to specify its outcome directly without waiting
for solicitation. Such a feature is generally useful when
·
A task fails so that the notification can be used by a business
activity exception handler to modify the goals and drive processing in a timely
manner.
·
The Business Activity coordination protocols allow participants
in a coordinated business activity to perform "tentative" operations
as a normal part of the activity. The result of such "tentative"
operations may become visible before the activity is complete and may require
business logic to run in the event that the operation needs to be compensated.
Such a feature is critical when the joint work of a business activity requires
many operations performed by independent services over a long period of time.
By using the XML [XML],SOAP [SOAP 1.1] [SOAP 1.2] and WSDL [WSDL]
extensibility model, SOAP-based and WSDL-based specifications are designed to
work together to define a rich Web services environment. As such, WS-BusinessActivity
by itself does not define all features required for a complete solution.
WS-BusinessActivity is a building block used with other specifications of Web
services (e.g., WS-Coordination [WSCOOR],
WS-Security [WSSec]) and application-specific
protocols that are able to accommodate a wide variety of coordination protocols
related to the coordination actions of distributed applications.
1.3 Terminology
The uppercase key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”,
“SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in
this document are to be interpreted as described in RFC2119 [RFC2119].
This specification uses an informal syntax to describe the
XML grammar of the XML fragments below:
·
The syntax appears
as an XML instance, but the values indicate the data types instead of values.
·
Element names
ending in "..." (such as <element.../> or <element...>)
indicate that elements/attributes irrelevant to the context are being omitted.
·
Attributed names
ending in "..." (such as name=...) indicate that the values are
specified below.
·
Grammar in bold
has not been introduced earlier in the document, or is of particular interest
in an example.
·
<!--
description --> is a placeholder for elements from some "other" namespace
(like ##other in XSD).
·
Characters are
appended to elements, attributes, and <!-- descriptions --> as follows:
"?" (0 or 1), "*" (0 or more), "+" (1 or more).
The characters "[" and "]" are used to indicate that
contained items are to be treated as a group with respect to the "?",
"*", or "+" characters.
·
The XML namespace
prefixes (defined below) are used to indicate the namespace of the element
being defined.
·
Examples starting
with <?xml contain enough information to conform to this specification;
others examples are fragments and require additional information to be
specified in order to conform.
1.4 Namespace
The XML namespace [XML-ns] URI that MUST be used by implementations of this specification is:
http://docs.oasis-open.org/ws-tx/wsba/2006/06
The following namespaces are used in this
document:
1.5 XSD and WSDL Files
Dereferencing the XML namespace defined in section 1.4 will produce the Resource Directory
Description Language (RDDL) [RDDL] document that
describes this namespace, including the XML schema [XML-Schema1]
[XML-Schema2] and WSDL [WSDL]
declarations associated with this specification.
SOAP bindings for the WSDL [WSDL],
referenced in the RDDL [RDDL] document, MUST use
"document" for the style attribute.
There should be no inconsistencies found between any of the
normative text within this specification, the normative outlines, the XML
Schema definitions, and the WSDL descriptions, and so no general precedence
rule is defined. If an inconsistency is observed then it should be reported as
a comment on the specification as described in the "Status" section
above.
The protocol elements define various extensibility points
that allow other child or attribute content. Additional children and/or
attributes MAY be added at the indicated extension points but MUST NOT
contradict the semantics of the parent and/or owner, respectively. If a
receiver does not recognize an extension, the receiver SHOULD ignore the
extension.
An implementation is not conformant with this specification
if it fails to satisfy one or more of the MUST or REQUIRED level requirements
defined herein. A SOAP Node MUST NOT use elements and attributes of the
declared XML Namespace (listed on the title page) for this specification within
SOAP Envelopes unless it is conformant with this specification.
1.8 Normative References
[RDDL] Jonathan Borden, Tim Bray, eds. “Resource Directory
Description Language (RDDL) 2.0”, http://www.openhealth.org/RDDL/20040118/rddl-20040118.html,
January 2004.
[RFC2119] S.
Bradner, “Key words for use in RFCs to Indicate Requirement Levels”, http://www.ietf.org/rfc/rfc2119.txt,
IETF RFC 2119, March 1997.
[SOAP 1.1] W3C Note,
"SOAP: Simple Object Access Protocol 1.1," http://www.w3.org/TR/2000/NOTE-SOAP-20000508/,
08 May 2000.
[SOAP 1.2] W3C Recommendation, "SOAP Version 1.2 Part 1: Messaging Framework
(Second Edition)", http://www.w3.org/TR/2007/REC-soap12-part1-20070427/,
April 2007.
[XML] W3C
Recommendation, "Extensible Markup Language (XML) 1.0 (Fourth Edition),"http://www.w3.org/TR/2006/REC-xml-20060816,
16 August 2006.
[XML-ns] W3C
Recommendation, "Namespaces in XML 1.0 (Second Edition)," http://www.w3.org/TR/2006/REC-xml-names-20060816,
16 August 2006.
[XML-Schema1] W3C Recommendation,
"XML Schema Part 1: Structures Second Edition," http://www.w3.org/TR/2004/REC-xmlschema-1-20041028,
28 October 2004.
[XML-Schema2] W3C Recommendation,
"XML Schema Part 2: Datatypes Second Edition," http://www.w3.org/TR/2004/REC-xmlschema-2-20041028,
28
October 2004.
[WSCOOR] OASIS Public Review
Draft, Web Services Coordination (WS-Coordination) 1.2, http:/docs.oasis-open.org/ws-tx/wscoor/2006/06,
August 2008
[WSDL] Web Services
Description Language (WSDL) 1.1 "http://www.w3.org/TR/2001/NOTE-wsdl-20010315"
[WSADDR] Web Services
Addressing (WS-Addressing) 1.0, W3C Recommendation, http://www.w3.org/2005/08/addressing
[WSPOLICY] W3C Recommendation,
Web Services Policy 1.5 – Framework (WS-Policy), http://www.w3.org/TR/2007/REC-ws-policy-20070904/,
September 2007.
[WSPOLICYATTACH] W3C Recommendation,
Web Services Policy 1.5 – Attachment (WS-PolicyAttachment, http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/,
September 2007.
[WSSec] OASIS
Standard, March 2004, "Web Services Security 1.0: SOAP Message Security
1.0 (WS-Security 2004), "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
OASIS
Standard, February 2006, Web Services Security: SOAP Message Security 1.1
(WS-Security 2004), http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf.
[WSSecPolicy] OASIS Committee Draft 01,
WS-SecurityPolicy 1.3, http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802,
July 2008.
[WSSecConv] OASIS Committee Draft 01, WS-SecureConversation 1.4, http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512,
July 2008.
[WSTrust] OASIS Committee
Draft 01, WS-Trust 1.4, http://docs.oasis-open.org/ws-sx/ws-trust/200802,
June 2008.
2 Business
Activity Context
This section describes the Business Activity usage of
WS-Coordination protocols.
WS-BusinessActivity
builds on WS-Coordination [WSCOOR], which defines an
Activation service, a Registration service, and a CoordinationContext type.
Example message flows and a complete description of creating and registering
for coordinated activities is found in WS-Coordination [WSCOOR].
The Business Activity coordination context is a
CoordinationContext type with a coordination type defined in this
specification. Business Activity application messages that propagate a
coordination context MUST use a Business Activity coordination context. If
these application messages use a SOAP binding, the Business Activity
coordination context MUST flow as a SOAP header in the message.
WS-BusinessActivity adds the following semantics to the
CreateCoordinationContext operation on the Activation service:
·
If the request includes the CurrentContext element, the target
coordinator is interposed as a subordinate to the coordinator stipulated inside
the CurrentContext element.
·
If the request does not include a CurrentContext element, the
target coordinator creates a new activity and acts as the root.
A coordination context MAY have an Expires element. This
element specifies the period, measured from the point in time at which the
context was first created or received, after which a business activity MAY be
terminated solely due to its length of operation. From that point forward, the
coordinator MAY elect to unilaterally cancel or compensate the activity, as
appropriate, so long as it has not made a close decision. Similarly, a participant
MAY elect to exit the activity so long as it has not already decided to complete.
A coordination context MAY have additional elements for
extensibility.
3 Coordination
Types and Protocols
Business Activities support two coordination types and two
protocol types. Either protocol type MAY be used with either coordination
type.
One of the following two URIs MUST be used to specify a
Business Activity CoordinationContext type:
http://docs.oasis-open.org/ws-tx/wsba/2006/06/AtomicOutcome
http://docs.oasis-open.org/ws-tx/wsba/2006/06/MixedOutcome
A coordinator for an AtomicOutcome coordination type MUST
direct all participants either to close or to compensate. A coordinator for a
MixedOutcome coordination type MUST direct all participants to an outcome but MAY
direct each individual participant to close or compensate. All Business
Activity coordinators MUST implement the AtomicOutcome coordination type. A Business
Activity coordinator MAY implement the MixedOutcome coordination type.
The Coordination protocols for business activities are
summarized below with names relative to the wsba base name:
·
BusinessAgreementWithParticipantCompletion: A participant
registers for this protocol with its coordinator, so that its coordinator can
manage it. A participant knows when it has completed all work for a business
activity.
·
BusinessAgreementWithCoordinatorCompletion: A participant
registers for this protocol with its coordinator, so that its coordinator can
manage it. A participant relies on its coordinator to tell it when it has
received all requests to perform work within the business activity.
The correct operation of the protocols requires that a
number of preconditions must be established prior to the processing:
- The source SHOULD have knowledge of the destination's
policies, if any, and the source SHOULD be capable of formulating messages
that adhere to this policy.
- If a secure exchange of messages is required, then the
source and destination MUST have appropriate security credentials (such as
transport-level security credentials or security tokens) in order to
protect messages.
3.2 BusinessAgreementWithParticipantCompletion
Protocol
The state diagram in Figure 1 illustrates the abstract behavior of the protocol between a coordinator and a
participant. The states in the Figure 1 reflect the view
an individual participant or coordinator has of its state in the protocol at a
given point in time. As messages take time to be delivered, the views of the
coordinator and a participant may temporarily differ. Omitted are details such
as resending of messages or the exchange of error messages due to protocol
error. Refer to Appendix B: State Tables for the
Agreement Protocols for a detailed description of this protocol.
Participants that register for this protocol MUST use the
following protocol identifier:
http://docs.oasis-open.org/ws-tx/wsba/2006/06/ParticipantCompletion
Figure 1: BusinessAgreementWithParticipantCompletion
abstract state diagram
The coordinator accepts:
Completed
Upon receipt of this notification, the coordinator knows
that the participant has completed all processing related to the protocol
instance. For the next protocol message the coordinator MUST send a Close or
Compensate notification to indicate the final outcome of the protocol instance.
After sending the Completed notification, a participant MUST NOT participate in
any further work under that activity.
Fail
Upon receipt of this notification, the coordinator knows
that the participant has failed during the Active, Canceling or Compensating
states; the state of the work performed by the participant is undetermined. For
the next protocol message the coordinator MUST send a Failed notification. This
notification carries a QName defined in schema indicating the cause of the failure.
Compensated
After transmitting this notification, the participant SHOULD
forget about the activity. Upon receipt of this notification, the coordinator knows
that the participant has successfully compensated all processing related to the
protocol instance; the coordinator SHOULD forget its state about that
participant.
Closed
After transmitting this notification, the participant SHOULD
forget about the activity. Upon receipt of this notification, the coordinator
knows that the participant has finalized the protocol instance successfully;
the coordinator SHOULD forget its state about that participant.
Canceled
After transmitting this notification, the participant SHOULD
forget about the activity. Upon receipt of this notification, the coordinator
knows that the participant has successfully canceled all processing related to
the protocol instance; the coordinator SHOULD forget its state about that
participant.
Exit
Upon receipt of this notification, the coordinator knows
that the participant will no longer participate in the business activity, and any
pending work was discarded by the participant and any work performed by the
participant related to the protocol instance was successfully canceled. For
the next protocol message the coordinator MUST send an Exited notification. The
Exit message MAY be sent by a participant only from the Active or Completing
states.
CannotComplete
Upon receipt of this notification, the coordinator knows
that the participant has determined that it cannot successfully complete all
processing related to the protocol instance. Any pending work was discarded by
the participant and any work performed by the participant related to the protocol
instance was successfully canceled. For the next protocol message the
coordinator MUST send a NotCompleted notification. After sending the
CannotComplete notification, a participant MUST NOT participate in any further
work under that activity. The CannotComplete message MAY be sent by a
participant only from the Active state.
The participant accepts:
Close
Upon receipt of this notification, the participant knows
the protocol instance is to be ended successfully. For the next protocol
message the participant MUST send a Closed notification to end the protocol
instance.
Cancel
Upon receipt of this notification, the participant knows
that the work being done has to be canceled. For the next protocol message, the
participant MUST send either a Canceled or Fail message. A Canceled message SHOULD
be sent by the participant if the work is successfully canceled; this also ends
the protocol instance. A Fail message SHOULD be sent by the participant if the
work was not successfully canceled.
Compensate
Upon receipt of this notification, the participant knows
that the work being done should be compensated. For the next protocol message
the participant MUST send a Compensated or Fail notification. A Compensated
message SHOULD be sent by the participant if the work is successfully
compensated; this also ends the protocol instance. A Fail message SHOULD be
sent by the participant if the work was not successfully compensated.
Failed
After transmitting this notification, the coordinator SHOULD
forget about the participant. Upon receipt of this notification, the
participant knows that the coordinator is aware of a failure and no further
actions are required of the participant; the participant SHOULD forget the
activity.
Exited
After transmitting this notification, the coordinator SHOULD
forget about the participant. Upon receipt of this notification, the
participant knows that the coordinator is aware the participant will no longer
participate in the activity; the participant SHOULD forget the activity.
NotCompleted
After transmitting this notification, the coordinator SHOULD
forget about the participant. Upon receipt of this notification, the
participant knows that the coordinator is aware that the participant cannot
complete all processing related to the protocol instance and that the
participant will no longer participate in the activity; the participant SHOULD
forget the activity.
Both the coordinator and participant accept:
GetStatus
This message requests the current state of a coordinator or
participant. In response the coordinator or participant returns a Status
message containing a QName indicating which column of the state table [Appendix B: State Tables for the Agreement Protocols]
the coordinator or participant is currently in. GetStatus never provokes a
state change.
For example, a coordinator that is waiting for a
participant to initiate the BusinessAgreementWithParticipantCompletion may use
this message to confirm that the participant is in one of the expected states:
wsba:Active or wsba:Completed. If the participant has forgotten the activity
the Status response MUST be wsba:Ended.
Status
This message is received in response to a GetStatus
request. The message includes a QName indicating the state of the coordinator
or participant to which the request was sent. For example, if a participant is
in the closing state as indicated by the state table, it would return
wsba:Closing.
The coordinator may enter a condition in which it has sent a
protocol message and it receives a protocol message from the participant that
is consistent with the former state, not the current state. In this case, the
coordinator MUST revert to the prior state, accept the notification from the
participant, and continue the protocol from that point. If the participant
detects this condition, it MUST discard the inconsistent protocol message from
the coordinator.
A party MUST be prepared to receive duplicate notifications.
If a duplicate message is received it MUST be treated as specified in the state
tables [Appendix B: State Tables for the Agreement
Protocols].
The BusinessAgreementWithCoordinatorCompletion protocol is
the same as the BusinessAgreementWithParticipantCompletion protocol, except
that a participant relies on its coordinator to tell it when it has received
all requests to do work within the business activity.
Participants that register for this protocol MUST use the
following protocol identifier:
http://docs.oasis-open.org/ws-tx/wsba/2006/06/CoordinatorCompletion
Figure 2: BusinessAgreementWithCoordinatorCompletion
abstract state diagram
The BusinessAgreementWithCoordinatorCompletion protocol
redefines the following notifications in Section 3.2 above:
The coordinator accepts:
Fail
Upon receipt of this notification, the coordinator knows
that the participant has failed during the Active, Canceling, Completing or
Compensating states; the state of the work performed by the participant is
undetermined. For the next protocol message the coordinator MUST send a Failed
notification. This notification carries a QName defined in schema indicating
the cause of the failure.
CannotComplete
Upon receipt of this notification, the coordinator knows
that the participant has determined that it cannot successfully complete all
processing related to the protocol instance. Any pending work was discarded by
the participant and any work performed by the participant related to the
protocol instance was successfully canceled. For the next protocol message the
coordinator MUST send a NotCompleted notification. After sending the
CannotComplete notification, a participant MUST NOT participate in any further
work under that activity. The CannotComplete message MAY be sent by a
participant only from the Active or Completing states.
In addition to the notifications in Section 3.2 above, the BusinessAgreementWithCoordinatorCompletion protocol adds the following notification:
The participant accepts:
Complete
Upon receipt of this notification the participant knows
that it will receive no new requests for work within the business activity. The
participant completes application processing and if successful MUST transmit a
Completed notification. If unsuccessful the participant MUST transmit an Exit,
Fail, or CannotComplete notification.
WS-Policy Framework [WSPOLICY] and WS-Policy Attachment [WSPOLICYATTACH] collectively define a
framework, model and grammar for expressing the capabilities, requirements, and
general characteristics of entities in an XML Web services-based system. To
enable a Web service to describe Business Activity related capabilities and
requirements of a service and its operations, this specification defines a pair
of Business Agreement policy assertions that leverage the WS-Policy framework [WSPOLICY].
The Business Activity policy assertions are
provided by a Web service to qualify the Business Activity related processing
of messages associated with the particular operation to which the assertions
are scoped. The Business Activity policy assertions indicate:
·
Whether the sender of an input message MAY or
MUST include an AtomicOutcome coordination context flowed with the message. The
coordination type of such a context MUST be the following:
http://docs.oasis-open.org/ws-tx/wsba/2006/06/AtomicOutcome
·
Whether the sender of an input message MAY or MUST include a
MixedOutcome coordination context flowed with the message. The coordination
type of such a context MUST be the following:
http://docs.oasis-open.org/ws-tx/wsba/2006/06/MixedOutcome
The normative outlines for the Business Activity policy
assertions are:
<wsba:BAAtomicOutcomeAssertion
[wsp:Optional="true"]? ... >
...
</wsba:BAAtomicOutcomeAssertion>
The following describes additional, normative constraints on
the outline listed above:
/wsba:BAAtomicOutcomeAssertion
A policy assertion that specifies that the sender of an
input message MUST include a coordination context for a Business Activity with
AtomicOutcome coordination type flowed with the message. From the perspective
of the requester, the target service that processes the activity MUST behave as
if it had participated in the activity. For application messages that use a
SOAP binding, the Business Activity coordination context MUST flow as a SOAP
header in the message.
/wsba:
BAAtomicOutcomeAssertion/@wsp:Optional="true"
Per WS-Policy [WSPOLICY], this
is compact notation for two policy alternatives, one with and one without the
assertion.
<wsba:BAMixedOutcomeAssertion
[wsp:Optional="true"]? ... >
...
</wsba:BAMixedOutcomeAssertion>
The following describes additional, normative constraints on
the outline listed above:
/wsba:BAMixedOutcomeAssertion
A policy assertion that specifies that the sender of an
input message MUST include a coordination context for a Business Activity with
MixedOutcome coordination type flowed with the message. From the perspective of
the requester, the target service that processes the activity MUST behave as if
it had participated in the activity. For application messages that use a SOAP
binding, the Business Activity coordination context MUST flow as a SOAP header
in the message.
/wsba:
BAMixedOutcomeAssertion/@wsp:Optional="true"
Per WS-Policy [WSPOLICY], this
is compact notation for two policy alternatives, one with and one without the
assertion.
Policy assertions defined in this specification MUST NOT
include a wsp:Ignorable attribute with a value of “true”.
Because the Business Activity policy
assertions indicate Business Activity related behavior for a single operation,
the assertions have an Operation Policy Subject [WSPOLICYATTACH].
WS-PolicyAttachment [WSPOLICYATTACH] defines two WSDL [WSDL] policy attachment points with an Operation
Policy Subject:
·
wsdl:portType/wsdl:operation – A policy
expression containing a Business Activity policy assertion MUST NOT be attached
to a wsdl:portType; the Business Activity policy assertions specify a concrete
behavior whereas the wsdl:portType is an abstract construct.
·
wsdl:binding/wsdl:operation – A policy
expression containing a Business Activity policy assertion SHOULD be attached
to a wsdl:binding.
An example use of the Business Activity
policy assertion follows:
(01) <wsdl:definitions
(02) targetNamespace="hotel.example.com"
(03) xmlns:tns="hotel.example.com"
(04) xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
(05) xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
(06) xmlns:wsba="http://docs.oasis-open.org/ws-tx/wsba/2006/06"
(07) xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd" >
(08) <wsp:Policy wsu:Id="BAAtomicPolicy" >
(09) <wsba:BAAtomicOutcomeAssertion/>
(10) <!-- omitted assertions -->
(11) </wsp:Policy>
(12) <!-- omitted elements -->
(13) <wsdl:binding name="HotelBinding"
type="tns:HotelPortType" >
(14) <!-- omitted elements -->
(15) <wsdl:operation name="ReserveRoom" >
(16) <wsp:PolicyReference URI="#BAAtomicPolicy" wsdl:required="true"/>
(17) <!-- omitted elements -->
(18) </wsdl:operation>
(19) </wsdl:binding>
(20) </wsdl:definitions>
Lines (8-11) are a policy expression that
includes a Business Activity policy assertion (Line 9) to indicate that a
coordination context for a Business Activity with an AtomicOutcome, expressed
in WS-Coordination [WS-COOR] format, MUST be used.
Lines (13-19) are a WSDL [WSDL] binding. Line (16) indicates that
the policy in Lines (8-11) applies to this binding, specifically indicating
that a coordination context for a Business Activity with an AtomicOutcome MUST
flow inside “ReserveRoom” messages.
It is strongly RECOMMENDED that the
communication between services be secured using the mechanisms described in
WS-Security [WSSec]. In
order to properly secure messages, the body and all relevant headers need to be
included in the signature. Specifically, the <wscoor:CoordinationContext>
header needs to be signed with the body and other key message headers in order
to "bind" the two together.
In the event that a participant
communicates frequently with a coordinator, it is RECOMMENDED that a security
context be established using the mechanisms described in WS-Trust [WSTrust] and WS-SecureConversation [WSSecConv] allowing for potentially more
efficient means of authentication.
It is common for communication with
coordinators to exchange multiple messages. As a result, the usage profile is
such that it is susceptible to key attacks. For this reason it is strongly
RECOMMENDED that the keys be changed frequently. This "re-keying" can
be effected a number of ways. The following list outlines four common
techniques:
·
Attaching a nonce to each message and using it
in a derived key function with the shared secret
·
Using a derived key sequence and switch
"generations"
·
Closing and re-establishing a security context
(not possible for delegated keys)
·
Exchanging new secrets between the parties (not
possible for delegated keys)
It should be noted that the mechanisms
listed above are independent of the Security Context Token (SCT) and secret
returned when the coordination context is created. That is, the keys used to
secure the channel may be independent of the key used to prove the right to
register with the activity.
The security context MAY be re-established using the mechanisms described in WS-Trust [WSTrust] and WS-SecureConversation [WSSecConv]. Similarly, secrets MAY be exchanged using the mechanisms described in WS-Trust [WSTrust]. Note, however, that the
current shared secret SHOULD NOT be used to encrypt the new shared secret.
Derived keys, the preferred solution from this list, MAY be specified using the
mechanisms described in WS-SecureConversation [WSSecConv].
The following list summarizes common
classes of attacks that apply to this protocol and identifies the mechanism to
prevent/mitigate the attacks:
·
Message alteration – Alteration is prevented by including signatures of the message
information using WS-Security [WSSec].
·
Message disclosure – Confidentiality is preserved by encrypting sensitive data using
WS-Security [WSSec].
·
Key integrity –
Key integrity is maintained by using the strongest algorithms possible (by
comparing secured policies – see WS-Policy [WSPOLICY] and WS-SecurityPolicy [WSSecPolicy]).
·
Authentication –
Authentication is established using the mechanisms described in WS-Security [WSSec] and WS-Trust [WSTrust]. Each message is authenticated
using the mechanisms described in WS-Security [WSSec].
·
Accountability –
Accountability is a function of the type of and string of the key and
algorithms being used. In many cases, a strong symmetric key provides
sufficient accountability. However, in some environments, strong PKI signatures
are required.
·
Availability –
Many services are subject to a variety of availability attacks. Replay is a
common attack and it is RECOMMENDED that this be addressed as described in the
next bullet. Other attacks, such as network-level denial of service attacks are
harder to avoid and are outside the scope of this specification. That said,
care should be taken to ensure that minimal processing be performed prior to
any authenticating sequences.
·
Replay – Messages
may be replayed for a variety of reasons. To detect and eliminate this attack,
mechanisms should be used to identify replayed messages such as the
timestamp/nonce outlined in WS-Security [WSSec]. Alternatively, and optionally, other technologies, such as
sequencing, can also be used to prevent replay of application messages.
The protocols defined in WS-BusinessActivity
use a "one way" message exchange pattern consisting of a sequence of
notification messages between a coordinator and a participant. There are two
types of notification messages used
in these protocols:
·
A notification message is a terminal message
when it indicates the end of a coordinator/participant relationship. Closed,
Compensated, Canceled, Exited, NotCompleted and Failed
are terminal messages as are the protocol faults defined in WS-Coordination [WSCOOR].
·
A notification message is a non-terminal message
when it does not indicate the end of a coordinator/participant relationship. Complete,
Completed, Close, Compensate, Cancel, Exit,
CannotComplete and Fail are non-terminal messages.
The following statements define addressing
interoperability requirements for the respective Business Activity message
types:
Non-terminal notification messages
- MUST include a [source endpoint] property
whose [address] property is not set to ‘http://www.w3.org/2005/08/addressing/anonymous’
or 'http://www.w3.org/2005/08/addressing/none’
Both terminal and non-terminal notification
messages
- MUST include a [reply endpoint] property
whose [address] property is set to 'http://www.w3.org/2005/08/addressing/none’
Notification messages used in WS-BusinessActivity protocols MUST
include as the [action] property an action URI that consists of the wsba
namespace URI concatenated with the "/" character and the element
name of the message. For example:
http://docs.oasis-open.org/ws-tx/wsba/2006/06/Complete
Notification messages are normally addressed
according to section 3.3 of WS-Addressing 1.0 – Core [WSADDR] by both coordinators and
participants using the Endpoint References initially obtained during the
Register-RegisterResponse exchange. If a [source endpoint] property is present
in a notification message, it MAY be used by the recipient. Cases exist where a
coordinator or participant has forgotten an activity that is completed and needs
to respond to a resent protocol message. In such cases, the [source endpoint]
property SHOULD be used as described in section 3.3 of WS-Addressing 1.0 -–
Core [WSADDR]. Permanent
loss of connectivity between a coordinator and a participant in an in-doubt
state can result in data corruption.
Protocol faults raised by a coordinator or participant
during the processing of a notification message are terminal notifications and
MUST be composed using the same mechanisms as other terminal notification
messages.
All messages are delivered using
connections initiated by the sender.
This document is based on initial contribution to OASIS
WS-TX Technical Committee by the following authors: Luis Felipe Cabrera (Microsoft),
George Copeland (Microsoft), Max Feingold (Microsoft), Robert W Freund (Hitachi),
Tom Freund (IBM), Sean Joyce (IONA), Johannes Klein (Microsoft), David
Langworthy (Microsoft), Mark Little (JBoss Inc.), Frank Leymann (IBM), Eric
Newcomer (IONA), David Orchard (BEA Systems), Ian Robinson (IBM), Tony Storey (IBM),
Satish Thatte (Microsoft).
The following individuals have provided invaluable input
into the initial contribution: Francisco Curbera (IBM), Doug Davis (IBM), Gert
Drapers (Microsoft), Don Ferguson (IBM), Kirill Gavrylyuk (Microsoft), Dan
House (IBM), Oisin Hurley (IONA), Thomas Mikalsen (IBM), Jagan Peri (Microsoft),
John Shewchuk (Microsoft), Stefan Tai (IBM).
The following individuals were members of the committee
during the development of this specification:
Participants:
Charlton Barreto, Adobe Systems, Inc.
Martin Chapman, Oracle
Kevin Conner, JBoss Inc.
Paul Cotton, Microsoft Corporation
Doug Davis, IBM
Colleen Evans, Microsoft Corporation
Max Feingold, Microsoft Corporation
Thomas Freund, IBM
Robert Freund, Hitachi, Ltd.
Peter Furniss, Choreology Ltd.
Marc Goodner, Microsoft Corporation
Alastair Green, Choreology Ltd.
Daniel House, IBM
Ram Jeyaraman, Microsoft Corporation
Paul Knight, Nortel Networks Limited
Mark Little, JBoss Inc.
Jonathan Marsh, Microsoft Corporation
Monica Martin, Sun Microsystems
Joseph Fialli, Sun Microsystems
Eric Newcomer, IONA Technologies
Eisaku Nishiyama, Hitachi, Ltd.
Alain Regnier, Ricoh Company, Ltd.
Ian Robinson, IBM
Tom Rutt, Fujitsu Limited
Andrew Wilkinson, IBM
B.
State Tables for the Agreement Protocols
The following state tables show state transitions that occur
in the receiver when a protocol message is received or in the sender when a
protocol message is sent.
Each cell in the tables uses the following convention:
|
Legend
|
|
Action to take
Next state
|
Each state supports a number of possible events. Expected
events are processed by taking the prescribed action and transitioning of the
next state. Unexpected protocol messages MUST result in a fault message as
defined in the state tables. These faults MUST use a standard fault code
defined in WS‑Coordination [WS-COOR].
The following rules need to be applied when reading the
state tables in this document:
·
For the period of time that a protocol message is in transit the
sender and recipient states will be different.
The sender of a protocol message
transitions to the "next state" when the message is first sent.
The recipient of a protocol message
transitions to the "next state" when the message is first received.
- As described earlier in this document, if the coordinator
receives a protocol message from the participant that is consistent with
the former state of the coordinator then the coordinator reverts to its
prior state, accepts the notification from the participant, and continues
the protocol from that point.
The GetStatus and Status protocol messages are not included
in the tables as these never result in a change of state.
These tables present the view of a coordinator or
participant with respect to a single partner. A coordinator with multiple
participants can be understood as a collection of independent coordinator state
machines, each with its own state.
