1
Getting Started with Oracle9iAS InterConnect

This chapter provides an overview of Oracle9iAS InterConnect, its features, and components.

Topics include:

What is Oracle9iAS InterConnect?

Oracle9iAS InterConnect is an integral component of Oracle9iAS and provides a comprehensive application integration framework to enable seamless integration of enterprise software. It is built on top of the Oracle9iAS integration platform and leverages its underlying functionalities. It is designed to integrate heterogeneous systems, such as Oracle Applications, non-Oracle Applications, or third party messaging oriented middleware. This integration can be deployed within an enterprise or across enterprise boundaries through the Internet.

The technical design goals for Oracle9iAS InterConnect are to:

Elevate the integration problem from a technical coding exercise to a functional modeling exercise, thereby reducing or eliminating the programming effort normally associated with integration.
Develop and expose an integration methodology that promotes reuse and reduces the complexity and management issues that arise over the software lifecycle.

Oracle9iAS InterConnect provides a complete framework for e-Business application integration across the Application-to-Application, Application Service Provider, and Business-to-Business domains. Oracle9iAS InterConnect components can be deployed for these domains in the following methods:

Application-to-Application--Applications are distributed within a Local Area Network or across a Wide Area Network. Oracle9iAS InterConnect is deployed within the organization to integrate these applications.
Application Service Provider--Applications are distributed across firewall boundaries with some applications residing inside the Application Service Provider firewall and others inside the customer firewall. Oracle9iAS InterConnect can be deployed inside either one of the two firewalls, or both, to integrate these applications across the firewalls.
Business-to-Business--Similar to the Application Service Provider model only the Application Service Provider is replaced with another business.

Oracle9iAS InterConnect Components

Oracle9iAS InterConnect has the following core components:

Oracle9iAS InterConnect Hub

The Hub consists of a middle tier repository server program communicating with a back-end database. The repository has the following functionality:

At design time, all integration logic defined in iStudio is stored in tables in the repository as metadata.
At runtime, the repository provides access to this metadata for adapters to integrate applications.

The repository server is deployed as a stand-alone Java application running outside the database. The repository schema is a set of tables in the Oracle9iAS Infrastructure. Both the repository server and the database are on the hub machine.

Oracle9iAS InterConnect Adapters

Adapters have two major tasks:

Provide connectivity between an application and the hub.
Transform and route messages between the application and the hub.

Adapters are deployed as stand-alone Java applications running outside the database. Adapters are physically located with the applications they connect to, either on the same machine as the application itself or on a separate machine. Adapters are usually not deployed on the hub machine.

See Also:

"Using Adapters for Integration"

Oracle9iAS InterConnect Development Kit

iStudio is a design time integration specification tool targeted at business analysts. This tool helps business analysts specify the integration logic at a functional level, instead of a technical coding level. iStudio exposes the integration methodology using simple wizards and reduces, or eliminates, the need for writing code to specify the integration logic. This reduces the total time required to complete an integration.

iStudio is a multi-user tool with fine-grained locking for all Oracle9iAS InterConnect first class objects. Therefore, multiple users can work simultaneously on the same integration scenario without compromising the consistency of the metadata.

iStudio allows business analysts to complete the following tasks:

Define data to be exchanged across applications.
Semantically map data across applications.
Define the business process collaboration across applications using Oracle Workflow and associate the semantic maps with business processes, if required.
Configure and deploy the integration.

iStudio is deployed as a stand-alone Java application running outside the database and can be deployed on any machine with access to the hub machine running Windows NT/2000/XP.

See Also:

Chapter 2, "Using iStudio"

Oracle9iAS InterConnect Management Infrastructure

The Oracle Enterprise Manager provides the following functionality:

Manages runtime components and resources.
Troubleshoots errors and tracks messages.

The Oracle Enterprise Manager console includes a server component usually installed on the hub machine. The client component can be installed on any machine where the integration environment is managed. Both client and server components are stand-alone Java applications running outside the database.

Oracle9iAS InterConnect SDKs

Oracle9iAS InterConnect is easily extended through SDKs that address custom integration needs.

iStudio SDK

The iStudio SDK is a collection of Java jar and Javadoc files usually deployed on the same machine as iStudio. The iStudio SDK is only available on Windows NT/2000/XP. Using the iStudio SDK and Java, users can build the following:

New transformation functions.
New browsers to import application-native data structures and APIs into iStudio.

Documentation and samples are provided with the iStudio SDK.

Adapter SDK

The Adapter SDK is a collection of Java jar and Javadoc files that can be deployed on any machine. The Adapter SDK is available on all tier one platforms. Using this adapter, users can write new adapters in Java for applications or protocols not currently supported by Oracle9iAS InterConnect. Specifically, only the bridge sub-component must be written. The agent is a generic engine already written and is part of each adapter.

Documentation and samples are provided with the Adapter SDK.

Oracle Workflow

Oracle Workflow provides a comprehensive business process management system that enables traditional workflow applications, as well as process collaboration in a single solution. Using Oracle Workflow Business Event System, Oracle9iAS InterConnect can model an integration solution on business processes. With Oracle9iAS InterConnect and Oracle Workflow, business collaborations across two or more applications can be defined to implement the organization's business processes.

Standard Messaging

Oracle9iAS InterConnect provides all the basic services expected of a messaging middleware platform including:

Guaranteed delivery of messages--All messages have guaranteed delivery end-to-end. Messages are delivered exactly once and in the order sent.
Scalability--Multiple adapters are instantiated to serve one application. The hub runs in an Oracle Parallel Server environment.
Load Balancing--Messages can be partitioned based on load between multiple adapters servicing one application. One or more adapters can serve all messages for one application. In addition, one or more adapters can be dedicated per integration point in which the application participates.
Runtime Management--The Oracle Enterprise Manager console helps manage the integration scenario and components at runtime. This console allows users to start and stop components, monitor message flow, detect problems, and manage errors.
Deployment Support--The messaging hub consists of Advanced Queues that are configured for runtime. Number of queues to create, naming these queues, and matching adapters with messages in a specific named queue can be configured using iStudio.

The following supplementary features do not require any additional coding:

Content Based Routing--Route messages by building business rules based on message content. For example, a procurement system routes fulfillment requests to different fulfillment centers based on an originating location.
Cross Referencing--Correlate keys that uniquely identify the entities in one application with corresponding entities created in other applications. For example, a purchase order created in a procurement system has a native id X. It is then routed to a fulfillment system and the purchase order is created in the fulfillment system with native id Y. Therefore, X and Y must be cross referenced for Oracle9iAS InterConnect to correlate communication about this same logical entity in two different systems without each system understanding the native id of the other system.
Domain Value Mapping--Map code tables across systems. For example, a purchase order in a procurement system has a PO Status field with possible domain values Booked and Shipped. The corresponding field in a fulfillment system has the possible domain values 1 and 2. Oracle9iAS InterConnect allows the user to create the mappings booked=1, shipped=2 so it can correlate these values at runtime without each system understanding the domain value set of the other system.

Supported Messaging Paradigms

Oracle9iAS InterConnect supports the following messaging paradigms. These paradigms are defined in iStudio at design time. The definitions are used at runtime to route the messages appropriately.

Publish/Subscribe Messaging--An application publishes a message if it sends data out to the Oracle9iAS InterConnect hub without knowing the destination applications. Furthermore, data is not expected in return. An application subscribes to a message if it receives the data from the Oracle9iAS InterConnect hub regardless of who sent the data. Furthermore, it does not send any data out in return. Events in iStudio are used to model this paradigm.
Request/Reply Messaging--An application publishes a message and expects a message in return as a reply. The application subscribing to the request sends a reply back to the sender after processing the request. Procedures in iStudio are used to model this paradigm. Request/Reply has the following two types of characteristics:
- Synchronous--The application making the request is blocked until it receives a reply.
- Asynchronous--The application makes the request and proceeds with normal processing. It does not wait for a response. A reply is delivered next and is consumed by the application.
Point-to-Point Messaging--Both Publish/Subscribe and Request/Reply can acquire a point-to-point characteristic if the sending application explicitly calls out which application should receive the message. This can be modeled using content-based routing in iStudio.

Oracle9iAS InterConnect Integration Process

Application integration using Oracle9iAS InterConnect involves the following two phases:

Design Time

During the design phase, a business analyst uses iStudio to define the integration objects, applications that participate in the integration, and the specifications of the data exchanged between applications. All the specifications are stored as metadata in the Oracle9iAS InterConnect Repository.

Runtime

For each application participating in a specific integration, Oracle9iAS InterConnect attaches one or more adapters to it. At runtime, the adapters retrieve the metadata from the repository to determine the format of messages, perform transformations between the various data formats, and route the messages to the appropriate queues in the Oracle9iAS InterConnect hub.

Figure 1-1 A graphical overview of design time and runtime phases in integration

Text description of the illustration intro3.gif

Separation of Integration Logic and Platform Functionality

Integration using Oracle9iAS InterConnect is a two-step process. During design time, integration logic is modeled in iStudio and captured in the repository as metadata. Metadata is created in the repository using iStudio during design time and is represented by application views, common views, and transformations. At runtime, the underlying services regard this metadata as runtime instructions to enable the conversation among participating applications. Integration has two components:

Integration logic--Consists of the business rules and transformation logic necessary to integrate heterogeneous systems. Using iStudio, this integration logic can be modeled and the results stored in the repository as metadata.
Platform functionality--Consists of the integration infrastructure provided with Oracle9iAS InterConnect and the Oracle database. In addition, Oracle9iAS InterConnect provides application and protocol adapters. The platform services provide the requisite infrastructure necessary for integration.

Unique Integration Methodology

iStudio exposes an integration methodology that eliminates the complexities of point-to-point custom integration solutions. The integration methodology is based on a hub-and-spoke model.

How the Hub-and-Spoke Methodology Works

An integration point is defined as an event that triggers communication between two or more participating applications in the integration scenario. The following are examples of such events:

Create Customer--An integration scenario may require that customer information across two applications be synchronized in real time. Whenever a new customer is created in the application, App1, the customer should also be created in the application, App2. Therefore, Create_Customer is an event that triggers the communication between the two applications--App1 produces the information, App2 consumes it.
Get Item Info--A user of App1 may request information on an item stored in App1. The information on that item might be segmented across the two applications. To give a meaningful response to the user of App1, it is necessary to query App2 for information on the item. Therefore, Get_Item_Info is an integration point between the two applications because it triggers communication between the two applications--App1 produces a query, App2 consumes it, App2 produces the response, and App1 consumes it.

The common view consists of a list of such integration points, each with its own associated data. Applications participate in the integration by binding to one or more of these common view integration points.

For each binding, applications have their own application view of data that needs to be exchanged. Each binding involves a mapping, or transformation, between the application view and the common view in the context of the integration point. In this model, the application views are at the spokes and the common view is the hub.

Create_Customer is an integration point. If the information to exchange is the new customer's name only, the common view has all the information potentially captured in a name defined in an application-independent method. This information must be a superset of all the information that needs to be exchanged across App1 and App2.

Prefix, First Name, Last Name, Middle Initial, Maiden Name, Suffix is an example of a common view customer name definition.

Now, App1's internal definition of name (App1's application view) could be First Name, Last Name, Middle Initial, Prefix.

The application view for App2 could be Name (one field that describes Last Name, First Name).

For App1, when sending this information out or publishing an event, transformations are defined from its application view to the common view. For App2, when receiving this information or subscribing to an event, transformations are defined from the common view to its application view.

Figure 1-2 illustrates this example within the hub-and-spoke model where the common view is the hub and the application views are the spokes.

Figure 1-2 Oracle9iAS InterConnect Hub-and-Spoke Model

Text description of the illustration introa.gif

This hub-and-spoke model has the following advantages:

Loosely coupled integration--Applications integrate to the common view, not with each other directly. This reduces the number of integration interfaces.
Easy Customization--Changes in application views because of application upgrades are localized. The changes in the upgraded application should only be reflected through changes in its application view and mappings to the common view. In other words, only the spoke of the changed application should be re-mapped to the hub. The other spokes and their relationships with the hub remain unchanged.
Easy Extensibility--Applications can be added or removed from the integration scenario without affecting other applications. For example, if a new application is added to the integration scenario, it must define its spoke component (the application view) and map that component to the hub (common view) on a per integration point basis. This does not affect other applications in the integration.
Enhanced Reusability--To integrate the Marketing CRM module to SAP, the integration would be from iMarketing to common view to SAP. If there is a requirement to integrate iMarketing to Peoplesoft, then the iMarketing to common view integration can be reused. Only the common view to the Peoplesoft integration needs to be built.

Integration Lifecycle Management

Managing, customizing, and evolving an integration over time is as important as creating the integration in the first place. The hub-and-spoke integration model has advantages to help achieve this goal. In addition, the Oracle9iAS InterConnect repository, which contains all the integration logic, provides extensive services for managing changes over time. The repository provides fine-grained versioning of all Oracle9iAS InterConnect first class objects such as events, messages, and data types. Some of the important aspects of versioning to aid the lifecycle support include:

Basic Versioning--New versions of first class objects, such as messages, can be created to address changing integration needs. Different versions of the same object can co-exist in the repository. This approach has two advantages:
- Eliminates the need for an expanded namespace to address modifications.
- Allows related entities to be grouped together for easier management.
Multiple Active Versions--Multiple versions of the same message can be active in the same integration scenario simultaneously. This helps transition an integration incrementally without requiring changes to existing messages. For example, if a purchase order definition for an application or the application view of the purchase order needs to change, a new version of the message can be created and activated for that application. Once this metadata is created, the application can smoothly transition from sending and receiving messages based on the old definitions to the new one.
Migration Support--Different versions of metadata can be migrated across repositories on a first class object basis. This feature allows fine-grained control of content in different repositories, such as a development repository and a production repository.
Consistency Control--Oracle9iAS InterConnect detects and flags metadata conflicts. This helps to prevent accidental overwriting of metadata and maintains consistency of metadata in the repository.

Using Adapters for Integration

Adapters are runtime components which process integration logic captured in the repository as runtime instructions to enable the integration. Prepackaged adapters help re-purpose applications at runtime to participate in the integration without any programming effort.

Adpaters complete the following tasks:

Application Connectivity--Connect to applications to transfer data between the application and Oracle9iAS InterConnect. The logical subcomponent within an adapter that handles this responsibility is called a bridge. This is the protocol/application-specific piece of the adapter that communicates with the application.

For example, the database adapter is capable of connecting to an Oracle database using JDBC and calling SQL APIs. This subcomponent only knows how to call the correct APIs.
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 subcomponent 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 subcomponent.

In the database adapter example, this is the subcomponent that knows which SQL API's 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.

Figure 1-3 Oracle9iAS InterConnect Adapter Architecture

Text description of adapterarch.gif follows.

Text description of the illustration adapterarch.gif

These adapters can be technology or application adapters. Oracle9iAS InterConnect currently packages technology adapters for the Oracle database, Advanced Queues, and HTTP/S technology.

1 Getting Started with Oracle9iAS InterConnect