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 provides an overview of the development of an e-business integration solutions and contains these sections:
The Internet revolution has advanced to the stage at which every enterprise must become an e-business. This is an imperative and not a choice. Hence, it is necessary to determine when and how an enterprise becomes an e-business.
What is e-business? It is a fundamental change to the way an organization conducts business. An e-business uses Internet technology to:
An e-business requires a variety of Internet-enabled applications including e-commerce Web sites, portals, supply-chain management, procurement management, online marketplaces, customer relationship management, and enterprise resource planning. All these applications must be integrated with one another to make an enterprise an e-business.
The necessity for businesses to become "zero latency organizations" drives enterprise-wide integration of information systems and applications. For instance, in a smoothly running e-business:
These developments drive the need for e-business integration:
When two or more companies merge, or when one company acquires another, they must automate a company-wide business process for the new entity. To do so, they connect their information systems together to synchronize and share information.
For instance, as telecommunications companies increasingly consolidate globally through mergers and acquisitions, they require a common view of their consolidated customer base. As a result, they must share and synchronize customer information among their front-end databases, their billing systems, and other front-end applications.
As businesses buy packaged applications to streamline parts of their business, they must integrate these applications with other packaged applications and with legacy systems within the enterprise. Enterprise integration technologies enable applications to communicate with each other in order to automate business processes.
Business process reengineering drives the requirement for enterprise integration. As organizations redesign and streamline their business processes, the underlying applications infrastructure that facilitates these business processes must communicate with different systems in new ways. Companies undergoing business process reengineering deploy integration middleware to connect different systems together.
Although these three developments provide the primary incentives for enterprise integration within companies, companies undergoing a transition to e-business face additional integration needs. With e-business, customers and suppliers have transparent and direct access to the internal business processes of an organization. As a result, the e-business itself creates a demand for enterprise integration within companies and between businesses. These factors include:
Many e-businesses outsource critical parts of their supply chain execution process to partners. These include manufacturing specialists who build specialized components, fulfillment specialists who provide logistics and fulfillment, and warehouse management specialists who manage a supplier's inventory in the warehouse.
For instance, many personal computer manufacturers assemble the computers themselves but outsource the manufacturing of the PC boards and use a third-party logistics provider to ship the PCs directly to consumers. In such a case, the company's supply chain applications and business processes must be tightly linked with the supply chain systems of the suppliers. This ensures global visibility of inventory levels and demand patterns to all participants. Business-to-business integration software links these systems together.
In an e-business, customers reach the company through a variety of facilities. They can:
All front-end applications of the business must be integrated so that customers have a unified view of the company no matter what channel they use to reach it. Ideally all front-end applications are designed to be integrated. In cases where applications are not integrated with each other, the business must use integration middleware to stitch the systems together.
As companies move toward e-business, they convert customer-, supplier-, and employee-facing business processes to self-service. Customers enter their own orders for products by going to a company's Web store; suppliers enter their own purchase orders and complete the requisitioning process through their own secure Web sites; employees file their own expense reports, create their own purchase orders, purchase office supplies, and buy all of their own travel tickets online.
To facilitate self-service, business processes must be streamlined to conduct Straight Through Processing. For instance, when an employee files an expense report, a workflow process notifies the employee's manager and debits the appropriate dollar amount from the company's financial systems, while crediting the employee in the company's payroll systems. E-Business integration middleware integrates all these discrete systems together to facilitate the business process.
As companies increasingly conduct business-to-business commerce through online marketplaces or exchanges, suppliers and customers who connect with these exchanges must automate their interactions in order to:
Suppliers and customers are beginning to use e-business integration middleware to tie their enterprise resource planning applications with online marketplaces to streamline business-to-business processes.
Oracle Corporation, for instance, offers a version of its own e-business integration middleware that links suppliers to the exchanges the company is building. This is known as the Oracle Integration Server.
Companies increasingly focus on their core competencies and outsource their enterprise applications to application service providers (ASPs) or to hosting companies. This creates a fundamental need to connect their own legacy information systems with those of the ASP and to connect the applications of one ASP to those of another. As a result, migrating a company's back-office systems from a corporate data center to that of an ASP creates demand for e-business integration middleware to tie these different systems together.
The business drivers of e-business integration translate into specific requirements within an integration infrastructure. To understand what kinds of integration middleware are required, we identify three fundamental reasons for e-business integration:
The first reason is the need to synchronize data between information systems. e-businesses require a consistent, global, enterprise-level view of their business objects or information. For instance, they require:
The fundamental integration need in all of these cases is for a consistent global view of information across the different systems that synchronizes data between the different information systems.
Synchronizing data between systems can be done either periodically by batch transfer or continually by repeated transactions.
For instance, synchronizing data between an online transaction processing system and a data warehouse is typically done by synchronization batch transfer. A batch job extracts new information from the transactional system, transforms it into the appropriate format, and loads or populates the data warehouse.
Other scenarios, however, require transactional data synchronization. For instance, when a banking customer makes an account transfer on a self-service Web site, the site must immediately reflect changes to his account. Account information stored in the bank's back-office systems must be synchronized through a transaction with the database backing the Web site. In some cases, the bank does not maintain two copies of a customer's account information: one in the database backing the Web site and another in the bank's back-office systems. Instead, the bank simply maintains customer information in one system and provides multiple applications with access to that system. This method has benefits and trade-offs associated with performance, scalability, and security that we discuss in the next section.
A second reason for intraenterprise or business-to-business integration is to separate one company's business processes and applications from those of its trading partners.
The growing complexity of software and the associated difficulty in upgrading to new software versions makes it necessary to isolate applications. As software grows more complicated, developers increasingly break big problems into multiple smaller problems that can be solved separately.
Developers create modules with well-defined interfaces between them that they combine together to develop the complete application. They focus on solving small problems within each module. By limiting communication between application modules through well-defined, standardized interfaces and by not sharing data between modules, developers can modify or upgrade one application module without affecting the other application modules. Program-to-program communication simplifies the application replacement process and minimizes the impact of a decision to change an application, relocate a data center, or even outsource the application completely.
Software complexity also affects the way one business communicates with another for business-to-business commerce. Each company looks to its trading partner as a provider of a service with well-defined standard interfaces. Developers standardize program-to-program communication by using application component models that define standardized interfaces for each module and a standardized protocol to communicate between modules.
In the same way, communication between companies is now being standardized with the definition of standard interfaces through which they communicate (captured as XML-based business object documents) and standard network protocols such as RosettaNet and OAGIS. Isolating one company's internal business processes from those of another enables each company to modify its internal processes without affecting its trading partners.
For instance, a company can change its own internal purchase order approval process. Because suppliers send the company purchase orders in a standard format over a standard Internet protocol, they are isolated from the company's purchase order approval process. This separation is a fundamental requirement for business-to-business commerce.
Business process automation, frequently called in the industry straight through processing, defines the process through which a multistep business process is streamlined. Automation eliminates human intervention by enabling one application to communicate directly with another.
For instance, most small electronic storefronts and companies conducting commerce online transfer new orders accepted by their front-end Web store database to their back-office financial and supply-chain systems by using a manual process such as file transfer protocol (FTP). Such manual intervention causes three problems: it introduces the possibility of human error, it reduces the speed and efficiency of order processing, and it raises the total cost of operating the storefront as the volume of orders grows.
Larger Web sites use a number of enterprise integration technologies to automate and streamline this multistep business process. These enable the storefront database to automatically propagate the order first to the financial system where the customer's credit history is validated and then to the supply-chain system to start the manufacturing and delivery process. Business process automation helps companies reduce costs, improve customer satisfaction, speed up business processes, and respond more rapidly to competition.
From an integration point of view, multistep business processes can be streamlined in two ways:
Certain applications that form part of a multistep business process can be linked together using a request and reply structure. For instance, a company that has set up a Web storefront can check a customer's credit rating and purchase history with the company before permitting the customer to proceed to checkout. In this case, the two steps of the business process, the Web storefront event and the credit rating application, are linked in a request and reply structure; the storefront sends a request to the credit rating application and requires a reply before it can proceed. These two steps in the business process are logically part of a larger composite application and must communicate with each other synchronously.
Interactive composite applications represent the most closely knit integration process. They always work in real time. Composite applications are rapidly growing in popularity as enterprises seek to provide more front-end marketing and service. A composite application generally appears to the end user to be a single Web application, but, behind the scenes, it invokes one or more mainframe transactions or calls to packaged applications or to NT applications.
Most applications that form part of a multistep business process are not linked in such a request and reply structure and can, instead, be linked together asynchronously.
A multistep process is the most common form of integration because it addresses so many business needs. In a multistep process, the applications are logically independent because each step results from the work of another system earlier in the process. For example, when an order is accepted at the Web store, it is sent to the financial application where it can be tracked and to the supply-chain application where it starts the supply chain planning process. The Web store needs to know only that the message has been delivered to the back-office applications to guarantee once-only delivery of the purchase in the order received in the purchase queue.
The communication between the different applications that makes up the different steps of the business process is performed asynchronously by using messaging middleware. Asynchronous communication has a number of benefits: it couples the two applications together, it isolates the applications from a network or system failure, and it isolates each application from a software failure in the other.
Asynchronous communication is increasingly used to streamline business processes within a company. Though useful internally, it is fundamental to linking together business processes between companies for business-to-business commerce.
To summarize: Enterprise application portfolios are becoming an expanding patchwork of independently designed systems. It is impractical to implement all enterprise-wide business functions using a monolithically designed set of systems. User requirements are inherently too complex and dynamic for any one design team to provide the entire solution. A typical enterprise must deal with applications written in-house many years ago, multiple newer independent software vendor's application packages, end-user client/server applications, and a growing number of Internet and intranet applications. However, unintegrated applications are no longer acceptable: business managers demand an increasing level of integration between their systems. The task of integrating these heterogeneous systems is a central function of the IT organization today. As a result, enterprises must employ a blend of data consistency, application isolation, and multistep business process automation techniques to address their integration needs.
In this section, we examine the various technological alternatives available for integration and the integration approaches that these alternatives enable. We have shown that e-business integration consists of three basic kinds of relationships: data consistency and synchronization, application isolation, and multistep business process automation. Now we consider the three primary technological alternatives for e-business integration:
Each of these integration technologies is suited to a specific kind of integration problem. No single integration methodology is suited to all integration problems.
We first examine the three different kinds of integration technologies and then discuss how each is suited to solving a specific integration problem. This section includes:
Data consistency patterns aim to obtain facts from redundant data that is stored in multiple systems. A number of different mechanisms are used to synchronize data between systems, but they can be broadly classified into two categories:
One way to synchronize data between different systems is to move data between the systems themselves. In fact, batch data transfer is the default approach to synchronizing data. Traditionally, many companies also use manual processes such as FTP to move data between systems. Database replication technology also synchronizes data stored in databases. Manual processes effectively synchronize data in a batch transfer or in pre-scheduled transactions.
However, as e-business drives the necessity to keep information consistent between systems, frequent real-time intervention is required. As a result, e-business requires that data movement use automated technologies such as database replication. Rather than relying on infrequent data batch runs, you must synchronize data using near-real-time transfer of individual updates as soon as you recognize them.
An alternative to moving data between systems is to keep data in one place and access it from multiple heterogeneous applications. This eliminates the necessity to constantly synchronize data by moving it between systems, something that is further complicated as systems multiply. To simplify, all data that must be accessed by different systems are stored in one central place to which all applications requiring subsets of the data have access.
Although this method eliminates the need for continual data movement, you must consider three fundamental concerns to determine whether you can solve the data synchronization problem by using a single database:
For example, if applications are distributed across a low bandwidth wide area network (WAN), data does not move smoothly or efficiently across a WAN. Thus, in this case, you might have to move data between the systems by batch or manual transfer. Heterogeneous data-access technologies are primarily gateways to enable access to heterogeneous data stores such as mainframe databases, hierarchical data stores, flat file stores, and others.
For example, an order may create a series of logically related transactions over a period of many days involving order entry, sales management, manufacturing, and supply chain planning and execution systems. In some cases, batch data transfer technologies are used to automate multistep business processes.
For critical business processes, workflow is automated through workload management tools such as workflow systems. Less critical and less well managed critical processes are often controlled through batch data transfer involving human intervention. As the need for faster end-to-end processing grows, batch transfers can become a bottleneck. Strategies such as end-to-end business process automation usually require messaging facilities to send individual events immediately to other systems. Data movement and data access technologies are best suited to synchronize information between different systems to provide a consistent global view of the information.
In order to isolate applications from each other, limited communication between applications occurs through a small set of well-defined interfaces that remain stable even as the applications change. In the modular development paradigm, components interact through program-to-program communication using well-defined standardized interfaces. Applications do not share data. By isolating program-to-program interaction to a small set of public interfaces, components are able to encapsulate business logic. An important added benefit of modularity is the ability to reuse components: if components are designed correctly, applications can be built by assembling these components in a plug and play fashion.
Three primary component models are used in the industry today:
As applications are increasingly developed using component-based techniques, a fundamental integration issue is the manner in which components communicate with each other. They can do so in two ways:
Each of the three common component models provides its own hosting environment for application components (called a container), which provides a set of services that enable components to operate. These include transaction services, naming and directory services, and brokering and trading services. For EJBs, these services are provided by a container called an Enterprise JavaBean Transaction Server; for CORBA, it is called an Object Request Broker or ORB; and for COM+, these services are provided by the Windows NT operating system itself.
These containers manage communications between components using a synchronous remote procedure call (RPC) mechanism. Synchronous communication is ideal when applications need to be isolated but are related to each other in a request and response structure. Component middleware such as an ORB is well-suited for such types of integration because it documents program-to-program interface definitions and manages the communications.
It is technically possible, although rare, to implement a one-way asynchronous event notification between heterogeneous applications using traditional ORB calls. The center of a standard ORB is designed for two-way, request-reply interactions; it lacks the sophisticated messaging facilities required to loosely couple applications, particularly those that facilitate a multistep business process. Message-oriented middleware solutions, particularly the new generation of integration brokers, are much better suited to carry out such integrations.
As automation of business processes within companies and business-to-business commerce increases, a new generation of middleware technology is emerging. It is based on asynchronous communication that loosely couples these applications and businesses together. The fundamental principle of messaging is to isolate information providers from information consumers so that an application can be added, dropped, or changed without affecting any other system.
Message-oriented middleware enables applications and business processes to communicate by sending a message from one application to the other. Since the applications are mission-critical, the middleware provides features such as guaranteed once-only delivery of the message, store queuing, and forward queuing. Additionally, these messaging platforms add sophisticated message routing and distribution facilities. These include:
Most component models such as Enterprise JavaBeans are now adding asynchronous communication interfaces to enable them to communicate with each other in a loosely coupled fashion. You can use basic message-oriented middleware both within a distributed application and to integrate one application to another because it is inherently connectionless. Asynchronous messaging facilities are best suited to applications that must be loosely coupled together such as when they form part of a multistep business process (and are not related in a request-response fashion).
Messaging middleware connects dissimilar applications in a fundamentally different way than do direct server-to-application gateways. Direct gateways are best at tactical, request-reply interactions especially when extending one or two back-end applications with a Web front end.
Message-based solutions are best suited for asynchronous applications that require either data consistency or multistep process applications and for systematic composite applications that have multiple heterogeneous participants. Messaging introduces an incremental layer of communication semantics and administration. This complexity is not necessary for some projects. However, messaging provides a rich, comprehensive infrastructure that handles consistency and multistep and composite patterns in one solution. Components dominate intra-application architecture and often are used to connect into message-based integration infrastructures.
Ultimately, message-centric integration connects all applications to each other through a general purpose enterprise hub. All applications publish information to this integration hub without needing to know where to send it, who will receive it, or what format the receiver prefers. The whole application portfolio remains flexible because connection logic and delivery instructions reside in the infrastructure rather than in the applications themselves.
Messaging enables a program to act as a producer by placing a message in a queue and then proceeding with its work. The queuing system reliably delivers the message to the appropriate recipient. The recipient, acting as a consumer, retrieves requests from the queue and acts on them. By isolating requests for service from the supply of services, messaging increases efficiency and provides the infrastructure to schedule complex tasks. With messaging, programs do not communicate with each other directly. They are disconnected from each other and communicate through the messaging system that serves as a communication hub among different application programs. Messaging, therefore, provides a useful paradigm for getting many programs to communicate with each other.
Three specific application design issues frequently motivate the use of a messaging service for interapplication communication.
Messaging is ideally suited for applications in which a program can proceed with its own work after sending a message to another program: the first program does not need to wait for a response from the second program to proceed. It is also suited for applications that can continue their work until a message must be retrieved.
If the first program requires a response to proceed, messaging is an inappropriate communication mechanism. A synchronous communication mechanism such as Net8 or CORBA RPC is preferable. In a synchronous mechanism, the first program sends a request to the second and then waits until the second sends a reply. The first uses this response to carry out further processing.
Messaging, in contrast, is suited to applications that do not require such a relationship; the first simply places a message on a queue and continues with its work without waiting for a response from the second.
Note that you can use these two models, synchronous communication and messaging, together in the same application. For instance in a shipping application, the order entry program communicates with another customer management program to check the validity of a customer before accepting his or her order. This requires synchronous communication, since the order entry program requires the reply from the customer management program before continuing to process the order.
However, when the order is complete, the order entry application notifies the shipping program that an order must be sent to the customer. This communication is best done using messaging since the order entry application does not need to wait for the response from the shipping program to further process the order.
The second factor that could influence you to use a messaging system for inter-program communication is the deployment architecture of the application. For synchronous communication to work, all programs must be running and available at the same time. The network that connects the programs must be available, the systems that run the programs must be up, and all the programs must be available simultaneously. If any nodes of the deployment environment are unreliable, then messaging provides a more robust solution. Messaging removes the time-dependent relationship between programs. As a result, applications are less vulnerable to program failure. For deferred execution to work correctly in the event of network, system, and application failures, messages that constitute requests for service must be stored persistently and processed exactly once. Being able to preserve messages is fundamental in an enterprise messaging infrastructure for four reasons:
|
 Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|