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 |
|
You have seen how the Oracle Integration Server supports a wide variety of e-business integration architectures and learned about the primary drivers of e-business integration and the specific components of Oracle Integration Server that meet these requirements. Next, we examine in greater detail the use of asynchronous messaging for enterprise integration. This chapter includes:
Asynchronous message-based integration is rapidly emerging as the primary technology required for enterprise integration. To help you understand how to use it most effectively, we next:
In order to understand how messaging can best be used for e-business integration, we now consider in detail the technical architecture associated with connecting a supplier's supply chain application to a business-to-business trading marketplace or exchange. This section includes:
For example, a supplier must automate the way it interacts with a B2B exchange so that it can automatically
Let us consider how the integration works from both the supplier standpoint and from the exchange standpoint. From an integration point of view, three primary technological requirements enable such communication. These include:
To send a message from its supply chain system to the exchange, the supplier must use a solution that receives a message payload and propagates it to the exchange. The message propagation facility must provide a number of services:
In propagating the message from its supply chain system to the exchange, the supplier must address two message or data transformation issues:
Before sending the message to the exchange, the supplier may need to get approval for the price list from an appropriate executive. Similarly, in responding to a purchase request from the exchange, the supplier may need to send the message to the company's Financial Application and to update the inventory status in the Supply Chain Application. To manage this multi-step business process, the supplier must maintain a business process management or workflow facility that coordinates messages between the different applications and the exchange with this:
Before sending the message to the exchange, a local workflow process may need to be invoked in order to determine whether there is sufficient inventory associated with each of the items on the new price list. In this case, a business process management facility will be required at the supplier end. The business process management or workflow facility will need to route the new price list from the backoffice application to the company's inventory application to compare inventory status for items on the price list. To manage this multi-step business process, the supplier must maintain a business process management or workflow facility that coordinates messages between the different applications and the exchange. Further, since a single business process may involve coordinating business events between the company's enterprise applications and with an exchanging or an external trading partner, a single business process management or workflow facility should be used for both intra-enterprise and business-to-business interactions.
Now that we understand the primary requirements for this integration scenario, let us examine in greater technical detail the specifics of the integration from the perspective of both the supplier and the exchange.
Various steps and integration components link the supplier's supply chain application with the business-to-business exchange. In this scenario this is an Oracle exchange. The steps and components involved in establishing such connectivity are illustrated in Figure 1.
These steps and components include:
The integration architecture of the Oracle exchange resembles the architecture described in the previous section.
An XML payload is received over the wire on the HTTP-S protocol and goes through the following stages:
We have now explained the concepts of the integration of applications and business processes using an asynchronous messaging infrastructure. In this section, we discuss in greater detail the specific technical aspects of the use of asynchronous messaging for e-business integration: This section contains:
Highly interdependent processes, often described as closely coupled or tightly coupled processes, are more difficult to maintain, more failure prone, and more difficult to recover than processes that operate independently of each other. For this reason, developers are increasingly designing modular applications with as much independence between processes as possible.
To limit the dependency between two processes, developers use
Middleware comprises a storage medium for messages called a queue, a generic message-passing process called a message broker, or both a queue and a message broker. Communicating through this intermediary enables each process to operate independently of the availability, performance, physical location, or implementation style of another process.
Aspects of the messaging system that is required for e-business integration including:
Two processes can communicate through a message either synchronously or asynchronously.
In synchronous processing, the sending process passes control to the receiving process and suspends processing until it receives a reply from the receiving process to confirm that it has received and processed the message.
In asynchronous processing, the middleware queue separates the sending process from the receiving process. The sending process continues processing as soon as the middleware receives the message. Note that a multithreaded program, one of whose threads waits for a message to be processed, is operating synchronously, even though the program continues to process other threads while that thread awaits a reply.
A message can be created or processed either in encapsulation or in the context of a session. A session is a period of time during which a user or a process establishes a recognized and predefined connection to another process. Messages are either durable or non-durable. Durable messages can be sent independently of a currently running session. Non-durable messages cannot, and they require session-based communication.
Session-based communication between processes takes place within the context of a session. The rules that govern the session affect the way the message is created and processed. Session rules also affect the way the middleware manages the message: how it is routed and stored and retained, whether a reply is sent to the sender, and so on.
Sessionless communication takes place outside of the context of the currently running session. The durable message is processed through a previously established connection to the database, the middleware, or the application. A sessionless message can be managed and processed without the requirement for additional information provided by the currently running session.
The transactional state of a communication is either "with state" or "without state." The transactional state is the state of the communication. It has nothing to do with stages in the life cycle of the message itself: created, ready for processing, processed, and so on.
"With state" communication occurs when messages are created, managed, and processed within the context of a single transaction. The position of the message within the transaction affects the way the message is processed. The process that creates the message, the middleware, and the process that acts on the message all independently maintain the "with state" condition so that the message is processed in the context of the transaction.
"Without state" communication occurs when messages are processed without reference to their position within a single transaction or when the message crosses transactional boundaries.
Synchronous communication is two-way communication because the sender of the message waits until it receives a reply indicating that the message has been successfully processed. In general, communication that is "with state" or session-based is two-way communication. A message sent in the context of a session or transaction is almost always associated with a reply sent by the receiving process.
The data contained in a message is its payload. A message sent from one discrete process or application to another independently of a session or transaction contains sufficient information to enable processing. Because further communication with the sender is not required to process the message, it is said to have an autonomous payload.
An asynchronous, "without state," sessionless message with an autonomous payload is a one-way communication. The management and processing of the message have no impact on the sender process, which continues immediately after the message is sent. One-way communication adds another degree of separation between the sender and the receiver of the message.
Now that you understand the broad technical aspects of messaging, we examine the two primary architectural alternatives in the use of messaging for e-business integration. Depending on your data processing and messaging requirements, you can use one of two possible architectures to organize your solution.
Two alternative message-based integration architectures and their relative benefits and trade-offs
A point-to-point integration architecture integrates each application directly with each of the other applications with which it needs to communicate. The applications communicate with one another directly on a one-to-one basis. This architecture has historically been used to provide file-based integration between applications.
It requires relatively little architectural infrastructure. In a phased implementation, it speeds implementation of the early phases. However, it has recognized limitations, particularly in terms of ongoing maintenance costs (which can be exponentially higher than those of hub-and-spoke architecture), and in lack of flexibility and manageability.
In contrast to point-to-point integration, most modern integration scenarios are best served by hub-and-spoke architecture. A hub-and-spoke architecture provides a central intermediary (called a hub) through which applications communicate with each other. In this architecture, each application (which represents a spoke) communicates with the intermediary (the hub), which in turn manages communication with the other applications. Applications do not communicate directly with each other.
In the context of a hub-and-spoke integration architecture, the hub provides a central point for a variety of services:
Note that because integration architecture is defined at many different levels, the hub-and-spoke structure may not exist at all levels. For instance, the hub and the spoke might all be deployed on the same hardware or potentially on different systems. In general, the hub provides a focus for application interfaces and integration requirements because each spoke communicates only with the hub. This isolates the resource requirement for integration services.
Some people think that the hub-and-spoke approach simplifies the interface to an application by reducing the number of integration points into an application. Actually, the API is as complex as in a point-to-point architecture, but the hub-and-spoke approach focuses the integration points for an application into one place, thus making applications easier to design, develop, and manage.
Consider two primary differences between hub-and-spoke and point-to-point architectures:
In a hub-and-spoke architecture, the hub provides these services to all the applications and thus simplifies how the integration occurs.
Now that you understand how you can use asynchronous messaging for e-business integration, we examine some of the key aspects of messaging technology specifically discussing in this section:
A fundamental requirement for an asynchronous messaging infrastructure that furnishes a platform for e-business integration is that the infrastructure provide persistent storage and management of messages. As described earlier, the ability to store and manage messages is critical for four reasons:
Such message priorities may also change over time: for instance, messages in a particular queue may become more important than messages in other queues during certain time windows. Message persistence enables messages in high priority queues to be processed first. Low priority messages can be stored and processed later without interfering with high priority messages.
Note that the need for message persistence is enhanced in a business-to-business commerce scenario in which the likelihood of communication failures and the need for auditing and tracking are far more significant than within a single enterprise. Although most messages in an integration scenario must be stored persistently, in some cases volatile messages are sufficient. For instance, if an e-mail is sent to an application to notify it that a message has been sent or received, the e-mail message need not be stored for auditing.
Most messaging systems do not provide automatic message persistence. They simply store the messages in RAW format in a file system. As a result, the message headers and payloads are not queryable. If the message does need to be stored persistently, the messaging system requires a two-phase commit operation between itself and a database system.
In contrast with such complexity, Oracle Corporation integrates a messaging infrastructure directly with its enterprise database: associating queues with database tables and ensuring that messages placed in these queues automatically persist in the database. You can then archive the messages and execute queries against both message headers and payloads using standard SQL.
Because messages must be propagated from one application or business process to another, the messaging infrastructure offers a mechanism to route the message from the sender to the receiver. Message propagation and routing can be performed in one of two ways:
A process identifies itself to the middleware as a subscriber and defines the topics on which it receives messages. The middleware sends the subscriber any future messages on that topic until the subscriber informs the middleware that it no longer wants messages on that topic or ceases to subscribe. This design technique provides an additional level of separation between the processes. The sender publishes message to middleware without regard to the receiver of the message, the delivery location, or the processing of the message. The middleware is responsible for:
The subscriber registers an interest in receiving messages on particular topics and subscribes without regard to the sender or publisher of the message and where the message is created.
Point-to-point and publish-subscribe based message routing are the two broad categories of message routing. In reality, each of these schemes can be more complex. For instance, in both a point-to-point and a publish-subscribe environment, messages can be routed in three ways: subject-based, topic-based, and rule-based. We now consider each of these and discuss, with examples, how each applies to publish-subscribe routing.
PLACE AN ORDER. Subscribers that have registered with the middleware stating an interest in receiving messages on that topic receive all messages on that topic until they unsubscribe from that topic: "Send me all messages on the topic PLACE AN ORDER."
PLACE AN ORDER in which the message contains UK in the country code field of the message data."
PLACE AN ORDER in which the message contains UK in the country code field of the message and the current time is between 9 am and 5 pm and I have the spare capacity to fulfill the order."
Businesses commonly use two messaging models to facilitate internal communication. A complete communication solution typically requires use of both models:
The event notification model addresses the need to communicate business events throughout the business. A business event is a logical occurrence in a business scenario. It may be simple, as when a customer places an order, or it may be more complex, as when a customer exceeds his credit limit while placing an order. A system event, on the other hand, is a physical point in the execution of a program at which an identifiable computing task takes place, for instance, writing to a file. A single business event is usually associated with a number of system events.
The event notification model defines the communication points between applications and the content of the communication. It uses asynchronous messaging and publish-subscribe routing to deliver messages that represent instances of a business event. Each business event is defined to the middleware as a separate publish-subscribe topic. The application or applications that process the business event also publish a message each time an instance of a business event occurs. An application that must know about the business event subscribes to the topic relevant to that event. The middleware manages delivery of the message to the subscriber and collection of the message by the subscriber.
Typically, each message announcing a business event is autonomous and requires no communication between the applications other than delivery of the message. Usually the subscriber need not respond to the publisher. Once it has acted on the information received in the message, the subscriber can raise an instance of another business event and can publish messages about this business event as another topic.
The second of the two most commonly used messaging models, the service request model, offers an alternative modeling style to event notification. It is based on the premise that one application can avail itself of the services of another application. For instance, application A requests a service from application B by creating a service request in the form of a message.
The service request model has many more variations than the event notification model. The variant selected depends on the requirements of the individual solution. For instance, the service request model is implemented using asynchronous messaging when no confirmation of service delivery is required. This variant may use publish-subscribe routing. If a confirmation is required, whether it is positive or negative, the service request model is implemented either by using asynchronous messaging or by synchronously using a call-and-reply messaging technology.
In a service request model, the application requiring a service that it cannot itself provide creates a service request message for a named application that provides the service. The middleware routes the message to the named application. The application providing the service has a defined means of invoking the services of queues and of a callable API. Three of the possible variations of the service request model are shown here:
If you use asynchronous messages to integrate applications or business processes, a fundamental requirement is to transform the message payload sent by the originating application to a different format that can be accepted by the receiving application. To understand the transformation process, consider an Oracle Customer Relationship Management (CRM) application that is attempting to send a purchase order received in its Web store module to an SAP financial application. There are two specific transformation requirements:
The Oracle CRM application stores all its data in SQL format and the SAP application stores and accesses its data in iDOCS, which is a flat file format. SQL datatypes must be converted into the iDOCS datatype at the byte representation level; this is called datatype or data level transformation. When considering data transformation itself, a number of different kinds of transformations can apply:
CUSTNUM to customer_id.
BranchId, CustomerNo, AccountType and CheckDigit to give AccountNumber.
The Oracle CRM application stores a customer name in four fields: Mr./Mrs./Miss, First Name, Last Name, Middle Initial. In contrast, the SAP application stores the same customer name in two fields: the first field specifying Mr./Mrs./Miss and the second field concatenating the First Name and Last Name with a blank in between. In this case, you must concatenate the fields in the customer name of the Oracle application before sending it to the SAP application. Such a transformation is called semantic transformation.
In addition to understanding these two different kinds of transformation requirements, you must consider four additional issues when thinking about how messages need to be transformed for a particular integration scenario.
In a point-to-point integration architecture, the sending application transforms the message into the format of the receiving application and then places the transformed message on the message propagation infrastructure, which then passes it to the receiving application.
If transforming data from a sending application to a receiving application in a hub-and-spoke architecture, you must decide whether to transform the message at the spoke or at the hub. For instance, the sending application might behave in the same way as in a point-to-point environment and simply use the hub as a message propagation and routing infrastructure. In contrast, if a single application sends information to multiple receiving applications, it can simply send an untransformed payload to the hub, which then applies the transformation appropriate to the target application receiving the message.
Additionally, in a hub-and-spoke architecture, the hub can directly transform the payload of each sending application into the format of the receiving application. Alternatively, each application can transform its data from an application-specific view into a common view and then send it to the hub, which converts it from the common view to the target application-specific view. The primary benefit of using a common view for transformation is that when a new application is added or an existing application is upgraded, the integrator needs only to change the mapping from the common view to the application specific view. It need not change the mapping from every single application that communicates with this application. As a result, using a common view for transformation is more extensible than direct transformation.
Using a common view for data transformation affects the way the data itself gets converted. In typical scenarios, the common view of data is increasingly represented using XML (or in certain cases Java classes). An adapter associated with the sending application converts the data from the application-specific format into the common view representation, places it in an XML document, and then sends it to the messaging infrastructure of the hub. The hub then applies an XSL-T transformation to the XML document based on the necessary semantic information, converts it to an outgoing XML representation, and places it on the message propagation infrastructure. An adapter of the receiving application then receives the XML payload, parses the XML payload, and converts it into the data format of the receiving application.
Note two important benefits of transforming data into XML:
There are, however, two potential drawbacks to using XML:
Finally, consider the frequency of transformation and the business events that necessitate a transformation. There are three kinds of such transformation events:
When considering an e-business integration scenario, the final aspect of messaging that you need to understand is interoperability between different message queuing systems and different types of integration middleware:
In order to ensure interoperability between messaging systems at both the payload and the system level, messaging middleware vendors have adopted two standards:
In the next section, we provide a brief overview of these two standards.
Java Messaging Services (JMS) is the Java industry standard for asynchronous messaging, developed jointly by Sun and other enterprise messaging vendors including Oracle. It complements the synchronous communication model specified by Java Remote Method Invocation (RMI).
The most commonly held misconception about JMS is that it is an application or component that provides messaging services. JMS itself is simply a definition of a standard. Vendors of messaging technologies (such as Oracle) develop and sell software (such as Advanced Queuing) to provide messaging services that conform to the JMS standard and that can be accessed through a Java API that conforms to the JMS standard.
These JMS compliant services are made available through a published interface that complies with the JMS standard for the programmatic interface (API). The API provides a framework that enables you to develop portable, message-based applications in the Java programming language.
The JMS standard defines four important components:
The JMS standard defines two types of message routing:
The JMS standard defines various characteristics about messages including some properties relating to the message itself (stored in the message header) and a number of different styles of payload for the message content. It also defines how content-based publish-subscribe is implemented using filtering conditions on the message header and its properties. The five styles are:
Each vendor who offers a JMS implementation develops a set of services that conform to the standard. The vendors are free to extend their implementation to offer services beyond those defined in the JMS standard.
Oracle8i Advanced Queuing offers just such an extended JMS interface, which is called Oracle Java Messaging Services (OJMS). Oracle provides JMS Queues using Advanced Queuing single-consumer queue functionality. Each JMS queue is mapped one-to-one to a single-consumer queue. JMS topics are supported using Advanced Queuing multi-consumer queues. Each JMS topic maps to a multi-consumer queue. Each JMS message type maps to an Oracle Object Type. The JMS connection encapsulates a JDBC connection. This enables the client to combine JMS messaging and other JDBC operations in the same database transaction. JMS Clients executing outside the database JVM can access the JMS API using the "thin" or "OCI" JDBC driver. JMS Clients executing inside the database JVM (JServer) can access the JMS API using the Oracle Server driver. The standard JMS interfaces are available in the javax.jms package.
The Oracle extensions to the JMS implementation can be found in the oracle.jms package.
XML (eXtensible Markup Language) is a markup language for documents containing structured information. It provides a mechanism for applying structure to an information set, such as a message or a document, by enabling the data in the set to be labeled, assigned attributes, qualities, or default values and enabling you to verify or validate the information set. It is becoming the standard message format for e-business and is the preferred standard for most major IT vendors.
The main advantage of XML lies in its flexibility and its simplicity. Each message contains within it the information required for the structure of the message to be understood. This is often called a self-describing message. Consequently, any program that knows the rules of XML can understand any message formatted as an XML message without having to store and overlay metadata about the structure of each message.
XML was derived as a subset of the SGML (Standard Generalized Markup Language), which has been the standard, vendor-independent way to maintain repositories of structured documentation for more than a decade. SGML is very powerful but complex to use for e-commerce, so XML was developed as a simplified version of SGML.
The content of a message or document can be thought of as a logical set of information, and that information often needs to be structured so that pieces of the information can be identified, accessed, and manipulated as subsets of the message or document. These subsets are known as elements. Each element can be made up of any number of other elements, and elements can repeat in a group.
XML has syntactic semantics that enable you to define labels known as tags that define where an element starts and where it ends. It is possible to define attributes that describe the characteristics of the element as a whole. These attributes apply to all the sub-elements and to the data contained within the element.
XML also enables you to define a validation template called a Document Type Definition or DTD, which can be used to provide two levels of validation:
|
 Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|