Adapters Inside ABCS Composite OR as Separate Composite AIA Governance

Best Practices for Designing and Building End-to-End Integration Flows 27-7 the source mode and provide this binding information - the values for element binding.ws. For details about how to populate the binding.ws.port and binding.ws.location elements of your composite, refer to Section 13.1.7.1, Populating the binding.ws Element in the composite.xml .

27.1.7 Adapters Inside ABCS Composite OR as Separate Composite

The most common and recommended approach to migrate an existing application is to migrate it 1-on-1. This makes every component in the old application an SCA composite. The next step is to use the benefits of SCA; combine multiple SCA composites into a single composite. But do you always gain an advantage by combining composites together? An architectural decision should be made on how you build the SCA. With SOASCA it is all about re-usability. Think about this - are you designing your SCA based on the business flow or are you designing our SCA from technical point of view? The answer lies in finding the correct balance. You might want to design a service once and reuse it many times. From that point of view you would build small SCAs. But you could also choose large SCAs with multiple services that are exposed to the outside world. In that case, since the SCA is relatively large, it increases the maintainability. What you want is to define and design services and create composites that reference these services.As a result the service is designed once and reused many times. Going back to the question of whether the adapters should be inside the ABCS composite or should be developed as a separate composite, as a best practice, AIA recommends that you put adapters that are interfaced with ABCS in a different composite. as shown in Figure 27–2 . This is also the preferred way when the same transport adapter service could be used with multiple ABCS. Figure 27–2 Example of Adapters Interfaced with ABCS in a Different Composite However, if no such reusability is foreseen, then there is nothing wrong in using the alternative design where an ABCS and a Transport Adapter service can be in the same composite as shown in Figure 27–3 . 27-8 Developers Guide for Oracle Application Integration Architecture Foundation Pack Figure 27–3 Example of ABCS and Transport Adapter Service in the Same Composite

27.1.8 AIA Governance

Once developed, built and deployed, AIA artifacts must be capable of being governed. To allow for the governance of shared artifacts such as EBOs, EBS WSDLs, ABM schemas, ABCS WSDLS, DVMs, and XREFs, AIA recommends designing and implementing these artifacts independent of the services capabilities that use them. They are not to be treated as service artifacts and should be managed and persisted in a central location. As mentioned in earlier sections, AIA uses MDS to persist these artifacts. Annotations are injected during the development phase in the composite XML file, apart from annotations in the WSDL file. The annotations in composite files provide detailed information about: ■ AIA artifacts and their relationship to other AIA artifacts ■ Composite-level descriptor properties, that are used to configure the component at deployment and run time. AIA Architecture categorizes SOA composites as adapter services, requester services, provider services, and so on. The meta information of these AIA services is used in maintaining OER assets of AIA asset types and linking them to OER assets with native asset types; this is accomplished with the help of the AIA Harvester which harvests the SOA Composites. In line with SOA modeling and development practices, these composites are expected to be harvested multiple times during the development cycle from conception till deployment to production environment. AIA Harvester is built on top of the Oracle Enterprise Repository Harvester Extension Framework. It introspects SOA artifacts and publishes their ensuing metadata into the Project Lifecycle Workbench back end or Oracle Enterprise Repository optional, or both, to aid governance and downstream automation. The best practice for using the AIA Harvester tool is to harvest to both Lifecycle DB and OER. The AIA Harvester then parses the AIA service artifacts and captures metadata into the AIA Project Lifecycle Workbench database and the Oracle Enterprise Repository. The system uses this information to generate deployment plans.

27.1.9 Using AIA Service Constructor