The BBL provides a messaging API that is invoked with the BEA MessageQ call API but is implemented with WebSphere MQ. Application recoding is not required; instead, applications link with the BBL library and exchange messages with the same content and delivery options as they did when the applications were linked with libdmq. This technique provides an extremely powerful capability to migrate older (BEAmessageQ and DECmessageQ) applications to IBM WebSphere MessageQ without having to recode the applications. The BBL does not impose any custom headers or specific data in the messages and therefore messages can be exchanged with:

  1. Applications that use the WMQ API directly
  2. Applications using the BBL

These two types of message exchange exemplify the two services provide by the BBL:

  1. Transport, through which the BMQ API uses WMQ as a messaging transport;
  2. Bridging, through which:
    1. Applications using the BBL can send messages to WMQ queues for reading by applications that are using the WMQ API directly (i.e., that are not using the BBL);
    2. Applications using the WMQ API directly can write messages to WMQ queues which are then presented to BBL-based applications with meaningful BMQ addresses

The BBL is not a complete emulation of the entire BmQ API, but rather, it implements most of the BEAmessageQ functions and features but is not complete. The BBL operates in a WMQ Server environment and does not provide messaging service in a WMQ Client environment

Correct operation of applications using the BBL depends on a properly-configured WMQ environment. In particular:

  1. The WMQ Command Server (amqpcsea)
  2. The WMQ trigger monitor (runmqtrm)

are required for each queue manager environment which supports a BBL instance.

The BBL uses a configuration file to define the message queuing parameters needed to transfer the message data between the two message services. Applications implemented with the BmQ API use configuration information contained in the BmQ group initialization file. Applications which use the BBL read their configuration information from the BBL Configuration File. The contents of the BBL Configuration file are derived from the BmQ group initialization file. The following restrictions apply on the DECmessageQ/BEAmessageQ side:

  1. Only message quotas are enforced
  2. The following group initialization table sections are related to functions that are not implemented in the BBL and hence are ignored:
    1. %MRS
    2. %SBS
    3. %CLS
    4. %ROUTE
  3. The following items are related to functions that are not implemented in the BBL and hence are ignored:
    1. %PROFILE: All fields except FIRST_TEMP_QUEUE
    2. %QCT: byte-quota, UCB Send, Security, Confirmation style
    3. %XGROUP: All items except groups name and group number

The actual BBL configuration file contains:

  1. Contains information derived from two sources:
    1. BmQ bus- and group-specific information, used when an application performs a BmQ API (pams-xxx( )) call. This is information related to BBL’s transport service.
    2. BmQ-WMQ queue mapping, used in the BmQ-WMQ bridge. This is information related to BBL’s bridging service.
  2. is an ASCII text file using the familiar format: [SECTION]
  3. Must be readable by any application using the BBL.
  4. May have an arbitrary name
  5. Is automatically generated to contain all transport-related information
  6. Is automatically updated to add bridge-related information.

Certified by IBM for Linux on Intel & Linux on Power: