Oracle has elected to move away from offering AIA Foundation Pack in its current form. Many of the features offered are being offered in a different packaging – predominantly SOA 12c Core Extensions, and some of the tooling which has not been heavily used will not be available in 12c.

AIA 11g Foundation Pack then it will be replaced by Oracle SOA Suite 12c Core Extensions via a SOA Suite 12c upgrade process for those who have already licensed it. The key consideration is the changes in feature availability in on premise upgrades and the ability to exploit all the tooling particularly into the SOA cloud is unlikely in the future.

Based on this we would recommended that any capabilities not offered natively in 12c should be retired from use, to remove potential issues as a result of upgrading or adopting  a  lift and shift cloud strategy. There is 1 possible caveat to this in the form of utilising the AIA canonical model, more on this  below. The sections shows how AIA capabilities have been re-aligned and you might move forwards.

A lot of the UI features have moved to products such as the Oracle Enterprise Repository (OER 12c) as a result the retirement of the Lifecycle Workbench and a few features have been retired.

Reference Process Models

Reference Process Models, are more aligned to the process of solution analysis and design. The capabilities here can be obtained from other tooling. Separating out process models from a product that is more technically aligned makes sense. We would recommend you want to look at process models in a solution independent capability – particularly as your processes maybe split across platforms and products and even between on-premise and the cloud.

Personally I have seen little use of the top down business process models wrapped up by AIA outside of prepackaged PIPs where process models have been considered they have been examined by business architects before determining by the technologists the delivery approach.

Common Objects

The canonical model piece is lost in the transition to 12c. The canonical model is presented through a series of XML Schemas and HTML documentation, so could be packaged up and continued to be used irrespective of of the SOA versioning – subject to ensuring no licensing constraint on where the schemas are applied that might prevent them being used in the SOA cloud for example.

If there are to be constraints around carrying schemas forward then a strategy of migrating to another broad canonical model such as OAGI  would be recommended. OAGI is particularly appealing given it strongly influenced AIA’s model but also their specialist domains leverage it as base definitions for example HR Open Standards.

Composite Application Validation System (CAVS)

CAVS provided a means by which it is possible to build integration tests that exercise composite components. This component could be leveraged by any Continuous Integration infrastructure. We have done this in the past before Oracle’s significant progress in adopting Maven and Hudson.

This is now part of the SOA Suite Core Extensions pack.

AIA Error Handling Framework (AIA-EH) including Resubmission Feature and Logging

This provides the common error management framework that can be extended to provide automated error handling – for example delay for a period and retry. This one of the most valuable capabilities offered in terms of functionality as it provides a unified framework on which you can do basic error trapping and retry to far more complex advanced capabilities. As part of 12c this has been advanced as well.

This is now part of the SOA Suite Core Extensions pack.

AIA Deployment Plans

Deployment plans tooling has now gone as the deployment mechanism (AID) has also been dropped. More on this below.

XSL Mapping Analyzer & reporting(XMan)

This tool provided the means to identify and understand how mappings have been customised or extended from base. This has been superseded by the Mapping Editor tooling in 12c which offers a better approach to this activity.

AIA Installation Driver & AIA Installer properties

This capability wrapped up a series of smaller WLST based processes to deploy a PIP either licensed or custom PIP. As the concept of custom PIP has been dropped in favour of a collection of composites and other artefacts as would be applied if building using just SOA Suite. The capabilities use within Specsavers’ has in the past been shown to be mixed with some people preferring the SOA deployment approach rather than the wrapped up AIA mechanism.

PIP Auditor

The PIP auditor was provided AIA 11g as a means to perform a health check on the configuration of a PIP including custom PIPs. Whilst  it is possible also include this tool into a Continuous Integration process  aide quality management it requires a lot of work to break the lengthy report into more manageable  . However this was not heavily adopted, and also not known to be used manually either, therefore the impact of not continuing its use is negligible.

Framework & Methodology

Still applicable as this is simply a set of architectural approaches utilising Oracle Middleware products such as SOA Suite

Project Life Cycle Workbench including AIA Artefact Generator

As a design tool this has been deprecated. However from a Specsavers viewpoint this has minimal impact as the workbench has not been heavily used in this form (this includes AIA Artefact Generator) as the elements can be generated manually by SOA during the development process.

As the above diagram shows, the life cycle processes are all underpinned by the development process itself.

With respect to the deployment of artefacts such as composites,DVMs etc this is still available through standard SOA mechanisms such WLST. Viewing deployed artefacts can still be done through various management consoles.