Substituting One Service Provider for Another

3-6 Concepts and Technologies Guide for Oracle Application Integration Architecture with any other web service, an EBS can be implemented using any language. The implementation takes an EBM as input and provides another EBM as output. Oracle AIA uses the Oracle SOA Suite Mediator to implement an EBS. Even though an EBS activity such as Create or Update can be built from the ground up using web services technology, AIA takes advantage of the existing functionality in the applications. The EBS acts as a virtual service to expose the actual implementation provided by the participating application in a format that is amenable to the EBS. The intermediary services provided by the participating applications in a format amenable to the EBS are called ABCSs. The ABCS acts as the glue connecting the EBS and the participating application that is exposing the business capability. The ABCS is responsible for exposing the data access, as well as the transaction-related business functions that are available in applications as services that an EBS can invoke. The ABCS approach does not preclude you from creating entirely new services for implementing the EBS. The virtualization layer enables the following aspects of Oracle AIA: ■ The physical implementation of the target service must be abstracted and its location must be hidden so that the target service Service Provider can eventually be replaced by some other service endpoint virtualization. ■ If the shapes of data and operations are different, data transformations and operation-to-operation mappings are needed. This is common when old systems in existing infrastructures need to be replaced with no interruption or change to the consumers. ■ The virtual service may be composed of more than one physical service, as in aggregation of services or rule-based routing. For example, a request from CA goes to the CA-Warehouse. ■ You may not want to expose all operations of the actual service to the external world partial service. ■ Target service might be supporting a different transport protocol than supported by the service consumer. For example, a header transformation must happen from JMS to SOAP. ■ If complex, content-based validations against XML are required, then Schematron should be used inside the mediator. For example, the order price must reflect the sum of prices of each order line. ■ If the service consumer expects an asynchronous message exchange pattern and the service provider allows only synchronous calls, the client application invokes a virtual or proxy service in AIA, it is an EBS representing the target services. For more information, see Section 1.8.4, What is an Application Business Connector Service? .

3.5.2 Substituting One Service Provider for Another

AIA enables you to decouple the requesters view of a service from the actual implementation. This approach increases the flexibility of the architecture by allowing the substitution of one service provider for another without the requester being aware of the change and without the need to alter the requester or EBS to abet the substitution. For example, the delivered integration between a CRM system and a financials system may leverage a service provided by the Oracle E-Business suite. At implementation time, you may want to substitute this service with one from another provider, such as Understanding Enterprise Business Services 3-7 PeopleSoft Financials. The substitution of the service provider has no impact on the requester or the client. This kind of decoupling is accomplished by having the requesters and service providers converse using a mediator. In AIA, the EBS publishes services to requesters. The requester binds to the EBS to access the service, with no direct interaction with the actual implementer of the service. Hence, to achieve the loose coupling between service consumer and the provider, the EBS takes the role of mediator. Routing rules can be definitionally specified to direct the EBS regarding how to delegate the request to the right service provider as well as to the right application instance. Situations might also occur in which the services that invoke the EBS might have knowledge of whom the requests need to be delegated to. In this scenario, the services might supply the information in the EBM prior to invoking the EBS. For example, you may have two billing system implementations-one dedicated to customers who reside in Northern America and the second dedicated to the customers residing in other parts of the world. The EBS evaluates this rule and deciphers the actual implementation that should be used for processing a specific message. Using this approach, the clients and service requesters are totally unaware of the actual implementers. Similarly, the underlying service implementers are oblivious to the client applications that made the request. Note that while the architecture allows for an entire message containing all instances to be sent to one service provider as opposed to another, it does not allow for a subset of the instances present in a message to go to one provider and the remaining instances to go to another provider.

3.5.3 Content-Based Selection of the Service Provider