Oracle Application Integration Architecture (AIA) solutions are Mediator and BPEL services that create specific integration scenarios between named participating applications. The services use diverse interactive styles and patterns for exchanging messages. This chapter lists various patterns, highlights their features, and presents guidelines for choosing them based on integration scenarios.
This chapter includes the following sections:
The business requirements of an integration scenario drive the need for different message exchange patterns between participating applications.
An application integration leverages the core functionalities of the best applications and links tasks to business processes. The functionalities are exposed as APIs. Events in applications trigger information interchange as a straight-through process consisting of multiple tasks spanning multiple applications. This can be real-time or batch mode. Triggering events can invoke interactions that are synchronous, asynchronous, or a combination.
Synchronous operations wait for a response before continuing. This forces operations to occur in a serial order. An operation blocks or waits for a response. Synchronous operations open a communication channel between the parties, make the request, and leave the channel open until the response occurs. This is effective unless many channels are left open for long periods. In that case, asynchronous operations may be more appropriate. The synchronous pattern may not be necessary or appropriate if the end user does not need an immediate response.
Asynchronous operations do not wait for a response before continuing. This allows operations to occur in parallel. The operation does not block or wait for the response. Asynchronous operations open a communication channel between the parties, make the request, and close the channel before the response occurs. Message correlation relates the inbound message to the outbound message. This is effective when many transactions take long periods of time to process. If the operations are short or must run in serial, synchronous operations may be more appropriate. The asynchronous pattern is effective if the end user does not need immediate feedback.
The following sections describe basic message exchange patterns and variations.
In this pattern, a requester sends a message to a replier system, which receives and processes the request, ultimately returning a message in response. Two applications have a two-way conversation over a channel.
Suppose an application that requests information from an external system has to wait for the response.
A CRM application gets account details from a billing application. The service representative clicks a button in the CRM application, which sends an Application Business Message (ABM) to the Siebel Get Account Details Application Business Connector Service (ABCS), which invokes the Get Account Details Enterprise Business Service (EBS). The CRM application waits for the Siebel Get Account Details ABCS to return the ABM before rendering the information on the screen.
The requester sends a request message and waits for a response message. The service provider receives the request message and responds with either a response message or a fault message. After sending the request message, the requester waits until the service provider responds with a message or a time out. The request and the response messages are independent.
Suppose a customer integrating two applications does not want the sender application to be affected if the receiving application is unavailable.
A customer wants to convert opportunities in the CRM On Demand application to quotes in the CRM On Premises application in real time or near real time. However, non-availability of the CRM On Premises application must not impact the CRM On Demand application. Most important, work done with CRM On Demand cannot be lost.
Asynchronous transaction using queue/topic
Oracle AIA uses queues for asynchronous and reliable message delivery. When a business event occurs, CRM On Demand can either push the message directly into a queue or send a SOAP message over HTTP to a JMS message producer (a Mediator adapter) that enters the message in a queue. CRM On Demand considers a message sent when it is dropped into a queue. CRM On Demand can continue sending new messages regardless of CRM On Premises availability. A JMS consumer (a Mediator/BPEL service with a JMS adapter) dequeues each message and invokes the CRM On Demand ABCS. This transaction ensures that a message is removed from the queue only after the CRM On Premises application successfully completes its task.
Suppose a customer wants to route requests to different applications providing the same business function based on certain criteria.
The customer uses vendor A's billing system for servicing EMEA customers and vendor B's billing system for servicing North American customers. The customer does not want the CRM system that gets bill details for customers to also route requests to the appropriate billing system.
Oracle AIA architecture can decouple the requester and provider. For this use case, Get Bill Details is the EBS operation. Each billing application provides an ABCS for Get Bill Details. The ABCS of the CRM application is integrated only with the Get Bill Details EBS. The Get Bill Details EBS is implemented as a Mediator routing service. The customer can define the routing rules at this level to identify the appropriate ABCS to invoke. For EMEA customers, vendor A's ABCS is invoked. For North American customers, vendor B's ABCS is invoked. Each vendor's ABCS gets bill details from their applications, converts the details to Enterprise Business Message (EBM) format, and sends the EBM to the EBS.
For more information, see Section 1.8.2, "What is an Enterprise Business Service?".
Suppose a customer wants to route requests to different instances of the same application based on certain criteria.
The customer has two Oracle BRM application instances: A for servicing EMEA customers and B for servicing North American customers. The customer does not want the CRM system that gets bill details for customers to also route requests to the appropriate BRM instance.
Oracle AIA architecture can decouple the requester and provider. For this use case, Get Bill Details is the EBS operation, which is implemented as a Mediator routing service. The BRM application has only one ABCS, which is integrated only with the Get Bill Details EBS. The customer must define a transformation service that adds target system information to the EBM header, which the BRM ABCS uses to route the request to the right BRM instance.
For more information, see Section 1.8.2, "What is an Enterprise Business Service?".
Suppose a business document with multiple line entries needs each line to be handled differently.
The customer uses vendor A's billing system for broadband customers and vendor B's billing system for wireless customers. A CRM system sends a Process Order Request EBM that can contain requests for both services. Vendor A's billing system receives the broadband-related portion of the order and vendor B's billing system receives the wireless product-related portion.
Message splitting and routing
The CRM system (CRM ABCS) invokes the Process Order EBS operation. The implementation is a BPEL process that splits the order business document into multiple business documents, each having data for only one order line. Each order line business document is passed to another EBS, such as Activate Service, which uses the routing rules to decipher the billing system to use.
Suppose a requester application does not send all the data required for invoking the EBS.
The CRM application passes only the order identifier as part of the ABM to the requester ABCS for invoking the Order Fulfillment process. However, the ProcessOrder EBS expects the entire order object.
Data enrichment of the ABM
Data enrichment may be required when the ABM received from the participating application lacks required content. The ABCS must use web services (or JCA-based adapters, if available) to get the information required to enrich the ABM from the participating application. The participating application must expose the needed business capabilities as web services.
Suppose a provider application does not return all the data the EBS operation requires.
The provider application does not have a service that matches the granularity of the EBS operation.
The EBS operation Get Bill Details provides complete bill information (information for all of the services in one bill) for a customer. It passes the customer identifier and the month as input parameters to the service provider. It expects the complete bill details from the provider. The billing application has a web service that provides only a bill summary. The application does not have a single service that provides complete details. However, it does have services to get details for every part of the bill.
Data aggregation of the ABM
You may need multiple interactions with the provider application to get all the needed content. Then you must combine the content to return a single response to the EBS. The billing application ABCS interacts with the provider application using three web services to retrieve the bill header, bill summary, and bill details. After retrieving all of the content, the ABCS combines the three ABMs and produces a single EBM.
Suppose information needed for providing a response is spread across multiple applications.
The EBS operation Get Bill Details provides complete bill information (information for all of the services in one bill) for a customer. It passes the customer identifier and the month as input parameters to the service provider. It expects the complete bill details from the provider. However, the customer has three billing applications, each with information about only one service: wireless, broadband, and land line.
Data aggregation of the ABM
The ABCS for the Get Bill Details EBS must retrieve details from multiple billing applications. It interacts with the applications using the services they provide. After retrieving all of the content, the ABCS combines the three ABMs and produces a single EBM.
A request-delayed response pattern is asynchronous. The requester sends a message and sets up a callback for a response, but does not wait for it. When the response arrives, a separate response thread invokes the appropriate callback and processes the response. The EBS has two operations; one for sending the request and another for receiving the response. The operations are independent and atomic. A correlation mechanism establishes the caller's context.
In a request-delayed response pattern, the requesting service invokes a one-way request operation in an EBS. The requesting service waits for the response. The EBS invokes the providing service. The providing service, after ensuring that the request is serviced, invokes the response EBS. The response EBS pushes the response to the requested service that waits for the asynchronous response. If an error occurs in the providing service, the response includes fault information. In the Customer EBS WSDL, the portType having all the Request-Response or Request only operations defines the one-way request operation. The portType having all the Response operations defines the one-way response operation.
In many integration scenarios, participating applications publish events and messages to which multiple participating applications subscribe. This pattern is transactional: it changes entities in the participating applications. These scenarios require an asynchronous and durable implementation model.
For more information about the publish-and-subscribe interaction pattern and implementing the publish-and-subscribe programming model, see "Establishing Resource Connectivity" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.