Index Changes

Systemic Quality: Redelivery

Sun-built JBI components use the Quality of Service (QoS) library to implement redelivery. The library supports parsing of design-time artifacts as well as runtime implementation of retry attempts.

Overview of Redelivery Rules.

  • Redelivery support in the common library consists of two separate pieces:
    • An API that allows components to define and query redelivery configuration and status information.
    • An implementation of the redelivery wire quality protocol.
  • Unique Message ID
    • Redelivery processing depends on the presence of a unique message id as a "standard" property on each message exchange. This message id is defined in QoS api ServiceQuality as
public static final String MESSAGE_ID	= "com.sun.jbi.messaging.messageid";
  • Redelivery parameters can be defined via QoS extensions in the service assembly jbi.xml. The redelivery implementation in the library automatically parses an endpoint's associated jbi.xml to determine QoS.
  • Redelivery status can also be reset if redelivery attempts have been exhausted. A component might use this feature if it wanted to restart the redelivery protocol in response to some user-initiated action.
  • Error Endpoint and Delete behaviors are limited to InOnly message exchange patterns. The Suspend behavior may be used with InOnly or InOut.

Redelivery configuration example


 <connections>
    <connection>
       <consumer endpoint-name="redeliverPTRole_partnerRole" service-name="ns1:redeliverPL" /> 
       <provider endpoint-name="javaee_port1" service-name="ns2:redeliverService" /> 
    </connection>
 </connections>
 <qos:connections>
    <qos:connection>
       <qos:consumer endpoint-name="redeliverPTRole_partnerRole" service-name="ns1:redeliverPL" /> 
       <qos:provider endpoint-name="javaee_port1" service-name="ns2:redeliverService" /> 
       <rd:redelivery maxAttempts="2" waitTime="1000">
          <rd:on-failure>
            [
             <rd:delete/> 
                 OR
             <rd:suspend/>
                 OR
             <rd:redirect endpoint-name="JmsServicePort" operation="JmsOper" service-name="ns1:JmsService"/>
                 OR
             <rd:error/>
            ]
          </rd:on-failure>
       </rd:redelivery>
    </qos:connection>
 </qos:connections>

Redelivery functionality

Redelivery configuration settings.

The user configures the each endpoint for redelivery through the CASA editor as shown in the configuration example above. The user can set the following redelivery parameters.

  • 'maxAttempts' : number of retries to attempt .
  • 'waitTime' : time to wait between redelivery attempts in milliseconds.
  • on-failure : type of action to be taken when redelivery attempts have been exhausted.

on-failure has three options that the user can configure.

  • Delete.
This option is supported only for InOnly message exchanges (ME). This implies that after the redelivery attempts have been exhausted the ME is simply deleted by the QoS utility and a 'Done' status is send back to the bpel-se, on which the bpel process proceeds with the next activity.
  • Redirect.
This option is supported for InOnly ME. The user would need to configure the 'endpoint' as the additional field. This implies that after the redelivery attempts have been exhausted the QoS utility would send the ME to the configured endpoint (ex: like a dead letter queue).
  • Suspend.
This option is supported for InOnly and InOut ME. This implies that after the redelivery attempts have been exhausted the bpel-se would have to suspend the instance of the bpel process. Suspend is only supported if monitoring is enabled in the bpel-se, since the user has to use the monitoring tool to resume a suspended instance.
  • Error.
This option is supported for InOnly and InOut ME. This is the default on-failure configuration in the event that user having defined the redelivery configuration may choose to not define the on-failure for this redelivery configuration.

Deployment of the configured service unit.

  • JBI components can use an instance of the QoS api 'com.sun.jbi.common.qos.messaging.MessagingChannel' as the 'DeliveryChannel' implementation. The channel has as an interceptor/wrapper that provides QoS capabilities and delegates to the actual 'DeliveryChannel' the messaging requirements.
  • On deployment an instance of 'com.sun.jbi.common.qos.descriptor.DeploymentLookup' is used within the component context to retrieve the configured QoS qualities for this SU.
  • The redelivery configuration 'com.sun.jbi.common.qos.redelivery.RedeliveryConfig' is retrieved for each endpoint in the deployed process.
  • The retrieved redelivery configuration for each endpoint is initialized with the QoS utility by way of the api's of the 'MessagingChannel'.

Runtime execution of redelivery.

For illustrative purposes, let us assume that user has configured the redelivery parameters as
'maxAttempts' : 2
'waitTime' : 1000ms

and for the 'on-failure' let us consider the three options.

  • delete (applicable only for InOnly ME, ex one-way invoke).
The JBI component will send and resend the ME till a 'Done' status is received for the ME. The QoS utility will attempt to deliver the message to the actual provisioning endpoint till the 'maxAttempts' count has been exhausted. It returns an 'Error' status for each failed attempt back to the JBI component, which will resend the ME. Finally on exhausting the 'maxAttempts' count the QoS utility will abandon the ME and return 'Done' status to the JBI component, which will resume execution of the process instance.
  • redirect (applicable only for InOnly ME, ex one-way invoke).
The behavior for this configuration is similar to the one for the 'delete' case above. The difference is that the QoS utility will route the ME to the configured redirect endpoint when the 'maxAttempts' count has been exhausted. If the QoS utility is successful in routing the message to the redirect endpoint, a 'Done' status is returned to the JBI component; otherwise, an 'Error' status is returned.
  • suspend.
The QoS utility in this case will always return an 'Error' status to the JBI component if it is not able to deliver the ME to the actual provisioning endpoint. The JBI component, before re-sending the ME to the QoS utility, will use the QoS utility api 'com.sun.jbi.common.qos.redelivery.RedeliveryStatus' to check if the 'hasFailed' api returns a false boolean value. If the 'hasFailed' api returns a true boolean value, the JBI component will suspend the process instance, allowing the instance to later resume.
  • error.
The QoS in this case will always return a 'Error' status to the JBI component if it is not able to deliver the ME to the actual provisioning endpoint. The JBI component, before re-sending the ME to the QoS utility will use the QoS utility api 'com.sun.jbi.common.qos.redelivery.RedeliveryStatus' to check if the 'hasFailed' api returns a false boolean value. If the 'hasFailed' api returns a true boolean value this indicates that the retries have been exhausted and the JBI component should throw an Exception.

Notes:

  • on-failure options of 'delete' and 'redirect' cannot be applied to InOut ME, because the InOut ME requires a response to be received for the process instance to proceed further and hence the return value for these options would not suffice.
  • if the on-failure condition is not specified in the jbi.xml for the redelivery configuration, the default will be the 'error' configuration.

Click Here for how to configure a BPEL endpoint for redelivery.

Note: Most of the content on this page prepared by Philip Varghese for BPELSERedelivery. Credit is due...

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-1) was last changed on 07-May-08 14:32 PM, -0700 by KevanSimpson