hi barth,
i am providing info on how to make use of ws-rm,
reward me points if helpfull.
Abstract:
This specification describes a domain-specific policy assertion for WS-ReliableMessaging
that that can be specified within a policy alternative as defined in WS-Policy Framework .
By using the XML , SOAP , and WSDL extensibility
models, the WS* specifications are designed to be composed with each other to provide a rich
Web services environment. This by itself does not provide a negotiation solution for Web services.
This is a building block that is used in conjunction with other Web service and application-specific
protocols to accommodate a wide variety of policy exchange models.
Status:
This document is a work in progress and will be updated to reflect issues
1 Introduction
This specification defines a domain-specific policy assertion for reliable messaging for use with WS-Policy
and WS-ReliableMessaging .
1.1 Goals and Requirements
1.1.1 Requirements
1.2 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 RFC 2119 .
This specification uses the following syntax to define normative outlines for messages:
· The syntax appears as an XML instance, but values in italics indicate data types instead of values.
· Characters are appended to elements and attributes to indicate cardinality:
o "?" (0 or 1)
o "*" (0 or more)
o "+" (1 or more)
· The character "|" is used to indicate a choice between alternatives.
· The characters "[" and "]" are used to indicate that contained items are to be treated as a group
with respect to cardinality or choice.
· An ellipsis (i.e. "...") indicates a point of extensibility that allows other child, or attribute, content.
Additional children and/or attributes MAY be added at the indicated extension points but MUST
NOT contradict the semantics of the parent and/or owner, respectively. If an extension is not
recognized it SHOULD be ignored.
· XML namespace prefixes (See Section Namespace) are used to indicate the namespace of the
element being defined.
1.3 Namespace
The XML namespace URI that MUST be used by implementations of this specification is:
http://docs.oasis-open.org/ws-rx/wsrmp/200602
Dereferencing the above URI will produce the Resource Directory Description Language
document that describes this namespace.
Table 1 lists the XML namespaces that are used in this specification. The choice of any namespace prefix
is arbitrary and not semantically significant.
The following namespaces are used in this document
Table 1
Prefix Namespace Specification
wsp http://schemas.xmlsoap.org/ws/2004/09/policy
wsrmp http://docs.oasis-open.org/ws-rx/wsrmp/200602 This specification.
1.4 Compliance
An implementation is not compliant with this specification if it fails to satisfy one or more of the MUST or
REQUIRED level requirements defined herein. A SOAP Node MUST NOT use the XML namespace
identifier for this specification (listed in Section Namespace) within SOAP Envelopes unless it is compliant
with this specification.
Normative text within this specification takes precedence over normative outlines, which in turn take
precedence over the XML Schema descriptions.
2 RM Policy Assertions
WS-Policy Framework and WS-Policy Attachment collectively define
a framework, model and grammar for expressing the requirements, and general characteristics of entities
in an XML Web services-based system. To enable an RM Destination and an RM Source to describe their
requirements for a given Sequence, this specification defines a single RM policy assertion that leverages
the WS-Policy framework.
2.1 Assertion Model
The RM policy assertion indicates that the RM Source and RM Destination MUST use WSReliableMessaging
to ensure reliable delivery of messages. Specifically, the WSReliableMessaging
protocol determines invariants maintained by the reliable messaging endpoints and
the directives used to track and manage the delivery of a Sequence of messages.
2.2 Normative Outline
The normative outline for the RM assertion is:
<wsrmp:RMAssertion [wsp:Optional="true"]? ... >
...
</wsrmp:RMAssertion>
The following describes additional, normative constraints on the outline listed above:
/wsrmp:RMAssertion
A policy assertion that specifies that WS-ReliableMessaging protocol MUST be used for
a Sequence.
/wsrmp:RMAssertion/@wsp:Optional="true"
Per WS-Policy , this is compact notation for two policy alternatives, one with and one
without the assertion. The intuition is that the behavior indicated by the assertion is optional, or in
this case, that WS-ReliableMessaging MAY be used.
2.3 Assertion Attachment
Because the RM policy assertion indicates endpoint behavior over an RM Sequence, the assertion has
Endpoint Policy Subject .
WS-PolicyAttachment defines three WSDL policy attachment points with Endpoint Policy
Subject:
· wsdl:portType – A policy expression containing the RM policy assertion MUST NOT be attached to
a wsdl:portType; the RM policy assertion specifies a concrete behavior whereas the wsdl:portType is an
abstract construct.
· wsdl:binding – A policy expression containing the RM policy assertion SHOULD be attached to a
wsdl:binding.
· wsdl:port – A policy expression containing the RM policy assertion MAY be attached to a wsdl:port.
If the RM policy assertion appears in a policy expression attached to both a wsdl:port and its
corresponding wsdl:binding, the parameters in the former MUST be used and the latter ignored.
An RM policy assertion allows for extensibility as defined in Section 2.2. Because the WSRM specification
allows an RM Sequence to span multiple WSDL ports and/or endpoints, implementations or specifications
that make use of this capability should be aware that doing so may create situations in which multiple
policies containing extended RM policy assertions may apply to the same RM Sequence. The means and
mechanisms for collating and resolving conflicts between RM policy assertions attached to multiple
wsdl:bindings and/or wsdl:ports that participate in a single RM Sequence is not defined by this
specification. Users/creators of extended RM policy assertions are encouraged to consider and address
any possible conflicts in the content and semantics of the RM policy assertion extensions.
2.4 Assertion Example
Table 2 lists an example use of the RM policy assertion.
Table 2: Example policy with RM policy assertion
(01)<wsdl:definitions
(02) targetNamespace="example.com"
(03) xmlns:tns="example.com"
(04) xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
(05) xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
(06) xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200602"
(07) xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-wssecurity-utility-1.0.xsd">
(08)
(09) <wsp:UsingPolicy wsdl:required="true" />
(10)
(11) <wsp:Policy wsu:Id="MyPolicy" >
(12) <wsrmp:RMAssertion/>
(13) <!-- omitted assertions -->
(14) </wsp:Policy>
(15)
(16) <!-- omitted elements -->
(17)
(18) <wsdl:binding name="MyBinding" type="tns:MyPortType" >
(19) <wsp:PolicyReference URI="#MyPolicy" />
(20) <!-- omitted elements -->
(21) </wsdl:binding>
(22)
(23)</wsdl:definitions>
Line (09) in Table 2 indicates that WS-Policy is in use as a required extension.
Lines (11-14) are a policy expression that includes a RM policy assertion (Line 12) to indicate that WSReliableMessaging
must be used.
Lines (18-21) are a WSDL binding. Line (21) indicates that the policy in Lines (11-14) applies
to this binding, specifically indicating that WS-ReliableMessaging must be used over all the messages in
the binding.
3 Security Considerations
It is strongly RECOMMENDED that policies and assertions be signed to prevent tampering.
It is RECOMMENED that policies SHOULD NOT be accepted unless they are signed and have an
associated security token to specify the signer has proper claims for the given policy. That is, a relying
party shouldn't rely on a policy unless the policy is signed and presented with sufficient claims to pass the
relying parties acceptance criteria.
It should be noted that the mechanisms described in this document could be secured as part of a SOAP
message using WS-Security or embedded within other objects using object-specific security
mechanisms.
Web Services Reliable Messaging (WS-ReliableMessaging)
One of the goals of Enterprise Service Oriented Architecture (Enterprise SOA) is to modularize the large applications into well defined functional blocks called deployment units which can then be independently deployed, assembled and managed. Complex applications often involve more than one deployment units that exchange business messages. Mission critical applications need certain assurance that the business messages are exchanged in a reliable manner. In order to relieve the burden on each application to ensure reliable messaging and there by to simplify the overall application programming model, the application platform must provide features such as reliable messaging. In addition to intra-enterprise scenarios, reliable messaging is a critical requirement for B2B scenarios. The adoption of Web Services technologies by SAP for Enterprise SOA translates the previous requirement of reliable message exchange between deployment units into a specific technological requirement - Web Services Reliable Messaging. The OASIS Web Services Reliable Messaging standard is precisely aimed at standardizing this space and enables SAP customers to easily assemble applications on top of SAP as well as non-SAP building blocks.
The OASIS Web Services Reliable Exchange (WS-RX) Technical Committee (TC) was launched in Jun 2005 to further the development of contribution from some vendors. Due to its critical relevance to Enterprise SOA and the NetWeaver platform, SAP accepted co-chairing this TC and some of the SAP participants serve as editors of the specifications. As of this writing (May 2006), this TC has produced committee draft version 3 and is progressing well to finalize the specification some time in 2006. Several members of this TC including SAP have also successfully conducted a workshop in Mar 2006 for testing the interoperability between their implementations of the committee draft specification.
There are mainly two specifications worked on by the WS-RX TC:
1. WS-ReliableMessaging (WS-RM): Defines the protocol for reliable exchange of messages between the Source and the Destination systems.
2. WS-ReliableMessagingPolicy (WS-RMP): Defines the declarations a Destination system could make regarding its reliable messaging capabilities. Such declarations are commonly used to decorate the Service definitions offered by the Destination system.
Guarantee of delivery is the fundamental problem for any reliable messaging solution, and in this regard the WS-RM specification utilizes a well known solution of resending messages until an acknowledgement is received by the Source from the Destination. To enable detection of duplicate messages, each message is tagged with a unique identifier. For supporting advanced features such as retaining the order of the transmitted messages, the identifier of each message also includes its cardinal information. To facilitate grouping of messages to be delivered together in a reliable manner, the WS-RM specification defines the notion of a Sequence comprising of one or more messages; and the protocol defines creation and orderly termination of a Sequence. The WS-RM protocol also defines several other features that aid in optimization of the message exchange such as an ability for the Source to request the Destination for an acknowledgement of all the received messages.
for entire details info....go to this link
regards
karthik
dont forget to reward me points......
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.