Loading

Friday, February 5, 2010

AIA Architecture -- SOA

The AIA architecture is evolved upon the loosely coupled approach. To initiate the approach, an architecture that is application neutral is created between the two participating applications say something like the buffer zone. This application neutral buffer zone utilizes the industry standard data layouts and business flows.

In order to enable the applications (both requesting and responding) to interact with the industry standard data process model, we have to use a common vocabulary. To enable the loosely coupled architecture and the ease of enhancing in the future, the data definitions from the requesting and the responding applications should be translated to the standard definitions available in the framework. This translation of data from the requesting and responding applications to the standard definition is carried out by application specific translators placed on each side of the buffer.

In a loosely coupled architecture, there is an occurrence of a no: of objects being created and also there is a need for a technology to maintain these objects. The various objects and processes that are created needs to be managed so that they become visible throughout the architecture and also supports efficient re-use and extensibility.

AIA is a collection of these components and methodology guidance for creating the loosely coupled standard based integration architecture. The basic requirement of AIA is to establish a standard data and processing definition that can be understood across all the system. So AIA has this Enterprise Business Objects (EBO) and Enterprise Business Services (EBS). These EBO‘s are:

1. Application independent,

2. Extensible,

3. Provide the common vocabulary that will be used within the architecture,

4. Provide the necessary abstraction to enable integration.

EBO represent common business entities such as Customer, Sales Order, etc.

EBS is a library of standard processes and operations that interact with the EBO such as query Customer or create Sales Order albeit these services do not understand the operational vocabulary used by specific applications. Likewise the specific applications do not know the vocabulary of services and objects provided by AIA. Therefore, for the end applications to communicate, a translation to a common vocabulary must be performed which is done by AIA through the EBO. The translation from application specific terminology to EBO is done through the Application Business Connector Services (ABCS).

The ABCS process is the key to maintain the loosely coupled architecture throughout. The end applications need not be connected to be tightly coupled. The ABCS communicate with the end applications using the Application Business Messages (ABM)

These messages are translated into standard messages (EBM) by the EBS. The EBM will populate all or a part of an EBO based on the message.

Since an Enterprise Business Message is assembly for schema components, extensibility would mean a new EBM. The solution is to create a new EBM xsd containing the required EBM definitions.

For example, let us say there is ItemEBM.xsd which has CreateItemEBM, UpdateItemEBM and QueryItemEBM. There is a need for DeleteItemEBM and ValidateItemEBM. To extend the ItemEBM.xsd, create a CustomItemEBM.xsd and include in it the definitions for DeleteItemEBM and ValidateItemEBM.

2 Responses to “AIA Architecture -- SOA”

vishwa said...
February 22, 2010 at 12:05 AM

Nice compilation and crisp outline about AIA


Sridevi K said...
October 9, 2016 at 9:49 PM

Regards
Sridevi Koduru (Senior Oracle Apps Trainer Oracleappstechnical.com)
LinkedIn profile - https://in.linkedin.com/in/sridevi-koduru-9b876a8b
Please Contact for One to One Online Training on Oracle Apps Technical, Financials, SCM, SQL, PL/SQL, D2K at training@oracleappstechnical.com | +91 - 9581017828.


Post a Comment

Disclaimer

The ideas, thoughts and concepts expressed here are my own. They, in no way reflect those of my employer or any other organization/client that I am associated. The articles presented doesn't imply to any particular organization or client and are meant only for knowledge Sharing purpose. The articles can't be reproduced or copied without the Owner's knowledge or permission.