Marek Potociar's Blog

23Nov/090

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... :-)

PrefixNamespace
wsphttp://www.w3.org/ns/ws-policy
wsrmp10http://schemas.xmlsoap.org/ws/2005/02/rm/policy
wsrmphttp://docs.oasis-open.org/ws-rx/wsrmp/200702
net30rmphttp://schemas.microsoft.com/net/2005/02/rm/policy
net35rmphttp://schemas.microsoft.com/ws-rx/wsrmp/200702
sunrmphttp://sun.com/2006/03/rm
sunrmcphttp://sun.com/2006/03/rm/client
metrohttp://java.sun.com/xml/ns/metro/ws-rx/wsrmp/200702

Feature nameDescriptionWS-RM 1.0 compatible assertionWS-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.

/wsrmp10:RMAssertion/wsrmp10:ExponentialBackoff

("Exponential backoff" algorithm only)

/metro:RetransmissionConfig/metro:Algorithm
Maximum Retransmission Count


A message is considered to be transferred if its delivery at the recipient
has been acknowledged by the recipient.


If an acknowledgment has not been received within a certain amount of time
for a message that has been transmitted, the infrastructure automatically
retransmits the message. The infrastructure tries to send the message for
at most a preconfigured number of times. Not receiving an acknowledgment
before this limit is reached is considered a fatal communication failure,
and causes the RM session to fail.

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.

/sunrmcp:CloseTimeout

(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.

14Jan/081

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: , , , , , ,

Tagged as: 1 Comment
1Jun/072

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:
,
,
,
,
,
,

23Feb/070

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:
,
,
,
,
,
,
,

Tagged as: No Comments
22Feb/070

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:

  1. How does the service's interface look like?
  2. What is the format of the message payloads the service claims to understands?
  3. 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:
,
,
,
,
,
,
,

Tagged as: No Comments
18May/060

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):

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:
,
,
,
,
,
,