1 Understanding the Oracle AIA Reference Architecture
This chapter introduces Oracle Application Integration Architecture (AIA) and integrations.
This chapter includes the following sections:
1.1 Introduction to Oracle Application Integration Architecture
Oracle Application Integration Architecture (AIA) is a complete integration solution for orchestrating agile, user-centric, business processes across enterprise applications. AIA offers prebuilt solutions at the data, process, and user interface levels delivering a complete process solution to business end users. All of the AIA components are designed to work together in a mix-and-match fashion. They are built for configurability, ultimately helping to lower IT costs and the burden of building, extending, and maintaining integrations.
Powered by Oracle Fusion Middleware, AIA enables organizations to use the applications of their choice and create Composite Business Processes (CBPs) following these guiding principles that define the ground rules for development, maintenance, and usage of a service-oriented architecture (SOA):
-
Reuse, granularity, modularity, compose ability, componentization, and interoperability.
-
Standards-compliance (both common and industry-specific).
-
Service identification and categorization, provisioning and delivery, and monitoring and tracking.
1.2 AIA Features
AIA Foundation Packs provide the methodology and framework along with the content that is critical for customers to figure out their integration problems.
Figure 1-1 illustrates the main AIA features and the underlying technology.
Table 1-1 lists the main features of AIA and how these features are delivered.
Table 1-1 AIA Features and Related Deliverables
| Features | Deliverables |
|---|---|
|
A robust architectural framework for engineering service-oriented business processes. |
|
|
Support for interaction styles to handle high transaction rates and volumes that are associated with mission-critical applications. |
Reference Architecture for different integration styles with and without canonical abstractions. |
|
Ability to leverage functionality provided by various Oracle and customer-owned software assets. |
Programming Models for constructing and assembling different types of AIA service artifacts that leverage various Oracle tools. |
|
Ability for customers to extend various AIA artifacts delivered as part of PIPs. |
Programming Models for extending various AIA service artifacts. |
|
Support for process model decomposition and analysis, service design, service construction, process definition, deployment plan generation, deployment, and upgrade. |
Project Lifecycle Workbench and Deployment Plan Generator |
|
Governance of design-time and run-time AIA artifacts. |
Oracle Enterprise Repository |
1.3 Understanding Integrations
This section includes the following topics:
1.3.1 The Integration Flow Concept
An integration flow represents the journey of a message from a business event-triggering source, through possible intermediary milestones, to one or more target milestones as shown in Figure 1-2. At each milestone, the message is stored in a different state.
An integration flow represents the run-time path of a message. It is not a design-time artifact.
There is no "one size, fits all" approach to integration. The selection of integration styles and supporting design patterns is driven by the specific requirements to meet the objectives of the integration. AIA supports a variety of integration styles and patterns to enable the flight of a message in an integration flow. The AIA artifacts that are required for the collaboration between applications or functions are dependent on the integration style adopted for an integration flow.
1.3.2 Integration Styles
The following sections provide details about each of these integration styles:
-
Data-centric integration
-
Integration through native interfaces
-
Integration through Web services
-
Reference data query
-
Process-centric integration
Figure 1-3 illustrates the flow of each integration style.
1.3.3 Data-Centric Integrations
Data-centric integrations transform data from its source format into its target format, and provide some level of logic in the transformation process to make it useful and coherent to the target environment.
Typical requirements driving data-centric integrations include bulk data replication where no individual message based processing is required or where multiple data enrichment activities are not required to populate the target system.
- Example 1 Initial Data Synchronization
-
An example of a data-centric integration is the initial data synchronization between applications where one application has been up and running for some time and contains meaningful, but non-volatile data that should be seeded within a new application that is being installed. This typically makes on-going integration efforts using one or more of the styles described below much simpler to achieve.
- Example 2 Bulk Upload of Recurring Transactions
-
Another example is a bulk upload of recurring transactions like sales orders which must be tallied for commission payments to the appropriate sales people. The commission payments are made either quarterly or monthly and while sales activities are going on every day, there is no need to have this information available in real time.
1.3.3.1 What Oracle Provides
Oracle provides two data-centric integration tools: Oracle Golden Gate and Oracle Data Integrator.
Oracle Golden Gate utilizes the change data capture logs of the databases and can work across a heterogeneous database landscape, while Oracle Data Integrator works directly against the database tables and utilizes an extract, load and transform approach to its handling of the data.
Oracle delivers a number of pre-built data-centric integrations such as Siebel CRM to Oracle Incentive Compensation to handle the sales order and commission payments use case described above and Communications Revenue Management: Billing and Revenue Management to E-Business Suite which calls for an automated scheduler to publish general ledger reports from Oracle Communications Billing and Revenue Management to Oracle E-Business Suite Financials. It provides capabilities for general ledger reports, such as incremental and cumulative revenue reporting, automated report regeneration, and the ability to customize reports.
1.3.4 Integration Through Native Interfaces
Every application executes on top of its own technology stack. Based on the application architecture there may be one or more supported ways to integrate with the application. For example, Oracle E-Business Suite exposes public Java interfaces and PL/SQL APIs, business events and batch interfaces to allow a wide range of integration options for customers and partners.
Typical requirements driving data-centric integrations include a simple exchange of business-oriented messages or consuming more sophisticated application capabilities exposed through these interface mechanisms. One example of the use of native interfaces is providing enterprise data through multiple channels such as web and voice where the application itself has no such capability to do so and the speed of delivery of this information is critical due to a high degree of human interaction.
1.3.4.1 What Oracle Provides
From a technology foundation perspective, each application exposes one or more mechanisms for integration based on its native technology stack. Some applications provide extended tooling to assist with the exposure and configuration, customization, and extension of the interface mechanisms.
Through the Oracle Validated Integration program a number of pre-built integrations created by our partners exist which take advantage of our applications' native interfaces. For example, one of our partners integrates with Siebel CRM to provide multi-channel access to contact center information. This improves customer satisfaction with their interactions to the call center by allowing the customer to choose their method of interaction (phone, chat, email, fax, letter, and so forth.) and get a consistent experience regardless of the medium.
1.3.5 Integration Through Web Services
XML-based Web services are a technology platform independent way of exposing application interfaces. Using XML as the common language, business transactions are sent from one application to another in near real time. Web services are exposed using industry standards such as WSDL and SOAP (or in a REST-ful manner), shielding the implementation and connectivity details of the provider application from the consumer. The primary requirement which leads to the use of Web services is similar to that of native integrations which involves the exchange of business messages. The key difference is the need to integrate applications across a wide variety of potentially incompatible technology platforms including integration with third-parties (for example business-to-business scenarios or the use of Software-as-a-Service) eliminates the use of the native interfaces as an option.
1.3.5.1 What Oracle Provides
Oracle Fusion Middleware including SOA Suite and Adapters (bridging from an application's native interfaces to the world of Web services) allows for the consumption, composition and integration of applications using Web services. The inclusion of Fusion Middleware to support Web service-based integration enables an expanded set of Quality of Service characteristics like resiliency, scalability, guaranteed delivery, and security.
Through the Oracle Validated Integration program a number of pre-built integrations created by our partners exist which take advantage of our applications' Web service-based interfaces. One partner has leveraged PeopleSoft's Web services interfaces along with Oracle Fusion Middleware to exchange standard HR-XML schemas. As a result, ordering a background check on an applicant is a matter of just a few clicks, and once a report is complete, the detailed search results can be viewed immediately-from within the PeopleSoft Enterprise interface.
1.3.6 Reference Data Query
Reference data query addresses supplemental information that is important to completing and or facilitating business transactions, but is not in and of itself part of the primary integration activity. Web services have further fueled the availability of reference data from third-party providers and there are many examples of companies which offer reference data services on a subscription basis.
Typical use cases include geocode or tax code lookups, evaluating availability to promise (ATP) for inventory/manufactured goods, or something as a simple as retrieving an account balance.
1.3.6.1 What Oracle Provides
Oracle Fusion Middleware, including SOA Suite and Adapters (bridging from an application's native interfaces to the world of Web services) allows for the consumption, composition and integration of applications using Web services. The inclusion of Fusion Middleware to support Web service-based integration enables an expanded set of Quality of Service characteristics like resiliency, scalability, guaranteed delivery, and security.
Through the Oracle Validated Integration program a number of pre-built integrations created by our partners exist which take advantage of our applications' Web service-based interfaces for reference data query. One of our partners provides a pre-built integration with Oracle E-Business Suite for tax jurisdiction lookup and tax calculation. The partner's solution includes a SOAP service, deployed at the customer site, which then invokes their Software-as-a-Service system for geocode lookup and tax calculation. The interface leverages the tax partner subscription method of Oracle E-Business Tax for third-party tax vendor integration.
1.3.7 Process-Centric Integration
While many applications expose Web service interfaces, there is a growing need for a more coordinated exchange of messages between applications. This orchestrated exchange of messages is typically intended to support one or more business processes. As a part of the orchestration of messages, additional activities may take place such as message transformation, enrichment or validation.
For example the process-centric integration style is seen in the orchestration of transactional data from the point of capture through transformation and movement to back-office systems. The process-centric integration style can also be used to drive the movement of transactional data through a process based on a business event.
1.3.7.1 What Oracle Provides
From a technology foundation perspective, Oracle provides support for the definition and orchestration of business processes through the SOA Suite and BPM Suite offerings. In addition to the expanded set of QoS capabilities, tools to visualize and define the orchestration itself are provided.
From a pre-built integration content perspective, Oracle delivers a number of process-centric integrations such as Oracle CRM On Demand to Oracle E-Business Suite which orchestrates the conversion of an opportunity into a Quote or Order. In addition, the pre-built Oracle CRM On Demand to Siebel CRM integration orchestrates the bi-directional and consolidation of Account, Contact, Opportunity, and Product information between an organization's Siebel on-premise solution and their Oracle CRM On Demand instances in real time.
1.3.8 What Integration Pattern Should be Used: Direct Transformation Of The Data Objects or a Canonical Data Model And EBOs?
Usage of canonical Enterprise Business Objects (EBOs) is an integration best practice, especially in integrations that involve connectivity with multiple source and destination systems. However, usage of a canonical data model does introduce some overhead and might introduce unnecessary engineering work.
Figure 1-4 illustrates an approach for deciding between a direct point-to-point transformation or canonical data model and EBOs.
1.4 AIA and Integration Styles
This section includes the following topics:
1.4.1 Pre-built Integration Accelerators
Oracle AIA delivers pre-built Integration Accelerators in three formats:
-
Direct integrations typically use one or more styles of integration, but do NOT use the canonical pattern.
-
Process Integration Pack (PIP)
PIPs typically use one or more styles of integration and DO use the canonical pattern.
-
Partial Process Integration Pack (PIP)
Partial PIPs deliver one spoke of a canonical-based integration.
1.4.2 Integration Through Native Application Interfaces Using the Oracle Applications Technology Infrastructure
In this style, messages flow from the requester application to the provider application. The mode of connectivity could be SOAP/HTTP, queues, topics, or native adapters. No middleware is involved in this integration.
The requester application must establish the connectivity with the provider applications. It is the responsibility of the requester application to send the request in the format mandated by provider's API, and to interpret the response sent by the provider. In addition, the 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 in the individual applications.
Figure 1-5 illustrates how a requester application interacts directly with the provider application.
In the case of more complex situations in which the integration flow consists of multiple steps involving interactions with multiple applications, it is imperative that workflow-like capability be leveraged in one or more applications.
There are no AIA artifacts to be built in this case. Direct connectivity must be established between applications.
1.4.3 Direct Integration Through Application Web Services Using Oracle SOA Suite
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 service is used to transform the business initiator request into the provider-application format.
The requester application-specific AIA service is responsible for the authentication and authorization of the requests. The provider application-specific AIA service propagates the authentication and authorization information of the requests to the provider application.
The integration flow consists of a requester application-specific AIA service artifact deployed on the middleware that manages interactions with all provider application-specific AIA services.
Figure 1-6 illustrates how a service deployed on the middleware enables the integration between the requester and the provider applications.
In the case of 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 interactions with all provider application-specific AIA services.
The AIA service artifacts that must be developed are determined by the complexity of the data exchange and the various message exchange patterns that are involved.
1.4.4 Integration Through Packaged Canonical and Standardized Interfaces Using Oracle Foundation Pack
Loose-coupling through a canonical (application-independent) model is one design pattern that can be implemented in the context of SOA to simplify the integration when there are either many instances of the same or similar participating applications. Participating applications in loosely coupled integrations communicate through 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 integrations, at the business logic tier, this is the ideal integration pattern because the reusability gained is worth the increased overhead cost. But, most importantly, the impact of changes on the overall integration based on the introduction of changes to one of the participating applications is isolated. This effectively brings the cost of maintaining these more complex integration scenarios in line with the costs of a single point-to-point integration.
In this case, an Enterprise Business Service (EBS) based on relevant 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 to the provider service format.
Figure 1-7 illustrates how the request sent by the source application is processed by target application with the help of the EBS and a set of intermediary services. Note that the request and provider transport services are optional. They are needed only for non-SOAP-based transports.
In the case of 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 that implements a workflow-like capability and manages all interactions with the provider application-specific AIA services through mediator AIA services.
In this case, it is assumed that the mediator AIA service interface chosen is accepted as a common interface. Thus, all requester application-specific AIA services invoke this mediator AIA service and all provider application-specific AIA services implement this common interface. The AIA service artifacts that must be developed are determined by the complexity of the data exchange and the various message exchange patterns that are involved.
1.4.5 Bulk Data Integration with an Extract, Transform, and Load Approach Using Oracle Data Integration Suite
Bulk data processing involves a large batch of discrete records or records with very large data sets. The methodology used for this integration is a point-to-point integration specializing in the movement of data with high performance and a reusability trade-off.
1.4.5.1 Integrations for High-Volume Transactions without an Xref Table
For use cases in which storing cross-reference (Xref) data for high-volume transactions does not make sense, AIA recommends using a point-to-point integration using Oracle Data Integrator.
An example of such a use case is a retail store chain headquarters that receives business transaction data from individual retail stores at the end of each day after each store closes. Depending on the time zone where each store is located, they start sending their day's worth of business transactions to headquarters. In this scenario, there is no need to store Xref data between each individual local store and headquarters because there is no data manipulation language (DML) operations on such data sets.
Figure 1-8 illustrates a high-volume transaction integration without the use of an XRef table.
The steps to load data are the same as those for using an Oracle Data Integrator package. There is no AIA component in this architecture. Local Enterprise Resource Planning (ERP) applications load their interface table and invoke an Oracle Data Integrator package to send data to the headquarters interface table. Once the data is processed, the Oracle Data Integrator updates the local ERP application's interface table with a status of Transferred or Processed for each row.
For more information about bulk data integration, see "Using Oracle Data Integrator for Bulk Processing" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
1.5 AIA Reference Process Models
AIA Reference Process Models are collections of best practices from various Oracle application portfolios. These models are delivered by AIA as Oracle Business Process Analyzer content.
Reference Process Models serve the following purposes:
-
Help categorize Business Processes into Business Activities and Business Tasks
-
Build a repository of reusable Business Activities and Business Tasks
-
Establish key performance indicators
-
Aid in identifying equivalent AIA service artifacts described as part of the AIA service inventory
For more information about Reference Process Models, see the Oracle Fusion Middleware Reference Process Models User's Guide for Oracle Application Integration Architecture Foundation Pack.
Figure 1-9 illustrates the relationship of business processes, activities and tasks that is detailed in the following sections.
1.5.1 What is a Business Process?
A set of activities and tasks accomplished in a particular business area are treated as a business process. Examples include Sales Management, Inventory Management, and so on. In themselves, they do not deliver business value. Business value is realized when business processes from different business areas are coordinated.
1.5.2 What is a Business Activity?
A Business Activity is a coordinated set of Business Tasks. A Business Activity can be considered to be equivalent to a subprocess. Examples include Process Payment, Ship Goods, and so on. Business activity functionality is provided by one application or a combination of applications.
1.5.3 What is a Business Task?
A Business Task is an elementary activity or atomic process capable of handling a unit of work. It cannot be split further without a loss of business meaning. It can be implemented by one or more providers. Examples include Create Customer, Query Payment, and so on.
1.5.4 What is a Composite Business Flow?
A Composite Business Flow is a set of coordinated tasks and activities, involving both human and system interactions across one or more business areas that leads to accomplishing a set of specific organizational goals. Characteristics of Composite Business Flows include the following:
-
Large, complex, and long running
-
Widely distributed and customized
-
Dynamic
-
Automated
-
Both business-oriented and technical in nature
-
Cross boundaries within and between businesses
-
Dependent on and supportive of human intelligence and judgment
-
Difficult to recognize
1.6 The Conceptual View of AIA
This section includes the following topics:
1.6.1 What is a Service Consumer?
A Service Consumer is the initiator of a business process, business activity, or business task in an enterprise. It has knowledge of the available AIA Conceptual Services and can present requests accordingly.
1.6.2 What are AIA Conceptual Services?
AIA Conceptual Services are developed using Oracle Fusion Middleware technologies. They constitute the service portfolio for the SOA implementation and enable the following:
-
Reuse, granularity, modularity, composeability, componentization, and interoperability
-
Standards-compliance (both common and industry-specific)
-
Service identification and categorization, provisioning and delivery, and monitoring and tracking
AIA Conceptual Services are categorized into Process Services, Activity Services, Data Services, Connector Services, and Infrastructure Services.
Figure 1-10 depicts the conceptual services of AIA.
1.6.3 What are Provider Applications and Resources?
Various applications acquired for their best-of-breed functionalities and any legacy applications built in-house are Provider Applications and Resources. Each of these applications exposes business functions, such as APIs, and can be accessed using different modes of connectivity.
1.7 The AIA Shared Service Inventory
Shared Services are application-agnostic services leveraged to build cross-application Composite Business Processes (CBPs). A successful AIA implementation is dependent on a robust Shared Services Inventory.
The various categories described in this section help relate Shared Services to Reference Process Model artifacts. Figure 1-11 depicts elements in the Shared Services Inventory.
1.7.1 What is a Process Service?
A Process Service is the implementation of major business events in an enterprise that have a significant impact on running the enterprise. It involves work being accomplished with the help of multiple resources.
Process Services automate business processes, orchestrate a series of human and automated steps, and normally span multiple information systems. They are analogous to Business Processes in AIA Reference Process Models.
The primary purpose of Process Services in AIA is to define and automate business processes that are external to and independent of the specific back-end systems used in the organization. This shields the business process from back-end system changes. Similarly, the applications are isolated from business process changes. Loose-coupling between the business processes and the applications simplifies changes and maintenance for business processes and applications.
Figure 1-12 depicts some characteristics of Process Services.
The structure of the information packets that are passed around should be rich enough to capture all of the significant event details. These can be custom-defined or accepted canonical messages, and be independent of the enterprise applications. Process Services leverage the Activity Services and Data Services and are triggered by significant business event initiators, such as CRM, UI applications, and business-to-business (B2B), for example.
1.7.2 What is an Activity Service?
An Activity Service represents an atomic business unit of work and has a set of steps involving system-to-system interactions. Activity Services may also warrant orchestration. In some cases, there may be matching application capabilities. These are exposed as mediator services on the service bus. Activity Services can act upon multiple canonical messages and be consumed by participating applications and process services. The structure of the message is either canonical or a user-defined format.
Figure 1-13 depicts some characteristics of Activity Services.
Activity Services are analogous to the Business Activities and Business Tasks in the AIA Reference Process Models. In some cases, multiple lower-level operations are combined to form an Activity Service, thereby hiding the complexity of the lower-level operations.
1.7.3 What is a Data Service?
A Data Service provides an aggregated, real-time view of enterprise data. Data consumers interact with enterprise data using Data Services. Data Services are primarily create, read, update, and delete (CRUD) operations that act upon canonical or user-defined messages. They are exposed on the service bus as mediator services.
Data Services eliminate point-to-point links at the data level and direct dependency on the data models of data sources. Data Services can be consumed by participating applications, process services, and activity services.
Figure 1-14 depicts some characteristics of Data Services.
Data Services are analogous to Business Tasks in AIA Reference Process Models.
1.7.4 What is a Utility Service?
A Utility Service provides error handling, diagnostic, and logging facilities across AIA implementations.
Figure 1-15 depicts some characteristics of Utility Services.
1.7.5 Implementing Process Services
The CBP AIA service artifact is an implementation of a Process Service.
1.7.5.1 Common Scenarios for Process Services
Process Services are analogous to Business Processes in AIA Reference Process Models, so they have the same goal: enabling structured accomplishment of work in an enterprise to ensure consistency and efficiency with low cost.
A Reference Process Model Business Process consists of a set of business activities and business tasks. There is a judicious mix of automated and manual tasks.
Process Services leverage technology and provide implementation software that can be executed on the application server. They leverage activity services and data services.
Following are two Process Service examples.
- Example 1 Resolve Customer Complaint Process Service
-
A business process defined to resolve complaints could:
-
Analyze a complaint and identify activities.
-
Schedule call, block resources, and assign technician.
-
Track activities and send statuses.
-
Close the complaint, generate metrics, and update statuses.
-
- Example 2 Settle Auto Accident Claim Process
-
A business process to settle auto accident claims could:
-
Analyze the claim and identify the parties and insurance agencies involved.
-
Schedule appointments and assign agents for collecting facts.
-
Compare facts collected with those from other agencies and attribute fault and settlement.
-
Send for approval.
-
Figure 1-16 illustrates a process service implementation.
1.7.6 Implementing Activity Services
The EBS AIA service artifact is the implementation of an activity service, if the EBS operation invokes an Enterprise Business Flow (EBF). In very few situations, an application might directly expose the needed functionality. In this case, an EBS operation may call an Application Business Connector Service (ABCS).
1.7.6.1 Common Scenarios for Activity Services
Activity Services are analogous to Business Activities in AIA Reference Process Models, so they have the same goal: providing a structure to accomplish work with the help of granular business tasks. Typically, an orchestration flow is used to implement Activity Services. The orchestration flow connects a set of business tasks. Activity Services can leverage other activity services and data services.
Following is an Activity Service example.
- Example 1 Creation of Customer in Billing Systems
-
An activity service can be implemented to create a customer in a billing system using an order document. This service may be composed of the following steps:
-
Retrieval of set of account identifiers from an order document
-
Retrieval of account particulars from a CRM system
-
Creation and update of customers in a billing system
-
1.7.7 Implementing Data Services
The EBS AIA service artifact is an implementation of a data service.
Data Services are analogous to Business Tasks in AIA Reference Process Models, so they have the same goal: providing a structure to accomplish work with the help of application provider services. Data Services leverage application provider services.
1.8 AIA Service Artifacts
This section includes the following topics:
1.8.1 What is a Composite Business Process?
A Composite Business Process (CBP) is a set of coordinated tasks and activities involving both human and system interactions. It is an implementation of the AIA Reference Process Model Business Process and is a Process Service.
In AIA, CBPs are implemented, managed, and monitored as a single SOA composite using SOA BPEL along with SOA Mediator, SOA Human Workflow, and SOA Business Rules components. The BPEL components are used to drive the flow.
1.8.2 What is an Enterprise Business Service?
An Enterprise Business Service (EBS) is a first-class object exposed on the enterprise service bus. An EBS is coarse-grained and performs a specific business activity or business task and is either an Activity Service or Data Service.
For example, the activity it performs could be one of the following:
-
Creating an account in a billing system.
-
Checking for the presence of an account in a billing system.
-
Getting the balance details for an account from a billing system.
An EBS is agnostic of a specific back-end implementation. Any back-end implementations that can support the interface standards defined by an EBS can be automatically considered as service providers. EBSs expose coarse-grained, message-driven interfaces for exchanging data between applications, both synchronously and asynchronously.
The salient features of EBSs include:
-
Ability to reuse available assets in the Oracle portfolio.
-
Ability to substitute a service provider with another without any impact to the client.
-
Content-based selection of the service provider.
Figure 1-17 shows how an EBS enables the loose-coupling of requesters with actual service providers.
1.8.3 What is an Enterprise Business Flow?
An Enterprise Business Flow (EBF) is used to implement a business activity or a task that involves leveraging capabilities available in multiple applications. An EBF strings together a set of capabilities available in applications to implement a coarse-grained business activity or task and composes a new service that leverages existing capabilities. An EBF involves only system-to-system or service-to-service interactions and does not include any activity that requires human intervention.
In a canonical integration, the EBF is an implementation of an EBS operation and calls other EBSs. An EBF never calls an ABCS or application directly. In other integration styles, the caller invoking the EBF can be an application or any other service.
An EBF can be implemented using Oracle Service Bus for stateless coordination of synchronous or one-way business activities where BPEL is used to coordinate asynchronous activities.
Figure 1-18 illustrates the way in which the EBF orchestrates a flow for synchronizing customers between the source application and the target application. When the sync operation is invoked from the source application, the EBF first determines if the customer already exists in the target application. If so, it updates the customer in the target application. If not, it creates the customer in the target application.
1.8.4 What is an Application Business Connector Service?
An Application Business Connector Service (ABCS) implements the EBS interface by exposing the business functions provided by the participating application. Figure 1-19 illustrates how the ABCS functions in the integration flow.
The ABCS is responsible for the coordination of the various steps provided by several business functions exposed by a provider application. For example:
-
Validation
-
Transformations: message translation, content enrichment, and normalization
-
Invocation of application functions
-
Error handling and message generation
-
Security
Figure 1-20 illustrates an ABCS implementation; in this case the CRM application querying an account balance from the billing system.
