Metro Reliable Messaging Configuration Summary
I finally found time to write up a summary of all features that can be configured in Metro Reliable Messaging. Please check the tables bellow. Enjoy...
| Prefix | Namespace |
|---|---|
| wsp | http://www.w3.org/ns/ws-policy |
| wsrmp10 | http://schemas.xmlsoap.org/ws/2005/02/rm/policy |
| wsrmp | http://docs.oasis-open.org/ws-rx/wsrmp/200702 |
| net30rmp | http://schemas.microsoft.com/net/2005/02/rm/policy |
| net35rmp | http://schemas.microsoft.com/ws-rx/wsrmp/200702 |
| sunrmp | http://sun.com/2006/03/rm |
| sunrmcp | http://sun.com/2006/03/rm/client |
| metro | http://java.sun.com/xml/ns/metro/ws-rx/wsrmp/200702 |
| Feature name | Description | WS-RM 1.0 compatible assertion | WS-RM 1.1+ compatible assertion |
|---|---|---|---|
| Enable Reliable Messaging + version | Specifies that WS-ReliableMessaging protocol MUST be used when sending messages. Defines also the version of the WS-RM protocol to be used. | /wsrmp10:RMAssertion | /wsrmp:RMAssertion |
| Sequence Inactivity Timeout | Specifies the time interval beyond which either RM Source or RM Destination may terminate the RM sequence due to inactivity. The default setting is 600,000 milliseconds (10 minutes). A web service endpoint will always terminate session whose inactivity timeout has expired. Specified in milliseconds. | /wsrmp10:RMAssertion/wsrmp10:InactivityTimeout | /net35rmp:InactivityTimeout |
| Acknowledgement interval | Specifies the duration after which the RM Destination will transmit an acknowledgement. If omitted, there is no implied value. Specified in milliseconds. | /wsrmp10:RMAssertion/wsrmp10:AcknowledgementInterval | /net35rmp:AcknowledgementInterval |
| Retransmission Interval | Specifies how long the RM Source will wait after transmitting a message and before retransmitting the message. If omitted, there is no implied value. Specified in milliseconds. | /wsrmp10:RMAssertion/wsrmp10:BaseRetransmissionInterval/sunrmcp:ResendInterval | /metro:RetransmissionConfig/metro:Interval |
| Retransmission Interval Adjustment Algorithm | Specifies that the retransmission interval will be adjusted using a specific (e.g. exponential back-off) algorithm. |
("Exponential backoff" algorithm only) | /metro:RetransmissionConfig/metro:Algorithm |
| Maximum Retransmission Count |
| N/A | /metro:RetransmissionConfig/metro:MaxRetries |
| Close sequence timeout | By default, the call to proxy.close() will not return until all messages have been acknowledged. RM close timeout is the interval (in milliseconds) that the client runtime will block waiting for a call to close() to return. If there are still unacknowledged messages after this interval is reached, and the call to close has returned, an error will be logged about messages being lost. |
(client side only) | /metro:CloseSequenceTimeout |
| Acknowledgement request interval | Defines the suggested minimum time that the sender (RM Source) should allow to elapse between sending consecutive Acknowledgement request messages to the RM Destination. | /sunrmcp:AckRequestInterval | /metro:AckRequestInterval |
| Bind RM sequence to security token | Defines the requirement that an RM Sequence MUST be bound to an explicit token that is referenced from a wsse:SecurityTokenReference in the CreateSequence message. | N/A | /wsrmp:RMAssertion/wsp:Policy/wsrmp:SequenceSTR |
| Bind RM sequence to secured transport | Defines the requirement that an RM Sequence MUST be bound to the session(s) of the underlying transport-level protocol used to carry the CreateSequence and CreateSequenceResponse message. (When present, this assertion MUST be used in conjunction with the sp:TransportBinding assertion.) | N/A | /wsrmp:RMAssertion/wsp:Policy/wsrmp:SequenceTransportSecurity |
| Exactly once delivery | Each message is to be delivered exactly once; if a message cannot be delivered then an error MUST be raised by the RM Source and/or RM Destination. The requirement on an RM Source is that it SHOULD retry transmission of every message sent by the Application Source until it receives an acknowledgement from the RM Destination. The requirement on the RM Destination is that it SHOULD retry the transfer to the Application Destination of any message that it accepts from the RM Source until that message has been successfully delivered, and that it MUST NOT deliver a duplicate of a message that has already been delivered. | default | /wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy/wsrmp:ExactlyOnce |
| At Most once delivery | Each message is to be delivered at most once. The RM Source MAY retry transmission of unacknowledged messages, but is NOT REQUIRED to do so. The requirement on the RM Destination is that it MUST filter out duplicate messages, i.e. that it MUST NOT deliver a duplicate of a message that has already been delivered. | N/A | /wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy/wsrmp:AtMostOnce |
| At Least once delivery | Each message is to be delivered at least once, or else an error MUST be raised by the RM Source and/or RM Destination. The requirement on an RM Source is that it SHOULD retry transmission of every message sent by the Application Source until it receives an acknowledgement from the RM Destination. The requirement on the RM Destination is that it SHOULD retry the transfer to the Application Destination of any message that it accepts from the RM Source, until that message has been successfully delivered. There is no requirement for the RM Destination to apply duplicate message filtering. | /sunrmcp:AllowDuplicates | /wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy/wsrmp:AtLeastOnce |
| InOrder delivery | Messages from each individual Sequence are to be delivered in the same order they have been sent by the Application Source. The requirement on an RM Source is that it MUST ensure that the ordinal position of each message in the Sequence (as indicated by a message Sequence number) is consistent with the order in which the messages have been sent from the Application Source. The requirement on the RM Destination is that it MUST deliver received messages for each Sequence in the order indicated by the message numbering. This DeliveryAssurance can be used in combination with any of the AtLeastOnce, AtMostOnce or ExactlyOnce assertions, and the requirements of those assertions MUST also be met. In particular if the AtLeastOnce or ExactlyOnce assertion applies and the RM Destination detects a gap in the Sequence then the RM Destination MUST NOT deliver any subsequent messages from that Sequence until the missing messages are received or until the Sequence is closed. | /sunrmp:Ordered | /wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy/wsrmp:InOrder |
| Flow Control | Enables or disables the flow control feature. When enabled, this feature works in conjunction with the Max Buffer Size setting to determine the maximum number of messages for sequence that can be stored at the endpoint awaiting delivery to the application. Messages may have to be withheld from the application if ordered delivery is required and some of their predecessors have not arrived. If the number of stored messages reaches the threshold specified in the Max Buffer Size setting, incoming messages belonging to the sequence are ignored. | /net30rmp:RmFlowControl | /net30rmp:RmFlowControl |
| Maximum Flow Control Buffer Size | If Flow control is enabled, this value specifies the number of request messages that will be buffered in the RM session. The default setting is 32. For more information, see the description of the Flow Control option. | /net30rmp:RmFlowControl/net30rmp:MaxReceiveBufferSize | /net30rmp:RmFlowControl/net30rmp:MaxReceiveBufferSize |
| Maximum concurrent RM sessions | Specifies how many concurrently active RM sessions (measured based on inbound RM sequences) the SequenceManager dedicated to the WS Endpoint accepts before starting to refuse new requests for sequence creation. | N/A | /metro:MaxConcurrentSessions |
| Reliable Messaging Persistence | Specifies whether the runtime should use persistent sequence and message storage or not. | N/A | /metro:Persistent |
| Sequence manager maintenace task execution period | Specifies the period (in milliseconds) of a sequence maintenance task execution. Sequence maintenance task takes care of terminating inactive sequences and removing the terminated sequences from the sequence repository. | N/A | /metro:MaintenanceTaskPeriod |
This information is now available via official Metro User Guide too.
The new Policy project on java.net
Last week Fabian was putting together web pages and content of the new Policy project on java.net. Now the work is almost finished.
The development of the policy framework started as an integral part of the Web Services Interoperability Technology development efforts. In the near future we are, however, planning to integrate the policy framework directly into JAX-WS RI and the standalone Policy project will allow us to do just that. For more information about the next steps, check Fabian's blog.
Also, there is yet another very important reason why we separated the policy framework code into a new project. We wanted a playground for some experimenting with generic Policy API design. This API will be pursuing the following goals:
- independence of any particular policy language
- usability beyond the scope of web services applications
I am really excited to participate in this project.
Tags: GlassFish, WS-Policy, Web Services, Metro, JAX-WS, Project Tango, WSIT
WS-Policy the main force behind WSIT
These days we are focusing on fine-tuning quality of WSIT 1.0 that will be released soon. If you want do play with it, feel free to download the latest build. As there are no open issues in policy engine, I found some time to create a screencast (actually this is my first screencast ever!) about the WS-Policy and how it is used in WSIT. Enjoy!
Technorati:Interoperability,
Java,
J2EE,
Open Source,
Web Services,
WSIT,
WS-Policy
What Is Web Services Policy And How Does It Work? [Part 2]
In my last blog entry about WSIT project, I tried to explain WHAT policy means in context of web services. In this follow-up I will try to bring more light to the question HOW does it all work.
How does Web Services Policy work?
WS-Policy specification defines these key concepts:
- assertion - which is a construct that defines a single requirement or description of a single property of the web service behavior
- policy alternative - represented by a set of assertions. Each policy alternative describes single communication contracts a client needs to meet in order to communicate with a service.
- policy expression - defined as a set of policy alternatives.
- operations - such as merge and intersection of policy expressions play a major role in automated policy expression processing.
The mere fact that policy expression is a set of policy alternatives is one of the key factors that makes policy really powerful. This means that a web service may define more than one communication contract, for example to meet different capabilities of different clients. Client does not need to support every contract that web service defines. In order to successfully communicate with a service, a client just needs (using intersection and merge operations) to pick one policy alternative that describes communication requirements the client is able or willing to meet. This was maybe most obvious example how to exploit the concept of multiple policy alternatives. There are many more use cases of course. Multiple policy alternatives may be used for example to support web service versioning, client request routing etc. We do not even need to stay in the field of web services and SOA - this concept may be applied in other IT domains as well.
Sun has it's own implementation of a web service stack that supports WS-Policy processing. It is developed as a part of project WSIT also known as the "Project Tango". Anybody who ever tried to develop a client that communicates with a secured web service would agree that it is a quite painful process one needs to go through to get all the information about security aspects of the web service to be able to manually setup the secured communication channel between the service and the client. Well, with WSIT it is no longer an issue. As part of the automated policy processing client application automatically configures the communication channel according to the policies attached to the service. And this works even if the policy on the service is changed - there is no need to change implementation or configuration of the client application anymore. In case you want to know more, Fabian has a cool blog that explains some more details about WSIT. Technorati:GlassFish,
Interoperability,
Java,
J2EE,
Open Source,
Web Services,
WSIT,
WS-Policy
What Is Web Services Policy And How Does It Work? [Part 1]
WSIT project Milestone 3 was just released. And that is a great opportunity for me to try to share some thoughts that should help you to find the answer to the question from the title of this blog. Lets apply a divide and conquer strategy so that we can address the two topics the question contains separately. In this blog we would find out what the term web service policy actually means. We would look at how does it work tomorrow in my following blog.
What is web services policy?
More and more often when people speak about web services they would mention also policies. What are they talking about? If we try to look up the word "policy" in an encyclopedia you end up with a definition like this:
A policy is a plan of action to guide decisions and actions. The term may apply to government, private sector organizations and groups, and individuals. The policy process includes the identification of different alternatives, such as programs or spending priorities, and choosing among them on the basis of the impact they will have. Policies can be understood as political, management, financial, and administrative mechanisms arranged to reach explicit goals. (Wikipedia) If we go on and search for some more explanation in a dictionary, we discover that word "policy" is being described as a "course or plan of action", "statement of requirement" or "contract". Well, how does all that apply to our question? What is a policy in context of web services? In my opinion, definition of web service policy might look like this: Policy is a set of assertions (rules, requirements, obligations) that define properties of contract of web service based communication. Great! We have our definition! Still, what is this policy good for? The answer is not that difficult. When a client wants to communicate with a web service, first it must get some answers (in a machine readable way) to the following questions:- How does the service's interface look like?
- What is the format of the message payloads the service claims to understands?
- What are the other (behavioral) requirements I must meet to be able to talk to the service?
The answer to the first question is obvious - WSDL is the mechanism that provides web service interface description. Within a WSDL file we may also find the answer to the second question - usually nested XSD expressions are used to describe formats of the messages that a web service uses in communication with its clients. So far, so good. And how do we get the answer to the last question? How do we find out whether our web service has some security restrictions for instance? Web services policy language is the answer. A language that defines a way how to express and describe qualities and requirements of a web service in various domains, such as security, transaction, reliability of communication (reliable messaging), message exchange optimization. There are several efforts aimed to define a common and standard language for expressing web service policies in a machine readable way. One of such languages that seems to get lots of attention is the Web Services Policy Framework specification, or simply WS-Policy. This specification, which is currently undergoing the standardization process at W3C defines the common policy language constructs. The means of attaching policies to a web service are described in a separate specification called WS-Policy Attachments.
...and that's it for today. Do not forget to read my next blog entry tomorrow. And if you want to know more about WSIT project and it's WS-Policy implementation, check also a very nice article written by Fabian. Technorati:GlassFish,
Interoperability,
Java,
J2EE,
Open Source,
Web Services,
WSIT,
WS-Policy
A role of WS-Policy in WSIT
In my last blog I discussed the rise of a new era in SOA development with the use of Java Web Services technology powered by the implementation of WS-* specifications. Today, I would like to write few lines about policy metadata - the real core of these new technologies.
Policy language and its usage is described in two separate specifications (which have already been submitted for standardization by W3 Consortium):
- Web Services Policy Framework (WS-Policy) specification and
- Web Services Policy Attachment (WS-PolicyAttachment) specification
These two specifications bind all other WS-* specifications together into one complex solution.
The main goal of the WS-Policy specification is to introduce a flexible and extensible way of expressing and understanding the capabilities, requirements and general web service properties. In other words, WS-Policy provides a web services policy language together with domain-neutral rules as to how to process and interpret these policies. To complement the WS-Policy specification - which is strictly focused on defining policy language - WS-PolicyAttachment completes the whole picture by defining the means of attaching actual policy expresions to policy subjects to which these expressions apply. This second specification also describes the way how to use policies in the context of web services description mechanisms – WSDL and UDDI.
WSIT introduces its own policy engine and I am a part of a team working on its design and implementation. We do our best to make sure the implementation is interoperable and - of course - fully compliant with WS-Policy and WS-PolicyAttachment specifications. Currently, we are still in a development phase and there's much to be tested and polished yet. But we have already achieved success in supporting all main use case scenarios as well as having demonstrated our ability to interoperate with policy engines from other vendors at several Interoperability workshops.
...and if you want to know even more about policy, don't forget to check the blogs of Jakub and Fabian - my project Tango team-mates.
Technorati:
Interoperability,
Java,
J2EE,
open source,
web services,
wsit,
ws-policy