A new version of the open-source Java web services stack Metro v2.0 has been released today. This new release brings several notable new features, such as Configuration Management (check the short info), Persistent RM, experimental Declarative tubeline assembler (see here) as well as new enhancements in WS-Security, Trust and SecureConversation areas.

For the full documentation of all Metro features check the Metro user guide. Metro v2.0 runs on Tomcat, GlassFish V2 and is also shipped with GlassFish V3 — the first application server to support Java EE 6 — which was, same as Metro v2.0, released today.

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…

RM Configuration Namespace

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

This table contains XML namespaces used in WS-Policy assertions that are used to configure Metro Reliable Messaging

Reliable Messaging Configuration

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.

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.

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.

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.

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.

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 table contains summary information about all features that can be configured within Metro Reliable Messaging domain