Reliable Secure Profile Version 1.0
Working Group Approval Draft
2009-09-14
This revision:
Latest revision:
http://mp.ws-i.org/apps/org/workgroup/rspwg/download.php/ReliableSecureProfile-1.0-WGAD.html
Editors:
Jacques Durand, Fujitsu
Gilbert Pilz, Oracle
Administrative contact:
Copyright © 2002-2009 by The Web
Services-Interoperability Organization ( WS-I)
and Certain of its Members. All Rights Reserved.
Abstract
This document
defines the WS-I Reliable Secure Profile 1.0, consisting of a set of
non-proprietary Web services specifications, along with clarifications,
refinements, interpretations and amplifications of those specifications which
promote interoperability. It also contains a set of executable test assertions
for assessing the conformance to the profile.
Status of this Document
This document is
a Working Group Approval Draft; it is an intermediate document that has been
approved for publication by the Working Group. It is a work in progress, and
should not be considered as final; other documents may supersede this document.
Notice
The material
contained herein is not a license, either expressly or impliedly, to any
intellectual property owned or controlled by any of the authors or developers
of this material or WS-I. The material contained herein is provided on an
"AS IS" basis and to the maximum extent permitted by applicable law,
this material is provided AS IS AND WITH ALL FAULTS, and the authors and
developers of this material and WS-I hereby disclaim all other warranties and
conditions, either express, implied or statutory, including, but not limited
to, any (if any) implied warranties, duties or conditions of merchantability,
of fitness for a particular purpose, of accuracy or completeness of responses,
of results, of workmanlike effort, of lack of viruses, and of lack of
negligence. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT,
QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD
TO THIS MATERIAL.
IN NO EVENT WILL
ANY AUTHOR OR DEVELOPER OF THIS MATERIAL OR WS-I BE LIABLE TO ANY OTHER PARTY
FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF
USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT, INDIRECT, OR
SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING
IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS MATERIAL,
WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH
DAMAGES.
Feedback
The Web
Services-Interoperability Organization (WS-I) would like to receive input,
suggestions and other feedback ("Feedback") on this work from a wide
variety of industry participants to improve its quality over time.
By sending email,
or otherwise communicating with WS-I, you (on behalf of yourself if you are an
individual, and your company if you are providing Feedback on behalf of the
company) will be deemed to have granted to WS-I, the members of WS-I, and other
parties that have access to your Feedback, a non-exclusive, non-transferable,
worldwide, perpetual, irrevocable, royalty-free license to use, disclose, copy,
license, modify, sublicense or otherwise distribute and exploit in any manner
whatsoever the Feedback you provide regarding the work. You acknowledge that
you have no expectation of confidentiality with respect to any Feedback you
provide. You represent and warrant that you have rights to provide this
Feedback, and if you are providing Feedback on behalf of a company, you
represent and warrant that you have the rights to provide Feedback on behalf of
your company. You also acknowledge that WS-I is not required to review,
discuss, use, consider or in any way incorporate your Feedback into future
versions of its work. If WS-I does incorporate some or all of your Feedback in
a future version of the work, it may, but is not obligated to include your name
(or, if you are identified as acting on behalf of your company, the name of
your company) on a list of contributors to the work. If the foregoing is not
acceptable to you and any company on whose behalf you are acting, please do not
provide any Feedback.
Feedback on this
document should be directed to wsi_rsp_comment@lists.ws-i.org.
Table of Contents
1. Introduction
1.1. Relationships
to Other Profiles
1.2. Guiding
Principles
1.3. Test
Assertions
1.4. Notational
Conventions
1.5. Profile
Identification and Versioning
2. Profile
Conformance
2.1. Conformance
Requirements
2.2. Conformance
Targets
2.3. Conformance
Scope
2.4. Claiming
Conformance
3. Reliable
Messaging
3.1. Use
of Extension Elements and Attributes in Messages
3.1.1. Ignore
Unknown Extension Elements
3.2. SOAP
Version Considerations
3.2.1. SOAP
Version Selection for Sequence Lifecycle Messages
3.3. Targeting
Sequence Lifecycle Messages
3.3.1. CreateSequence
Target
3.3.2. Use
of the Offer Element
3.4. Sequence
Identifiers
3.4.1. Duplicate
Identifier in CreateSequenceResponse
3.5. Sequence
Termination
3.5.1. Sequence
Termination from the Destination
3.5.2. Last
Message Number
3.5.3. Sequence
Lifecycle Independence
3.6. Sequence
Faults
3.6.1. Transmission
of Sequence Faults
3.6.2. WS-ReliableMessaging
Faults
3.7. Sequence
Assignment
3.7.1. Sequence
Assignment for Reliable Response Messages
3.7.2. Scope
of an RM Node
3.8. Retransmission
of Messages
3.8.1. Retransmission
of Unacknowledged Messages
3.8.2. Retransmission
of Sequence Lifecycle Messages
3.8.3. Message
Identity
3.9. Piggybacking
3.9.1. Endpoint
Comparison for Piggybacked SequenceAcknowledgment Headers
3.9.2. Treatment
of ReferenceParameters in AcksTo EPRs
3.9.3. Preventing
Piggybacked Acknowledgements
3.9.4. Conflicting
Requirements for wsa:Action
3.9.5. Use
of the mustUnderstand Attribute
4. Secure
Conversation
4.1. Unsupported
Context Tokens
4.1.1. Unrecognized
Extensions in a Security Context Token
4.2. Demonstrating
Proof of Possession
4.2.1. Amending
Contexts
4.2.2. Renewing
Contexts
4.2.3. Cancelling
Contexts
4.3. Claims
Re-Authentication
4.3.1. Re-Authenticating
Claims
4.4. Referencing
Security Context Tokens
4.4.1. Associating
a Security Context
4.4.2. Derived
Token References to Security Contexts
4.5. Addressing
Headers
4.5.1. Protecting
Addressing Headers
5. MakeConnection
5.1. Guidance
On the Use of MakeConnection
5.1.1. Action
Values
5.1.2. Binding
to HTTP
5.1.3. Transmission
of MakeConnection Faults
5.2. MakeConnection
Addressing
5.2.1. Addressing
Variants
5.2.2. MakeConnection
Anonymous URI
5.3. MakeConnection
Fault Behavior
5.3.1. [Detail]
Property Mapping
6. Secure
Reliable Messaging
6.1. Initiating
a Secure Sequence
6.1.1. Secure
Context Identification
6.1.2. Security
Token References
6.2. Signature
Coverage
6.2.1. Single
Signature for Sequence Header and SOAP Body
6.2.2. Signed
Elements
6.2.3. Single
Signature for SOAP 1.1 Fault and SequenceFault Header
6.3. Secure
Use of MakeConnection
6.3.1. Security
Context for MakeConnection
6.3.2. Signing
the MessagePending header
6.4. Replay
Detection
6.4.1. Unique
Timestamp Values
Appendix A: Referenced
Specifications
Appendix B: Extensibility
Points
Appendix C: Normative
References
Appendix D: Acknowledgements
1. Introduction
This document
defines the WS-I Reliable Secure Profile 1.0 (hereafter, "Profile"),
consisting of a set of non-proprietary Web services specifications, along with
clarifications, refinements, interpretations and amplifications of those
specifications which promote interoperability.
Section 1
introduces the Profile, and explains its relationships to other profiles.
Section 2,
"Profile Conformance," explains what it means to be conformant to the
Profile.
Each subsequent
section addresses a component of the Profile, and consists of two parts; an
overview detailing the component specifications and their extensibility points,
followed by subsections that address individual parts of the component
specifications. Note that there is no relationship between the section numbers
in this document and those in the referenced specifications.
1.1 Relationships to Other Profiles
This Profile is
intended to be composed with the WS-I Basic Profile 1.2, WS-I Basic Profile
2.0, WS-I Basic Security Profile 1.0 and WS-I Basic Security Profile 1.1.
Composability of RSP with the previously mentioned profiles offers the
following guarantee to users: conformance of an artifact to RSP does not
prevent conformance of this artifact to these other profiles, and vice-versa.
Because the
conformance targets defined for RSP may not match exactly the conformance
targets for another profile, the following more precise definition of
composability is assumed in this profile:
A profile P2 is said to
be composable with a profile P1 if, for any respective pair of conformance
targets (T2, T1) where T1 depends on T2 (see definition below), conformance of
an instance of T2 to P2 does not prevent conformance of the related T1
instance(s) to P1, and vice-versa in case T2 depends on T1.
A target T1 is
said to depend on a target T2 if either:
- T2 and T1 are just different names for the same type of
artifact (e.g. ENVELOPE in RSP and SOAP_ENVELOPE in BSP)
- or T2 is a specialization (or particular instance) of
T1 (e.g. SECURE_ENVELOPE in BSP is a specialization of ENVELOPE in RSP)
- T2 is contained in T1 (e.g. SECURITY_HEADER in BSP is
contained in ENVELOPE in RSP)
- more generally, an instance of T2 will restrict in some
way the possible values - or behaviors - of T1 instances associated with
it.
In order to
conform to this profile (RSP):
- If SOAP 1.1 is being used, all requirements defined in
BP 1.2 must be complied with.
- If SOAP 1.2 is being used, all requirements defined in
BP 2.0 must be complied with.
- Implementations must conform to the WS-Addressing 1.0 -
Core and SOAP Binding specifications, and if WSDL is used, the
WS-Addressing 1.0 - Metadata specification.
1.2 Guiding Principles
The Profile was
developed according to a set of principles that, together, form the philosophy
of the Profile, as it relates to bringing about interoperability. This section
documents these guidelines.
No guarantee of interoperability
It is impossible to
completely guarantee the interoperability of a particular service. However, the
Profile does address the most common problems that implementation experience
has revealed to date.
Application semantics
Although communication
of application semantics can be facilitated by the technologies that comprise
the Profile, assuring the common understanding of those semantics is not
addressed by it.
Testability
When possible, the
Profile makes statements that are testable. However, such testability is not
required. Preferably, testing is achieved in a non-intrusive manner (e.g.,
examining artifacts "on the wire").
Strength of requirements
The Profile makes strong
requirements (e.g., MUST, MUST NOT) wherever feasible; if there are legitimate
cases where such a requirement cannot be met, conditional requirements (e.g.,
SHOULD, SHOULD NOT) are used. Optional and conditional requirements introduce
ambiguity and mismatches between implementations.
Restriction vs. relaxation
When amplifying the
requirements of referenced specifications, the Profile may restrict them, but
does not relax them (e.g., change a MUST to a MAY).
Multiple mechanisms
If a referenced
specification allows multiple mechanisms to be used interchangeably, the
Profile selects those that are well-understood, widely implemented and useful.
Extraneous or underspecified mechanisms and extensions introduce complexity and
therefore reduce interoperability.
Future compatibility
When possible, the
Profile aligns its requirements with in-progress revisions to the
specifications it references. This aids implementers by enabling a graceful
transition, and assures that WS-I does not 'fork' from these efforts. When the
Profile cannot address an issue in a specification it references, this
information is communicated to the appropriate body to assure its
consideration.
Compatibility with deployed services
Backwards compatibility
with deployed Web services is not a goal for the Profile, but due consideration
is given to it; the Profile does not introduce a change to the requirements of
a referenced specification unless doing so addresses specific interoperability
issues.
Focus on interoperability
Although there are
potentially a number of inconsistencies and design flaws in the referenced
specifications, the Profile only addresses those that affect interoperability.
Conformance targets
Where possible, the
Profile places requirements on artifacts (e.g., WSDL descriptions, SOAP
messages) rather than the producing or consuming software's behaviors or roles.
Artifacts are concrete, making them easier to verify and therefore making
conformance easier to understand and less error-prone.
Lower-layer interoperability
The Profile speaks to
interoperability at the application layer; it assumes that interoperability of
lower-layer protocols (e.g., TCP, IP, Ethernet) is adequate and
well-understood. Similarly, statements about application-layer substrate
protocols (e.g., SSL/TLS, HTTP) are only made when there is an issue affecting
Web services specifically; WS-I does not attempt to assure the interoperability
of these protocols as a whole. This assures that WS-I's expertise in and focus
on Web services standards is used effectively.
1.3 Test Assertions
This profile
document contains embedded Test Assertions (TA) that are associated with each
normative profile requirement. In the HTML rendering of this document, these
test assertions are accessible via a toggle link at the end of each
requirement. When clicking on such a link, a table pops up that displays the TA
parts. At the end of this table is another toggle link ("help-glossary")
that displays an explanation glossary for the TA structure. In other formats of
this document, the test assertions are grouped in an appendix not controlled by
any link, in order to facilitate the printing of hard copies. The resulting set
of test assertions embedded in this document represents a conformance test
suite for the profile.
Release notes
related to the test material included in this document are available here:
|
Note Item: |
|
|
test suite |
The test
assertions are scripted using XPath2.0 and are automatically processable
using the version 2.0 of the WS-I Analyzer tools. Several
requirements have been tagged "NOT_TESTABLE". This means that these
requirements cannot be tested based on the technology choices (black-box
testing, XPath scripting). Other
requirements have been tagged "NOT_TESTED". This is the case for
most optional requirements (SHOULD, MAY), and for most Extensibility points. Other
requirements have been tagged "TESTABLE_SCENARIO_DEPENDENT". This
is the case when a specific test scenario is needed in order to exercise the
related test assertion, because the test assertion is designed to trigger
only on specific input material, e.g. that is known to NEVER be recognizable
by an endpoint. A subsequent
version may cover untested requirements. In this profile, the core
requirements for assessing interoperability of implementations have been
initially targeted. |
|
test assertions notes |
A few test
assertions are scenario-dependent: they only trigger if specific values are
used in the messages generated by the test scenarios. They are: RSP0001: this TA is designed to
only detect messages with unrecognizable extensions that use the namespace:
"http://dummy.examples.org/unknown/nmspace". RSP0400a: this TA is designed to
only detect messages that use an unrecognizable Sequence ID of value :
"http://dummy.examples.org/unknown/nmspace". RSP0400b: this TA is designed to
only detect messages that use an unrecognizable Sequence ID of value :
"http://dummy.examples.org/unknown/nmspace". RSP1001: this TA is designed to
only detect messages that use an unrecognizable element inside an SCT, with
namespace of value : "http://dummy.examples.org/unknown/nmspace". One test
assertion does not match any specific Rxxxx, but stems from general profile
requirement: RSP8001: this TA is designed to
ensure that all messages are either compliant with SOAP 1.1 or SOAP 1.2. Test assertions
are not guaranteed to exhaustively cover every case where a profile
requirement applies. In several instances, more than one test assertion is
needed to address the various situations where a profile requirement applies. To learn more
about the details of test assertion outcomes and how they are reported in the
test report, see the glossary link that appears below each test assertion
table. |
|
test log rules |
Test Log
content conventions: The test
assertions designed for this test suite are written to work over "test
log" files that are assumed to follow some rules in their structure and
content. These rules are more completely stated in the documentation
associated with the log file description. Some of these rules are: - Every message
in the log must be uniquely identified: it must have a unique pair of values
for: {message/@conversation, message/@id}, where @id is unique within each
conversation. Typically, a conversation is used to identify an HTTP
connection and the group of messages over this connection. - A response
message (for WSDL request-responses as well as RM lifecycle messages) always
appears after the request message in the log file. - A
wsa:RelatesTo reference always refers to a message that has been logged
before. - A Fault
message always appears after the message-in-error. - An RM
acknowledgement always appears after the messages it acknowledges. - there should
not be both a doc-lit and an rpc-lit bindings for the same portType. - imports must
be resolved locally to the log file. |
1.4 Notational Conventions
The keywords
"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.
Normative
statements of requirements in the Profile (i.e., those impacting conformance,
as outlined in " Conformance
Requirements") are presented in the following manner:
RnnnnStatement text here.
where
"nnnn" is replaced by a number that is unique among the requirements
in the Profile, thereby forming a unique requirement identifier.
Requirement
identifiers can be considered to be namespace qualified, in such a way as to be
compatible with QNames from Namespaces
in XML. If there is no explicit namespace prefix on a requirement's
identifier (e.g., "R9999" as opposed to "bp10:R9999"), it
should be interpreted as being in the namespace identified by the conformance
URI of the document section it occurs in. If it is qualified, the prefix should
be interpreted according to the namespace mappings in effect, as documented
below.
Some requirements
clarify the referenced specification(s), but do not place additional
constraints upon implementations. For convenience, clarifications are annotated
in the following manner: C
Some requirements
are derived from ongoing standardization work on the referenced
specification(s). For convenience, such forward-derived statements are
annotated in the following manner: xxxx, where "xxxx"
is an identifier for the specification (e.g., "WSDL20" for WSDL
Version 2.0). Note that because such work was not complete when this document was
published, the specification that the requirement is derived from may change;
this information is included only as a convenience to implementers.
As noted above,
some requirements may present compatibility issues (whether forwards or
backwards) with previously published versions of the profile. For convenience,
such requirements are annotated in the following manner: Compat
Extensibility
points in underlying specifications (see " Conformance
Scope") are presented in a similar manner:
EnnnnExtensibility Point Name - Description
where
"nnnn" is replaced by a number that is unique among the extensibility
points in the Profile. As with requirement statements, extensibility statements
can be considered namespace-qualified.
This
specification uses a number of namespace prefixes throughout; their associated
URIs are listed below. Note that the choice of any namespace prefix is
arbitrary and not semantically significant.
- soap11
- "http://schemas.xmlsoap.org/soap/envelope/"
- soap12
- "http://www.w3.org/2003/05/soap-envelope"
- xsi
- "http://www.w3.org/2001/XMLSchema-instance"
- xsd
- "http://www.w3.org/2001/XMLSchema"
- wsdl
- "http://schemas.xmlsoap.org/wsdl/"
- soapbind
- "http://schemas.xmlsoap.org/wsdl/soap/"
- wsa
- "http://www.w3.org/2005/08/addressing"
- wsrm
- "http://docs.oasis-open.org/ws-rx/wsrm/200702"
- wsmc
- "http://docs.oasis-open.org/ws-rx/wsmc/200702"
- wssc
- "http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
- wst
- "http://docs.oasis-open.org/ws-sx/ws-trust/200512"
- wsse
-
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
- wsu
- "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
1.5 Profile Identification and Versioning
This document is
identified by a name (in this case, Reliable Secure Profile) and a version
number (here, 1.0). Together, they identify a particular profile instance.
Version numbers
are composed of a major and minor portion, in the form "major.minor".
They can be used to determine the precedence of a profile instance; a higher
version number (considering both the major and minor components) indicates that
an instance is more recent, and therefore supersedes earlier instances.
Instances of
profiles with the same name (e.g., "Example Profile 1.1" and
"Example Profile 5.0") address interoperability problems in the same
general scope (although some developments may require the exact scope of a
profile to change between instances).
One can also use
this information to determine whether two instances of a profile are
backwards-compatible; that is, whether one can assume that conformance to an
earlier profile instance implies conformance to a later one. Profile instances
with the same name and major version number (e.g., "Example Profile
1.0" and "Example Profile 1.1") MAY be considered compatible.
Note that this does not imply anything about compatibility in the other direction;
that is, one cannot assume that conformance with a later profile instance
implies conformance to an earlier one.
2 Profile Conformance
Conformance to
the Profile is defined by adherence to the set of requirements defined for a specific target, within the scope of the Profile. This
section explains these terms and describes how conformance is defined and used.
2.1 Conformance
Requirements
Requirements
state the criteria for conformance to the Profile. They typically refer to an
existing specification and embody refinements, amplifications, interpretations
and clarifications to it in order to improve interoperability. All requirements
in the Profile are considered normative, and those in the specifications it
references that are in-scope (see "Conformance Scope") should
likewise be considered normative. When requirements in the Profile and its
referenced specifications contradict each other, the Profile's requirements
take precedence for purposes of Profile conformance.
Requirement
levels, using RFC2119
language (e.g., MUST, MAY, SHOULD) indicate the nature of the requirement and
its impact on conformance. Each requirement is individually identified (e.g.,
R9999) for convenience.
For example;
R9999 Any WIDGET
SHOULD be round in shape.
This requirement
is identified by "R9999", applies to the target WIDGET (see below),
and places a conditional requirement upon widgets; i.e., although this
requirement must be met to maintain conformance in most cases, there are some
situations where there may be valid reasons for it not being met (which are
explained in the requirement itself, or in its accompanying text).
Each requirement
statement contains exactly one requirement level keyword (e.g.,
"MUST") and one conformance target keyword (e.g.,
"MESSAGE"). The conformance target keyword appears in bold text (e.g.
" MESSAGE"). Other conformance targets appearing in non-bold
text are being used strictly for their definition and NOT as a conformance
target. Additional text may be included to illuminate a requirement or group of
requirements (e.g., rationale and examples); however, prose surrounding
requirement statements must not be considered in determining conformance.
Definitions of
terms in the Profile are considered authoritative for the purposes of
determining conformance.
None of the
requirements in the Profile, regardless of their conformance level, should be
interpreted as limiting the ability of an otherwise conforming implementation
to apply security countermeasures in response to a real or perceived threat
(e.g., a denial of service attack).
2.2 Conformance Targets
Conformance
targets identify what artifacts (e.g., SOAP message, WSDL description, UDDI
registry data) or parties (e.g., SOAP processor, end user) requirements apply
to.
This allows for
the definition of conformance in different contexts, to assure unambiguous
interpretation of the applicability of requirements, and to allow conformance
testing of artifacts (e.g., SOAP messages and WSDL descriptions) and the
behavior of various parties to a Web service (e.g., clients and service
instances).
Requirements'
conformance targets are physical artifacts wherever possible, to simplify
testing and avoid ambiguity.
The following
conformance targets are used in the Profile:
- MESSAGE
- protocol elements that transport the ENVELOPE (e.g., SOAP/HTTP messages)
(from Basic
Profile 1.1)
- ENVELOPE
- the serialization of the soap:Envelope element and its content (from Basic Profile
1.1)
- DESCRIPTION
- descriptions of types, messages, interfaces and their concrete protocol
and data format bindings, and the network access points associated with
Web services (e.g., WSDL descriptions) (from Basic Profile
1.0)
- INSTANCE
- software that implements a wsdl:port or a uddi:bindingTemplate (from Basic Profile
1.0)
- CONSUMER
- software that invokes an INSTANCE (from Basic Profile
1.0)
- SENDER
- software that generates a message according to the protocol(s) associated
with it (from Basic
Profile 1.0)
- RECEIVER
- software that consumes a message according to the protocol(s) associated
with it (e.g., SOAP processors) (from Basic Profile
1.0)
- MC-SENDER
- software that generates a message containing an EPR that uses the
wsmc:MakeConnection Anonymous URI, and generates a MakeConnection message
as defined by WS-MakeConnection 1.1 (from WS-MakeConnection
1.1)
- MC-RECEIVER
- software that consumes a MakeConnection message as defined by WS-MakeConnection
1.1 (from WS-MakeConnection
1.1)
- RMS
- RM Source as defined by WS-ReliableMessaging 1.2 (from WS-ReliableMessaging
1.2)
- RMD
- RM Destination as defined by WS-ReliableMessaging 1.2 (from WS-ReliableMessaging
1.2)
- RM-NODE
- an instance of either an RM Source or an RM Destination (as defined
above)
2.3 Conformance Scope
The scope of the
Profile delineates the technologies that it addresses; in other words, the
Profile only attempts to improve interoperability within its own scope.
Generally, the Profile's scope is bounded by the specifications referenced by
it.
The Profile's
scope is further refined by extensibility points. Referenced specifications
often provide extension mechanisms and unspecified or open-ended configuration
parameters; when identified in the Profile as an extensibility point, such a
mechanism or parameter is outside the scope of the Profile, and its use or
non-use is not relevant to conformance.
Note that the
Profile may still place requirements on the use of an extensibility point.
Also, specific uses of extensibility points may be further restricted by other
profiles, to improve interoperability when used in conjunction with the
Profile.
Because the use
of extensibility points may impair interoperability, their use should be negotiated
or documented in some fashion by the parties to a Web service; for example,
this could take the form of an out-of-band agreement.
The Profile's
scope is defined by the referenced specifications in Appendix
A, as refined by the extensibility points in Appendix
B.
2.4 Claiming Conformance
Claims of
conformance to the Profile can be made using the following mechanisms, as
described in Conformance
Claim Attachment Mechanisms, when the applicable Profile requirements
associated with the listed targets have been met:
- WSDL 1.1 Claim Attachment
Mechanism for Web Services Instances
- MESSAGE DESCRIPTION INSTANCE RECEIVER RMS RMD
- WSDL 1.1 Claim Attachment
Mechanism for Description Constructs
- DESCRIPTION
- UDDI Claim Attachment Mechanism
for Web Services Instances - MESSAGE DESCRIPTION INSTANCE
RECEIVER
- UDDI Claim Attachment Mechanism
for Web Services Registrations - REGDATA
The conformance
claim URI for this Profile is "http://ws-i.org/profiles/rsp/1.0" .
3. Reliable Messaging
This section of
the Profile incorporates the following specifications by reference, and defines
extensibility points within them:
- Web
Services Reliable Messaging 1.2
Extensibility points: - E0001
- CreateSequence element and attribute extensions - Extending
CreateSequence, via additional elements or attributes, is the primary
mechanism for negotiating supplemental semantics to be applied to the
requested and/or offered Sequence. Note this extensiblity point does not
cover the pre-defined use of the
/wsrm:CreateSequence/wsse:SecurityTokenReference element.
- E0002
- CreateSequenceResponse element and attribute extensions - Extending
CreateSequenceResponse, via additional elements or attributes, may be
used to signal the acceptance of the supplemental semantics requested by
the use of E0001 or it may be used in its own right to request or signal
additional semantics to be applied to either requested and/or offered
Sequence.
- E0003
- CloseSequence element and attribute extensions - The CloseSequence
element may be extended via additional elements or attributes to indicate
the use of supplemental semantics or options in the closure of the
Sequence.
- E0004
- CloseSequenceResponse element and attribute extensions - The
CloseSequenceResponse element may be extended via additional elements or
attributes to indicate the use of supplemental semantics or options in
the closure of the Sequence.
- E0005
- TerminateSequence element and attribute extensions - The
TerminateSequence element may be extended via additional elements or
attributes to indicate the use of supplemental semantics or options in
the termination of the Sequence.
- E0006
- TerminateSequenceResponse element and attribute extensions - The
TerminateSequenceResponse element may be extended via additional elements
or attributes to indicate the use of supplemental semantics or options in
the termination of the Sequence.
- E0007
- Sequence element and attribute extensions - The Sequence header element
may be extended via additional elements or attributes to convey
supplemental semantics or options that apply to the Sequence identified
by the header.
- E0008
- AckRequested element and attribute extensions - The AckRequest header
element may be extended via additional elements or attributes to convey
supplemental semantics or options that apply to the request.
- E0009
- SequenceAcknowledgment element and attribute extensions - The
SequenceAcknowledgment header element may be extended via additional
elements or attributes to convey supplemental semantics or options that
apply to the acknowledgment.
- E0010
- SequenceFault element and attribute extensions - The SequenceFault
element may be extended via additional elements or attributes to convey
supplemental semantics or options that apply to the fault.
- Internationalized
Resource Identifiers (IRIs)
- Web Services
Addressing 1.0 - SOAP Binding
3.1 Use of Extension
Elements and Attributes in Messages
The protocol
elements defined by WS-ReliableMessaging contain extension points wherein
implementations MAY add child elements and/or attributes.
3.1.1 Ignore Unknown
Extension Elements
To
ensure the ability to safely extend the protocol, it is necessary that adding
an extension does not create the risk of impacting interoperability with
non-extended implementations.
R0001
A RECEIVER MUST NOT generate a fault as a consequence of receiving a message
(e.g. wsrm:CreateSequence) that contains extension elements and/or attributes
that it does not recognize. Any exceptions to this rule are clearly identified
in requirements below or the specifications underlying the profile TESTABLE_SCENARIO_DEPENDENT RSP0001
|
Test Assertion
Analysis: |
|
|
General Notes: |
NOTE1: the actual test
target is the observable artifact under test. NOTE2: given partial coverage,
probably better to test for the negative case: predicate=true means failure.
Inthe error message (or warning message): mention what to look for NOTE3:
need to finalize the expected fault-message correlation. NOTE4: test env
alignment: use same unrecognizable extension. |
|
Coverage Assessment: |
partial (only some
extension cases, and some messages types to be tested, and also can't sort
out the real cause of the Fault) |
|
Target Type: |
ENVELOPE |
|
Test Target: |
for a soap:Envelope
(not just wsrm:CreateSequence) with a special extension that is known to be
NOT understood |
|
Test co-Target(s): |
|
|
Test Prerequisite: |
|
|
Predicate: |
there is a Fault in
response to the message with extension. |
|
Prescription: |
mandatory |
|
Reporting: |
true=warning,
false=undetermined |
|
Test Control: |
Align with
unrecognizable extension expected in the TA. Generate a wsrm:CreateSequence
message that makes use of the unrecognizable extension. Require response for
anonymous URI. |
|
Test Assertion: |
RSP0001 |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[
|
|
co-Target: myresponse |
/wsil:testLog/wsil:messageLog/wsil:message[ |
|
Predicate: |
not($myresponse//*:Body/*:Fault) |
|
Reporting: |
true=passed, false=failed |
|
Prescription: |
mandatory |
|
Error Message: |
A SOAP Fault was generated in response to a message that
contains elements with an unrecognized extension - here, a predefined
namespace URI. |
|
Diagnostic Data: |
|
Test Assertion Part |
|
|
Test Assertion ID: |
[ markup: testAssertion/@id] (required) A unique ID for the
current test assertion. |
|
Description: |
[ markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At
minimum expressing the TA predicate. |
|
Comments: |
[ markup: testAssertion/comments ] (optional) A plain text comment
about the TA script and how well it covers the profile requirement. Explanation
material for users, and developers (what could be improved, etc.). |
|
Target: |
[ markup: testAssertion/target ] (required) The artifacts to be
tested, defined by an XPath expression that returns a list of XML nodes from
the log file in input. For every artifact (node) selected by the Target
expression, there will be a report entry for this TA in the test report, with
a result of either:
See the "reporting" item for the meaning of these
results. |
|
Cotarget: |
[ markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be
accessed for the testing. Identified by an XPath expression that may refer to
the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget
the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The
value of this attribute can be used as a variable (when prepending '$' to it)
by subsequently defined cotargets, prerequisite and predicate. |
|
Prerequisite: |
[ markup: testAssertion/@preReq ] (optional) [ markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target
does not qualify for this Test Assertion (the test report is
"notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion
IDs. Each one of the prerequisite TAs must either use the same target (e.g.
SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a
more general type than the main TA target. The target must "pass"
each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target
of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath
(boolean) expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the
result for the current TA in the report will be "notRelevant".
Otherwise, the target can be further evaluated by the predicate of the main
TA. The expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name
($[name]). |
|
Predicate: |
[ markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is
fulfilling the profile requirement addressed by this test Assertion. By
default: - A result of true
means the requirement is fulfilled (reported as a "passed" in the
test report). However, in some cases and for testability reasons, the
predicate may be designed as a partial indicator e.g. only indicates some
cases of fulfillment, or some cases of violation. As a result, when
"true" indicates fulfillment it may be that "false" is
unconclusive, or conversely "false" will indicate violation, but
"true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the profile
requirement. The predicate expression implicitly refers to the target (whic
is its "XPath context") although it may explicitly refer to it
using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
|
Prescription: |
[ markup: testAssertion/prescription/@level ] (required) Conveys the level of
prescription associated with the profile requirement. At least three values
may be used:
|
|
Reporting: |
[ markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false),
specifies how it must be interpreted w/r to the profile feature. Two
attributes are used that both must be present, when this element is present:
The reported outcomes
have the following meaning:
NOTES: the predicate of the TA may be worded in a negative way
so that @false='passed' although that is not recommended. The result of a
test should not be related to the prescription level, e.g. a
"preferred" or "permitted" level should not imply that
@false='warning'. Other test results that are automatically generated and not
controlled by the "reporting" element are:
|
While the extensibility points of the
profiled specifications can be used, per R0001 they MUST be ignored if they are
not understood. However if a SENDER wishes to ensure that the RECEIVER
understands and will comply with any such extensions, they need to include a
SOAP header, marked with mustUnderstand="1" , in the request message that requires adherence to the semantics
of those extensions.
3.2
SOAP Version Considerations
In general, it is not expected that the service descriptions for
applications that use WS-ReliableMessaging will include bindings of the WS-RM
protocol itself. This being the case, there is some uncertainty about which
version of SOAP should be used to carry Sequence Lifecycle Messages.
3.2.1 SOAP Version
Selection for Sequence Lifecycle Messages
For messages that flow from the RMS to the
RMD, the version(s) of SOAP used for Sequence Lifecycle Messages are
constrained to the version(s) of SOAP that are supported by the target endpoint
(i.e. the endpoint to which the client is attempting to reliably communicate).
For example, if a client is attempting to communicate reliably to an endpoint
who's service description indicates that it only supports SOAP 1.1, the RMS
should only send Sequence Lifecycle Messages using SOAP 1.1. Sequence Lifecycle
Response Messages (CreateSequenceResponse, TerminateSequenceResponse, and
CloseSequenceResponse) should use the version of SOAP used by their
corresponding request message (CreateSequence, TerminateSequence, and
CloseSequence respectively); this applies to WS-RM fault messages as well. For
messages that flow from the RMD to the RMS (SequenceAck messages with an empty
body, unsolicited CloseSequence messages, and unsolicited TerminateSequence
messages) this profile adheres to and expands upon WS-RM's statement that
"The SOAP version used for the CreateSequence message SHOULD be used for
all subsequent messages in or for that Sequence, sent by either the RM Source
or the RM Destination".
R0900 Unless
otherwise specified (e.g. through some WSDL or WS-Policy designator), the RMD MUST send Sequence Lifecycle Messages destined to the
CreateSequence/AcksTo EPR with the same SOAP version that was used in the
CreateSequence message. TESTABLE RSP0900
|
Test Assertion
Analysis: |
|
|
General Notes: |
When passing around EPRs (that do not have embedded WSDL) it is
not clear which version of SOAP should be used when talking to that EPR. This
requirement tries to answer this question at least with respect to RM Acks /
AcksTo EPR by requiring the RMD to use the same SOAP version that was used in
the originating CS message. This means that the RMD needs to save this
information, where before this was not required |
|
Coverage Assessment: |
Good |
|
Target Type: |
ENVELOPE |
|
Test Target: |
A SOAP Envelope with a SeqAck Header |
|
Test co-Target(s): |
|
|
Test Prerequisite: |
|
|
Predicate: |
The [target] has the same SeqID value and SOAP Envelope
namespace as the previous message that contains a CreateSequence or
CreateSequenceResponse. |
|
Prescription: |
mandatory |
|
Reporting: |
true=warning, false=passed |
|
Test Control: |
Run a reliable request/response application message exchange.
Create a sequence using a CreateSequence that includes an Offer element. This
will ensure that the messages carrying the Acks in both directions are using
the correct SOAP namespace. |
|
Test Assertion: |
RSP0900 |
|
Description: |
This test assertion
takes as prerequisite RSP8001, a "base TA" that does match any
particular Rxxxx requirement, but matches fundamental requirements from RSP:
namely that an Envelope is either under SOAP 1.2 or SOAP 1.1 namespace. |
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
|
|
Prerequisite: |
RSP8001 |
|
Predicate: |
some $csr in /wsil:testLog/wsil:messageLog//*:Envelope
(($cs/../../@conversation = $csr/../../@conversation) or |
|
Reporting: |
true=passed,
false=failed |
|
Prescription: |
mandatory |
|
Error Message: |
Some RM Lifecycle
message related to a requested sequence (CreateSequence) was sent to the
AcksTo EPR with a SOAP version different from the version used for the
CreateSequence message. |
|
Diagnostic Data: |
|
Test Assertion Part |
What it means: |
|
Test Assertion ID: |
[ markup: testAssertion/@id] (required) A unique ID for the
current test assertion. |
|
Description: |
[ markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At
minimum expressing the TA predicate. |
|
Comments: |
[ markup: testAssertion/comments ] (optional) A plain text comment
about the TA script and how well it covers the profile requirement.
Explanation material for users, and developers (what could be improved,
etc.). |
|
Target: |
[ markup: testAssertion/target ] (required) The artifacts to be
tested, defined by an XPath expression that returns a list of XML nodes from
the log file in input. For every artifact (node) selected by the Target
expression, there will be a report entry for this TA in the test report, with
a result of either:
See the "reporting" item for the meaning of these
results. |
|
Cotarget: |
[ markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be
accessed for the testing. Identified by an XPath expression that may refer to
the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget
the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The
value of this attribute can be used as a variable (when prepending '$' to it)
by subsequently defined cotargets, prerequisite and predicate. |
|
Prerequisite: |
[ markup: testAssertion/@preReq ] (optional) [ markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target
does not qualify for this Test Assertion (the test report is
"notRelevant") The first part (preReq attribute) is an enumeration of Test
Assertion IDs. Each one of the prerequisite TAs must either use the same
target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target
that is of a more general type than the main TA target. The target must
"pass" each one of these prerequisite TAs in order to qualify for
this TA. (e.g. the target of TA t1 can be a WSDL binding while the target
of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath
(boolean) expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the
result for the current TA in the report will be "notRelevant".
Otherwise, the target can be further evaluated by the predicate of the main
TA. The expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name
($[name]). |
|
Predicate: |
[ markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is
fulfilling the profile requirement addressed by this test Assertion. By
default: - A result of true
means the requirement is fulfilled (reported as a "passed" in the
test report). However, in some cases and for testability reasons, the
predicate may be designed as a partial indicator e.g. only indicates some
cases of fulfillment, or some cases of violation. As a result, when
"true" indicates fulfillment it may be that "false" is
unconclusive, or conversely "false" will indicate violation, but
"true" is unconclusive. In such cases, the "Reporting" element
specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic
is its "XPath context") although it may explicitly refer to it
using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
|
Prescription: |
[ markup: testAssertion/prescription/@level ] (required) Conveys the level of
prescription associated with the profile requirement. At least three values
may be used:
|
|
Reporting: |
[ markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false),
specifies how it must be interpreted w/r to the profile feature. Two
attributes are used that both must be present, when this element is present:
The reported outcomes
have the following meaning:
NOTES: the predicate of the TA may be worded in a negative way
so that @false='passed' although that is not recommended. The result of a
test should not be related to the prescription level, e.g. a
"preferred" or "permitted" level should not imply that
@false='warning'. Other test results that are automatically generated and not
controlled by the "reporting" element are:
|
R0901 Unless
otherwise specified (e.g. through some WSDL or WS-Policy designator), the RMS of an Offered Sequence MUST send Sequence Lifecycle Messages
destined to the CreateSequence/Offer/Endpoint EPR with the same SOAP version
that was used in the CreateSequence message. TESTABLE RSP0901
|
Test Assertion
Analysis: |
|
|
General Notes: |
The possible lifecycle messages covered by this requirement are:
CloseSequence and TerminateSequence. Similar to R0900, its not clear what version
of SOAP should be used when sending messages to the CS/Offer/Endpoint EPR.
This requirement would require an RMD to save the SOAP version of the CS and
use that same version of any Close or Terminate Sequence messages sent to the
CS/Offer/Endpoint EPR |
|
Coverage Assessment: |
Good(should be able to cover all cases) |
|
Target Type: |
ENVELOPE |
|
Test Target: |
A CloseSequence or TerminateSequence message |
|
Test co-Target(s): |
|
|
Test Prerequisite: |
|
|
Predicate: |
For any message that contains a CloseSequence or
TerminateSequence element in the Body, extract the SeqID value and find (in a
previous message) a CreateSequence, or CreateSequenceResponse, that
references this SeqID. The namespace of the SOAP Envelope elements of these
messages MUST be the same |
|
Prescription: |
mandatory |
|
Reporting: |
true=passed, false=failed |
|
Test Control: |
Run a reliable request/response application message exchange.
Create a sequence using a CreateSequence that includes an Offer element. To
ensure the CloseSequence message is tested we could make sure there's a gap
in the request sequence then have the RMS send a Close. This should cause the
service to close the response sequence before it terminates it. Question: is
there a RSP requirement that covers the non-Offered case? Seems like there
should be but I can't find it |
|
Test Assertion: |
RSP0901 |
|
Description: |
This test assertion
takes as prerequisite RSP8001, a "base TA" that does match any
particular Rxxxx requirement, but matches fundamental requirements from RSP:
namely that an Envelope is either under SOAP 1.2 or SOAP 1.1 namespace. |
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
|
|
Prerequisite: |
RSP8001 |
|
Predicate: |
some $cs in preceding::*:Envelope
|
|
Reporting: |
true=passed,
false=failed |
|
Prescription: |
mandatory |
|
Error Message: |
Some RM Lifecycle
message related to an offered sequence (CreateSequence) was sent to the
CreateSequence/Offer/Endpoint EPR with a SOAP version different from the
version used for the CreateSequence message. |
|
Diagnostic Data: |
|
Test Assertion Part |
What it means: |
|
Test Assertion ID: |
[ markup: testAssertion/@id] (required) A unique ID for the
current test assertion. |
|
Description: |
[ markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At
minimum expressing the TA predicate. |
|
Comments: |
[ markup: testAssertion/comments ] (optional) A plain text comment
about the TA script and how well it covers the profile requirement.
Explanation material for users, and developers (what could be improved,
etc.). |
|
Target: |
[ markup: testAssertion/target ] (required) The artifacts to be
tested, defined by an XPath expression that returns a list of XML nodes from
the log file in input. For every artifact (node) selected by the Target
expression, there will be a report entry for this TA in the test report, with
a result of either:
See the "reporting" item for the meaning of these
results. |
|
Cotarget: |
[ markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be
accessed for the testing. Identified by an XPath expression that may refer to
the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget
the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The
value of this attribute can be used as a variable (when prepending '$' to it)
by subsequently defined cotargets, prerequisite and predicate. |
|
Prerequisite: |
[ markup: testAssertion/@preReq ] (optional) [ markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target
does not qualify for this Test Assertion (the test report is
"notRelevant") The first part (preReq attribute) is an enumeration of Test
Assertion IDs. Each one of the prerequisite TAs must either use the same
target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target
that is of a more general type than the main TA target. The target must
"pass" each one of these prerequisite TAs in order to qualify for
this TA. (e.g. the target of TA t1 can be a WSDL binding while the target
of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath
(boolean) expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the
result for the current TA in the report will be "notRelevant".
Otherwise, the target can be further evaluated by the predicate of the main
TA. The expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name
($[name]). |
|
Predicate: |
[ markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is
fulfilling the profile requirement addressed by this test Assertion. By
default: - A result of true
means the requirement is fulfilled (reported as a "passed" in the
test report). However, in some cases and for testability reasons, the
predicate may be designed as a partial indicator e.g. only indicates some
cases of fulfillment, or some cases of violation. As a result, when
"true" indicates fulfillment it may be that "false" is
unconclusive, or conversely "false" will indicate violation, but
"true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the profile
requirement. The predicate expression implicitly refers to the target (whic
is its "XPath context") although it may explicitly refer to it using
the variable name "$target". It may refer to any cotarget using its
name as variable name ($[name]). |
|
Prescription: |
[ markup: testAssertion/prescription/@level ] (required) Conveys the level of
prescription associated with the profile requirement. At least three values
may be used:
|
|
Reporting: |
[ markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false),
specifies how it must be interpreted w/r to the profile feature. Two
attributes are used that both must be present, when this element is present:
The reported outcomes
have the following meaning:
NOTES: the predicate of the TA may be worded in a negative way
so that @false='passed' although that is not recommended. The result of a
test should not be related to the prescription level, e.g. a
"preferred" or "permitted" level should not imply that
@false='warning'. Other test results that are automatically generated and not
controlled by the "reporting" element are:
|
3.3 Targeting Sequence Lifecycle Messages
WS-ReliableMessaging is silent on where certain Sequence Lifecycle
Messages (such as CreateSequence) should be sent.
3.3.1 CreateSequence Target
The WS-RM specification is silent on exactly
where an RMS should send a CreateSequence message to establish a Sequence. This
is true for the case of a client-side RMS creating a Sequence to carry request
messages as well as the case of a server-side RMS creating a Sequence to carry
response messages. This is an interoperability issue because, unless the
respective RMS and RMD implementations agree on the expected target for
CreateSequence messages, the intended recipient may not configure the necessary
infrastructure (WS-RM message handlers, etc.) and the CreateSequence message
may either cause a fault or be ignored.
R0800 Baring
some out of band agreement, an ENVELOPE carrying a CreateSequence
message MUST be addressed to the same destination as one of the Sequence
Traffic Message for that Sequence. TESTABLE RSP0800
|
Test Assertion
Analysis: |
|
|
General Notes: |
|
|
Coverage Assessment: |
Good |
|
Target Type: |
ENVELOPE |
|
Test Target: |
|
|
Test co-Target(s): |
|
|
Test Prerequisite: |
|
|
Predicate: |
|
|
Prescription: |
mandatory |
|
Reporting: |
true=pass, false=fail |
|
Test Control: |
|
Test Assertion: |
RSP0800 |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
|
|
co-Target: mycsr |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
|
|
Predicate: |
some $env in
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Header/wsrm:Sequence/wsrm:Identifier
= $mycsr/*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier] satisfies |
|
Reporting: |
true=passed,
false=failed |
|
Prescription: |
mandatory |
|
Error Message: |
None of the messages
sent in a reliable sequence, has been sent to the same destination endpoint
as the CreateSequence message (at least one should be). |
|
Diagnostic Data: |
|
Test Assertion Part |
What it means: |
|
Test Assertion ID: |
[ markup: testAssertion/@id] (required) A unique ID for the
current test assertion. |
|
Description: |
[ markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At
minimum expressing the TA predicate. |
|
Comments: |
[ markup: testAssertion/comments ] (optional) A plain text comment
about the TA script and how well it covers the profile requirement.
Explanation material for users, and developers (what could be improved,
etc.). |
|
Target: |
[ markup: testAssertion/target ] (required) The artifacts to be
tested, defined by an XPath expression that returns a list of XML nodes from
the log file in input. For every artifact (node) selected by the Target
expression, there will be a report entry for this TA in the test report, with
a result of either:
See the "reporting" item for the meaning of these
results. |
|
Cotarget: |
[ markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be
accessed for the testing. Identified by an XPath expression that may refer to
the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget
the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The
value of this attribute can be used as a variable (when prepending '$' to it)
by subsequently defined cotargets, prerequisite and predicate. |
|
Prerequisite: |
[ markup: testAssertion/@preReq ] (optional) [ markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target
does not qualify for this Test Assertion (the test report is
"notRelevant") The first part (preReq attribute) is an enumeration of Test
Assertion IDs. Each one of the prerequisite TAs must either use the same
target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target
that is of a more general type than the main TA target. The target must
"pass" each one of these prerequisite TAs in order to qualify for
this TA. (e.g. the target of TA t1 can be a WSDL binding while the target
of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath
(boolean) expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the
result for the current TA in the report will be "notRelevant".
Otherwise, the target can be further evaluated by the predicate of the main
TA. The expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name
($[name]). |
|
Predicate: |
[ markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is
fulfilling the profile requirement addressed by this test Assertion. By
default: - A result of true
means the requirement is fulfilled (reported as a "passed" in the
test report). However, in some cases and for testability reasons, the
predicate may be designed as a partial indicator e.g. only indicates some
cases of fulfillment, or some cases of violation. As a result, when
"true" indicates fulfillment it may be that "false" is
unconclusive, or conversely "false" will indicate violation, but
"true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the profile
requirement. The predicate expression implicitly refers to the target (whic
is its "XPath context") although it may explicitly refer to it
using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
|
Prescription: |
[ markup: testAssertion/prescription/@level ] (required) Conveys the level of
prescription associated with the profile requirement. At least three values
may be used:
|
|
Reporting: |
[ markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false),
specifies how it must be interpreted w/r to the profile feature. Two
attributes are used that both must be present, when this element is present:
The reported outcomes
have the following meaning:
NOTES: the predicate of the TA may be worded in a negative way
so that @false='passed' although that is not recommended. The result of a
test should not be related to the prescription level, e.g. a
"preferred" or "permitted" level should not imply that
@false='warning'. Other test results that are automatically generated and not
controlled by the "reporting" element are:
|
This requirement applies equally to cases in
which the first Sequence Traffic Message is addressed to a URI (as may happen
when the target endpoint is retrieved from a WSDL document) or to an EPR (as
may happen when the target endpoint is the wsa:ReplyTo address of the corresponding
request message).
3.3.2 Use of the Offer Element
The use of the Offer element within a
CreateSequence message is an optional feature of WS-ReliableMessaging. Using
Offer avoids the exchange of CreateSequence and CreateSequenceResponse messages
to establish a new sequence for response messages. However, WS-RM does not
define a mechanism by which an RMS can determine if an Offer is desired by the
RMD. This creates a potential interoperability issue in cases where an RMS that
either doesn't wish to use or cannot support the use of Offer attempts to
create a Sequence with an RMD that requires the use of Offer. To ensure
interoperability, the Offer feature must be optional for both the initiator of
the Sequence (the RMS) as well as the RMD.
Conversely, when an RMS includes an Offer
within a CreateSeqence and the RMD rejects that Offer (e.g. if it only has
input-only operations and concludes it has no need for the offered Sequence),
if the RMD indicates this choice by faulting the CreateSequence the RMS has no
programmatic means of determining that the fault was due to the presence of an
Offer. To ensure interoperatbility in these cases, the RMD, rather than
faulting the CreateSequence, must instead simply not accept the offered
Sequence by not including an Accept element in the CreateSequenceResponse.
R0010 An RMD MUST NOT fault a CreateSequence due to the absence of the Offer
element. TESTABLE RSP0010
|
Test Assertion
Analysis: |
|
|
General Notes: |
|
|
Coverage Assessment: |
partial |
|
Target Type: |
|
|
Test Target: |
|
|
Test co-Target(s): |
|
|
Test Prerequisite: |
|
|
Predicate: |
No fault is sent back by the CS receiver. |
|
Prescription: |
mandatory |
|
Reporting: |
true=warning, false=undetermined |
|
Test Control: |
Warning: apparent failure. Verify if the Fault has not other
causes. |
|
Test Assertion: |
RSP0010 |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[
|
|
co-Target: myresponse |
/wsil:testLog/wsil:messageLog/wsil:message[
|
|
Predicate: |
not($myresponse//*:Body/*:Fault) |
|
Reporting: |
true=passed,
false=failed |
|
Prescription: |
mandatory |
|
Error Message: |
Warning: A
wsrm:CreateSequence message was faulted. Please verify to make sure it was
not faulted because of the absence of an Offer element. |
|
Diagnostic Data: |
|
Test Assertion Part |
What it means: |
|
Test Assertion ID: |
[ markup: testAssertion/@id] (required) A unique ID for the
current test assertion. |
|
Description: |
[ markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At
minimum expressing the TA predicate. |
|
Comments: |
[ markup: testAssertion/comments ] (optional) A plain text comment
about the TA script and how well it covers the profile requirement.
Explanation material for users, and developers (what could be improved,
etc.). |
|
Target: |
[ markup: testAssertion/target ] (required) The artifacts to be
tested, defined by an XPath expression that returns a list of XML nodes from
the log file in input. For every artifact (node) selected by the Target
expression, there will be a report entry for this TA in the test report, with
a result of either:
See the "reporting" item for the meaning of these
results. |
|
Cotarget: |
[ markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be
accessed for the testing. Identified by an XPath expression that may refer to
the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget
the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The
value of this attribute can be used as a variable (when prepending '$' to it)
by subsequently defined cotargets, prerequisite and predicate. |
|
Prerequisite: |
[ markup: testAssertion/@preReq ] (optional) [ markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target
does not qualify for this Test Assertion (the test report is
"notRelevant") The first part (preReq attribute) is an enumeration of Test
Assertion IDs. Each one of the prerequisite TAs must either use the same
target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target
that is of a more general type than the main TA target. The target must
"pass" each one of these prerequisite TAs in order to qualify for
this TA. (e.g. the target of TA t1 can be a WSDL binding while the target
of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath
(boolean) expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the
result for the current TA in the report will be "notRelevant".
Otherwise, the target can be further evaluated by the predicate of the main
TA. The expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name
($[name]). |
|
Predicate: |
[ markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is
fulfilling the profile requirement addressed by this test Assertion. By
default: - A result of true
means the requirement is fulfilled (reported as a "passed" in the
test report). However, in some cases and for testability reasons, the
predicate may be designed as a partial indicator e.g. only indicates some
cases of fulfillment, or some cases of violation. As a result, when
"true" indicates fulfillment it may be that "false" is
unconclusive, or conversely "false" will indicate violation, but
"true" is unconclusive. In such cases, the "Reporting" element
specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic
is its "XPath context") although it may explicitly refer to it
using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
|
Prescription: |
[ markup: testAssertion/prescription/@level ] (required) Conveys the level of
prescription associated with the profile requirement. At least three values
may be used:
|
|
Reporting: |
[ markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false),
specifies how it must be interpreted w/r to the profile feature. Two
attributes are used that both must be present, when this element is present:
The reported outcomes
have the following meaning:
NOTES: the predicate of the TA may be worded in a negative way
so that @false='passed' although that is not recommended. The result of a
test should not be related to the prescription level, e.g. a
"preferred" or "permitted" level should not imply that
@false='warning'. Other test results that are automatically generated and not
controlled by the "reporting" element are:
|
R0011 An RMD MUST NOT fault a CreateSequence due to the presence of the Offer
element. TESTABLE RSP0011
|
Test Assertion
Analysis: |
|
|
General Notes: |
|
|
Coverage Assessment: |
partial |
|
Target Type: |
|
|
Test Target: |
|
|
Test co-Target(s): |
|
|
Test Prerequisite: |
|
|
Predicate: |
No fault is sent back by the CS receiver. |
|
Prescription: |
mandatory |
|
Reporting: |
true=warning, false=undetermined |
|
Test Control: |
Warning: apparent failure. Verify if the Fault has not other
causes. |
|
Test Assertion: |
RSP0011 |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body/wsrm:CreateSequence/wsrm:Offer] |
|
co-Target: myresponse |
/wsil:testLog/wsil:messageLog/wsil:message[
|
|
Predicate: |
not($myresponse//*:Body/*:Fault) |
|
Reporting: |
true=passed,
false=failed |
|
Prescription: |
mandatory |
|
Error Message: |
Warning: A
wsrm:CreateSequence message was faulted. Please verify to make sure it was
not faulted because of the presence of an Offer element. |
|
Diagnostic Data: |
|
Test Assertion Part |
What it means: |
|
Test Assertion ID: |
[ markup: testAssertion/@id] (required) A unique ID for the
current test assertion. |
|
Description: |
[ markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At
minimum expressing the TA predicate. |
|
Comments: |
[ markup: testAssertion/comments ] (optional) A plain text comment
about the TA script and how well it covers the profile requirement.
Explanation material for users, and developers (what could be improved,
etc.). |
|
Target: |
[ markup: testAssertion/target ] (required) The artifacts to be
tested, defined by an XPath expression that returns a list of XML nodes from
the log file in input. For every artifact (node) selected by the Target
expression, there will be a report entry for this TA in the test report, with
a result of either:
See the "reporting" item for the meaning of these
results. |
|
Cotarget: |
[ markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be
accessed for the testing. Identified by an XPath expression that may refer to
the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget
the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The
value of this attribute can be used as a variable (when prepending '$' to it)
by subsequently defined cotargets, prerequisite and predicate. |