Index Changes
This is version 1. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

MQ BC: Integration 114789

Message Descriptor Support Overhaul

The Component's support for MQ Message Descriptors has been revised. The structure of the Component's header extensibility element was previously defined as having as content a sequence of specific elements that identify each descriptor; e.g.,

<mq:body ... />
    <mq:correlationId ... />
    <mq:applicationId ... />

There are currently a total of twenty-six MQ message descriptors exposed thru the WebSphere MQ Base Java API, only 2 of which are represented in the previous schema. Extending it to support the rest would have bloated the structure that the user needed to negotiate through. The structure has now been generalized:

<mq:body ... />
<mq:header descriptor="correlationId" .../>
<mq:header descriptor="applicationid" .../>

The WebSphere MQ Base Java API assigns to each message descriptor an appropriate Java data type representation, which the MQ Binding Component will now mind when deciding whether a given descriptor's value can be normalized (mapping from API data type to a XML Schema data type) or denormalized (from a XML Schema data type to an API data type).

Table: Supported API-XML Data Type Correspondence

Descriptor (example) API data type XML Schema data type(s)
applicationId java.lang.String {}string
correlationId byte[] {}base64binary
correlationId byte[] {}hexBinary
priority int {}integer
priority int {}string
putDateTime java.util.GregorianCalendar {}dateTime
putDateTime java.util.GregorianCalendar {}string

For message normalization, the element or type of the message part intended to hold the descriptor value determines if the translation is permitted. For example, mapping the descriptor correlationId, which holds binary data, to a part that is typed anything other than a base64binary or hexBinary is disallowed. In the case of message denormalization, the type of the descriptor corresponding to the message part holding the content determines how the character value is evaluated and into which API data type it is coerced. For example, the contents of a message part intended for a descriptor represented as a GregorianCalendar object must be typed dateTime or string to be accepted, and if so accepted the process will attempt to parse the content as a dateTime-formatted value.

Component WSDL/configuration validation and its runtime message normalizers have been modified to raise exceptions for any unsupported data type mapping.

JSPWiki v2.4.100
« Home Index Changes Prefs
This particular version was published on 13-Nov-08 11:23 AM, -0800 by NoelDAng