Oracle Application Integration Architecture (AIA) solutions are delivered as Mediator and BPEL services to create specific integration scenarios between named participating applications. The services interact with each other in various ways, giving rise to diverse interactive styles and patterns for exchanging messages between services. This chapter lists various patterns, highlights the features, and presents guidelines for choosing patterns based on their suitability to an integration scenario.
This chapter includes the following sections:
Section 5.1, "Introduction to Patterns for Exchanging Messages"
Section 5.6, "Asynchronous Request - Delayed Response Pattern"
For more information, see "Working with AIA Design Patterns" in Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
Business requirements drive the need for different patterns to exchange messages between participating applications in an integration scenario.
In any application integration, the core functionalities of the best applications are leveraged to accomplish tasks by linking them 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. From the perspective of events triggering the information interchange, the interactions can be invocations that are synchronous, asynchronous, or a combination of the two.
Synchronous operations wait for a response before continuing. This forces the operations to occur in a serial order. It is often said that 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 method is effective unless large numbers of channels are being left open for long periods of time. 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 is used to relate the inbound message to the outbound message. This method is effective when large numbers of transactions could 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 basic patterns for exchanging messages along with variations of the basic patterns are detailed in the following sections.
In this pattern, a requester sends a request message to a replier system, which receives and processes the request, ultimately returning a message in response. This enables two applications to have a two-way conversation with one another over a channel.
Consider the following business problem: An application making a request to get information from an external system has to wait until the response is received.
Use case
A CRM application gets account details from a billing application. When the service representative clicks a button in the CRM application to get the account details for a customer, the CRM application sends an Application Business Message (ABM) to the Siebel Get Account Details Application Business Connector Service (ABCS), which is responsible for invoking the Get Account Details Enterprise Business Service (EBS). The CRM application waits for the ABM to be returned by the Siebel Get Account Details ABCS before it can render the information on the screen.
Synchronous request-response
The requester sends a request and waits for a response message. The service provider receives the request message and responds with either a response or a fault message. After sending the request message, the requester waits until the service provider responds with a message or a time out. Both the request and the response messages are independent.
Consider the following business problem: A customer integrating two applications does not want the sender application to be affected due to non-availability of the receiving application.
Use case
The customer has CRM On Demand and CRM On Premises applications. The customer wants the opportunities that are created in the CRM On Demand application to be created as quotes in the CRM On Premises application. The conversion of opportunity to quote happens in real time to near real time. But at the same time, non-availability of the CRM On Premises application should have no impact on the functioning of the CRM On Demand application. Also, no work that is done on CRM On Demand during non-availability of CRM On Premises can be lost.
Asynchronous transaction using queue/topic
Oracle AIA uses queues for asynchronous and reliable delivery of messages. CRM On Demand, upon occurrence of a business event, 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 is responsible for entering the message in the queue. CRM On Demand can consider the message as sent as soon as the message is dropped into the queue. With this mechanism, the CRM On Demand application can continue sending new messages regardless of whether the CRM On Premises is available. A JMS consumer (another Mediator/BPEL service with JMS adapter) is responsible for dequeuing the messages and invoking the CRM On Demand ABCS. Having the CRM On Demand ABCS, EBS, the CRM On Premises ABCS, and the web services as part of the transaction initiated by the JMS message producer ensures that the message gets removed from the queue only after the successful completion of the task in the CRM On Premises application.
Consider the following business problem: A customer with multiple applications providing the same business function wants to employ certain criteria to identify the application that can provide service for a specific request.
Use case
The customer has two billing systems-one from vendor A and one from vendor B. The customer uses vendor A billing system for servicing EMEA customers and vendor B billing system for servicing North American customers. The customer has a CRM system that gets bill details for their customers. They do not want the CRM system to be responsible for routing the request to the appropriate billing system.
Message routing/mediation
Oracle AIA architecture enables the requester to be completely decoupled from the provider. For this use case, Get Bill Details is the EBS operation. Each of the billing applications provides 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 that must be invoked. For EMEA customers, vendor A's ABCS is invoked; and for North America customers, vendor B ABCS is invoked. Each of the vendor's ABCS is responsible for interacting with their applications to get the bill details and hand them over to EBS in Enterprise Business Message (EBM) format
For more information, see Section 1.8.2, "What is an Enterprise Business Service?".
Consider the following business problem: A customer with multiple instances of the same application providing the same business function wants to employ certain criteria to identify the application instance that can provide service for a specific request.
Use case
The customer has two instances of the Oracle BRM application in their ecosystem-BRM Instance A and B. The customer uses BRM instance A for servicing EMEA customers and instance B for servicing North American customers. The customer has a CRM system that gets bill details for their customers. They do not want the CRM system to be responsible for routing the request to the appropriate BRM instance.
Message routing/mediation
Oracle AIA architecture enables the requester to be completely decoupled from the provider. For this use case, Get Bill Details is the EBS operation. Only one ABCS for the BRM application exists. This ABCS is responsible for routing the request to the right instance. 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 that must be invoked. The customer must define a transformation service for populating the target system information in the EBM header. The BRM ABCS uses the information present in the EBM header to route the request to the right BRM instance.
For more information, see Section 1.8.2, "What is an Enterprise Business Service?".
Consider the following business problem: A business document with multiple line entries needs each one of the line items to be handled differently
Use case
The customer has two billing systems-one from vendor A and another from vendor B. The customer uses vendor A's billing system for broadband customers and vendor B billing system for wireless customers. The customer has a CRM system that sends a Process Order Request EBM that can contain requests for both the services. In this situation, the broadband-related portion of the order is sent to vendor A's billing system and the wireless product-related portion of the order is sent to vendor B billing system.
Message splitting and routing
The CRM system (CRM ABCS) invokes the Process Order EBS operation. The implementation is a BPEL process that is responsible for splitting the order business document into multiple business documents each having data for only one order line. After splitting the documents, each of these is handed over to another EBS, such as Activate Service. This EBS uses the routing rules to decipher the billing system that must be used.
Consider the following business problem: The requester application does not send all of the required data that is necessary for invoking the EBS.
Use case
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 to be passed as the payload.
Data enrichment of the ABM
This may be required in situations in which the ABM that is received from the participating application does not contain all of the required content. The enrichment can be done by issuing additional calls to the participating application to get more information. In this situation, the ABCS is responsible for interacting with the participating application using web services (or JCA-based adapters, if available) to get all of the required information to enrich the ABM. The participating application is responsible for exposing the needed business capabilities as web services.
Consider the following business problem: The provider application does not return all of the required data expected by EBS.
The provider application does not have a service that matches the granularity of the EBS operation.
Use case
The EBS operation Get Bill Details provides complete bill information for a particular customer. It passes the customer identifier and the specific month as the input parameters to the service provider. It expects the complete bill details from the provider. The billing application has a web service that can provide only bill summary. The application does not have a single service that can provide the complete details. However, it does have services to get details for every part of the bill.
Data aggregation of the ABM
You may need to make multiple interactions with the provider application to get all of the content; and then combine them to produce a single response that can be returned to the EBS. For this use case, the ABCS for the billing application interacts three times with the provider application using three web services-for getting bill header, bill summary, and for bill details. After retrieving all of the content, the ABCS is responsible for combining the three ABMs and producing a single EBM.
Consider the following business problem: Information needed for providing the response is spread across multiple applications.
Use case
The EBS operation Get Bill Details provides complete bill information (information for all of the services in one bill) for a particular customer. It passes the customer identifier and the specific month as the input parameters to the service provider. It expects the complete bill details from the provider. However, the customer has one billing application that has information about wireless services only, another that has information about broadband only, and a third system that has information about land line-related services.
Data aggregation of the ABM
The ABCS for the Get Bill Details EBS must retrieve details from multiple billing applications. It is responsible for interacting with each of these applications using the services provided by them. This ABCS is also responsible for consolidating them into a single response. After retrieving all of the content, the ABCS combines the three ABMs and produces a single EBM.
A request - delayed response pattern is asynchronous in nature. In this situation, the requester sends the request message and sets up a callback for a response. The requester does not wait for the response after sending the request message. A separate thread listens for the response message. When the response message arrives, the response thread invokes the appropriate callback, and processes the response. The EBS would have a pair of operations-one for sending the request and another for receiving the response. Both the operations are independent and atomic. A correlation mechanism is used to establish 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 waiting for the asynchronous response. If an error occurs in the providing service, the response is sent with fault information populated. In the Customer EBS WSDL, the one-way operation meant for request is defined in the portType having all the operations, which are either Request - Response or Request only. The one-way operation meant for response is defined in the portType having all the operations, which are for Response.
Multiple integration scenarios exist in which participating applications publish events and messages that are subscribed to by multiple participating applications. This pattern is transactional in the sense that changes are made to the 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.