How to Avoid Redundant Data Model Representation in AIA How to Avoid Redundant Service Contracts Representation in AIA

Working with AIA Design Patterns 25-13 Figure 25–10 Error Scenario Using Parallel Routing Rule and Web Service Call

25.2 AIA Assets Centralization Patterns

This section describes how to avoid redundant data model representation and service contract representation in AIA. This section includes the following topics: ■ Section 25.2.1, How to Avoid Redundant Data Model Representation in AIA ■ Section 25.2.2, How to Avoid Redundant Service Contracts Representation in AIA

25.2.1 How to Avoid Redundant Data Model Representation in AIA

Problem The service contracts between the applications and AIA interfaces must use similar business documents or data sets which results in the redundant data models representation. A change in the data model is very difficult to apply and it is very difficult to govern. Solution AIA recommends separation of the data model or schemas physically from the service contracts or the implementations. These schemas should be centralized at a location which could be referenced easily during design or run time. All the EBOs Enterprise Business Objects, ABOs Application Business Objects, and any other utility schemas should be maintained at a central location in a structured way. As the EBO schemas are used for various business processes in common, a thorough analysis should be done before coming up with a canonical data model. 25-14 Developers Guide for Oracle Application Integration Architecture Foundation Pack Impact ■ A change in the data model or schema should be treated very carefully because multiple dependent service contracts could be impacted with a small change. ■ Versioning policies should be clearly defined, otherwise redundant service implementations for a minor change may occur. ■ Governance is a challenge to manage the shared data models or common assets.

25.2.2 How to Avoid Redundant Service Contracts Representation in AIA

Problem The granularity of the service contract can be at the operation level or at the entity level. The entity level definition can have various operations defined in the same service contract but the implementation can be at operation level which results in creating multiple implementation artifacts using the same service contract. This causes redundant service contracts representation in various implementations. Solution AIA recommends that the service contracts WSDL be separated physically from the implementations. These service contracts should be centralized at a location which can be referenced easily during design or run time. All the EBS Enterprise Business Service, ABCS Application Business Connector Service, and any other utility service contracts should be maintained at a central location in a structured way. Impact ■ A change in the service contract should be treated very carefully because multiple dependent service implementations could be impacted with a small change. ■ Governance is a challenge to manage the shared service contracts or common assets.

25.3 AIA Assets Extensibility Patterns