8
Runtime System Concepts and Components

This chapter describes the runtime concepts, components, processes, and component configuration of OracleAS InterConnect in the following topics:

• Integration Architecture

• Features

• Components

• Real Application Clusters Configuration

Integration Architecture

OracleAS 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 OracleAS 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.

Features

The OracleAS InterConnect runtime features are as follows:

• Messaging Paradigms

• Message Delivery

• Message Retention

• Routing Support

• Error Management

• Scalability and Load Balancing

• File Persistence

Messaging Paradigms

OracleAS InterConnect runtime supports three major messaging paradigms:

• Publish/Subscribe

• Request/Reply (synchronous and asynchronous)

• Point-to-Point

These paradigms can be configured on a per integration point basis.

See Also: Chapter 1, "Getting Started with OracleAS InterConnect"

Message Delivery

The following are features of message delivery:

• Guaranteed Delivery--All messages are guaranteed to be delivered from the source application(s) to the destination application(s).

• Exactly Once Delivery--The messages are neither lost nor duplicated. The destination application(s) will receive each sent message exactly once.

• In Order Delivery--The messages are delivered in the exact same order as they were sent. This is applicable only when there is one instance of the adapter running per application serviced.

Message Retention

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.

Routing Support

The current version of OracleAS 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, oai_hub_queue is the only multiconsumer Advanced Queue configured to be the persistent store for all messages for all applications. This will handle all your standard as well as content based routing needs. Moreover, 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.

See Also: "Scalability and Load Balancing"

Content-Based Routing

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 bank code value based on objects stored in the repository, and routes the message to the appropriate recipient system.

Error Management

This release has significant improvements to deal with error conditions in your integration environment:

• Central Logging--If there is an error in the system, it is logged centrally in the repository.

• Central Monitoring--These errors can be monitored through the runtime management console.

Resubmission

You can resubmit errored-out messages again into your integration environment for processing after modifying them (if required) using the runtime management console.

Tracing

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.

Tracking

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.

Scalability and Load Balancing

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.

See Also: Chapter 9, "Runtime Management"

OracleAS 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:

Scenario 1

• Requirement

  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.

• Solution

  In this case, you cannot add more than one adapter to Application A for load balancing.

Scenario 2

• Requirement

  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, and computation heavy and EventB and EventC messages are very light.

• Solution

  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.

  See Also: Chapter 1, "Getting Started with OracleAS InterConnect"

Scenario 3

• Requirement

  There is no message order dependency, even within the same event type.

• Solution

  Since there are no ordering restrictions, two approaches for load balancing can be employed:

  • No message partitions are created. One or more adapters are added utilizing the entire Message Capability Matrix. This means that at runtime any one of the adapters would be available to receive any message, though only one of them would actually receive the message. Which adapter receives the message will be determined solely by which adapter is the first to request the next message for processing.

  • Message Partitions can be created based on projections of the number of messages for a particular event type. For example, if there will be three times as many 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.

File Persistence

Adapters deliver messages from applications to the integration hub and vice versa. By default, adapters store messages in local file persistence during processing. This makes adapters stateful. If your customized scenario requires OracleAS InterConnect to be deployed in a fail safe environment, stateful adapters become cumbersome to manage. If an adapter fails in the middle of processing a message, a new adapter instance that takes over the failed adapter must somehow read the message from the failed adapter's local file persistence.

To overcome this problem, OracleAS InterConnect provides a feature to make adapters stateless for fail safe environments by turning off file persistence through parameters in the adapter.ini file.

Note: There are two parameters associated with file persistence, agent_pipeline_to_hub and agent_pipeline_from_hub. You should set both parameters to false to make adapters stateless.

Table 8-1 Summarizes file persistence parameters.

Table 8-1 File Persistence Parameters

Parameter	Description
agent_pipeline_to_hub=false	Turn off local file persistence when sending messages from application to the hub.
agent_pipeline_from_hub=false	Turn off local file persistence when sending messages from the hub to the application.

Components

There are six major components in the runtime system:

• Adapters

• Repository

• Advanced Queues

• Oracle Workflow

Adapters

Prepackaged adapters help re-purpose applications at runtime to participate in the integration without any programming effort.

Agent and Bridge Combination

Adapters are the run-time component for OracleAS InterConnect. Adapters have the following responsibilities:

• Application Connectivity--Connect to applications to transfer data between the application and OracleAS InterConnect. The logical sub-component within an adapter that handles this responsibility is called a bridge. This is the protocol/application-specific piece of the adapter that knows how to communicate with the application. For example, the database adapter is capable of connecting to an Oracle database using JDBC and calling SQL APIs. This sub component does not know which APIs to call, only how to call them.

• Transformations--Transform data from the application view to common view and vice versa as dictated by the repository metadata. In general, adapters are responsible for carrying out all the runtime instructions captured through iStudio as metadata in the repository. Transformations are an important subset of these instructions. The logical sub component within an adapter that handles the runtime instructions is called an agent. This is the generic runtime engine in the adapter that is independent of the application to which the adapter connects. It focuses on the integration scenario based on the integration metadata in the repository. There is no integration logic coded into the adapter itself. All integration logic is stored in the repository. The repository contains the metadata that drives this sub component. In the database adapter example, this is the sub-component that knows which SQL APIs to call, but not how to call them. All adapters have the same agent code. It is the difference in metadata that each adapter receives from the repository that controls and differentiates the behavior of each adapter.

Adapters can be configured to cache the metadata at runtime to address performance needs. There are three settings for caching metadata:

• No Caching--For each message, the adapter will query the repository for metadata. This setting is recommended for an early or unstable integration development environment.

• Demand Caching--The adapter will query the repository only once for each message type and then cache that information. For subsequent messages of the same type, it will use the information from the cache. This setting is recommended for a stable integration development environment.

• Full Caching--At start-up time, the adapter will cache all its relevant metadata. This setting is recommended for a production environment.

The following adapters are available with OracleAS InterConnect:

• OracleAS InterConnect Adapter for DB--Allows you to communicate to an Oracle database using JDBC.

• OracleAS InterConnect Adapter for AQ--Allows you to communicate to an Advanced Queue with Raw, XML, and ADT payloads.

• OracleAS InterConnect Adapter for HTTP--Allows you to communicate across firewalls with an HTTP or HTTPS server using XML payloads.

• OracleAS InterConnect Adapter for FTP--Enables an Oracle FTP Application to be integrated with other applications using OracleAS InterConnect. This adapter is useful in all enterprise application integration scenarios involving the FTP transport protocol or local file system. The Advanced Queuing adapter can monitor incoming messages which are in the form of FTP files placed in a remote FTP server or on local file systems. The Advanced Queuing adapter is also capable of sending messages to remote FTP servers via proxy host. The payload for this adapter can be XML data or D3L data.

• OracleAS InterConnect Adapter for MQ Series--Enables OracleAS InterConnect to send messages to and receive messages from the MQ Series queues and topics. This allows an application that uses IBM's MQ Series as its messaging technology to be integrated with other applications using OracleAS InterConnect. Therefore, the Advanced Queuing adapter is useful in all enterprise application integration scenarios involving MQ Series-based applications.

• OracleAS InterConnect Adapter for SMTP--The SMTP adapter enables an SMTP application to be integrated with other applications using OracleAS InterConnect. This adapter is useful in all enterprise application integration (EAI) environments where e-mail uses the Internet Message Access Protocol 4 (IMAP4) and SMTP transport protocols.

• OracleAS InterConnect Adapter for PeopleSoft 7.5x

• OracleAS InterConnect Adapter for PeopleSoft 8

• OracleAS InterConnect Adapter for SAP R/3

• OracleAS InterConnect Adapter for CICS

• OracleAS InterConnect Adapter for Siebel 2000

• OracleAS InterConnect Adapter for Siebel 7

• OracleAS InterConnect Adapter for J.D. Edwards OneWorld XE

  See Also: Adapter-specific installation and user's guides for details on respective OracleAS InterConnect Adapters

Repository

The repository consists of two components:

• Repository Server--A Java application that runs outside the database. It provides CORBA services to create/modify/delete metadata at design time using iStudio and query during runtime using adapters. Both adapters and iStudio act as CORBA clients to communicate with the repository server.

• Repository Database--The repository server stores metadata in database tables. The server communicates to the database using JDBC.

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

Advanced Queues provide the messaging backbone for OracleAS InterConnect in the hub. In addition to being the store and forward unit, they provide message retention, auditing, tracking, and guaranteed delivery of messages.

See Also: Oracle Database Application Developer's Guide for information on Advanced Queues

Oracle Workflow

Oracle Workflow facilitates integration at the business process level through its Business Event System. OracleAS InterConnect and Oracle Workflow are integrated to leverage this facility for business process collaborations across applications.

Real Application Clusters Configuration

Introduction

Real Application Clusters (RAC) harnesses the processing power of multiple interconnected computers, unites the processing power of each component to create a robust computing environment. In RAC environment, all active instances can concurrently execute transactions against a shared database. RAC coordinates each instance's access to the shared data to provide data consistency and data integrity. It features balance of workloads among the nodes by controlling multiple server connections during period of heavy use and provide persistent, fault tolerant connections between clients and RAC database.

See Also: The following documentation for additional information on RAC: Oracle9i Real Application Clusters Administration Oracle Application Server 10g Concepts

OracleAS InterConnect Adapters Supporting RAC

OracleAS InterConnect adapters leverage RAC technology, provide consistent and uninterrupted services without having to restart the adapters, if an instance fails, and provide guaranteed message delivery. OracleAS InterConnect adapters connect to the first of the listed available nodes in adapter.ini and hub.ini files.

See Also: OracleAS InterConnect adapters installation documentation for details on adapter.ini and hub.ini files associated with specific adapters

If one of the nodes fails, database connection is re-established to the next available node in the adapter.ini or hub.ini file list mentioned above, recursively, until a successful connection is made transparent to the user.

The hub connections for all adapters are RAC enabled. The spoke connections for DB and AQ adapters are RAC enabled.

See Also: Section Support for Oracle Real Application Clusters in the Oracle9i Application Developer's Guide-Advanced Queuing

Configuration

The adapter.ini and hub.ini files must be populated with the information about the host, port, and instance for all the nodes. Additional sets of parameters which specifies the number of nodes are also required to be populated. All the existing entries remain the same except a new entry for each node is added. Table 8-2 describes the additional sets of parameters which specify the number of nodes required to be populated.

Table 8-2 Additional Parameters for RAC Configuration

File Name	Parameter
hub.ini	host_num_nodes hub_hostx hub_portx hub_instancex--where x varies between 2 and the number of nodes.
adapter.ini for the Advanced Queueing adapter	ab_bridge_num_nodes aq_bridge_host aq_bridge_port aq_bridge_instance
adapter.ini for the Database adapter	db_bridge_num_nodes db_bridge_schema1_hostx db_bridge_schema1_portx db_bridge_schema1_instancex--where x varies between 2 and the number of nodes.

Sample hub.ini File

The following are sample hub.ini files.

hub_username=oaihub904
hub_password=oaihub904
hub_use_thin_jdbc=true
hub_host=dlsun1312
hub_instance=iasdb
hub_port=1521
hub_num_nodes=2
hub_host2=vindaloo
hub_instance2=orcl
hub_port2=1521

Sample Database Adapter adapter.ini File that Shows the Spoke Database Entry

The following are sample adapter.ini files for the Database adapter that shows the spoke database entry.

db_bridge_schema1_host=dlsun1312
db_bridge_schema1_port=1521
db_bridge_schema1_instance=iasdb
db_bridge_num_nodes=2
db_bridge_schema1_host2=vindaloo
db_bridge_schema1_port2=1521
db_bridge_schema1_instance2=orcl