AIA 11g: Best Practices for Decoupling Services and Avoiding Invalid Composites at Server Startup

AIA is a design and development methodology for SOA and each integration flow consists of multiple composites to ensure proper decoupling according to SOA best practices. Therefore, almost always a SOA composite is calling another and there is apparently a chain of dependencies. Some people wonder why they are experiencing invalid SOA composites after a server restart. The quick answer: This is caused by referring to concrete WSDLs where abstracts WSDLs should have been used.

You would not see the problem at the first deployment of a new composite X when you reference the concrete WSDL of composite Y. Why? Composite Y is up and running at the time of the deployment of composite X. But the problem starts when the server is restarted. Because then there is no guarantee that the composites will be activated in the right order to resolve any dependencies. If you have bad luck, service X is activated before composite Y. As the reference cannot be resolved as Y is still down, X remains in status 'Invalid'. You might say that SOA 11g should take care of the right activation order, but thinking of circular dependencies makes it obvious that we need a better way to solve this.

The good news is that SOA 11g provides ways to fully de-couple services at design time. AIA advocates always using abstract WSDLs when composites refer to others. Note that abstract WSDLs fully describe a service's interface, that's all we need at design time. The concrete WSDLs are only needed later at execution time to provide the binding details, i.e. the information how the deployed composite can be invoked.

The following diagram illustrates the fact that references between SOA composites actually consist of two parts: an abstract wsdl (design time) and a concrete wsdl (runtime):


Click to view enlarged image

As the diagram indicates, AIA promotes 11g Metadata Services (MDS) for storing each service's abstract WSDL. By that, MDS becomes the source of truth for all service interfaces and the composites should not have any redundant copies.

So from an implementation point of view, the composite.xml files have references to both the abstract WSDLs and the concrete WSDLs. See this sample reference from a composite.xml (requester ABCS in this case) as an example for proper referencing the abstract WSDL in MDS (oramds protocol) and the concrete WSDL (http protocol to the SOA Infrastructure):

<reference name="AIADemoProcessSalesOrderOrchestrationEBS"
ServiceLibrary/Core/EBO/ SalesOrder/V2/SalesOrderEBS.wsdl

<interface.wsdl interface=" SalesOrder/V2#wsdl.interface(SalesOrderEBS)"/>

< port="





Note that ui:wsdlLocation stores the url to the abstract WSDL referenced at design time & deployment time. At runtime the location is used to determine the binding (i.e. the actual endpoint) from the concrete WSDL. Please make sure that all references in composite.xml and <Process_Name>.componentType files are following this structure. This will fully decouple your composites at design time and avoid any activation issues at server startup.

When you are leveraging AIA Service Constructor to create new ABCSs, it will help you assigning both the abstract and concrete WSDLs for the referenced AIA Error Handling composite through it's user interface. For other references (e.g. the called application services in a provider ABCS) you have to follow these steps to fully comply with the approach described above:

  1. Create the ABCS composite using AIA Service Constructor while providing concrete WSDLs for references

  2. Upload abstract WSDLs (the newly generated WSDL of the ABCS and any other abstract WSDL that are referenced) to MDS

  3. Change all URLs in composite.xml and .componentType files according to the sample above

  4. Delete the generated abstract WSDL from the ABCS project

  5. Deploy the ABCS composite

This procedure will ensure that you do not encounter the issue of invalid composites after a server restart.



i am getting error while working with AIA PIP 3.1 with JDE E1.

While running ItemInitialLoad process.I got the following error.

ORAMED-03302:[Exception in oneway execution]Unexpected exception in one-way operation "InitialLoadItemList" on reference "InitialLoadItemListJDEE1toAgileImpl".Possible Fix:Check whether the reference service is properly configured and running or look at exception for analyzing the reason or contact Oracle Support Services. Release ECO SDK Execution Failed: The Change Order Not found - ECO-IL-290003

Please rectify it if possible.
Waiting for your reply.
We are in critical stage,unable to solve the above error.

With Regards
Jyoti Nayak

Posted by Jyoti Nayak on October 21, 2011 at 09:59 AM PDT #

What about if you ensure that the WSDL stored in MDS is already concrete? E.g.

<reference name="AIADemoProcessSalesOrderOrchestrationEBS"
ServiceLibrary/Core/EBO/ SalesOrder/V2/SalesOrderEBS.wsdl">

<interface.wsdl interface=""/>

< port=""

ServiceLibrary/Core/EBO/ SalesOrder/V2/SalesOrderEBS.wsdl"/>

The advantages are:

1. When including this WSDL in another SOA composite than no binding warning will appear and as such no manual update of composite.xml is required.
2. The design time WSDL from MDS can immediately be communicated to third parties without manipulating to add the binding, SOA endpoint.

Posted by Sander on July 11, 2013 at 07:41 AM PDT #

there are a couple of issues with your proposal:
* It's a concious decision to separate design time and runtime artifacts, i.e. abstract and concrete wsdls. Design time artifacts are generic while runtime artifacts are highly specific to their particular deployment. It's not a good practise to mix both.
* concrete WSDLs would have to be tweaked for each environment to match the specifics of the environment such es host name and port
* You can't share MDS references externally since 3rd party consumers would not be able to use oramds references, so your 2nd point does not apply.


Posted by Gerhard Drasch on July 11, 2013 at 08:13 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

News, views and implementation best practices from the Oracle Application Integration Architecture team.


« December 2016