Release 2 (9.0.2)
Part Number A92174-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle9iAS InterConnect User's Guide Release 2 (9.0.2) Part Number A92174-01 |
|
This chapter describes the runtime concepts, components and processes of Oracle9iAS InterConnect.
This chapter discusses the following topics:
Oracle9iAS InterConnect runtime is an event-based distributed messaging system. An event is any action that initiates communication through messaging between two or more applications integrated through Oracle9iAS InterConnect. The messaging system can be deployed both within an enterprise or across enterprise boundaries.
The runtime enables inter-application communication through hub and spoke integration. This methodology keeps the applications decoupled from each other by integrating them to a central hub rather than to each other directly. The applications are at the spokes of this arrangement and are unaware of the applications with which they are integrating with. To them, the target of a message (or the source) is the hub. Since each application integrates with the hub, translation of data between the application and hub (in either direction) is sufficient to integrate two or more applications.
The Oracle9iAS InterConnect runtime features are as follows:
Oracle9iAS InterConnect runtime supports three major messaging paradigms:
These paradigms can be configured on a per integration point basis.
All messages are guaranteed to be delivered from the source application(s) to the destination application(s).
The messages are neither lost nor duplicated. The destination application(s) will receive each sent message exactly once.
The messages are delivered in the exact same order as they were sent.
Messages remain in the runtime system until they are delivered. Advanced Queues in the hub provide the message retention. The messages are deleted when each application that is scheduled to receive a specific message has received that message. For auditing purposes, you can configure the system to retain all messages even after they have been delivered successfully to each application.
The current version of Oracle9iAS InterConnect has significant improvements over the previous releases for configuring your routing needs. Routing is a function of the Advanced Queues in the hub. By default, there is only one multiconsumer Advanced Queue configured to be the persistent store for all messages for all applications--oai_hub_queue. This will handle all your standard as well as content based routing needs. Morever, this queue is created automatically when you install the repository in the hub. The only reason to change this configuration is if Advanced Queues becomes a performance bottleneck. For most scenarios, this is unlikely because most of the message processing is done in the adapters, not in the hub.
Content-based routing allows you to route messages to specific destination applications based on message content. For example, an electronic funds transaction settlement application is designed to transmit bank transactions with a specific bank code to identify the destination bank system. When the electronic funds transfer application publishes each message at runtime, the Oracle Application InterConnect runtime component determines the BankCode value based on objects stored in the repository, and routes the message to the appropriate recipient system.
This release has significant improvements to deal with error conditions in your integration environment:
You can resubmit errored-out messages again into your integration environment for processing after modifying them (if required) using the runtime management console.
You can modify the .ini files of adapters to turn up the tracing level to troubleshoot errors. You can view the tracing logs by opening up log files through the runtime management console.
Messages can be tracked by specifying tracking fields using iStudio. The runtime system checkpoints state at certain pre-defined points so that you can monitor where the message is currently in the integration environment. This tracking capability can be utilized through the runtime management console.
At runtime, it is possible that the adapter attached to a particular application becomes a performance bottleneck. You can detect this by monitoring the message througput information through the runtime console.
Oracle9iAS InterConnect addresses adapter scalability through a well-defined methodology.
Multiple adapters can be attached to one application to share the message load. This can be done in several ways depending upon the needs of your integration environment. For example, Application A publishes three different kinds of events--EventA, EventB, and EventC. Three potential scenarios should be examined to determine how one or more adapters should be attached to the application to meet performance objectives:
The order in which the messages are sent by Application A must be adhered to strictly for the life of all messages. For example, if Application A publishes messages in a specific order, they must be received by the subscribing applications in the exact same order across all the different event types.
In this case, you cannot add more than one adapter to Application A for load balancing.
The order in which messages are sent by Application A must be adhered to but not across different event types. For example, Application A publishes the following messages in order: M1_EventA, M2_EventB, M3_EventA. M1 and M3 must be ordered with respect to each other because they correspond to the same event type. However, M2 has no ordering restrictions with respect to M1 and M3. In addition, EventA messages are transformation/size/computation heavy and EventB and EventC messages are very light.
In this case, you can create message partitions in the Message Capability Matrix. Partition1 can process EventA messages, and Partition2 can process EventB and EventC messages. When you install the adapters, you specify not only the application it is attached to but also the partition it uses. These message partitions can be used to effectively load balance message processing.
There is no message order dependency, even within the same event type.
Since there are no ordering restrictions, two approaches for load balancing can be employed:
EventA messages than EventB or EventC messages, you could create two partitions--one for handling EventA messages, and the other for handling the other two event types.
There are four major components in the runtime system:
Prepackaged adapters help re-purpose applications at runtime to participate in the integration without any programming effort.
Adapters are the run-time component for Oracle9iAS InterConnect. Adapters have the following responsibilities:
Adapters can be configured to cache the metadata at runtime to address performance needs. There are three settings for caching metadata:
The following adapters are available with Oracle9iAS InterConnect:
The repository consists of two components:
Adapters have the ability to cache metadata. If the repository metadata is modified after adapters have cached metadata, those adapters are automatically notified by the repository server to purge their caches and re-query the new metadata.
Advanced Queues provide the messaging backbone for Oracle9iAS InterConnect in the hub. In addition to being the store and forward unit, they provide message retention, auditing, tracking, and guaranteed delivery of messages. For more information on Advanced Queues, see the Oracle Database Application Developer's Guide
Oracle Workflow facilitates integration at the business process level through its Business Event System. Oracle9iAS InterConnect and Oracle Workflow are integrated to leverage this facility for business process collaborations across applications.
|
 Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|