Building AIA Integration Flows 20-19
20.3.1 Integration Through Native Application Interfaces Using the Oracle Applications Technology Infrastructure
In this style, messages flow from the requester application to the providing application. The mode of connectivity could be SOAPHTTP, queues, topics, or native
adapters.
No middleware is involved in this integration. The requester application must establish the connectivity with the provider
applications. The requester application is responsible for sending the request in the format mandated by providers API as well as interpreting the response sent by the
provider. Requester and provider applications are responsible for the authentication and authorization of requests.
The integration flow consists of individual application functions interacting directly. All capabilities required to make this interaction possible must be available or made
available in the individual applications.
Figure 20–2 illustrates how a requester application interacts directly with a provider
application.
Figure 20–2 Example of a Requester Application Interacting Directly with a Provider Application
In more complex situations, when the integration flow consists of multiple steps involving interactions with multiple applications, you must leverage the
workflow-like capability in one or more applications.
No AIA artifacts are built in this case. You must establish direct connectivity between applications.
For more information about different modes of connectivity, see Chapter 21,
Establishing Resource Connectivity.
20.3.2 Understanding Integration Styles with Integration Framework
In all the integration styles with integration framework, middleware technologies are leveraged. The applications push the messages to the middleware, and the
middleware pushes the messages to the target applications.
These integration styles have integration framework:
■
Integration flow leveraging provider services
20-20 Developers Guide for Oracle Application Integration Architecture Foundation Pack
■
Integration flow leveraging provider services with canonical model-based virtualization
The AIA service artifacts needed for implementing an integration flow in any of the integration styles with integration framework depends on:
■
Complexity of data exchange
– No processing logic
– With processing logic
■
Message exchange pattern
– Synchronous request-response
– Asynchronous one-way fire-and-forget - Need for guaranteed delivery
assumed
– Asynchronous request-delayed response - Need for guaranteed delivery and
correlation of response assumed These AIA service artifacts are defined in AIA Architecture:
■
CBPs
■
EBSs
■
EBFs
■
ABCSs
■
Adapter Services
– JMS Producer and JMS Consumer
– JCA Adapter Service
For more information about different message exchange patterns, see Chapter 10,
Designing and Developing Enterprise Business Services and
Chapter 25, Working with AIA Design Patterns.
For more information about different AIA service artifacts and Oracle SOA Suite components used to implement them, see the Oracle Fusion Middleware Concepts and
Technologies Guide for Oracle Application Integration Architecture Foundation Pack.
20.3.2.1 Integration Flow with Requester Application Services
The requester application invokes a single AIA service on the middleware. The request presented by the requester application is fulfilled by the AIA service by invoking
suitable APIs in the provider applications. The AIA service can accept a message in the requester application format. The AIA service presents the request to the provider
applications in the format mandated by the providers API. The AIA service accepts the response in the provider application format, if needed. The AIA service is
responsible for the authentication and authorization of the requests.
The integration flow consists of this single AIA service artifact deployed on the middleware managing all interactions with all participating applications.
Figure 20–3 illustrates how a service deployed on the middleware enables integration
between the requester and the provider application.
Note: In the following sections, for each integration style with
integration framework, the AIA artifacts to be developed are recommended for a combination of situations.
Building AIA Integration Flows 20-21
Figure 20–3 Example of Integration Flow with Native Application Services
For more complex situations in which the integration flow consists of multiple steps involving interactions with multiple applications, the AIA service implements a
workflow-like capability and manages all interactions with all the participating applications.
The AIA service artifacts to be developed depend on the complexity of data exchange and various message exchange patterns.
Table 20–1 lists suitable AIA artifacts for a combination of situations.
20.3.2.2 Direct Integration Through Application Web Services
A provider application-specific AIA service, exposing a coarse-grained functionality of the provider application leveraging one or more APIs, is created with a suitable
provider application-specific interface. Several business initiators can invoke this AIA service. If the business initiators cannot present the request in the format understood
by the provider application-specific AIA service, a requester application-specific AIA
Table 20–1 AIA Artifacts for Integration Flows with Requester Application Services
Message Pattern No Processing Logic
With Processing Logic
Synchronous Request Response
EBS CBP
Asynchronous One-Way EBS
CBP Asynchronous
Request-Delayed Response EBS - Request
EBS - Response CBP
20-22 Developers Guide for Oracle Application Integration Architecture Foundation Pack
service is used to transform the business initiator request to the provider application format. The requester application-specific AIA service is responsible for authenticating
and authorizing the requests. The provider application-specific AIA service propagates the authentication and authorization information of the requests to the
provider application.
The integration flow would consist of a requester application-specific AIA service artifact deployed on the middleware managing all interactions with all provider
application-specific AIA services.
Figure 20–4 illustrates how a service deployed on the middleware enables the
integration between the requester and the provider application.
Figure 20–4 Example of Integration Flow Leveraging Provider Services
For more complex situations in which the integration flow involves interactions with multiple applications, the requester application-specific AIA service implements a
workflow-like capability and manages all interactions with all the provider application-specific AIA services.
The AIA service artifacts to be developed depend on the complexity of data exchange and various message exchange patterns.
Table 20–2 lists suitable AIA artifacts for a combination of situations.
20.3.2.3 Integration Through Packaged Canonical and Standardized Interfaces
Loose coupling through a canonical application-independent model is a sign of a true SOA. Participating applications in loosely coupled integrations communicate through
Table 20–2 AIA Artifacts for Leveraging Provider Services
Message Pattern No Processing Logic
With Processing Logic
Synchronous Request Response
Requester ABCS Provider ABCS
Requester ABCS Provider ABCS
Asynchronous One-Way Requester ABCS
Provider ABCS Requester ABCS
Provider ABCS Asynchronous
Request-Delayed Response Requester ABCS
Provider ABCS Requester ABCS
Provider ABCS
Building AIA Integration Flows 20-23
a virtualization layer. Instead of direct mappings between data models, transformations are used to map to the canonical data model. While this allows for
greater reusability, the transformations both increase the message size and consume more computing resources. For functional integrations, this integration pattern is ideal
since the reusability gained is worth the slight overhead cost.
In this case, an EBS based on the Enterprise Business Objects EBOs and Enterprise Business Messages EBMs is created as a mediator service.
A provider service, exposing a coarse-grained functionality of the provider application leveraging one or more APIs, is created with the same EBM interface as the EBS
operation interface.
If the business initiators cannot present the request in the format understood by the EBS operation interface, a requester service is used to transform the business initiator
request into the provider service format.
Figure 20–5 illustrates how the request sent by the source application is processed by
the target application with the help of the EBS and a set of intermediary services. Note that the request and provider transport services are optional and are needed only in
case of non-SOAP-based transports.
Figure 20–5 Example Showing Canonical Model-based Virtualization
For more complex situations in which the integration flow involves interactions with multiple applications, the requester application-specific AIA service presents its
request to the mediator AIA service. The mediator AIA service triggers an AIA service, which implements a workflow-like capability and manages all interactions with all the
provider application-specific AIA services through mediator AIA services. In this case, the mediator AIA service interface chosen is assumed to be accepted as the common
interface. Thus, all requester application-specific AIA services invoke this mediator AIA service, and all the provider application-specific AIA services implement this
common interface. The AIA service artifacts to be developed depend on the complexity of data exchange and various message exchange patterns.
Table 20–3 lists suitable AIA artifacts for a combination of situations.
Table 20–3 AIA Artifacts for Integration Flows with Multiple Application Interactions
Message Pattern No Processing Logic
With Processing Logic
Synchronous Request Response
Requester ABCS EBS
Provider ABCS Requester ABCS
EBS Provider ABCS
Asynchronous One-Way Requester ABCS
EBS Provider ABCS
CBP Requester ABCS
EBS EBF
Provider ABCS
20-24 Developers Guide for Oracle Application Integration Architecture Foundation Pack
20.3.3 Bulk Data Processing
