|
|
Application Integration Architecture (AIA)
In the integrations that are built using AIA, the application making the request (requestor application) is not tightly coupled with the application providing the service (provider application).
AIA uses queues for asynchronous and reliable delivery of messages. A business event can either push the message directly into a queue or send a SOAP message over HTTP to a JMS message provider (an ESB adapter) that will be responsible for entering the message in the queue.
AIA leverages ODI for batch processing.
AIA addresses all types of integrations (including user interface and process integration), but the primary focus is to describe how functional and data integration is achieved. Data integration makes the same data available to more than one application, and is ideal when there is minimal amounts of business logic to be reused across applications. Functional integration connects the applications at the business logic layer, and is used when there is a need to reuse functionality such as business logic or a process. Functional integration can be accomplished either by exposing objects interfaces or by exposing web service interfaces.
Oracle Application Integration Architecture components
|
|
|
Enterprise Business Object (EBO)
Represents a layer of abstraction on top of the logical data model.
Whenever possible, the EBO leverages widely adopted international standards for modeling an dnaming, such as UN/CEFACT CCTS and ISO 11179.
Apart from creating the complete definition for an EBO, a definition is also created for each of the contexts in which this EBO will be used.
Each EBO is represented in an XML schema.
|
|
|
Enterprise Business Message (EBM)
The context-specific EBO definitions are created by assembling a set of common components and EBO-specific business components. These context-specific EBO definitions are then used in the appropriate context-specific EBM. For example, the cancel-specific invoice definition would be a part of the 'CancelInvoice EBM'. These EBMs can be used either as the request or response parameters.
For every EBO, there will be 2 schema modules - one containing the definition of the EBO and another containing the definition of the context-specific definitions for that EBO.
For example, both the request and response messages will have content from the EBO.
Every EBM possesses the same message architecture.
Each service request and response is represented in an EBM by using a distinct combination of an action and an instance.
EBS Steps
|
|
|
EBM Header
Uniquely identifies the message for auditing, logging, security, and error handling.
Associates the message with the specific instance of the sender system.
|
|
|
Enterprise Business Service (EBS)
EBSs represent the application independent web service.
An EBS is a self-contained, business level interface.
The request and response-specific payload for each of the services is defined as an EBM. The EBM typically contains one or several instances of a single EBO, wihch forms the crux of the message, the action to be performed, and the metadata about the message specified in the message header section.
EBS components do not presuppose a specific backend implementation of that service. They simply provide an integration layer for the customer's choice of a backend.
Any backend implementations that can support the interface standards defined by an EBS can be automatically considered as service providers.
AIA supports 2 categories of EBS, 'entity-based services' and 'process-based services'. All of the standard activities that need to be performed using an EBO are brought together under an entity service.
An entity-based EBS: create, update, delete, query, sync
All of the business activities that need to act upon a particular business object in order to fulfill a specific business process are brought together under a 'process service'.
The EBS is a web service.
Increases the flexibility of the architecture by allowing the substitution of one service provider for another without the requestor being aware of the change and without the need to alter the requestor or EBS abet the substitution.
This kind of decoupling is accomplished by having the requestors and service providers converse via a mediator.
Ever EBO will have an EBS. Each action of the EBO will have a service operation as its interface. The EBS is a very lightweight service and is implemented as an ESB routing service.
In scenarios where there are multiple instances for a single application, the ESB service enriches the EBM header sectoin of the document with details about the service provider and the end-point location. The pre-built integrations to be delivered by Oracle leverage the AIA Configuration Properties file to identity the end point locaiton.
EBSs are of 2 types: business object services, business process services.
Business Object Service: These services expose operations that act on a specific EBO. Consist of standard CRUD operations that have the same look and feel across services as well as any specialized operations specific to the EBO. Implemented as an ESB routing service.
Business Process Service: These services expose operations related to an enterprise business process. Implemented as an ESB routing service. * Operations exposed on the EBS will initiate cross-functional EBFs that take care of coordinating complex long lived flows that span multiple services. * These flows can only interact with EBS services. * Unlike Business Object Services, a Business Process Service may act on more than one EBO.
EBS Steps
|
|
|
Application Business Connector Services (ABCS)
An ABC service can be requestor-specific or provider-specific.
The role of the requestor ABC service is to act as a vehicle to allow the participating application to invoke the EBS.
The ABC service is responsible for: validation, transformations, error handling and message generation, security, etc.
The application needs to be able to send messages that comply with EBS expectations.
Very few applications are built to readily interface with EBSs.
The ABC service leverages a variant of the industry-standard integration pattern called VETO Pattern (Validate, Enrich, Transform, and Operate).
An ESB routing service may use XSL-based validation as well as content-based routing directly in the service itself.
Although a single ABC service can be used to handle multiple activities, it is highly recommended to allow only a single ABC service per action.
If the applications expose their functionality via a web service interface, verify that the granularity of functionality matches exactly that of what has to be exposed as an EBS.
In situations where granularity of functionality exposed by the application via the web service doesn't match that of the EBS, attempts should be made to have appropriate modificaitons or enhancements made in the application. In situations where these modifications cannot be made to the application, the ABC service will not only be responsible for the transformations, but will also need to aggregate and disaggregate services.
This type of ABC service can be implemented only through BPEL and not through ESB.
It is highly recommended that much of the application logic be encapsulated within native applications as opposed to having them handled in the ABC service.
In the case of packaged-applications, the much preferred route is to use the respective packaged-application adapters. These adapters can be deployed as J2CA resource adapters.
The ABC service is responsible for facilitating logging and monitoring capabilities.
Validations are based on the constraints that are imposed by the participating application providing the service.
In the case of asynchronous interaction styles (request-only), where the user experience will be hindered if validations are not performed at the time of capture, the requestor application should use another integration point to perform the validation prior to submitting the message for processing.
The ABC service can be implemented in 2 ways; as an ESB or BPEL process, or an interface that will be exposed as a WSDL.
A single ABC service should be responsible for invoking the application business service available in the appropriate deployed (e.g., if there are 2 E-Business Suites).
Because an EBM can carry multiple instances, the provider application business connector (ABC) service should have the ability to iterate through each of the instances and process them.
The requestor applicaiton can either pass everything that an ABC service will ever need or it can just pass the bare minimum which in turn could be used by the ABC service as the driver to fetch relevant details from the client-side participating application. In the latter approach, the ABC service might need to engage in conversations with the participating application to get all of the details relevan to compose an EBM. It is highly recommended that the participating applications resort to the first approach to minimize overhead.
|
|
|
Process Integration Pack (PIP)
A pre-built set of integrated orchestratoin flows, application integration logic, and extensible enterprise business objects and services required to manage the state and execution of a defined set of activities or tasks between specific Oracle applications associated with a given proces. The PIP product offering is suited to those customers seeking to rapidly implement a discrete business process. PIPs use the AIA architecture to deliver composite industry processes for specific industries.
|
|
|
Compositve Application Validation System (CAVS)
Is a framework that includes initiators to simulate calls to participating applications and simulators to simulate responses from participating applications.
The CAVS provides a test repository, an execution engine, and user interface.
|
|
|
Business Service Repository (BSR)
The BSR stores and provides information about the objects, messages, and services that compose the integration scenarios. An integration scenario refers to the end-to-end flow of a message.
The BSR is secure and UDDI v3 compliant.
Enables it to become the system of record for your business services.
|
|
|
Schema Extensions / Namespace
There are 2 main reasons why extensions must use their own namespace names.
The version of the schema is identified with the help of the 'schema declaration version attribute' available in the XML schema and with the help of a required custom attribute on the XML instance document.
Each of the EBOs has its own namespace, using the following format:
http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/[object name]/v[major version number]
http://xmlns.oracle.com/EnterpriseObjects/Industry/[Industry Name]/EBO/[object name]/v[major version number]
|
|
|
Transformations
The transformation scripts delivered as part of pre-built integrations are made extensions ready.
A transformation script exclusively dedicated for housing customer extenstions is delivered.
|
|
|
Versioning
The version number is composed of 2 parts; major and minor version number.
A new major version number is introduced if changes in semantics, removing required components, changing a type, etc.
A new minor version number is introduced if adding additional optional components, etc.
A release that updates the major versoin number of an EBO contains changes that make it incompatible with the prior major release.
Introduction of a new version of the service doesn't force the consumers of a specific version of the service to switch to the latest version immediately.
|
|
|
Logging / Error Handling / Deployment / Security
The Error Handling Framework is designed to trigger an error logging event for errors occurring in any of the AIA services, whether they are BPEL or ESB.
These log files can be managed and viewed using the OEM user interface.
The infrastructure framework provides deployment tools for automating the migration of artifacts from development to test to deployment environments. Process and service dependency analysis identifies all artifacts required for a given deployment.
AIA supports authentication, authorization, encryption, logging, etc.
A typical web service policy could: decrypt the incoming XML message, extract the user's credentials, perform an authentication for this user, write a log record, pass the message to the intended web service, return an error and write an exception record, etc.
Consider whether or not the client identity and password need to be transmitted from one end to another via the EBM header. Use custom headers in the WS-Header section to transmit the security informatoin to the server-side ABC service.
|
|
