Provide Provision for Throttling Capability Artifacts Centralization Separation of Concerns

Best Practices for Designing and Building End-to-End Integration Flows 27-3 Even though this duration is subject to change based on your company policies, attempts should be made to do the purging at the earliest time. Purging must be preceded by archiving of the instance data. For more information, see in Oracle Fusion Middleware Administrators Guide for Oracle SOA Suite.

27.1.3 Syntactic Functional Validation of XML Messages

This section discusses: ■ Section 27.1.3.1, Syntactic Validation ■ Section 27.1.3.2, Data Functional Validation

27.1.3.1 Syntactic Validation

With document style, a web service endpoint can use the capabilities of a validating parser and the run time to perform syntactic validation on business documents against their schema definitions. A schema specifies the data shape of the payload that could be sent to the web service operation. When a SOAP message is received by the web-services handler, the schema pertaining to the operation being called is used to validate the content of the SOAP message. Because this validation has a performance impact, it should be used judiciously in a production environment. AIA recommends enabling the schema validation only for the service-receiving message from a requester outside its boundary. Even though the requester could be an internal application, the syntactic validation is normally applied at run time only for messages coming from an external source. We highly recommend that you turn off schema validation for the intermediary services residing in AIA layer. In a development environment, we highly recommend that you turn on schema validation for all services during certain testing phases to ensure that messages produced by services are syntactically valid. For more information about how to enable schema validation, see Oracle Fusion Middleware Developers Guide for Oracle SOA Suite.

27.1.3.2 Data Functional Validation

AIA highly recommends that the validation be done by the service provider. It could be done either by the provider ABCS or by the application itself.

27.1.4 Provide Provision for Throttling Capability

The implementation of cross-functional business processes often requires integrating endpoint systems having divergent nonfunctional characteristics such as availability and concurrent processing capability. Occasionally, the endpoints become unavailable due to planned or unplanned outages and many systems may not be able to handle large volumes of concurrent messages. Overwhelming these systems with a high-volume of requests may result in the failure of target endpoints, which in turn has a cascading impact on the overall integration. AIA recommends implementing store and forward capability using queues in most of the situations while interacting either with the requester or provider application. This gives opportunities for customers to implement throttling that helps impose a limit on the rate at which message requests are handed over to a specific endpoint. 27-4 Developers Guide for Oracle Application Integration Architecture Foundation Pack For more information, see Section 25.1, AIA Message Processing Patterns .

27.1.5 Artifacts Centralization

To facilitate the governance of shared artifacts such as Enterprise Business Objects, Enterprise Business Service WSDLs, Application Business Message Schemas, ABCS WSDLs, Domain Value Maps, and Cross-Reference Meta data, AIA highly recommends designing and implementing these artifacts independently from the service capabilities that use them. AIA strongly discourages the management and persistence of these artifacts as part of individual services. AIAs programming model recommends the use of MDS to persist these artifacts. For more information about how MDS is used for centralization of these assets, see Section 20.1.3.4, Using MDS in AIA .

27.1.6 Separation of Concerns

Separation of concerns is a core principle of SOA. It helps you introduce loose coupling in the integration flow where it is required. However, it must be applied not only at the architectural level, but at the implementation level as well. Managing dependencies between services at development and run time is a challenging task when developers implement requester and provider ABC services. One of the approaches is to make them de-coupled. Using this approach, the cross-dependencies in the code that handle each concern of the service can be minimized. You may see error messages indicating invalid SOA composites after a server restart. This is caused by referring to concrete WSDLs where abstract WSDLs should have been used. You will 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. The problem starts when the server is restarted because there is no guarantee that the composites will be activated in the right order to resolve any dependencies. If service X is activated before composite Y, the reference cannot be resolved because Y is still down, so X remains in status Invalid. You can begin with separating the interface from implementation. ■ Do not use the concrete WSDLs directly in your consuming artifacts. If the Service Provider not as in ProviderABCS changes, then you must redeploy the consumer. ■ Do not reference the deployed concrete WSDL of a Service Provider. If Provider is unavailable, then consumer cannot be compiled or be deployed. For example, assume you are building a Provider ABCS that consumes an adapter service, You have directly referenced the concrete WSDL of the adapter service and developed your consuming Provider ABCS. Now, when the adapter service is not available or not deployed as yet, when you are compiling or deploying your Provider ABCS, you will hit a road block. ■ Introduce a common directory of abstract WSDLs of your services and store these abstract WSDL s on a centrally accessible endpoint. SOA 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 services interface, which is all that is needed at design time. The Best Practices for Designing and Building End-to-End Integration Flows 27-5 concrete WSDLs are only needed later at execution time to provide the binding details, that is the information on how the deployed composite can be invoked. Figure 27–1 illustrates that references between SOA composites actually consist of two parts: an abstract WSDL design time and a concrete WSDL run time. Figure 27–1 References Between SOA Composites AIA uses Metadata Services MDS for storing each services abstract WSDL. Thus MDS becomes the source of truth for all service interfaces and the composites should not have any redundant copies.

27.1.6.1 Using MDS as the Central Storage for Abstract WSDLs, and Other Shared Artifacts

SOA Suite 11g has introduced a central repository, Metadata Service MDS, that backs your application and hence your composites at design time and run time. MDS is like a version management system, where you can store and use the shared common artifacts at design and run time. AIA leverages the MDS repository to store common design time artifacts that are shared with all developers. AIA has introduced a common directory of abstract wsdls in the MDS, which is a centrally accessible endpoint. The artifacts that are stored in the MDS include: ■ Schemas - EBO schemas and ABM schemas, ■ WSDLs - Abstract WSDLs of EBS, ABCS, Adapter Services, CBPs and EBFs ■ DVMs and XREFs. AIAComponents presents the various schemas and WSDLs referred to by various services. The structure is shown in Table 27–1 : Table 27–1 Structure of AIA Components Location Artifacts ApplicationConnectorServic eLibrary Abstract WSDLs of various Application Business Connector Services ABCSs 27-6 Developers Guide for Oracle Application Integration Architecture Foundation Pack For more details on how to upload these artifacts into MDS, and how to update them in the MDS, see Section 20.1.3.4, Using MDS in AIA The abstract WSDLs of all AIA services are stored in the MDS. You build your consumer AIA service composite application using the abstract WSDL of a referenced service. So where is your MDS located, and how does an application know how to reference it? You configure your developer environment to point to the MDS. The configuration file is available in application_home.adfMETA-INFadf-config.xml and by default it points to your local - JDeveloper file system based MDS. You must configure it to point to the MDS on your managed SOA server. For details, see Section 20.1.1, How to Set Up JDeveloper for AIA Development In a composite, a referenced service is defined by its abstract WSDL. As an example, we will use the scenario which is described earlier in this section. You will build a Provider ABCS that consumes an adapter service, by referencing the abstract WSDL of the adapter service. What does it bring to the table? First, there is no dependency on the referenced services during the deployment of the composites. Hence there is no dependency on the order of deployment for the composites. A referenced service does not need to be deployed first, in order for it to be referenced by another service. This also resolves the cases where there are cyclic references involved among the services. After a composite has been designed, you must perform a few tasks. Since you have used an abstract WSDL to reference an external service, the run-time bindings are not generated in the composite. For the referenced service you must open the composite in ApplicationObjectLibrary WSDLs of services exposed by applications and schemas of application business objects B2BObjectLibrary Business-to-business B2B schemas B2BServiceLibrary Abstract WSDLs of various B2B Connector Services B2BCSs and B2B Infrastructure Services BusinessProcessServiceLibra ry Abstract WSDLs of Composite Business Processes CBPs and Enterprise Business Flows EBFs EnterpriseBusinessServiceLi brary Abstract WSDLs of Enterprise Business Services EBSs EnterpriseObjectLibrary Schemas of the Oracle AIA Canonical Model InfrastructureServiceLibrary Abstract WSDLs of infrastructure services Transformations XSLs shared among various services UtilityArtifacts Utility schemas and WSDLs config AIAConfigurationProperties.xml and AIAEHNotification.xml dvm Domain Value Maps faultPolicies Default policies applicable to all the services xref Metadata for Cross References Table 27–1 Cont. Structure of AIA Components Location Artifacts 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