National language support implications

This section describes how the WebSphere MQ-bridge handles messages flowing between MQSeries systems that use different national languages. The diagram in Figure 25is used to describe the flow of a message from an WebSphere MQ Everyplace client application to a WebSphere MQ application.

Figure 25. Message flow from WebSphere MQ Everyplace to WebSphere MQ

Diagram showing a message flowing from a Palm Pilot through an MQe server to an MQSeries server. The flow consists of six stages that are described in detail below. The language transformation takes place at stage four, in the MQe-MQ bridge on the MQe server.

  1. Client application

    1. The client application builds an WebSphere MQ Everyplace message object containing the following data:

      A Unicode field
      This string is generated using appropriate libraries available on the client machine (if C/C++ is being used).

      A byte field
      This field should never be translated

      An ascii field
      This string has a very limited range of valid characters, conforming to the ASCII standard. The only valid characters are those that are invariant over all ASCII codepages.
    2. The message is put to the Palm queue manager. No translation is done during this put.
  2. Client queue manager puts to the server queue manager

    The message is not translated at all through this step.

  3. WebSphere MQ Everyplace server puts the message onto the WebSphere MQ-bridge queue

    The message is not translated at all through this step.

  4. WebSphere MQ-bridge passes the WebSphere MQ Everyplace message to the user-written transformer
    Note:
    The examples in this section are in Java because transformers can only be written in Java. (See Unsupported Java APIs

    The transformer creates a WebSphere MQ message as follows:

    If using writeString(), the character set of the string may also be set. The transformer returns the resultant WebSphere MQ message to the calling WebSphere MQ-bridge code.

  5. The WebSphere MQ-bridge passes the message to WebSphere MQ using the WebSphere MQ Classes for Java

    Unicode values in the WebSphere MQ message are translated from big-endian to little-endian, and vice-versa, as required. Byte values in the WebSphere MQ message are translated from big-endian to little-endian, and vice-versa, as required. The field that was created using writeString() is translated as the message is put to WebSphere MQ, using conversion routines inside the WebSphere MQ Classes for Java. ASCII data should remain ASCII data regardless of the character set conversions performed. The translations done during this step depend on the code page of the message, the CCSID of the sending WebSphere MQ Classes for Java client connection, and the CCSID of the receiving WebSphere MQ server connection.

  6. The message is got by a WebSphere MQ application

    If the message contains a unicode string, the application must deal with that string as a unicode string, or else convert it into some other format (UTF8 for example). If the message contains a byte string, the application may use the bytes as-is. (raw data). If the message contains a string, it is read from the message, and may be converted to a different data format as required by the application. This conversion is dependent on the codeset value in the characterSet header field.

Conclusion

If you have an WebSphere MQ Everyplace application, and wish to convey character-related data from WebSphere MQ Everyplace to WebSphere MQ, your choice of method is determined largely by the data you wish to convey:



© IBM Corporation 2002. All Rights Reserved