Technical Architecture for AIA 11gR1 FP 3.1

AIA 11g R1 Installation and deployment-flexibilities, topologies, architecture and tools. Introduction: Oracle Application Integration Architecture (AIA) is a fully SOA-based product for Enterprise Application Integration providing you all vital ingredients, end-to-end, for a successful SOA Adoption. Oracle AIA Foundation Pack (FP) provides the architecture blueprint and standards-based canonical business objects to design true SOA Integrations. AIA FP also provides the framework for rapidly implementing, testing, deploying, monitoring and governing business integrations allowing you to jumpstart your SOA Initiative or to attain higher levels of maturity for you existing SOA Adoption. AIA FP is an installable product and can be deployed against Oracle SOA Suite deployments. AIA Installer ensures that all Oracle-delivered AIA FP content. Tools etc Described earlier is installed, configured and ready to use at the end of its run. Although AIA FP does not deliver the actual services that implement any specific business integration, it is important to understand the options and flexibilities provided during the FP Installation and determine the appropriate topology (single silo-ed, clustered, distributed etc.), because it consequently determines the way integration content (like services, JMS etc) will later be deployed and operated on top of the FP layer. This paper will initially discuss that. This Integration content itself could be Oracle AIA Process Integration Packs - PIPs (Oracle delivered pre-built, extensible and deployable integration content meant for specific business processes between specific Enterprise applications) or custom-built Integration content built by you for integrating your different Organization’s Application assets. Scope: This document intends to provide an overview of the flexibilities that AIA 11gR1 installer offers. It also provides the insight into when and how you could use these flexibilities to achieve the deployment topology that best suits your organization. This will focus on the AIA deployment architecture and associated tools that allow you to easily construct your own deployment for the AIA content that you created of customized.This is will also provides you a brief overview on migration strategies that you could employ for your AIA Environments. AIA Installer – Overview of Installation and Deployment Modes AIA Installer provides a wizard driven installation approach for installing AIA Foundation pack and other AIA products. The Installer prompts users to select products to be installed and deployed and to input server details and required configuration details. The user has flexibility in providing the server details (SOA Server and database) and in configuring the installation as per the topology requirements. Basic Installation and deployment mode This mode represents the basic single server installation of AIA. If this is the first time you are installing AIA FP, you might want to begin with Basic Installation mode. For this installation mode you would need a WebLogic Server with Admin Server and SOA Server configured in the same server. You will be installing AIA (creating AIA_HOME directory) on this server and deploying the artifacts to the SOA Server For a basic installation you will typically configure all AIA database schemas on the same database server although you can still choose different database connections (which will be elaborated in later sections) This installation mode will deliver a fully functional single server installation of AIA. AIA Installer - Installation and Deployment Topologies Using different modes of the AIA Installation, several deployment topologies can be achieved by leveraging the flexibilities of the installer and installation tools The topologies arise through variations in three primary areas. • AIA Instance details • Database Schema details • SOA Server selection The flexibilities that each of these present will be explained followed by some sample Installation topologies. In the remainder of this document you will notice two terminologies being used – AIA Installation and AIA Deployment. Although used interchangeably at times, there is a distinct difference. AIA Instance For every physical Weblogic Server there can be one installation of AIA. This installation is identified by an AIA_HOME, which is an ORACLE_HOME created as a part of the AIA Installation. The AIA_HOME is where all the AIA content is delivered as files. An AIA_HOME should be maintained as the source of truth and identifies the availability of an Installation during patching, upgrades etc. This AIA installation can be associated with multiple AIA deployments. Each unique AIA deployment associated with a given AIA installation is called an AIA Instance. The figure below will provide an overview. Note: AIA Installation refers to the delivery of all AIA content (AIA_HOME) to the server whereas AIA Deployment refers to the deployment of AIA products (like AIA foundation pack or AIA demo) to specified servers or deploying specific AIA artifacts. There can be several AIA instances associated with a centralized AIA Installation. This provides the ability to have multiple AIA instances available on the same Weblogic server, assuming there are at least as many non-clustered SOA Servers available on that Weblogic Server (one SOA Server per Weblogic domain as per SOA Suite recommendations). Each AIA instance is always associated with a Foundation Pack deployment and each AIA Instance can potentially have its own AIA related database schemas (in addition to the fact that there would definitely be different SOA Suite database schemas and MDS for every SOA Server). This makes each AIA instance a completely independent runtime entity. AIA instances could also be deployments on a remote SOA Server (not on the physical Weblogic server where the installation was performed). Even in this case, AIA_HOME is the centralized file store and it also has static information of all AIA Instances it is associated with i.e. the remote SOA Servers on which the deployments happen will store no AIA content on the file system. Note: Because all the instances share the same installation (AIA_HOME), the artifacts in each AIA instance is and should be of the same version. This implies that when upgrading or patching the design time content in centralized AIA_HOME is modified and if a service is used in more than one instance, then all services need to take up the patched or the upgraded version of the artifact. Patch and upgrade information and inventories are maintained only against the AIA Installation and not in each of the deployment servers. Using multiple AIA Instances is useful in several scenarios. The most common scenarios are 1. When there is a need to optimize the number of physical servers required. Multiple AIA Deployments can exist in the same server with each deployment having its own SOA Server and its own set of AIA related schemas. This eliminates the need of installing multiple copies of AIA in different physical servers. Developers and others alike can share the same physical server. For example, in Figure 1, two different developers, with each managing and working only on their own SOA Servers and AIA deployments, can use two AIA Instances- AIA1 and AIA2. They can use JDeveloper or other tools to modify artifacts directly on the SOA Server and periodically synchronize the content with the AIA_HOME directly or use source control from where periodical builds will refresh the content on AIA_HOME. 2. When continuous code integration is required while working with development, test environments etc. As depicted in figure 1, the same content in AIA_HOME can be deployed to multiple servers as different AIA instances. Each of the AIA instances will have their own AIA Foundation Pack. This allows spawning multiple environments with continuous code integration. For example, AIA2 and AIA3 can correspond to development and test environments. 3. When different business process integrations belonging to the same AIA version are required to be working on different domains or different physical servers. Several pre-built AIA business Integration processes (AIA PIPs) belonging to the same AIA release can be deployed to different AIA instances. These instances can be on the same server or on a remote server. This topology is useful for both development and production time. Example each of AIA2 and AIA3 can hold a copy of a Foundation Pack and a different PIP. 4. When there is a need to have multiple deployments of the same business specific integration artifacts based on geography of the organization etc. This is similar to scenario 2 but is typically applicable in production scenarios. Database Schema Options AIA Installer provides you multiple options while configuring the database schemas used by AIA. The schema types that you can configure include • AIA Schema (used by AIA Error Handling, CAVS, System Setup) • Cross Reference Schema • AIA Lifecycle Schema (used by AIA Project Lifecycle Workbench) • JMS Schema Each of these schema types is AIA specific and so has to be configured as a part of AIA Installation. Using AIA Installer for each schema type, you can provide the details of the actual schema to be created or you can even specify already existing schemas to which you want to connect to (either created through another AIA installation or created manually through SQL scripts). AIA Installer provides a mechanism to configure each schema type one at a time or more than one schema type at the same time. When performing this, Installer provides the option to provide the same physical database server for all AIA schemas or optionally each schema can configured be on a different database server. The following figure shows the above options available through the installer. Later chapters will give detailed information on how to complete information on this screen. The figure below is an illustration of how AIA Instances can be created using the above screen to utilize database schemas running on single or multiple physical servers or any other combination in between. The above flexibility opens up several topology options from a database perspective. We will discuss a few common scenarios. 1. Multiple AIA Instances sharing the same AIA Lifecycle database - Typically every AIA Instance has its own set of AIA schemas however it is not an uncommon scenario for AIA instances to share the same physical schema. One example is AIA lifecycle schema used by AIA Project Lifecycle Workbench. The Workbench is for orchestrating the development-time activities and so a common Lifecycle Workbench Database schema is desirable. This topology is often useful in a distributed development environment; you may have different teams working on different AIA instances, yet they share a same AIA Project Lifecycle Workbench, which guide them through a common release/development cycle. In figure 4, the Foundation Pack installations corresponding to AIA1 and AIA2 can each have its own AIALifecycle Schema viz. AIA1_LIFECYCLE and AIA2_LIFECYCLE. Alternatively when creating AIA2 Instance, it can be configured to ‘Connect to’ AIA1_LIFECYCLE using the AIA Database Details screen presented above, instead of creating a new schema for itself. Multiple Instances sharing the same AIA Lifecycle Database. To do this, while running the installer the second time to create AIA2 follow these steps a. Choose the AIA Lifecycle schema checkbox alone in the table region of the database details screen. b. Click inside the cell corresponding to ‘AIA Lifecycle’ Row and ‘Schema Name’ column. c. Now this cell will be editable. Change the name to AIA1_AIALIFECYCLE. The default value would be AIA2_AIALIFECYCLE. This is because the AIA Instance name provided in the first screen of the installation is appended to the schema name automatically. d. In the region below enter the database connection details. e. In the Enter Schema Details region, choose ‘connect to existing schema’ and provide the password of the AIA1_AIALIFECYCLE schema that was created during the earlier run of the installer when creating AIA1 Instance. This schema is now configured to reuse an existing schema f. Now uncheck the AIA Lifecycle row in the table and choose all other schema types. g. Provide connectivity information, desired password and SYS user credentials at one shot to create other schemas. AIA Deployment Architecture Until now we have discussed deployment topologies, strategies and flexibilities while installing and deploying Oracle-delivered AIA products using the AIA Installer. More often than not, it is also required to customize Oracle delivered content (like customizing a PIP) and/or completely build new AIA content using Foundation Pack, like building out your specific Integration for your assets. Now the biggest challenge is how to go about deploying content in an automated and repeatable fashion. The good news is AIA deployment Architecture bears this in mind. AIA FP exposes all the tools and utilities required so that you can construct your deployment of custom content and deploy them in the same manner as how Oracle does. AIA treats deployment as a part of a continuous SOA lifecycle and several stakeholders contribute at different stages to derive the deployment content. Yet AIA Deployment architecture provides loose coupling so that these stakeholders are not bound to work together and in a rigid fashion – a true SOA principle.