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 alwaysusing 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 good news is that SOA 11g provides ways to fully de-couple services at design time. AIA advocates alwaysusing 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 fact that references between SOA composites actually consist of two parts: an abstract wsdl (design time) and a concrete wsdl (runtime):
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" ui:wsdlLocation="oramds:/apps/AIAMetaData/AIAComponents/EnterpriseBusiness
ServiceLibrary/Core/EBO/ SalesOrder/V2/SalesOrderEBS.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/EnterpriseServices/Core/ SalesOrder/V2#wsdl.interface(SalesOrderEBS)"/>
<binding.ws port="http://xmlns.oracle.com/EnterpriseServices/Core/SalesOrder/V2#wsdl.
endpoint(AIADemoProcessSalesOrderOrchestrationEBS/SalesOrderEBS_pt)"
location="http://aia11g.us.oracle.com:8001/soa-infra/services/default/
AIADemoProcessSalesOrderOrchestrationEBS/AIADemoProcessSalesOrder
OrchestrationEBS_2?WSDL"/>
</reference>
ServiceLibrary/Core/EBO/ SalesOrder/V2/SalesOrderEBS.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/EnterpriseServices/Core/ SalesOrder/V2#wsdl.interface(SalesOrderEBS)"/>
<binding.ws port="http://xmlns.oracle.com/EnterpriseServices/Core/SalesOrder/V2#wsdl.
endpoint(AIADemoProcessSalesOrderOrchestrationEBS/SalesOrderEBS_pt)"
location="http://aia11g.us.oracle.com:8001/soa-infra/services/default/
AIADemoProcessSalesOrderOrchestrationEBS/AIADemoProcessSalesOrder
OrchestrationEBS_2?WSDL"/>
</reference>
Note that ui:wsdlLocation stores the url to the abstract WSDL referenced at design time & deployment time. At runtime the binding.ws 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:
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:
- Create the ABCS composite using AIA Service Constructor while providing concrete WSDLs for references
- Upload abstract WSDLs (the newly generated WSDL of the ABCS and any other abstract WSDL that are referenced) to MDS
- Change all URLs in composite.xml and
.componentType files according to the sample above - Delete the generated abstract WSDL from the ABCS project
- Deploy the ABCS composite
This procedure will ensure that you do not encounter the issue of invalid composites after a server restart.
0 comments:
Post a Comment