The AIA FP is Oracle's "accelerator framework" for implementing SOA-based system integrations. AIA FP and its prebuilt integrations such as PIPs were originally created to facilitate and accelerate the integration between different Oracle applications such as Siebel, E-Business Suite, PeopleSoft, and JD Edwards, among others. Customers looking to simultaneously implement and integrate several Oracle applications gain huge benefits from employing PIPs, as these significantly reduce the effort and risk involved with building interfaces to support business processes. Given Oracle's aggressive and continuous growth by acquisition, AIA FP and prebuilt integrations have become fundamental to rapidly integrate newly acquired products with their existing apps portfolio.
The AIA FP contains a variety of design-time and runtime artifacts that can be used when defining, designing, building, testing, and deploying SOA solutions. The following diagram presents an overview of the different components that build up the AIA FP:
The AIA FP consists of:
- AIA Architecture Framework Standards
- Service Constructor JDeveloper Plugin
- Code Compliance Inspector (CCI)
- Lifecycle Workbench
- Composite Application Validation System (CAVS)
- Setup Pages
- AIA Message Resubmission Utility
- AIA Solution Pack
- AIA Harvester
- AIA Deployment Plan Generator
- AIA Installation Driver
- AIA WSM Policies
- AIA Composites
- AIA Prebuilt Integrations
- AIA Error Handling Framework
- AIA Metadata
The preceding components will be described in the following sections.
These artifacts include tools, libraries, and other AIA assets that support the design-time phase of a project. These tools are:
- AIA Architecture Framework Standards: Consist of artifacts available for use during design-time governance stages. These include a reference architecture, a methodology, reference process models, conventions, and the AIA object library, which is basically a collection of XML artifacts such as XSD's and WSDLs, available for use.
Tip
For more information on the AIA architecture framework refer to:
AIA Concepts and Technologies Guide:
http://docs.oracle.com/cd/E23943_01//doc.1111/e17363/toc.htm
AIA Reference Process Models User's Guide:
http://docs.oracle.com/cd/E28280_01/doc.1111/e17368/toc.htm.
- Service Constructor JDeveloper Plugin: JDeveloper plugin used to automate the creation of AIA services. At present this plugin only supports the creation of AIA Business Connector Services (ABCS) that will be described later in the chapter:
Tip
For more information refer section 4 Working with Service Constructor of the AIA Developers Guide:
http://docs.oracle.com/cd/E28280_01/doc.1111/e17364/workingwservcon.htm#BABBEHEI.
- Code Compliance Inspector (CCI): JDeveloper plugin that can be used to check that code in SOA projects is compliant with AIA standards and best practices.
Tip
For more information on CCI please refer to section 20 Using the Code Compliance Inspector of the AIA Infrastructure Components and Utilities User's Guide http://docs.oracle.com/cd/E28280_01/doc.1111/e17366/chapter20.htm.
- AIA User Interfaces: A number of web applications aimed at supporting a project through the different AIA development lifecycle phases. The main web applications are:
- Lifecycle Workbench: This application provides a comprehensive console that can be used by business analysts, solution architects, and services designers, to streamline the analysis, definition, and decomposition of SOA solutions built with AIA.
Tip
For more information refer section 3 Working with Project Lifecycle Workbench of the AIA Developers Guide.
http://docs.oracle.com/cd/E28280_01/doc.1111/e17364/workingwplw.htm#CHDEIHFG.
- CAVS: The Composite Application Validation System (CAVS) is a testing application that supports the creation of stub services to simulate back end systems that might be unavailable during early testing stages. CAVS provides a mechanism for services created in accordance with the AIA standards to programmatically route a payload to CAVS, without the modification of the composite itself.
Tip
For more information on CAVS refer to the AIA Infrastructure Components and Utilities User's Guide.
http://docs.oracle.com/cd/E28280_01/doc.1111/e17366/toc.htm.
- Setup Pages: Basically a configuration page to set up error notifications, error codes, routing configurations, and application registries, among others.
Tip
For more information on setup pages refer to the AIA Infrastructure Components and Utilities User's Guide.
http://docs.oracle.com/cd/E28280_01//doc.1111/e17366/toc.htm
- Lifecycle Workbench: This application provides a comprehensive console that can be used by business analysts, solution architects, and services designers, to streamline the analysis, definition, and decomposition of SOA solutions built with AIA.
- AIA Message Resubmission Utility: It allows browsing through a list of faults and resubmitting them based on specific criteria:
- AIA Solution Pack: This pack seeds OER with all of the asset types, categorizations, and metadata required to fully govern AIA solutions and assets. This component will be covered in more detail later in the chapter.
- AIA Utilities: A series of utilities available for post installation use with the AIA FP. The main utilities are:
- AIA Harvester: A command line utility tailored for harvesting AIA services and assets into OER.
- AIA Deployment Plan Generator: An Ant utility that takes the Bill of Materials file (
BOM.xml), generated from the Project Lifecycle Workbench pack, as input and generates a Deployment Plan file (<projectCode>DP.xml) and a Harvester Settings file (HarvesterSettings.xml), based on the information supplied in the BOM. - AIA Installation Driver: An Ant utility that reads a deployment plan generated from the Deployment Plan Generator and deploys all SOA artifacts specified in the plan to the target servers contained in the installation driver properties file (
AIAInstallProperties.xml).
These artifacts include tools, libraries, and other AIA assets that support the runtime phases of a project. The supporting tools include:
- AIA WSM Policies: A Web Service Manager policy set created by the AIA FP installer to globally attach security policies to any AIA composite deployed to a SOA server.
- AIA Composites: A number of SOA Suite 11g AIA composites deployed into the SOA Server. These include: AIA utility services deployed during the AIA FP installation, AIA Prebuilt Integrations, and custom developed AIA services that follow the AIA FP lifecycle. The following screenshot shows the AIA composites deployed after installation of the FP:
- AIA Prebuilt Integrations: Prebuilt integration solutions created by Oracle with the AIA FP. There are two types of Prebuilt Integrations:
- Direct Integrations: Basically point-to-point integrations that manage data flows and data synchronizations between applications
- Process Integration Packs (PIPs): Integration accelerators that combine one or more integration styles, such as data-centric integration, web services, reference data query, and/or process-centric integrations, to deliver end-to-end integration solutions
Tip
For a list of all available prebuilt integrations please refer to Oracle's AIA documentation page http://docs.oracle.com/cd/E38316_01/index.htm.
- AIA Error Handling Framework: This provides a complete common error handling solution for services developed following the AIA standards. As can be appreciated from the figure, the main features of the AIA Error Handling framework are:
- Support for other technologies such as Oracle Data Integrator (ODI) and Oracle B2B
- Support for the main types of faults, such as system, remote, and business faults
- Configurable error notifications
- Integration with Human Workflow using the SOA/BPM Suite Worklist Application
- AIA specific error logger
Tip
For more information on the AIA Error Handling Framework please refer to section 13 Introduction to Oracle AIA Error Handling of the AIA Infrastructure Components and Utilities User's Guide: http://docs.oracle.com/cd/E28280_01/doc.1111/e17366/chapter13.htm.
- AIA Metadata: A set of XML artifacts that mainly consist of AIA, specific XSDs, WSDLs, and other XML files, that are stored in the SOA Suite Metadata Service repository (MDS). The principle component of the AIA Metadata is the AIA Components. AIA Components contains the main XML libraries available for use in AIA FP. Enterprise Business Object(s) (EBO) and Enterprise Business Message(s) (EBM) are examples of AIA XSDs available for use in the object libraries. Enterprise Business Service(s) (EBS) is an example of AIA WSDLs Assets available for use in the service libraries.
Tip
For a full list of the AIA Metadata content refer to section 2.1.3.5 Content of $AIA_HOME/AIAMetaData of the AIA Developer's Guide at http://docs.oracle.com/cd/E28280_01/doc.1111/e17364/bldgintflows.htm#BACBBAIC.
The following sections describe in more detail some of the key components of the AIA FP.
Tip
For a full description of the AIA FP please refer to 3Oracle's AIA documentation page: http://docs.oracle.com/cd/E28280_01/aia.htm.
Services built with the AIA FP follow a specific development lifecycle as illustrated in the following diagram:
The AIA methodology follows a top-down approach that can be summarized as follows:
- Business requirements are captured by Business Analysts using a BPM tool. At the time of writing this book, Oracle's documentation shows the Business Process Analysis Suite (BPA) as the preferred tool to conduct this analysis; however, this decision might change in the near future. The requirements are captured in the form of process models at levels 1 to 4.
Note
In future releases of the AIA FP it is very likely that the use of BPA will be superseded by another Oracle product. BPA Suite is in fact a rebrand of the IDS Scheer ARIS product. Shortly after the acquisition of IDS Scheer by Software AG back in 2009, Oracle announced that support for BPA Suite would end in the mid-term.
- An SOA architect decomposes the requirements into different business tasks using the Project Lifecycle Workbench (
http://<soa managed server>:<port>/AIA). The tasks are entered into a project as follows:
- Service Design and Construction occurs as following:
- An SOA designer defines the different AIA services that are required to satisfy each business task. This activity is accomplished by adding several components under Service Solution Component; a collection of these components realizes the functionality specified by a given business task:
- Using JDeveloper with AIA Service Constructor plugin, an SOA developer browses through the different active requests (basically service solution components waiting to be developed) and then chooses a task to work on:
- The developer generates and/or updates the relevant composites and adds the required annotations into the composite metadata:
- The developer harvests the built composites using the AIA Harvester utility back into the Project Lifecycle Workbench or alternatively into OER.
- An SOA designer defines the different AIA services that are required to satisfy each business task. This activity is accomplished by adding several components under Service Solution Component; a collection of these components realizes the functionality specified by a given business task:
- Back in Project Lifecycle Workbench, an SOA developer chooses which of the composites are to be deployed, and exports a Bill of Material (BOM) file for these composites. Then, using the BOM file as input for the Deployment Plan Generator, a deployment plan is thus generated:
- Using a deployment plan as input for the AIA Installer Driver utility, an SOA support engineer deploys all composites listed in the BOM to the defined target SOA servers.
- Optionally the SOA Testing team may wish to perform tests on the AIA composites using the CAVS before releasing the composites into the integration or user acceptance testing environments. Should a defect be identified in any of the composites during the testing stage, it is possible to go back to the Service Design and Construction phase to fix the issue and redeploy.
Tip
For detailed instructions on designing and building services using the AIA Foundation Pack please refer to the AIA Developer's Guide at http://docs.oracle.com/cd/E28280_01/doc.1111/e17364/toc.htm.
The AIA reference architecture consists of a Conceptual Service Architecture and an AIA Shared Service Library. These architectural assets provide the foundations for AIA and enable the adoption of the core SOA design principles such as:
- Reusability: Designed and built assets that can be re-used across the enterprise now or in the future
- Granularity: Ability to identify the optimal granularity for the functionality delivered by a service and its service operations
- Modularity: Ability to break down a problem into smaller and distinct services that can be unit-tested in isolation and that expose well defined and standard interfaces
- Composability: Ability to create solutions by bringing together existing services that could themselves be made up of composed services
- Loosely Coupling: Service contracts are independent of application schemas or application
- Standards-compliance: Services are created based on industry standards and expose standard interfaces
- Discoverability: Services contain self-describing metadata that allows them to be identified and interpreted
The AIA Conceptual Service Architecture is summarized in the following diagram:
This architecture consists of:
- Process Services: These are services that automate business processes that span across multiple information systems and that require the orchestration of human and automated tasks as well as technical orchestration and use of business rules. Process Services are coarse grained in nature and their scope is limited to the business process that they support. Services can be short-lived or long-running, potentially spanning several months or even years.
Process Sales Order is an example of a Process Service as it usually requires credit checks and address checks against the customer, human workflow for approvals depending on the sales order amount, availability to promise checks, creation of the order, and frequent notification of the order status to the customer and other systems.
- Activity Services: These services deliver a well scoped (yet still coarse-grained) business task that might require interaction with different systems. Activity Services support Process Services by providing the functionality needed to complete each task within the process.
Customer Credit Check is an example of an Activity Service as it delivers a specific business task in support of a broader business process but in itself it may require interaction with more than one system (for example different credit agencies).
Another example of an Activity Service is the Customer Business Service. This service would usually provide CRUD (create, read, update and delete) capabilities. The functionality is delivered by orchestrating and aggregating data from multiple systems that hold customer data.
- Data Services: These services deliver fine grained functionality and interact directly with the backend information systems. Data Services provide decoupling as they create an abstraction layer between backend systems and coarse grained services.
Create Customer, Read Customer, Update Customer, and Delete Customer are all examples of Data Services as they encompass fine grained business functions against specific backend systems.
- Utility Services: Services that provide common error handling, diagnostic, and logging facilities for the use of other services. For example BAM services or exception handling or logging services.
The AIA Shared Service Library is basically a Logical Service Architecture derived from the AIA Conceptual Service Architecture. The following diagram depicts it:
As can be seen from the preceding diagram, the AIA Share Service Library consists of a number of service artifacts. These artifacts define the AIA Service Taxonomy and are the building blocks for solutions delivered using AIA.
- Composite Business Process (CBP): A Process Service is ideally implemented as a BPMN 2.0 process using the BPM Suite 11g. However they can also be implemented as BPEL processes using SOA Suite 11g.
CBPs are application agnostic as they only interact with an EBS to complete their tasks and also to implement a canonical schema.
- Enterprise Business Service (EBS): EBSs are considered both Activity Services as well as Data Services as they expose coarse grained operations in support of specific business tasks. They also provide support for CRUD-like operations against first-class entities such as Customer, Sales Order, Purchase Order, Invoice, among others.
EBS services are application agnostics and their contract is based on a canonical schema. EBSs only deal with EBF, CPB, or ABCS. EBSs are typically implemented as SOA Suite 11g composite applications and use the Mediator to route requests to other services.
EBS services don't make use of BPEL as they don't actually do any service orchestration. Instead, they consume EBF or ABCS services as required.
- Enterprise Business Flow (EBF): These are the Activity Services responsible for delivering business tasks and implementing business logic.
EBF services are application-agnostic as they only deal with EBS services in technical orchestrations.
EBFs are typically implemented as SOA 11g composites applications using the BPEL PM to perform the technical orchestrations. They also implement a canonical schema.
- Application Business Connector Service (ABCS): They are a type of Data Service that exposes the fine-grained business functions provided by the participating applications. ABCS are responsible for transforming messages from application-specific format or Application Business Message (ABM) into AIA's canonical format or Enterprise Business Message (EBM).
ABCS services are also responsible for implementing the VETO pattern. This means validating (validating semantics and data), enriching (getting additional data required that may be required), transforming (from ABM to EBM), and operating on a message (calling out).
ABCS services are typically implemented as SOA Suite 11g composite applications using mainly Mediator and BPEL components. BPEL is used to enrich the message. Mediator is used to transform and operate. Validation often involves the implementation of WSM policies and other checks such as semantic validations.
There are two types of ABCS:
- ABCS Requesters (ABCSreq): Responsible for receiving client messages in application-specific semantics (ABM) and then validating the message, enriching it, transforming it into an EBM, and calling out to an EBS.
- ABCS Provider (ABCSprov): Responsible for exposing fine-grained backend system functionality. They receive EBM messages from an EBS, transform them to ABM, and then persist them to backend systems.
- Application Business Flow (ABF): In some integration scenarios introducing several layers of abstractions to an interface cannot be justified. For such scenarios, AIA supports point-to-point integrations by delivering Direct Integrations using Application Business Flows (ABF):
Tip
Although Direct Integrations may result in better business outcomes for some specific integration scenarios, the abuse of this pattern may result in higher operational costs for mid and long term. Therefore, before deciding to implement Direct Integrations we strongly advise you to evaluate the short, mid, and long term benefits of it.
AIA services implement the VETORO integration pattern. This pattern is a variant of the industry-standard pattern VETO, which stands for Validate, Enrich, Transform, Operate. AIA introduces an extra Route and Operate step resulting in the VETORO variant.
Following is an example of an end-to-end interface implemented with AIA:
Tip
For more detailed information on the AIA Reference Architecture please refer to section 1 Understanding the Oracle AIA Reference Architecture of the AIA Concepts and Technologies Guide.
http://docs.oracle.com/cd/E28280_01/doc.1111/e17363/chapter01.htm#sthref9.
At the core of any integration, regardless of the architectural style or technology, there must be a message that contains the data required to action a business function. In AIA terms, these messages are referred to as Enterprise Business Messages (EBMs). EBMs are exchanged by the different AIA services in order to transfer messages between the participating applications.
Strictly speaking, EBMs are envelopes that contain the business data that the participating applications are interested in. For this reason EBMs contain certain metadata in an EBM Header that would facilitate the transport of the message to the relevant destinations. This is comparable to how the postal service works. In order to send a letter an envelope must contain a recipient name and address. Without this information the envelope will never reach the destination (chances are that it will never leave the postal office and the message will get lost). Optionally, envelops may contain a return address so it can be returned to the sender's address in case of non-delivery.
An example of an EBM that supports the creation of a customer would be CreateCustomerPartyEBM and the corresponding response would be CreateCustomerPartyResponseEBM.
The business data that makes an EBM message relevant for the participating applications are contained in data objects referred to as
Enterprise Business Objects (EBOs). Using our previous analogy, this would be equivalent to the actual letter inside the envelope. Examples of EBOs could be a CustomerPartyEBO, SalesOrderEBO, and ItemEBO, among others. EBOs contain all of the relevant business data required by the participating applications or by the service to perform business logic.
EBMs and EBOs work hand-in-hand and during the transportation of the message they are coupled. Again, going back to our analogy, there wouldn't be much point in delivering an envelope that doesn't contain a letter. Equally, a letter would never be delivered without an envelope containing the recipient's address (perhaps the stamp could be considered as a metric used in cloud services to charge integration based on usage, but that's a topic for a different book).
Both EBMs and EBOs are defined using XML Schema Documents (XSDs). Furthermore, EBMs and EBOs are built using common semantics and frequently implement the Canonical Scheme and Schema Centralization patterns. Individual applications on the other hand normally use their own specific data formatting for messages referred to as Application Business Messages (ABM) that contain Application Business Objects (ABOs). It is the responsibility of ABCSs to transform ABMs/ABOs to EBMs/EBOs and vice versa.
The following diagram illustrates, at a high level, the anatomy of an EBM message:
In a nutshell, an EBM message consists of:
- EBM Header: This carries important metadata that might be needed by the transporting party to ensure message delivery. Some of the information that can be included in the header includes:
- Information about the message originator
- Information about the message destination
- Unique identifier of the message
- Error handling information
- Timestamps
- Verbs (for example, create or update)
- EBM Body: Basically a place holder for the EBO.
- EBO: The business object containing the relevant business data. Since certain messages may require specific data items that cannot be held in a single EBO, it is possible to create a context-specific EBO that contains elements from multiples EBOs.
EBMs as well as EBOs are agnostic of the underlying transport mechanism. EBMs can be sent using a variety of transport protocols such as HTTP, JMS, RMI, and others. However, since AIA services are implemented as SOAP web services and defined using the WSDL, the preferred transport is HTTP. The following diagram illustrates how an EBM messages fits in a standard HTTP/SOAP message:
Implementing SOAP web services provides many benefits because AIA can rely on additional standards such as WS-Security to implement security (authentication, authorization, encryption, and signatures), WS-Addressing for asynchronous web services and WS-Policy for implementing several other policies.