WS-I

Reliable Secure Profile Version 1.0

Working Group Approval Draft

2009-09-14

This revision:

http://mp.ws-i.org/apps/org/workgroup/rspwg/download.php/ReliableSecureProfile-1.0-WGAD.html?versionID=$Revision: 1.1 $

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:

secretary@ws-i.org


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:

In order to conform to this profile (RSP):

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:

TESTING-RELEASE-NOTES

Note Item:

Release Notes : 2009-08-24

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.

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:

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:

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:

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:

RSP0001

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[
some $elt in .//* satisfies
string(fn:namespace-uri($elt)) = 'http://dummy.examples.org/unknown/nmspace'
]

co-Target: myresponse

/wsil:testLog/wsil:messageLog/wsil:message[
(@type = 'response' and @conversation = $target/../../@conversation) or
(.//*:Envelope/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] =
$target/*:Header/wsa:MessageID)
]
/wsil:messageContents/*:Envelope

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:

HELP - GLOSSARY

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:

  • passed
  • failed
  • warning
  • notApplicable
  • notRelevant
  • missingInput
  • undetermined

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).
- A result of false means the requirement is violated (reported as a "failed" 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:

  • mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT)
  • preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED
  • permitted: maps to RFC2119 keywords MAY, OPTIONAL.

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:

  • @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed')
  • @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed')

The reported outcomes have the following meaning:

  • passed: the target passes the test and can be considered as fulfilling the profile feature.
  • failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature.
  • warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation.
  • undetermined: the test result is inconclusive for this predicate value.

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:

  • notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it).
  • missingInput: a cotarget expression returned an empty node set.
  • notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

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:

RSP0900

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
[(*:Header/wsrm:SequenceAcknowledgement/wsrm:Identifier = preceding::*:Envelope/*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier) or
(*:Body/wsrm:CloseSequenceResponse/wsrm:Identifier = preceding::*:Envelope/*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier) or
(*:Body/wsrm:TerminateSequenceResponse/wsrm:Identifier = preceding::*:Envelope/*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier) or
(*:Body/wsrm:CreateSequenceResponse)]

Prerequisite:

RSP8001

Predicate:

some $csr in /wsil:testLog/wsil:messageLog//*:Envelope
[*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier = $target/*:Header/wsrm:SequenceAcknowledgement/wsrm:Identifier or
(*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier = $target/*:Body/wsrm:*/wsrm:Identifier)]
satisfies
some $cs in /wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body/wsrm:CreateSequence] satisfies

(($cs/../../@conversation = $csr/../../@conversation) or
($csr/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or
not (@RelationshipType)] = $cs/*:Header/wsa:MessageID)) and
fn:namespace-uri($target) = fn:namespace-uri($cs)

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:

HELP - GLOSSARY

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:

  • passed
  • failed
  • warning
  • notApplicable
  • notRelevant
  • missingInput
  • undetermined

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).
- A result of false means the requirement is violated (reported as a "failed" 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:

  • mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT)
  • preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED
  • permitted: maps to RFC2119 keywords MAY, OPTIONAL.

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:

  • @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed')
  • @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed')

The reported outcomes have the following meaning:

  • passed: the target passes the test and can be considered as fulfilling the profile feature.
  • failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature.
  • warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation.
  • undetermined: the test result is inconclusive for this predicate value.

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:

  • notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it).
  • missingInput: a cotarget expression returned an empty node set.
  • notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

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:

RSP0901

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
[(*:Header/wsrm:AckRequested/wsrm:Identifier = preceding::*:Envelope/*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier) or
(*:Body/wsrm:CloseSequence/wsrm:Identifier = preceding::*:Envelope/*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier) or
(*:Body/wsrm:TerminateSequence/wsrm:Identifier = preceding::*:Envelope/*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier) ]

Prerequisite:

RSP8001

Predicate:

some $cs in preceding::*:Envelope
[*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier = $target/*:Header/wsrm:AckRequested/wsrm:Identifier or
(*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier = $target/*:Body/wsrm:*/wsrm:Identifier)]
satisfies
fn:namespace-uri($target) = fn:namespace-uri($cs)

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:

HELP - GLOSSARY

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:

  • passed
  • failed
  • warning
  • notApplicable
  • notRelevant
  • missingInput
  • undetermined

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).
- A result of false means the requirement is violated (reported as a "failed" 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:

  • mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT)
  • preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED
  • permitted: maps to RFC2119 keywords MAY, OPTIONAL.

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:

  • @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed')
  • @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed')

The reported outcomes have the following meaning:

  • passed: the target passes the test and can be considered as fulfilling the profile feature.
  • failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature.
  • warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation.
  • undetermined: the test result is inconclusive for this predicate value.

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:

  • notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it).
  • missingInput: a cotarget expression returned an empty node set.
  • notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

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:

RSP0800

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
[*:Body/wsrm:CreateSequence]

co-Target: mycsr

/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
[*:Body/wsrm:CreateSequenceResponse]
[(./../../@conversation = $target/../../@conversation) or
(*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $target/*:Header/wsa:MessageID)]

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
($env/*:Header/wsa:To = $target/*:Header/wsa:To)

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:

HELP - GLOSSARY

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:

  • passed
  • failed
  • warning
  • notApplicable
  • notRelevant
  • missingInput
  • undetermined

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).
- A result of false means the requirement is violated (reported as a "failed" 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:

  • mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT)
  • preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED
  • permitted: maps to RFC2119 keywords MAY, OPTIONAL.

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:

  • @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed')
  • @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed')

The reported outcomes have the following meaning:

  • passed: the target passes the test and can be considered as fulfilling the profile feature.
  • failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature.
  • warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation.
  • undetermined: the test result is inconclusive for this predicate value.

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:

  • notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it).
  • missingInput: a cotarget expression returned an empty node set.
  • notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

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:

RSP0010

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[
*:Body/wsrm:CreateSequence[not(wsrm:Offer)]]

co-Target: myresponse

/wsil:testLog/wsil:messageLog/wsil:message[
(@type = 'response' and @conversation = $target/../../@conversation) or
(.//*:Envelope/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] =
$target/*:Header/wsa:MessageID)
]
/wsil:messageContents/*:Envelope

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:

HELP - GLOSSARY

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:

  • passed
  • failed
  • warning
  • notApplicable
  • notRelevant
  • missingInput
  • undetermined

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).
- A result of false means the requirement is violated (reported as a "failed" 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:

  • mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT)
  • preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED
  • permitted: maps to RFC2119 keywords MAY, OPTIONAL.

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:

  • @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed')
  • @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed')

The reported outcomes have the following meaning:

  • passed: the target passes the test and can be considered as fulfilling the profile feature.
  • failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature.
  • warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation.
  • undetermined: the test result is inconclusive for this predicate value.

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:

  • notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it).
  • missingInput: a cotarget expression returned an empty node set.
  • notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

R0011 An RMD MUST NOT fault a CreateSequence due to the presence of the Offer element. TESTABLE RSP0011

Test Assertion Analysis:

RSP0011

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[
(@type = 'response' and @conversation = $target/../../@conversation) or
(.//*:Envelope/*:Header/wsa:RelatesTo[not (@RelationshipType) or ( @RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' ) ] = $target/*:Header/wsa:MessageID)
]/wsil:messageContents/*:Envelope

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:

HELP - GLOSSARY

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:

  • passed
  • failed
  • warning
  • notApplicable
  • notRelevant
  • missingInput
  • undetermined

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).
- A result of false means the requirement is violated (reported as a "failed" 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:

  • mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT)
  • preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED
  • permitted: maps to RFC2119 keywords MAY, OPTIONAL.

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:

  • @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed')
  • @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed')

The reported outcomes have the following meaning:

  • passed: the target passes the test and can be considered as fulfilling the profile feature.
  • failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature.
  • warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation.
  • undetermined: the test result is inconclusive for this predicate value.

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:

  • notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it).
  • missingInput: a cotarget expression returned an empty node set.
  • notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

3.4 Sequence Identifiers

Under certain conditions it is possible for the CreateSequence or CreateSequenceResponse messages to be lost or delayed. Depending upon the timing of the attempts to resend such messages, it is possible to receive duplicate CreateSequence or CreateSequenceResponse messages (in fact, it is possible to receive duplicate messages even without retries). This creates the potential for CreateSequence and CreateSequenceResponse messages that contain duplicate Sequence Identifiers. Furthermore there are situations in which one party (RMS or RMD) may erroneously send a CreateSequence or CreateSequenceResponse message with a duplicate Sequence Identifier. Due to the crucial role of Sequence Identifiers in the WS-RM protocol, the handling of duplicate Sequence Identifiers needs to be further refined to prevent interoperability problems.

3.4.1 Duplicate Identifier in CreateSequenceResponse

Regardless of the causative circumstances, the existence of two, non-terminated Sequences with the same Identifier makes it difficult for the RMS to correctly function, therefore the RMS should take steps to prevent this condition.

R0700 The RMS MUST generate a fault when it receives a CreateSequenceResponse that contains a Sequence Identifier that is the same as the Identifier of a non-terminated Sequence. NOT_TESTABLE COM0700

Test Assertion Analysis:

COM0700

General Notes:

not testable since generated faults may not be visible or if testable will never fail

Coverage Assessment:

Target Type:

Test Target:

Test co-Target(s):

Test Prerequisite:

Predicate:

Prescription:

mandatory

Reporting:

Test Control:

 

Test Assertion:

COM0700

Description:

Target:

Predicate:

Reporting:

true=passed, false=failed

Prescription:

mandatory

Error Message:

Diagnostic Data:

HELP - GLOSSARY

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:

  • passed
  • failed
  • warning
  • notApplicable
  • notRelevant
  • missingInput
  • undetermined

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).
- A result of false means the requirement is violated (reported as a "failed" 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:

  • mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT)
  • preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED
  • permitted: maps to RFC2119 keywords MAY, OPTIONAL.

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:

  • @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed')
  • @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed')

The reported outcomes have the following meaning:

  • passed: the target passes the test and can be considered as fulfilling the profile feature.
  • failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature.
  • warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation.
  • undetermined: the test result is inconclusive for this predicate value.

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:

  • notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it).
  • missingInput: a cotarget expression returned an empty node set.
  • notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

Note that this requirement does not differentiate between duplicate Identifiers created by "the same" RMD or "different" RMDs; the simple fact that the RMS already has an active Sequence with the same Identifier is enough to trigger this requirement.

3.5 Sequence Termination

Termination of sequences must be done in a way to ensure that both the RMS and RMD share a common understanding of the final status of the sequence. The Profile places the following requirements on termination procedures:

3.5.1 Sequence Termination from the Destination

An RMS may need to get a final sequence acknowledgment, for supporting a particular delivery assurance. This is only possible after the sequence is closed and before it is terminated. When the termination is decided by the RMD, the RMS must also be made aware of this closure so that it can request a final acknowledgement.

R0200 In the case where an RMD decides to discontinue a sequence, it MUST close the Sequence and MUST attempt to send a wsrm:CloseSequence message to the AcksTo EPR. NOT_TESTABLE COM0200

Test Assertion Analysis:

COM0200

General Notes:

untestable without ESP, hard to simulate an rmd autonomous decision to discontinue a sequence hard to impossible.

Coverage Assessment:

Target Type:

Test Target:

Test co-Target(s):

Test Prerequisite:

Predicate:

Prescription:

mandatory

Reporting:

Test Control:

 

Test Assertion:

COM0200

Description:

Target:

Predicate:

Reporting:

true=passed, false=failed

Prescription:

mandatory

Error Message:

Diagnostic Data:

HELP - GLOSSARY

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:

  • passed
  • failed
  • warning
  • notApplicable
  • notRelevant
  • missingInput
  • undetermined

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).
- A result of false means the requirement is violated (reported as a "failed" 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:

  • mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT)
  • preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED
  • permitted: maps to RFC2119 keywords MAY, OPTIONAL.

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:

  • @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed')
  • @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed')

The reported outcomes have the following meaning:

  • passed: the target passes the test and can be considered as fulfilling the profile feature.
  • failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature.
  • warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation.
  • undetermined: the test result is inconclusive for this predicate value.

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:

  • notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it).
  • missingInput: a cotarget expression returned an empty node set.
  • notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

3.5.2 Last Message Number

Among other benefits, the use of Sequence Message Numbers makes an RMD aware of gaps - messages it has not received - in a sequence. For this awareness to apply to messages missing from the end of a sequence the RMD must be aware of the highest message number sent.

R0210 Any ENVELOPE containing either a wsrm:CloseSequence or a wsrm:TerminateSequence element MUST also contain a wsrm:LastMsgNumber element if the Sequence in question contains at least one Sequence Traffic Message. TESTABLE RSP0210

Test Assertion Analysis:

RSP0210

General Notes:

Coverage Assessment:

Good

Target Type:

ENVELOPE (either CS or TS)

Test Target:

For a soap:Envelope with either a wsrm:CloseSequence or a wsrm:TerminateSequence element in the soap:Body

Test co-Target(s):

Test Prerequisite:

Predicate:

the Envelope also contains wsrm:LastMsgNumber: proposed XPath= se:Body/wsrm:*/wsrm:LastMsgNumber

Prescription:

mandatory

Reporting:

true=pass, false=fail

Test Control:

Generate either a wsrm:CloseSequence message, or a wsrm:TerminateSequence

 

Test Assertion:

RSP0210

Description:

The soap:envelope in the message also contains a wsrm:LastMsgNumber element if it has a wsrm:CloseSequence or a wsrm:TerminateSequence element.

Target:

//wsil:messageContents/*:Envelope[
*:Body/wsrm:CloseSequence or *:Body/wsrm:TerminateSequence
]

Predicate:

*:Body/wsrm:*/wsrm:LastMsgNumber

Reporting:

true=passed, false=failed

Prescription:

mandatory

Error Message:

The soap:envelope in a wsrm:CloseSequence or a wsrm:TerminateSequence message does not contain a wsrm:LastMsgNumber element.

Diagnostic Data:

{SOAP message}

HELP - GLOSSARY

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:

  • passed
  • failed
  • warning
  • notApplicable
  • notRelevant
  • missingInput
  • undetermined

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).
- A result of false means the requirement is violated (reported as a "failed" 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:

  • mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT)
  • preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED
  • permitted: maps to RFC2119 keywords MAY, OPTIONAL.

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:

  • @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed')
  • @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed')

The reported outcomes have the following meaning:

  • passed: the target passes the test and can be considered as fulfilling the profile feature.
  • failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature.
  • warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation.
  • undetermined: the test result is inconclusive for this predicate value.

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:

  • notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it).
  • missingInput: a cotarget expression returned an empty node set.
  • notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

There is a corner case for sequences in which no messages have been sent (i.e. empty sequences). In these cases it is permissable to omit wsrm:LastMsgNumber since there is no valid value for this element.

3.5.3 Sequence Lifecycle Independence

WS-ReliableMessaging is unclear about the relationship, if any, between the lifecycles of a Sequence and its corresponding Offered Sequence. Considering that such a relationship is not necessary for the proper functioning of the WS-RM protocol and that the existence of a such a relationship would create unnecessary and undesirable interdependencies between the RMS and the RMD, this profile makes the clarifying requirement that no such relationship exists.

R0220 An RM-NODE (RMD or RMS) MUST NOT assume that the termination (or closure) of a Sequence implicitly terminates (or closes) any other Sequence. NOT_TESTED

3.6 Sequence Faults

This Profile adds the following requirement to the handling of faults that are generated as the result of processing WS-RM Sequence Lifecycle messages.

3.6.1 Transmission of Sequence Faults

In Section 4, "Faults" WS-ReliableMessaging states that a receiver that generates a fault related to a known sequence SHOULD transmit that fault. However, the WS-I Basic Profile 1.2 states, in requirement R1029, that, under certain circumstances, the receiver must transmit the fault. Mapping the specifics of the BP 1.2 requirement onto the details of the WS-RM specification results in the following requirement:

R0400 If a fault is generated while processing a wsrm:CreateSequence, wsrm:CloseSequence, or wsrm:TerminateSequence message, or a message containing a wsrm:AckRequested header, the RECEIVER MUST transmit the fault. TESTABLE_SCENARIO_DEPENDENT RSP0400a RSP0400b

Test Assertion Analysis:

RSP0400a

General Notes:

NOTE1: needs artificial traffic generation to stimulate fault; if then easy, might need to use signature of corruption and correlation to fault or lack thereof.NOTE2: Test env. can cause a fault situation for one of the RM protocol mesg, and then we must observe a correlating Fault in the log. NOTE3: TA will only test some of the faulty cases (partial coverage)

Coverage Assessment:

partial, due to lack of exhaustive coverage of cases.

Target Type:

ENVELOPE (of RM protocol message)

Test Target:

For a faulty RM protocol message above (based on predefined test control protocol)

Test co-Target(s):

Test Prerequisite:

Predicate:

There is a related Fault message in response, in the log.

Prescription:

mandatory

Reporting:

true=pass, false=fail

Test Control:

Generate a faulty RM protocol message, or using MIM corrupt a correctly generated one.

 

Test Assertion:

RSP0400a

Description:

Target:

/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[
*:Body/wsrm:CloseSequence or
*:Body/wsrm:TerminateSequence or
*:Header/wsrm:AckRequested]
[.//wsrm:Identifier = 'http://dummy.examples.org/unknown/nmspace']

co-Target: myresponse

/wsil:testLog/wsil:messageLog/wsil:message[
(@type = 'response' and @conversation = $target/../../@conversation) or
(.//*:Envelope/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] =
$target/*:Header/wsa:MessageID)
]
/wsil:messageContents/*:Envelope

Predicate:

$myresponse//*:Body/*:Fault

Reporting:

true=passed, false=failed

Prescription:

mandatory

Error Message:

Warning: A fault must have been generated due to unrecognized RM sequence ID in wsrm:CloseSequence, wsrm:TerminateSequence or *:Header/wsrm:AckRequested message, but the fault was not transmitted as response.

Diagnostic Data:

HELP - GLOSSARY

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:

  • passed
  • failed
  • warning
  • notApplicable
  • notRelevant
  • missingInput
  • undetermined

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).
- A result of false means the requirement is violated (reported as a "failed" 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:

  • mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT)
  • preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED
  • permitted: maps to RFC2119 keywords MAY, OPTIONAL.

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:

  • @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed')
  • @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed')

The reported outcomes have the following meaning:

  • passed: the target passes the test and can be considered as fulfilling the profile feature.
  • failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature.
  • warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation.
  • undetermined: the test result is inconclusive for this predicate value.

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:

  • notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it).
  • missingInput: a cotarget expression returned an empty node set.
  • notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

Test Assertion Analysis:

RSP0400b

General Notes:

NOTE1: needs artificial traffic generation to stimulate fault; if then easy, might need to use signature of corruption and correlation to fault or lack thereof.NOTE2: Test env. can cause a fault situation for one of the RM protocol mesg, and then we must observe a correlating Fault in the log. NOTE3: TA will only test some of the faulty cases (partial coverage)

Coverage Assessment:

partial, due to lack of exhaustive coverage of cases.

Target Type:

ENVELOPE (of RM protocol message)

Test Target:

For a faulty RM protocol message above (based on predefined test control protocol)

Test co-Target(s):

Test Prerequisite:

Predicate:

There is a related Fault message in response, in the log.

Prescription:

mandatory

Reporting:

true=pass, false=fail

Test Control:

Generate a faulty RM protocol message, or using MIM corrupt a correctly generated one.

 

Test Assertion:

RSP0400b

Description:

Target:

/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[
*:Body/wsrm:CloseSequence or
*:Body/wsrm:TerminateSequence or
*:Header/wsrm:AckRequested]
[.//wsrm:Identifier = 'http://dummy.examples.org/unknown/nmspace']

co-Target: myresponse

/wsil:testLog/wsil:messageLog/wsil:message[
(@type = 'response' and @conversation = $target/../../@conversation) or
(.//*:Envelope/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] =
$target/*:Header/wsa:MessageID)
]
/wsil:messageContents/*:Envelope

Predicate:

not($myresponse//*:Body/wsrm:CreateSequenceResponse) and not($myresponse//*:Body/wsrm:TerminateSequenceResponse) and not($myresponse//*:Header/wsrm:SequenceAcknowledgement)

Reporting:

true=passed, false=failed

Prescription:

mandatory

Error Message:

A legitimate response - either a wsrm:CreateSequenceResponse or a wsrm:TerminateSequenceResponse or a wsrm:SequenceAcknowledgement - has been sent back to a lifecycle management message that contained an unrecognizable sequence ID.

Diagnostic Data:

HELP - GLOSSARY

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:

  • passed
  • failed
  • warning
  • notApplicable
  • notRelevant
  • missingInput
  • undetermined

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).
- A result of false means the requirement is violated (reported as a "failed" 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:

  • mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT)
  • preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED
  • permitted: maps to RFC2119 keywords MAY, OPTIONAL.

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:

  • @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed')
  • @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed')

The reported outcomes have the following meaning:

  • passed: the target passes the test and can be considered as fulfilling the profile feature.
  • failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature.
  • warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation.
  • undetermined: the test result is inconclusive for this predicate value.

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:

  • notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it).
  • missingInput: a cotarget expression returned an empty node set.
  • notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

3.6.2 WS-ReliableMessaging Faults

The use of WS-ReliableMessaging for faults that are themselves related to the WS-RM protocol is undefined and unlikely to be interoperable. Accordingly this profile prohibits the assignment of WS-RM fault messages to a WS-RM Sequence.

R0620 An ENVELOPE that has wsrm:SequenceTerminated, wsrm:UnknownSequence, wsrm:InvalidAcknowledgement, wsrm:MessageNumberRollover, wsrm:CreateSequenceRefused, wsrm:SequenceClosed, or wsrm:WSRMRequired as the value of either the SOAP 1.2 /S:Fault/S:Code/S:Subcode/S:Value element or the /wsrm:SequenceFault/wsrm:FaultCode element MUST NOT contain a wsrm:Sequence header block. TESTABLE RSP0620

Test Assertion Analysis:

RSP0620

General Notes:

This is a simple case of creating an assertion that tests for the co-occurrence of the elements that the requirement states shouldn‚€™t occur together.

Coverage Assessment:

Good

Target Type:

ENVELOPE

Test Target:

A SOAP Envelope in which any of the following appear: a. wsrm:SequenceTerminated b. wsrm:UnknownSequence c. wsrm:InvalidAcknowledgment d. wsrm:MessageNumberRollover e. wsrm:CreateSequenceRefused f. wsrm:SequenceClosed g. wsrm:WSRMRequired

Test co-Target(s):

Test Prerequisite:

Predicate:

The [target] does not contain a wsrm:Sequence header.

Prescription:

mandatory

Reporting:

true=pass, false=fail

Test Control:

TBD ‚€“ a scenario that causes either a wsrm:SequenceTerminated or wsrm:UnknownSequence fault.

 

Test Assertion:

RSP0620

Description:

Target:

/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
[*:Body/*:Fault//*:Value[node() = 'wsrm:SequenceTerminated' or
node() = 'wsrm:UnknownSequence' or
node() = 'wsrm:InvalidAcknowledgement' or
node() = 'wsrm:MessageNumberRollover' or
node() = 'wsrm:CreateSequenceRefused' or
node() = 'wsrm:SequenceClosed' or
node() = 'wsrm:WSRMRequired']]

Predicate:

not(./*:Header ) or ./*:Header[not (wsrm:Sequence) ]

Reporting:

true=passed, false=failed

Prescription:

mandatory

Error Message:

A wsrm error message contains a wsrm:Sequence header.

Diagnostic Data:

HELP - GLOSSARY

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:

  • passed
  • failed
  • warning
  • notApplicable
  • notRelevant
  • missingInput
  • undetermined

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).
- A result of false means the requirement is violated (reported as a "failed" 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:

  • mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT)
  • preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED
  • permitted: maps to RFC2119 keywords MAY, OPTIONAL.

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:

  • @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed')
  • @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed')

The reported outcomes have the following meaning:

  • passed: the target passes the test and can be considered as fulfilling the profile feature.
  • failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature.
  • warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation.
  • undetermined: the test result is inconclusive for this predicate value.

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:

  • notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it).
  • missingInput: a cotarget expression returned an empty node set.
  • notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

3.7 Sequence Assignment

WS-ReliableMessaging is silent on the mechanism for assigning messages (either request messages or response messages) to a particular Sequence. While this flexibility is beneficial from a general web services specification perspective, it creates some interoperability issues.

3.7.1 Sequence Assignment for Reliable Response Messages

Given a scenario in which a consumer and a provider engage in a series of reliable request/response exchanges, it is important for the consumer and provider to have a common understanding of the Sequence assignment mechanism for reliable response messages. Without such an understanding it is impossible, for example, to implement in-order delivery for response messages.

R0600 Any two ENVELOPEs that are sent reliably by an RMS in response - either as a replies or as faults - to two request messages that were sent within the same Sequence, SHOULD contain the same wsrm:Identifier (that is, share the same Sequence). TESTABLE RSP0600

Test Assertion Analysis:

RSP0600

General Notes:

NOTE1: only a recommendation. TA will be useful to assess the behavior of implementations, if not to assess conformance. NOTE2: no requirement the response sequence is resulting from an offer?

Coverage Assessment:

Good

Target Type:

ENVELOPE (with RM header)

Test Target:

For an Envelope E1b that is sent reliably in response to another Envelope E1a sent reliably, if there exists an Envelope E2b that is sent reliably in response to another Envelope E2a sent reliably in the same sequence as E1a.

Test co-Target(s):

Test Prerequisite:

Predicate:

every Envelope E2b matching the context has same wsrm:Identifier as E1b.

Prescription:

preferred

Reporting:

(default)

Test Control:

 

Test Assertion:

RSP0600

Description:

Target:

/wsil:testLog/wsil:messageLog/wsil:message

[@type = 'response' and .//*:Header/wsrm:Sequence]
[some $resp1 in . satisfies
some $req1 in /wsil:testLog/wsil:messageLog/wsil:message[@type = 'request' and (@conversation = $resp1/@conversation or .//*:Header/wsa:MessageID = $resp1//wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)]) and
.//*:Header/wsrm:Sequence] satisfies

$req1/preceding::wsil:message[@type = 'request' and
(.//*:Header/wsrm:Sequence/wsrm:Identifier = $req1//*:Header/wsrm:Sequence/wsrm:Identifier) and
(.//*:Header/wsa:ReplyTo/wsa:Address = $req1//*:Header/wsa:ReplyTo//wsa:Address or
(not(.//*:Header/wsa:ReplyTo) and not($req1//*:Header/wsa:ReplyTo)) )]

]

co-Target: siblingresp

/wsil:testLog/wsil:messageLog/wsil:message
[@type = 'response']
[
some $resp2 in . satisfies

some $req2 in ./preceding::wsil:message[@type = 'request' and (@conversation = $resp2/@conversation or .//*:Header/wsa:MessageID = $resp2//wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] )] satisfies

some $req1 in $req2/following::wsil:message[@type = 'request' and .//*:Header/wsrm:Sequence/wsrm:Identifier = $req2//*:Header/wsrm:Sequence/wsrm:Identifier] satisfies

($req1/@conversation = $target/@conversation or $req1//*:Header/wsa:MessageID = $target//wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)])
and
($req2//*:Header/wsa:ReplyTo/wsa:Address = $req1//*:Header/wsa:ReplyTo/wsa:Address or (not($req2//wsa:ReplyTo) and not($req1//wsa:ReplyTo)))

]
[fn:last()]

Predicate:

$siblingresp//*:Header/wsrm:Sequence/wsrm:Identifier = $target//*:Header/wsrm:Sequence/wsrm:Identifier

Reporting:

true=passed, false=failed

Prescription:

preferred

Error Message:

Two Message envelopes E1resp and E2resp were sent reliably (RM) as responses to two other envelopes E1req and E2req that both belong to the same RM sequence. Yet, E1resp and E2resp do not belong to teh same RM sequence.

Diagnostic Data:

HELP - GLOSSARY

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:

  • passed
  • failed
  • warning
  • notApplicable
  • notRelevant
  • missingInput
  • undetermined

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).
- A result of false means the requirement is violated (reported as a "failed" 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:

  • mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT)
  • preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED
  • permitted: maps to RFC2119 keywords MAY, OPTIONAL.

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:

  • @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed')
  • @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed')

The reported outcomes have the following meaning:

  • passed: the target passes the test and can be considered as fulfilling the profile feature.
  • failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature.
  • warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation.
  • undetermined: the test result is inconclusive for this predicate value.

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:

  • notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it).
  • missingInput: a cotarget expression returned an empty node set.
  • notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

Note that the RMS referred to above is a "server-side RMS" (i.e. the RMS responsible for transmitting response messages from the producer to the consumer in a reliable fashion).

3.7.2 Scope of an RM Node

WS-ReliableMessaging does not define the scope of an RM node other that to say that the scope is not restricted. For example, with respect to R0600 above, an Offered Sequence should be used to carry the response to any message sent over the Sequence corresponding to the CreateSequence request that included the Offer. However, it should not be assumed that the Sequence Traffic Messages carried over the Offered Sequence must be addressed to a particular response endpoint.

R0610 The scope of an RM Node is an implementation choice that MUST NOT be constrained by the remote RM-NODE. For example, the RMD MUST NOT constrain the values used by the RMS in the wsa:ReplyTo EPRs used by the RMS to be the same for all request messages (Sequence and Lifecycle messages). TESTABLE RSP0610

Test Assertion Analysis:

RSP0610

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:

RSP0610

Description:

Target:

/wsil:testLog/wsil:messageLog/wsil:message
[@type = 'response' and .//*:Header/wsrm:Sequence]
[some $resp1 in . satisfies

some $req1 in /wsil:testLog/wsil:messageLog/wsil:message[@type = 'request' and (@conversation = $resp1/@conversation or .//*:Header/wsa:MessageID = $resp1//wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)]) and .//*:Header/wsrm:Sequence] satisfies

$req1/preceding::wsil:message[@type = 'request' and (.//*:Header/wsrm:Sequence/wsrm:Identifier = $req1//*:Header/wsrm:Sequence/wsrm:Identifier) and ( not(.//*:Header/wsa:ReplyTo/wsa:Address = $req1//*:Header/wsa:ReplyTo/wsa:Address))]

]

co-Target: siblingresp

/wsil:testLog/wsil:messageLog/wsil:message
[@type = 'response']
[
some $resp2 in . satisfies
some $req2 in ./preceding::wsil:message[@type = 'request' and (@conversation = $resp2/@conversation or .//*:Header/wsa:MessageID = $resp2//wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] )] satisfies
some $req1 in $req2/following::wsil:message[@type = 'request' and .//*:Header/wsrm:Sequence/wsrm:Identifier = $req2//*:Header/wsrm:Sequence/wsrm:Identifier] satisfies

($req1/@conversation = $target/@conversation or $req1//*:Header/wsa:MessageID = $target//wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)]) and not($req2//*:Header/wsa:ReplyTo/wsa:Address = $req1//*:Header/wsa:ReplyTo/wsa:Address ) and ($req2//wsa:ReplyTo or $req1//wsa:ReplyTo)

]
[fn:last()]

Predicate:

$siblingresp//*:Header/wsrm:Sequence/wsrm:Identifier = $target//*:Header/wsrm:Sequence/wsrm:Identifier

Reporting:

true=passed, false=failed

Prescription:

mandatory

Error Message:

Warning: Two response messages sent reliably (RM) and related to two request messages sent over the same RM sequence, should have been sent over the same RM sequence (according to R0600) and yet were sent over different sequences. Please verify this is not because they were sent to two different EPRs.

Diagnostic Data:

HELP - GLOSSARY

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:

  • passed
  • failed
  • warning
  • notApplicable
  • notRelevant
  • missingInput
  • undetermined

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).
- A result of false means the requirement is violated (reported as a "failed" 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:

  • mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT)
  • preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED
  • permitted: maps to RFC2119 keywords MAY, OPTIONAL.

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:

  • @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed')
  • @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed')

The reported outcomes have the following meaning:

  • passed: the target passes the test and can be considered as fulfilling the profile feature.
  • failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature.
  • warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation.
  • undetermined: the test result is inconclusive for this predicate value.

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:

  • notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it).
  • missingInput: a cotarget expression returned an empty node set.
  • notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

Within this context the phrase "scope of an RM node" is defined as "the set of all EPRs that address a given RM node".

3.8 Retransmission of Messages

WS-ReliableMessaging protocol requires retransmission of messages. The Profile places the following restrictions and refinements on such retransmissions:

3.8.1 Retransmission of Unacknowledged Messages

To ensure reliable delivery of messages within a Sequence, it is necessary for the RMS to retransmit unacknowledged messages and for the RMD to accept them.

R0101 An RMS MUST continue to retransmit unacknowledged messages until the Sequence is closed or terminated. TESTABLE RSP0101

Test Assertion Analysis:

RSP0101

General Notes:

NOTE1:The TA should only apply when there is evidence of message resending. NOTE2: "continuation of resending" is hard to evaluate.

Coverage Assessment:

Partial

Target Type:

ENVELOPE(CS or CSR)

Test Target:

For either a CloseSequence message or a CloseSequenceResponse message sent by RMS, and if there is evidence of resending for a message sent before this CloseSequence[Response], over this sequence.

Test co-Target(s):

Test Prerequisite:

Predicate:

The same message is NOT resent after the CloseSequence[Response] was sent.

Prescription:

mandatory

Reporting:

true=pass, false=fail

Test Control:

The RM resending parameters are set in a way that a message capture log can reflect the actual resending over time. Sequence must be closed by RMD or RMD, before the resending schedule expires.

 

Test Assertion:

RSP0101

Description:

Target:

//wsil:messageContents/*:Envelope
[*:Body/wsrm:CloseSequence or *:Body/wsrm:TerminateSequence]
[some $seqid in *:Body//wsrm:Identifier satisfies
some $env1 in ./preceding::*:Envelope[*:Header/wsrm:Sequence/wsrm:Identifier = $seqid] satisfies

$env1/preceding::*:Envelope[*:Header/wsrm:Sequence/wsrm:Identifier = $seqid and *:Header/wsrm:Sequence/wsrm:MessageNumber = $env1/*:Header/wsrm:Sequence/wsrm:MessageNumber ]

]

Predicate:

not (
some $seqid in ./*:Body//wsrm:Identifier satisfies
(some $env1 in ./preceding::*:Envelope[*:Header/wsrm:Sequence/wsrm:Identifier = $seqid ] satisfies

(./following::*:Envelope[*:Header/wsrm:Sequence/wsrm:Identifier = $seqid and
*:Header/wsrm:Sequence/wsrm:MessageNumber = $env1/*:Header/wsrm:Sequence/wsrm:MessageNumber ]))

)

Reporting:

true=passed, false=failed

Prescription:

mandatory

Error Message:

A CloseSequence message or a TerminateSequence message was sent by RMS for a sequence that contains messages that have been resent. But the resending has not stopped after these terminating messages have been logged.

Diagnostic Data:

HELP - GLOSSARY

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:

  • passed
  • failed
  • warning
  • notApplicable
  • notRelevant
  • missingInput
  • undetermined

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).
- A result of false means the requirement is violated (reported as a "failed" 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:

  • mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT)
  • preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED
  • permitted: maps to RFC2119 keywords MAY, OPTIONAL.

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:

  • @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed')
  • @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed')

The reported outcomes have the following meaning:

  • passed: the target passes the test and can be considered as fulfilling the profile feature.
  • failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature.
  • warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation.
  • undetermined: the test result is inconclusive for this predicate value.

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:

  • notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it).
  • missingInput: a cotarget expression returned an empty node set.
  • notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

R0102 An RMD MUST accept unacknowledged message until the Sequence is closed or terminated. TESTABLE RSP0102

Test Assertion Analysis:

RSP0102

General Notes:

NOTE1: a message should be intercepted, causing a gap in the Ack ranges. Regardless of how long the delay before resending , the message must finally be acknowledged if sequence not closed.

Coverage Assessment:

Good

Target Type:

ENVELOPE(with RM header)

Test Target:

For a message that is a resend, in a RM sequence that is not closed or terminated yet.

Test co-Target(s):

Test Prerequisite:

Predicate:

The message is not faulted by the RMD, AND the next acknowledgement shows it has been acknowledged.

Prescription:

mandatory

Reporting:

(default)

Test Control:

MIM to block messages, to cause significant delay in resending.

 

Test Assertion:

RSP0102

Description:

Target:

/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
[*:Header/wsrm:Sequence = preceding::*:Envelope/*:Header/wsrm:Sequence]
[some $tgenv in . satisfies

not( some $clseq in $tgenv/preceding::*:Envelope[*:Body/wsrm:CloseSequence or *:Body/wsrm:TerminateSequence ] satisfies
$clseq/*:Body//wsrm:Identifier = $tgenv/*:Header/wsrm:Sequence/wsrm:Identifier )

]

Predicate:

( some $env in following::*:Envelope[*:Header/wsrm:SequenceAcknowledgement/wsrm:Identifier = $target/*:Header/wsrm:Sequence/wsrm:Identifier] satisfies
some $ackrange in $env/*:Header/wsrm:SequenceAcknowledgement/wsrm:AcknowledgementRange satisfies

($ackrange/@Lower le $target/*:Header/wsrm:Sequence/wsrm:MessageNumber and
$ackrange/@Upper ge $target/*:Header/wsrm:Sequence/wsrm:MessageNumber)
) and
not (/wsil:testLog/wsil:messageLog/wsil:message[
(@type = 'response' and @conversation = $target/../../@conversation) or
(.//*:Envelope/*:Header/wsa:RelatesTo[not (@RelationshipType) or ( @RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' ) ] = $target/*:Header/wsa:MessageID)]
/wsil:messageContents/*:Envelope/*:Body/*:Fault )

Reporting:

true=passed, false=failed

Prescription:

mandatory

Error Message:

Warning: One of these two conditions occurred: (a) A resent message (reliable messaging) was not acknowledged before the closing/termination of the RM sequence, or (b) the resent message was faulted. In both cases, this could be a sign that the receiving RMD did not accept the resent message: to investigate further.

Diagnostic Data:

HELP - GLOSSARY

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:

  • passed
  • failed
  • warning
  • notApplicable
  • notRelevant
  • missingInput
  • undetermined

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).
- A result of false means the requirement is violated (reported as a "failed" 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:

  • mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT, REQUIRED (and sometimes MAY NOT)
  • preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED
  • permitted: maps to RFC2119 keywords MAY, OPTIONAL.

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:

  • @true attribute: may take values among {passed, failed, warning, undetermined} (default is 'passed')
  • @false attribute: may take values among {passed, failed, warning, undetermined} (default is 'failed')

The reported outcomes have the following meaning:

  • passed: the target passes the test and can be considered as fulfilling the profile feature.
  • failed: the target fails the test and can be considered as violating (or not exhibiting) the profile feature.
  • warning: the test result is inconclusive. There is a possibility of profile requirement violation, that deserved further investigation.
  • undetermined: the test result is inconclusive for this predicate value.

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:

  • notRelevant: the target failed the prerequisite condition and therefore does not qualify for further testing (i.e. the predicate expression is NOT evaluated on it).
  • missingInput: a cotarget expression returned an empty node set.
  • notApplicable: this target was not even selected by the target XPath expression, while being of the same general artifact type (e.g. message type).

Note: there are cases where it may be obvious that retransmitting a message is unlikey to result in an outcome that is any different from the previous, failed transmission(s). For example, in the case of HTTP, a 401 status code may indicate that access to an endpoint has been refused for the credentials that accompanied the request. Unless some action is taken to grant access to those credentials, retransmitting the request is likely to result in the same error and may cause negative side-effects such as the locking of an account due to "excessive failed login attempts".

3.8.2 Retransmission of Sequence Lifecycle Messages

WS-ReliableMessaging Section 2.1 defines the messages that affect the created/closing/closed/terminating state of a Sequence as "Sequence Lifecycle Messages". WS-RM is silent on what a SENDER (RMS or RMD) is expected to do when it either fails to send one of the messages or does not receive the corresponding response message (e.g. an RMS sends a CreateSequence message but does not receive a CreateSequenceResponse message).

R0110 When a SENDER fails to successfully send a Sequence Lifecycle Message or it does not receive the corresponding response message (if one exists), it is RECOMMENDED that the SENDER attempt to resend the message. The frequency and number of these retries are implementation dependent. NOT_TESTED

3.8.3 Message Identity

In cases where wsa:MessageID