Oracle8i Integration Server Overview
Release 3 (8.1.7)

Part Number A83729-01





Go to previous page Go to next page

Methodology and Solutions

This chapter introduces you to the methodology of e-business integration and offers examples of ways in which Oracle Integration Server meets integration challenges. The topics in this chapter are:

Selecting the Appropriate E-Business Integration Methodology

We have examined the three primary integration technologies available: data synchronization technologies, component-oriented development technologies, and message-oriented middleware. Now we consider how these technologies optimally map to the three fundamental integration problems: synchronizing data between systems, isolating applications from each other, and automating multistep business processes within companies and between companies.

Although the choice of methodology usually requires a close study of the specific environment in which integration is implemented, you can use certain broad architectural principles to guide integration decisions.

This section includes:

Synchronizing Data Among Systems

The fundamental architectural choice in determining how to synchronize data among systems is whether you need to move data between different systems or whether you need to provide data access to a variety of system from a central location. If you must provide data access, then the ideal choice of integration technology is to use gateways to access the databases and legacy systems in which the data resides.

If you must move data between systems, you can use two different mechanisms: database replication and asynchronous messaging. Three factors influence your choice of technology:

Despite these concerns, in a number of cases where simple data synchronization between two data sources is the only integration requirement, using database replication simplifies how you build and deploy the applications and is probably the most appropriate choice.

Isolating Applications and Businesses from Each Other

If the integration scenario is primarily focused on isolating applications and businesses from each other, data synchronization technologies such as database replication and database gateways are not appropriate. To isolate applications from each other, communication between the applications must be limited to a standard set of well-defined public interfaces. Data synchronization technologies, by definition, violate encapsulation and as a result are not suited for application isolation.

When you need to isolate applications from each other while facilitating communication between them, the primary choice is between a synchronous or an asynchronous communication facility. Three factors determine which communication mechanism to use:

Automating Multi-step Business Processes

Automating a multi-step business process requires applications to communicate with each other in a loosely coupled structure. The only appropriate choice of integration technology in this case is asynchronous message-oriented middleware. In choosing to deploy a middleware solution, the primary architectural decisions that you make depend on the complexity of the integration problem. There are four key issues that you must consider:

Integration Topology

When deploying messaging middleware, you must determine whether to use a point-to-point interface to link applications or to use a hub-and-spoke architecture to link applications. Although point-to-point connectivity is simple when connecting two applications, it quickly becomes unmanageable if more than two applications need to connect.

In such cases, use a hub-and-spoke architecture. In this architecture, applications are not connected directly with each other. Instead, each application is connected to a hub that provides connectivity between all the applications. A change or upgrade to any one application changes only its relationship with the hub and does not affect all the other applications with which it must be integrated.

Messaging Architecture

Next, you must determine the messaging architecture to use based on three questions:

Must messages be stored persistently? If messages are business critical and must be audited and tracked, for example, to resolve disputes between companies or to track information flows, the message header and contents must be stored persistently in a database.These messages can be warehoused and analyzed using standard decision support tools. If the messages are not business critical, then the message brokering facility can provide volatile queuing facilities.

Must messages be propagated with guaranteed delivery? If messages are business critical or if the messaging system connects two mission critical applications, then the messages need to propagated with guaranteed once-only, in-order delivery; otherwise messages can simply be propagated impermanently.

How must messages be routed? Messages can be routed between applications and business processes based on their subject or topic, their content or payload information, or by using the publish-subscribe method.

In most e-business integration scenarios, messages are routed based on their content: in most cases, invoking a specific workflow to process the message in a specific way before sending it to an appropriate destination.

Data Transformation

Applications that form part of a business process usually store and manage data in different data formats. For instance, the Oracle E-Business Suite of packaged applications stores and manages data in SQL format. SAP applications operate on data in iDOCs format, which is a derivative of ASCII.

Four data transformation issues must be addressed when connecting one application to another:

Business Process Management and Workflow

Finally, you must decide whether messages can simply be sent from one application to another or whether they require processing before they are propagated. For instance, when a company sends a purchase order from its supply chain application to the procurement system of another company, the purchase order can require the approval of a purchasing manager at the originating company. If so, the messaging middleware must invoke a workflow application before forwarding the message to the trading partner. In this case, the messaging platform requires a facility for business process management of workflow.

Application Integration: The Solution Spectrum

Remember that all integration scenarios involve three fundamental integration problems: synchronizing data between systems, isolating applications and business from each other, and automating multistep business processes. Integration requires a range of different technologies, each of which is appropriate to a particular type of integration problem.

Oracle Corporation recognizes that integration is not a single, narrowly defined problem that can be solved by any single technology. A complete solution to this complex problem requires a variety of technologies, all of which must be seamlessly integrated. This section clarifies your choices by illustrating some typical integration scenarios. These should help you gain an appreciation of the different types of integration technology that constitute a comprehensive solution.

This section includes:

Data Integration


Your enterprise has a number of applications, each with its own databases. The applications change the information in their databases frequently and independently of each other.


How does an application get the most current information residing in the database of another application? For example the order entry application needs to access the same customer data as the accounts receivable application in order to use the address.


Data Access Gateways and Replication: Gateways enable applications to easily and directly access other databases to get the information they need. Replication automatically synchronizes the information in multiple databases so that each database has the most current information. Changes in any database are immediately reflected in other databases.

Application Integration

A business process involving multiple applications requires integration of application logic and application functionality. To facilitate this integration, applications must communicate to exchange important business information. The two different communication models are synchronous and asynchronous communication.

Synchronous Communication with Functional Interfaces


You want to create a front-end e-commerce Web application that accepts orders. Before accepting the order, the application requires credit card authorization, customer credit rating, inventory levels, delivery schedules, and pricing. If any of these services is not available, the order application cannot complete the transaction. This might mean asking the customer to try again later.


The services required for order entry are provided by other dedicated applications. So, how does the e-commerce application access these services? How can these applications be integrated to implement and automate the business process?


Synchronous, request-reply protocol based on functional interfaces: Each application offers services by defining a set of specific functions as public interfaces. To request these services, applications invoke the corresponding interfaces. Examples of request-reply protocols based on functional interfaces include Remote Procedure Calls (RPC), Common Object Request Broker (CORBA), COM, and Java Remote Method Invocation (RMI). Standards for semantically richer interfaces, specifically aimed at distributed enterprise transactional applications, are emerging with component models such as Enterprise JavaBeans and COM+.

Asynchronous Communication with Message-Based Interfaces


You want to implement an end-to-end order-fulfillment process that involves a number of applications such as order entry, manufacturing, inventory management, distribution, and billing. The order fulfillment process originates with the order-entry application with which a customer places an order. After that, business objects and events must flow between the applications.


These applications are distributed across a wide area network, are owned by different organizations, and have heterogeneous internal architecture. They were designed as single-function, standalone applications, with no plans for integration. The network that connects the applications might be unreliable. The organizations that own the application might change, relocate, or replace the applications at will, without informing the organizations owning the other applications. Furthermore, one application does not require a response from another in order to proceed. Hence, synchronous communication integration is not a viable option.


Asynchronous communication with message queuing: Applications communicate with each other by exchanging information as messages through queues. Each application defines a set of messages that it accepts as input and a set of messages that it publishes as output for other applications. The messages represent business objects like customer records or business events like a new shipment requests. Asynchronous communication with message queuing enables loose coupling, so that individual applications are completely isolated from application, network, and system failures.

An example of a message queuing interface is the industry-standard Java Messaging Service (JMS).

Business Process Modeling and Execution


Consider the order-fulfillment scenario described in the previous section. Assume that the applications are integrated and that the entire business process is automated.


Business managers decide that the business process must be modified. For instance, the order-fulfillment process moves from a clerk-oriented system to a Web-based self-service system that requires a different approval process. The flow of the process must be changed and new applications must be added to the process. How quickly can the business decision be translated into reality? How do you minimize the time that elapses between decision making and implementation?


Business process modeling and execution: Firstly, a business analyst models the entire business process using a graphical modeling tool. Then, a technical analyst fills in the details and maps the model to the underlying integration infrastructure. Next, the model is validated and generated in a repository. Finally, it is executed by a business process coordinator. To change the process at any time, only the high-level model requires change. You can quickly implement the entire cycle, from identifying the change to executing the new model.

Business Process Intelligence


Same as in the previous section.


The end-to-end business process is not performing to expectation, even though each of the individual applications is finely tuned. A holistic view of the business process is not available. Standard system management and monitoring tools provide performance metrics only about individual components, not about the entire process. To complicate matters further, performance varies daily and seasonally with market variations, thus making it hard to pinpoint the exact cause of the problem. So, how do you identify the inefficiencies and bottlenecks to help you to deploy your resources intelligently?


This solution utilizes Business Process Intelligence as its strategy. The only way to get a holistic view of the entire business process is to track each transaction end-to-end. This implies tracking all the information (data, messages, and business events) in order to reconstruct the transaction later. Further, you must collect this information over an extended period of time, and it must be warehoused and analyzed to gather intelligence about the business process. The accumulated information can be mined to discover patterns and to provide insight into how resources can be optimally deployed.

Business-to-Business Integration

The previous section discussed the range of technologies required for a complete application integration solution. The focus of most integration projects in enterprises to date has been on integration of applications within the enterprise. The few projects that involved integration beyond the enterprise with partners and suppliers were limited in their scope and used simple mechanisms like FTP and e-mail. The real mission-critical, inter-enterprise transactions are conducted over private value-added networks (VANs) using proprietary protocols like EDI, HL-7, and SWIFT.

e-Business integration requires extensive, flexible, and dynamic cooperation and collaboration with customers, suppliers, and partners. Some examples of new business models that require this type of integration include:

The integration must take place over the low-cost and ubiquitous Internet, so that an enterprise can choose from a worldwide selection of partners, suppliers, and vendors. This necessity places additional requirements on a solution. These requirements include:

Go to previous page Go to next page
Copyright © 1996-2000, Oracle Corporation.

All Rights Reserved.