Oracle® Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack 11g Release 1 (11.1.1.5.0) E17364-03 |
|
![]() Previous |
![]() Next |
This chapter describes how to make architectural decisions about Application Business Connector Services (ABCS) for your Oracle Application Integration Architecture (AIA) integrations.
This chapter includes the following sections:
The role of the ABCS is to expose the business functions provided by the participating application in a representation that is agreeable to Enterprise Business Services (EBSs). It can also play another role in which it serves as a glue to allow the participating application to invoke the EBSs. Figure 11-1 illustrates a scenario in which the E-Business Suite application is using an ABCS to invoke an EBS. In this scenario, the ABCS is playing a requester role. The same diagram also illustrates how the EBS invokes one of three ABCS to perform a specific task. Here, the three ABCS are playing provider roles.
The ABCS enables participating applications to become service providers as well as service consumers. It also enables applications having nonstandard connectivity to expose their functionality as web services.
For more information about ABCS, see "Understanding Application Business Connector Services" in the Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack..
The two types of ABCSs are:
The requester ABCS is provided by the requesting application to interface with an EBS for performing a single business task. The service interfaces between Requesting/Source application and EBS. The role of the requester ABCS is to enable the participating application to invoke the EBS either to access data or to perform a transactional task.
The requester ABCS is a service provided by the requesting application to invoke the EBS. It receives the Application Business Message (ABM) as payload and optionally returns the ABM as the response.
The ABM can be enriched by having additional conversations with the requester application. The ABM is transformed into an Enterprise Business Message (EBM) using XSL. Responses received from the EBS (EBM) are transformed into the ABM.
Non-SOAP payloads are handled by having transport adapters in between requester application and requester ABCS. Requester applications must pass system information for the ABCS to have subsequent conversations.
The provider ABCS is supplied by the provider application to interface with an EBS for performing a single business task. The service interfaces between the EBS and provider or target application.
The provider ABCS:
Is a service supplied by the provider application to interface with the provider application
Receives EBM as payload
Optionally returns the EBM as the response
The EBM is transformed into an ABM using XSL. The ABM can be enriched by having additional conversations with the provider application. Responses received from the application (ABM) are transformed into the EBM.
Non-SOAP connectivity with the provider application is handled by having transport adapters in between the provider ABCS and the provider application.
For more information about ABCS, see "Understanding Application Business Connector Services" in the Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack..
An ABCS architect or developer must perform the following tasks as part of the design activity:
Understand the ABCS role
Identify the business events triggering the invocation of ABCS
Identify the interactions between application and the ABCS and vice versa
Identify the appropriate technologies to be used to facilitate the interaction
Define the ABCS contract
The following sections discuss these tasks:
The ABCS contract (WSDL) specifies how a caller interacts with its Business Connector Service. The caller could either be a participating application or another service such as EBS.
Figure 11-2 illustrates the decision flow for defining the contract (WSDL) for the ABCS.
This section discusses design decisions that you must make to enable the ABCS to participate in either a requester or provider role.
To determine how to enable the ABCS to participate in a requester role:
Determine how the ABCS is invoked or triggered. This analysis tells you how the ABCS is invoked by the application. Determine:
Whether the application can make a SOAP-based invocation of ABCS.
Whether the application service can invoke the ABCS using JCA adapter.
Whether the ABCS must subscribe to messages published by the application due to occurrence of business events.
Determine what interaction pattern is needed.
The following questions will help the architect in identifying the optimal message exchange pattern.
What business events will cause the invocation of requester ABCS?
Is the application expecting a response from the requester ABCS?
Does the application need to wait until the response is received for performing the next task?
Does the application need to wait until the request is fully processed by the provider application?
For more information about choosing a MEP, see Section 11.3.2, "Choosing the Appropriate MEP."
Determine what Enterprise Business Services or operations need to be invoked.
Does the message sent by the requester application have all the information necessary for requester ABCS to construct the EBM?
If not, does it have to reach out to applications to get the additional information?
If yes, what technologies are available? What application interfaces are to be used to get the additional information?
For more information, see Section 11.4, "Technology Options".
Can the application possibly publish a message with incomplete information?
Should the ABCS wait until the message with complete information is published?
In such a scenario, an aggregator should collect and store individual messages until a complete set of related messages has been received
If yes, what is the application service and how does it communicate with it?
To determine how to enable the ABCS to participate in a provider role:
Decide whether the application can directly consume the information sent by EBS.
Determine how the ABCS interacts with provider applications.
Define the tasks that must be done by this ABCS.
Determine what message exchange pattern (MEP) is used to communicate with the application.
Determine whether data validation must be done on the EBM sent by the EBS prior to sending the request to the provider application.
Decide whether you need guaranteed delivery of messages.
Determine whether it is a single message containing data for multiple instances.
Decide whether the entire message should be processed as a single unit of work.
Decide what must be done when a subset of instances present in that message encounter failure.
The ABM schemas are created by the participating applications. Consider the following points when defining the ABMs:
Construct messages that are durable and long-lasting because frequent changing of the ABM definition puts duress on ABCS development.
Ensure reusability of business components across multiple ABMs to promote reusability of transformation maps.
Design ABMs to pass the following system data:
System Instance - connection information that helps identify the system ID registered in the system registry
Locale - language code in which the request is sent
Sender information - contextual details pertaining to the origination of the message
Design ABMs that are extensible
To analyze the participating application integration capabilities:
After identifying the participating applications, you must analyze the integration capabilities of each participating application and how each application exposes its data.
Work with the application providers (developers) to decide the best way to interact with the application to attain the needed functionality.
The interactions can be inbound or outbound. The interaction mechanism can be one of these:
Web Service using SOAP/HTTP
Events/Queues
JCA Adapter
Database Adapter
For more information about various types of connectivity to different resources, see Chapter 21, "Establishing Resource Connectivity."
Obtain relevant details from the applications in situations in which the interactions between the participating applications and the ABCS happen through a message queue adapter, database adapter, or JCA adapter.
These details are used in configuring the adapters. The configuration results in the WSDL creation. Care must be taken to ensure that the environment-specific details are configured in relevant resource files on the server and not directly in the WSDLs.
Identify the available functionality within the participating applications as well as the mapping between EBMs and application business objects (map operations).
A one-to-one, one-to-many, or many-to-one mapping between the two may exist.
Tabulate the mapping between the Enterprise Business Object (EBO) attributes/elements and the application objects attributes/elements in a spreadsheet.
Remember these points when creating the transformation maps:
For an ABM being mapped to an EBM, ensure that an attempt is made to populate all of the data elements present in the ABM to the relevant elements in the EBM.
In situations in which the ABM does not have all of the content to supply all of the data elements in the EBM, you must work with the respective requester application teams to identify the application services that could be used to enter the content in the EBM.
For example, a Siebel application invoking the CreateOrder ABCs might supply only the Siebel Customer ID in the ABM that is being passed as the payload. However, the EBM to be passed as a payload to the CreateOrder EBS operation expects all the information regarding the Customer. So the CreateOrder ABCS is responsible for invoking a Siebel service to retrieve complete Customer details from the Siebel application and populate the EBM. Although the integration platform provides support for this pattern, we highly recommend that you work with the participating application to ensure that the payload being passed to the ABCS is as close to the shape of the EBM as possible to minimize the chattiness.
The possible interaction types between an ABCS and its client are:
Synchronous request-response
Asynchronous request only
Asynchronous request-delayed response
MEPs vary in functionality and usage depending on the role of the ABCS.
For more information about MEPs, see "Understanding Interaction Patterns" in the Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.
Synchronous Request-Response Pattern
A requester sends a request to a provider, who processes the request and sends back a response.
The requester is in a suspended mode until the response is received from the provider.
Results are in real-time response or error feedback.
The message exchange is one-way, with a requester sending a request to a provider. No response comes from provider to requester.
The requester is free, after request submission, to resume normal execution.
Asynchronous Request - Delayed Response
This involves two one-way invocations.
First, a one-way message is sent from requester to provider. At a later time, another one-way message is returned from the provider to the original requester.
Two distinct one-way messages are correlated.
For more information about MEPs, see "Understanding Interaction Patterns" in the Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.
Identify how the participating applications interact with the ABCS for inbound as well as outbound interactions.
Identify whether the requester application must be in a call-waiting state until it has received the response from the provider application.
Waiting until the response is received from the provider application forces the requester application to invoke the ABCS in a synchronous manner. For example, a CRM application submitting a request to retrieve account details from a billing application would fit this scenario. In this case, the requester cannot perform any task until the response is received.
On the other hand, sending a request from the CRM application to create a customer in a billing application can be done in an asynchronous manner. After publishing an outbound request, the CRM application can move to the next activity without having to wait until the provider application has successfully created a customer. In this case, the CRM application invokes this outbound request in an asynchronous manner.
Applications can leverage different kinds of integration technologies for synchronous versus asynchronous invocations. You must select the most appropriate technology based on the situation.
For more information about how AIA services interact with applications, see Chapter 21, "Establishing Resource Connectivity."
In a single flow, even though the requester ABCS MEP is influenced by the MEP for the EBS operation to be invoked, the requester application's interaction capabilities influence the MEP for requester ABCS. For provider ABCS, the MEP is predominantly influenced by the MEP of the EBS operation.
Most of the cases involving Query and Validate need this pattern because the participating application that initiated the request is waiting for the response. For all the other cases, the suitability of this pattern is determined by the demands of the response time and possibility of meeting those requirements based on the amount of processing to be done.
The MEP between requester ABCS and EBS is synchronous. The MEP between provider ABCS and participating application servicing the request can be either synchronous or asynchronous.
For more information about Query, see Section 12.8.7, "Query".
For more information about Validate, see Section 12.8.5, "Validate".
Use Case
CRM Application requesting account details about a customer from the billing system
Figure 11-3 illustrates the two-way communication between AIA services, requester ABCS, and CustomerPartyEBS.
Use this pattern when:
The requester ABCS receives the request message from the participating application and ends with invoking of the EBS. In this case, no response comes from the EBS to the requester ABCS and no response is made to the participating application that initiated the request.
The provider ABCS receives the request message from the EBS and ends with invoking the provider participating application API. No response is made to the EBS that initiated the request.
Use Case
A CRM application submitting a request to the BRM application to create CustomerParty
From the perspective of the participating application, Siebel, a request message to the BRM application to create a CustomerParty is enqueued for processing at a later time. The Siebel application is free to resume its processing immediately. The request message is dequeued from the queue and is processed in an asynchronous fashion.
Figure 11-4 illustrates the one-way invocation between AIA services, Requester ABCS, and CustomerPartyEBS.
Use this pattern when:
The requester ABCS receives the request message, processes the message, and finally updates the participating application that initiated the request by invoking an API exposed by the participating application. The participating application is not waiting for the response.
The provider ABCS receives the request message from the EBS Request mediator service, processes the message, and finally responds to the requesting service-requester ABCS or Enterprise Business Flow (EBF)-by invoking the response operation of the EBS Response mediator service. The EBS Mediator service is not waiting for the response.
The MEP between requester ABCS and EBS can be synchronous or asynchronous, and between the provider ABCS and the provider participating application can also be synchronous or asynchronous.
This section discusses technology options for:
Outbound Interaction with the Application
For inbound interactions see Section 12.9, "Invoking the ABCS".
For more information about resource connectivity, see Chapter 21, "Establishing Resource Connectivity."
Communication between ABCSs and the application is governed by the application capabilities.
Communication technologies include:
JCA Adapters
Standard web service interfaces
Adapters
JMS queues
JCA Adapters, when available and authorized for use, should be the first choice for developers to connect to applications.
JCA Adapters:
Natively invoke participating applications in a co-located fashion.
Standardize the programming interface.
Standardize the quality of services (QoS) implementation.
Provide support for tasks associated with connection management, transaction management, and scalability in combination with the run-time environment.
For more information about establishing outbound connectivity, see Chapter 21, "Establishing Resource Connectivity."
This is the most common means of communicating with participating applications.
Most applications expose functionality in the form of a web service. The most common transport used is SOAP over HTTP, however some applications may expose direct XML over HTTP.
In situations in which the message submission is decoupled from the processing of the message, usage of queues is suggested. When JMS queues are used, they must be accessed using JMS Adapter. The message is enqueued to the JMS queue by the ABCS and the application would dequeue the message.
Tip: AIA highly recommends that participating applications making an outbound interaction in an asynchronous mode use message queues to publish the requests. AIA recommends this approach because it allows for high scalability as well as a better end-user experience. Similarly, the ABCS making an outbound interaction to the applications must assess the tasks to be performed by the application. Use of message queues to communicate with the applications in situations in which applications need longer periods to perform the tasks. |
Participating applications making an outbound interaction in a synchronous mode alone should send the requests using SOAP/HTTP.
For more information about JMS Adapters, see Oracle Fusion Middleware Configuring and Managing JMS for Oracle WebLogic Server.
AIA recommends using a BPEL component to build an ABCS composite.
BPEL is the most effective solution when:
You have a long-lived process
In scenarios in which you have a long-lived process that may take hours or even days, BPEL is the best technology choice. In this case, BPEL persists (dehydrates) the process at certain hook points and then bring the process to life when needed.
You need complex orchestration capabilities
In scenarios that require complex orchestration, parallel processing, and multiple conversations with participating applications, as well as with integrated services such as BPA, BAM, Workflow, and Rules Engine, BPEL is the most effective solution.
You have content augmentation and validation that cannot be done using XSLT
In cases in which the decision-making and validation is not simple enough to perform using XSLT, other means are needed such as the standard BPEL procedural constructs or even calling out to the Rules Engine. BPEL enables you to easily perform fairly complicated decision trees and route the results to different partners.
You need aggregation or disaggregation
In scenarios in which the ABCS must make multiple calls to the application to process a message or to collect data and then consolidate it in one message, BPEL is the suitable technology. BPEL constructs enable you to split or consolidate payloads and aggregate or disaggregate calls. The BPEL process is also responsible for maintaining the state and handling transactions in between invocations.
You must augment the participating application functionality.
For more information, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.