Release 3 (8.1.7)
Part Number A83729-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Integration Server Overview Release 3 (8.1.7) Part Number A83729-01 |
|
This chapter introduces the Oracle Message Broker and contains these sections:
Oracle Message Broker is a Java-based message management subsystem that provides a message brokering facility to major message queuing systems including AQ, the IBM MQSeries, and the TIBCo Rendezvous. Its drivers provide a consistent, open, JMS-compliant API for these message queuing systems.
OMB provides its own proprietary volatile queuing and propagation. You can store its administrative metadata in a local or a remote LDAP server so that it operates independently of an Oracle database instance. OMB supports the JMS standard publish-subscribe, topic-based routing and supports both durable and non-durable subscribers. You can apply filters to the message control properties. OMB supports JMS transacted sessions.
The Oracle Message Broker consists of these components:
The Oracle Message Broker Core acts as a JMS provider. See Chapter 4, "Key Integration Concepts" as defined in the JMS standard.
Oracle Message Brokers in different locations communicate with one another and coordinate message transmission between brokers.
The Oracle Message Broker Core provides:
Oracle Message Broker provides five drivers that provide a JMS API to underlying message queuing systems. It uses the message queuing systems to provide persistence and message management.
The drivers also coordinate the translation of the messages into the native storage formats required for the message queuing systems to store the messages.
The drivers are:
The Oracle Message Broker uses an LDAP directory for storing and accessing administrative information. It includes a command line tool and a graphic tool for the administration and monitoring utilities. It also has a performance monitoring tool based on the ORB Dynamic Monitoring Service (DMS) of the Oracle Object Request Broker.
The client programming interface is the set of services offered by the Oracle Message Broker to Java client programs and is often referred to as the JMS API. A set of C++ class libraries offers a similar programmatic interface for C++ programmers.
Oracle Corporation provides a Java-based developers toolkit as part of Oracle Message Broker version 2 that you can use to develop adapters. The kit provides a framework that lets you develop programs of a standard construction and that supports three types of access to applications:
The toolkit enables you to link the application and queuing technology through JMS Queues/Topics, providing transaction management and basic exception management. The developer extends the framework by adding application API- specific calls, file-based access, or a JDBC connection, depending on the type of access to the application that is required.
The framework for SQL access converts XML-formatted messages dequeued from a JMS Queue/Topic to Business Components for Java (BC4J). SQL that is defined within the BC4J object applies changes to the application over a JDBC connection.
Oracle Corporation offers Java Messaging Services (JMS) through two products: Oracle Java Messaging Services and Oracle Message Broker. You must understand the differences between the two products to ensure that you make the best use of the products in the context of the specific requirement.
This section contains:
OJMS offers an AQ-only implementation of JMS with AQ extensions, and consequently it is inherently closely coupled with the database.
OMB offers non-extended Java Messaging Services over all the major messaging technologies including AQ and the OMB proprietary queuing mechanism. OMB is designed to use minimal space and to use LDAP services for its metadata. Its proprietary queuing mechanism (called volatile queues) enables it to offer non-durable subscription to JMS Topics.
The AQ driver that enables OMB to use AQ as a message store includes no extensions that enable you to use AQ features that do not appear in the JMS standard. However, OMB offers publish-subscribe routing using JMS Topics and applies message filtering at the point of message collection. The OJMS driver does not offer message filtering.
Consider using Oracle Message Broker if these factors are functionally or architecturally important:
If you use either OMB, OJMS, or both in an integration solution, look carefully at these compatibility considerations:
Unfortunately, the different JMS implementations are incompatible, both with each other and with the native APIs, because they use different attributes in the AQ repository to record the JMS message properties and payload. Consequently, messages created using one JMS API (for instance, the OMB JMS AQ Driver) must be transformed before they can be collected by another JMS API (for instance, the OJMS API). You must dequeue the message using one of the native AQ APIs, manipulate the message properties and JMS properties, and sometimes separate the JMS properties from the payload before enqueuing the message in the new format to a compatible queue.
OMB has a number of drivers that enable the Oracle AQ, the TIBCo Rendezvous, and the IBM MQSeries to act as JMS message servers in a Java programming environment. You can use these message servers to create OMB-specific, JMS-format messages in AQ, MQSeries, and Rendezvous, and ordinary messages in MQSeries and Rendezvous.
By defining propagation between queues that use these different message formats and message servers, you can use OMB as a message translation service between the queues, transforming the message, for example, from a native MQSeries message to an OMB-specific, JMS-format AQ message.
Some restrictions apply to the types of messages supported. Read "Drivers", Oracle8i Message Broker Administration Guide 2.0.1.0 for details.
In OMB, you can define client-side callouts in Java, C, and C++. These can be used to connect to Mercator Enterprise Broker.
You can connect directly from OMB to the Workflow, Java APIs, or, through PL/SQL calls, to the PL/SQL API only through predefined programming in Java.
We can use the same MQSeries example that we used in the AQ chapter to demonstrate some of the scenarios for integrating to OMB.
The example given below is used solely to illustrate the process and should not be taken as a recommendation of any one solution over any other.
Scenario
One of the applications included in a hub-and-spoke integration solution has a ready-made message-based interface that places messages in a set of MQSeries queues and that expects business events in the form of MQSeries messages. The application interface is written in C and creates and consumes messages using the native MQSeries API. The objective is to transport messages from MQSeries to AQ and from AQ to MQSeries.
Our objective is simply to get the messages in MQSeries into OMB and vice-versa.
The solution depends upon the types of messages we send or receive from MQSeries, the architectural principles, the language or languages used in the integration solution, the approach to modularization, the standards used, and so on.
|
See Also:
|
Programmatic
Developing a predefined Java, C, or C++ program that communicates with OMB through the standard client-side OMB APIs is an alternative means of indirectly connecting OMB queues to other messaging technologies.
In certain application integration scenarios, it may be desirable to have applications interact with other messaging technologies such as MQSeries and TIBCo Rendezvous because of a decoupling requirement, application platform, existing interface, or previous strategic technology choices. It is important to understand how these messaging technologies can interact effectively with the Oracle Integration Server products.
If you have an interface to the application that extracts messages to a messaging technology other than AQ, your first task is to identify your objectives and to establish the routes by which you can get from the messaging technology to these objectives. The most common mistake at this point is to assume that the most direct route from A to B is the fastest, the simplest, the easiest, or the most effective.
The process is most easily shown by example. The scenario that follows is used solely to illustrate the process and should not be taken as a recommendation of any one solution over the other.
Scenario
One of the applications included in a hub-and-spoke integration solution has a ready-made message-based interface that places messages in a set of MQSeries queues and that expects business events in the form of MQSeries messages. The application interface is written in C and creates and consumes messages using the native MQSeries API. One of the objectives is to get a message in MQSeries that represents a business event to instantiate an Oracle Workflow business process.
The solution depends upon the architectural principles, the language or languages used in the integration solution, the approach to modularization standards used, and so on.
It is not possible to cover all the possible alternative scenarios and permutations of solution, but a few examples based on variations of the scenario illustrate the point.
Variant 1
You take a code-based adapter development approach, using the Java programming language, and have not adopted the JMS standard. The designer prefers a coarse-grained approach to modularization (that is, a smaller number of bigger program units).
There are no requirements to:
In this variant, you write a simple, predefined Java program that gets the message through the MQSeries native Java API and transforms the message payload into the required parameter format before invoking the Java Workflow method that instantiates the business process.
Variant 2
You take a code-based adapter development approach using the Java programming language. You adopt the JMS standard for all message interfaces and the designer prefers a coarse-grained approach to modularization (that is, a smaller number of bigger program units).
The MQSeries queue and the Workflow instance reside on different computers and the Oracle database is not installed on the application computer. You may need in the future to receive the same business event from publishers using TIBCo Rendezvous messages and AQ messages.
There are no requirements to:
In this variant, you write a simple predefined Java program that gets the message through Oracle Message Broker and transforms the message payload into the required parameter format before invoking the Java Workflow method that instantiates the business process.
Variant 3
The variant is the same as for Variant 2, but this time you asynchronously inform the MQSeries-enabled application of a business event that has occurred during a step or activity in an Oracle Workflow business process.
There are no requirements to:
In this variant, you develop an adapter that uses the Workflow AQ API to record the asynchronous message. You develop a simple, predefined Java program that gets the message through the native Java AQ API, sets the relevant JMS properties, and passes the message to Oracle Message Broker, which records the message in the MQSeries queue.
Variant 4
Take a graphical approach to developing adapters and connectors, thus minimizing the coding effort. No specific language is mandated and XML is the preferred format for external interfaces. The MQSeries queue and the Workflow instance reside on different computers and the Oracle database is not installed on the application system.
Messages must be retained as an audit trail. In the future, it may be necessary to receive the same business event from publishers using TIBCo Rendezvous messages and AQ messages.
The business event is the same as for Variant 3; you are asynchronously informing the MQSeries-enabled application of a business event that has occurred during a step or activity in an Oracle Workflow business process.
This time, the coding effort is reduced but more components are involved. The Workflow step performs an asynchronous callout by writing to the WF_OUTBOUND queue.
Mercator subscribes to the WF_OUTBOUND queue, transforms the message into an OMB-style JMS format, and places it in an OMB-style AQ queue. OMB propagates the message between the AQ queue and the MQSeries queue.
The increased number of transformation steps may cause the end-to-end delivery time of an individual message to be slightly increased, but message throughput should not be adversely affected.
Variant 5
For this variant, you take a code-based adapter development approach, but with no specific language mandated. The applications are predominantly Oracle-based and the application using MQSeries is one of the few running on a computer without an Oracle database.
Messages must be retained as an audit trail. In the future, it may be necessary to receive the same business event from publishers using TIBCo Rendezvous messages and AQ messages.
The business event is the same as for Variants 3 and 4; you are asynchronously informing the MQSeries-enabled application of a business event that has occurred during a step or activity in an Oracle Workflow business process.
The MQSeries messages are simple and the expected message volumes are expected to be approximately 200 messages per minute.
The Workflow step performs an asynchronous callout by writing to the WF_OUTBOUND queue.
The predefined PL/SQL program subscribes to the WF_OUTBOUND queue, transforms the message data into the format required by the application, and calls the Procedural Gateway package that puts the message on MQSeries. You then use MQSeries to propagate the message to the application computer where the application can collect it.
This section introduces several tools including:
You can write predefined programs to connect any messaging technologies to any of the Oracle Integration Server products, provided both the messaging technology and the OIS product have an API for that language.
The amount of programming required depends on the extent of the differences in message format between the two products, the standard on which the API is based, and the extent to which the API supports the standard. Remember that, to remain simple, predefined programs are designed to connect only one topic to one service call or topic. You must also maintain the code.
Programs that facilitate generic communication between any queue in a messaging product and any aspect of the API of another product are time-consuming to develop, difficult to test thoroughly, tend not to be robust, and rarely scale linearly.
Effective programs are normally developed by the product vendors as a collaborative effort, consume fairly large R&D budgets, and use complex multithreaded programming to enable an acceptable level of scalability.
Transformation tools such as Mercator Enterprise Broker can transform messages between one messaging technology and another. The requirement to migrate messages between messaging technologies is rarely sufficient justification in itself to warrant the purchase and implementation of such specialized products. Often these products take up a lot of storage space and some are transactionally weak or offer no commit model when moving between technologies.
A number of products available from Oracle and other vendors simplify the programming effort required to transform messages from one technology to another.
The three most significant message transformation tools are:
|
 Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|