|Oracle® Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack
11g Release 1 (184.108.40.206)
Part Number E17363-07
|PDF · Mobi · ePub|
This chapter introduces Enterprise Business Services (EBS) and explains why an EBS is needed to facilitate an integration. The chapter then discusses EBS types and EBS operations. Finally, it provides a high-level overview of the tasks involved in the EBS creation.
This chapter includes the following sections:
For more information about EBS, see " Designing and Developing Enterprise Business Services" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
EBSs are the foundation blocks in the Oracle Application Integration Architecture (AIA). An EBS represents the application or implementation-independent web service definition for performing a task. The architecture facilitates distributed processing using an EBS.
An EBS is a service interface definition, currently manifested as an abstract Web Service Definition Language (WSDL) document, which defines the operations, message exchange pattern, and payload applicable for each operation of a service.
An EBS is self-contained; that is, it can be used independently of any other services. In addition, it can also be used within another EBS. EBSs are business-level interfaces. They are standard service definitions that applications participating in the integration can implement. EBSs are generally coarse-grained and typically perform a specific business activity such as creating an account in a billing system or getting the balance details for an account from a billing system. Each activity in an EBS has a well-defined interface described in XML. This interface description includes all details required for a client to independently invoke the service.
These services expose coarse-grained, message-driven interfaces for exchanging data between applications, both synchronously and asynchronously. The request-specific and response-specific payload for each service is defined as an Enterprise Business Message (EBM). The EBM typically contains one or more instances of a single Enterprise Business Object (EBO), the action to be performed, and the metadata in the message header.
For more information, see Section 2.2.1, "EBM Architecture".
EBS components do not presuppose a specific back-end implementation of that service. They simply provide an integration layer for your choice of a back end. Regardless of the choice, you can still achieve the seamless interaction experience in the prebuilt integrations delivered by AIA. Any back-end implementations that support EBS interface standards are considered service providers.
For more information about EBS, see "Designing and Developing Enterprise Business Services" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
An operation is a unique action that has a specific payload and results in a clearly defined, repeatable outcome.
Each EBS contains multiple operations.
A standard set of operations is defined for all Entity services. Additionally, each Entity service may have one or more nonstandard operations.
Operations are categorized based on the Verb associated with the operation.
Every operation must have a Verb identified. The Verb helps to precisely define the scope, payload, and name of the operation.
An EBS may have synchronous and asynchronous versions of the same operation.
By default, the behavior of a service operation (synchronous or asynchronous) is predetermined by the associated Verb.
For more information, see Section 3.3, "Verbs".
AIA makes an explicit distinction between operations that can process a single instance of a payload versus operations that can process multiple instances. Distinct operations are provided for both cases. Only the standard operations have this distinction implemented.
Every operation has a Verb to identify the action to be performed. The Open Applications Group Integration Specification (OAGIS) originally introduced the concept of a verb in their business object document (BOD) definitions. The EBO definition adopted this concept with some modifications.
A web service does not use a Verb because its operation definition identifies the action it performs. However, not all integrations use web services, and message-oriented integration scenarios still exist that may require the processing action to be identified within the message.
Verbs define the semantics of operations and provide a consistent, unambiguous framework for naming operations and operation payloads.
For more information about verbs and how to use them, see "Constructing the ABCS " in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
AIA supports two categories of EBS, entity-based services and process-based services.
An entity service includes all standard activities that an EBO must perform. Hence, every EBO has a corresponding EBS, which has definitions for performing standard activities such as Create, Update, Delete, Query, and so on. Sample EBSs include Customer, Party, Item, Sales Order, and Installed Asset.
Create: To create an object instance
Update: To update an object instance with only the changes that occurred
Delete: To delete an object instance
Query: To retrieve details about an object
Sync: To send a current snap shot
Each activity uses the EBM that represents the activity-specific view of the EBO as input and output.
Entity services expose operations that act on a specific EBO.
The corresponding EBS for a business object entity exposes all actions that can be performed on this object as service operations.
The entity operations consist of standard Create, Read, Update, and Delete (CRUD) operations, which are similar across services, and any specialized operations that are specific to the EBO.
Entity services are implemented as Mediator routing services.
Entity services receive and return messages in the form of EBMs.
Entity services leverage the context-based routing rules to delegate requests to the appropriate application-specific Application Business Connector Service (ABCS) containing the actual implementation.
Figure 3-1 illustrates the EBS logical components and the EBS physical implementation of entity services.
A process service includes all business activities acting upon a particular business object to fulfill a specific business process. For example, an EBS like OrderProcessOrchestration, Employee On Boarding might exist. The Employee On Boarding EBS might have operations such as Hire Employee, Terminate Employee, and so on that you might not find in the Person EBS.
EBM interfaces are implementation-agnostic. Because of this application-independence, an EBS both expects an EBM as input and returns an EBM as output.
Process services expose operations related to an enterprise business process.
The corresponding EBS for an Enterprise Business Flow (EBF) exposes all actions that can be performed on this flow as service operations.
Process services are implemented as Mediator routing services.
Process services receive and return messages in the form of EBMs.
Operations the EBS exposes initiate cross-functional EBFs that coordinate complex long-lived flows spanning multiple services.
These flows can interact only with EBS services. This way both the Process EBS and the related business flows are completely application-agnostic.
Unlike an Entity Service, a Process Service can act on multiple EBOs.
Figure 3-2 illustrates EBS logical components for process services.
Figure 3-3 illustrates the EBS physical implementation of process services.
The EBS architecture enables:
Reuse of available assets.
Substitution of one service provider with another without any impact on the client.
Content-based selection of the service provider.
An EBS is a web service, so EBS interfaces are defined in Web Service Definition Language (WSDL). WSDL specifies EBS-specific service operations (business activities) and input and output arguments (messages) for each service operation. As with any web service, an EBS can be implemented in 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.
Although you can build EBS activities such as Create or Update from the ground up using web services technology, AIA takes advantage of existing application functionality. Participating applications provide intermediary services in Application Business Connector Service (ABCS) format. The ABCS exposes application data and transaction-related business functions as services that an EBS can invoke.
The virtualization layer enables the following aspects of Oracle AIA:
The physical implementation of the Service Provider (also called the endpoint or target) must be abstracted and its location hidden so another service can potentially replace it.
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 must be replaced with no interruption or change to the consumers.
The virtual service may be composed of multiple physical services, 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).
The target service and the service consumer might support different transport protocols.
If complex, content-based validations against XML are required, then use Schematron 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?".
AIA enables you to decouple the requester's view of a service from the actual implementation. This architectural flexibility allows service provider interchangeability. The requester is unaware and the EBS needs no alteration if the service provider is changed.
For example, the delivered integration between a CRM system and a financials system may use the service of the Oracle E-Business suite. At implementation time, you may want to substitute this service with one from another provider, such as PeopleSoft Financials. Substituting the service provider has no impact on the requester or the client.
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.
Routing rules can tell the EBS how to delegate a request to the right service provider and application instance. The services that invoke the EBS might have request delegation knowledge. In this scenario, the services might supply the information in the EBM before invoking the EBS.
For example, you may have two billing systems, one for Northern American customers and another for all others. The EBS evaluates this rule and deciphers the actual implementation necessary for processing a specific message. The clients and service requesters are unaware of the implementers. Similarly, the implementers are unaware of the client applications that made the request.
The architecture allows an entire message (containing all instances) to be sent to only one service provider. Different messages can go to different providers, but instances within a message cannot be divided among two or more providers.
In a service-oriented architecture (SOA), there is no way to loosely couple a service entirely between systems. You must choose what aspects should be loosely coupled and what can be tightly coupled.
Oracle AIA places importance on the client being unaware of who the service provider is, the language, the platform in which the services are implemented, and finally, the communication protocol. So these aspects are totally decoupled. Making a change to one of these aspects has no impact on the client.
However, at design time, the requester explicitly specifies the name of the EBS operation, which in turn is responsible for identifying the actual service provider. The data formats are also specified at design time, and regardless of the actual service providers, the data formats needed to pass the content do not change. So changing the name of the EBS, the service operation, or the structure of the data formats impacts the client. As mentioned in the previous sections, an EBM is passed as a request, and another EBM is received as a response.
The purpose of the EBS is:
To receive the request from the calling application.
To identify the implementation and the deployment responsible for providing the requested service.
To delegate the requested task to the right implementation.
To receive the response and return the EBM to the calling application.
For more information about EBSs, see "Designing and Developing Enterprise Business Services" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
Business processes define and orchestrate a series of discrete steps to complete an integration task, such as synchronizing a product across multiple applications or submitting an order from CRM to the back office for fulfillment.
Business processes are defined independently of the underlying applications, simplifying the integration of applications from multiple vendors. Business processes always use an EBS.
For more information, see Section 3.1, "Introduction to EBS".
EBSs have application-independent interfaces. BPEL processes use them to interact with different applications. The payload of the EBS is the EBM. The EBM contains the EBO. Within a cross-application business process, the EBO holds the in-memory representation of the message that is sent back and forth between applications.
Figure 3-6 illustrates how a request coming from a participating application initiates a business process.
Figure 3-7 is a sequence diagram of events leading to a successful initiation of a BPEL process.
This diagram illustrates how to keep the BPEL processes application-independent.
An application-independent BPEL process contains no steps specific to any particular participating application.
For more information about EBF, see "Designing and Constructing Enterprise Business Flows" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
Every EBO must have an EBS. The EBS defines and implements corresponding services for every action that can be done on the EBO. The EBS is a very lightweight Meidator routing service. Every service operation must have its own set of routing rules.
Example 3-1 shows the interface definition for each action that can be carried out on the Invoice EBO.
Example 3-1 Interface Definition
<portType name="SalesOrderInterface"> <portType name="SalesOrderInterface"> <documentation> <svcdoc:Interface> <svcdoc:Description> This interface contains operations that can act upon the Sales Order object </svcdoc:Description> <svcdoc:DisplayName>Sales Order Interface</svcdoc:DisplayName> <svcdoc:Status>Active</svcdoc:Status> </svcdoc:Interface> </documentation> <operation name="QuerySalesOrder"> <documentation> <svcdoc:Operation> <svcdoc:Description> This operation is used to query an Sales Order object<=>/svcdoc:Description> <svcdoc:MEP>SYNC_REQ_RESPONSE</svcdoc:MEP> <svcdoc:DisplayName>Query Sales Order</svcdoc:DisplayName> <svcdoc:Status>Active</svcdoc:Status> <svcdoc:Scope>Public</svcdoc:Scope> </svcdoc:Operation> </documentation> <input message="sordsvc:QuerySalesOrderRequestMsg"/> <output message="sordsvc:QuerySalesOrderResponseMsg"/> </operation> <operation name="CreateSalesOrder"> <documentation> <svcdoc:Operation> <svcdoc:Description> This operation is used to Create a Sales Order object<=/svcdoc:Description> <svcdoc:MEP>ASYNC_REQ_RESPONSE</svcdoc:MEP> <svcdoc:DisplayName>Create Sales Order</svcdoc:DisplayName> <svcdoc:Status>Active</svcdoc:Status> <svcdoc:Scope>Public</svcdoc:Scope> <svcdoc:CallbackService>SalesOrderEBS</svcdoc:CallbackService> <svcdoc:CallbackInterface>UpdateSalesOrderEBM</svcdoc:Callback=>Interface> <svcdoc:CallbackOperation>UpdateSalesOrder</svcdoc:CallbackOperation> </svcdoc:Operation> </documentation> <input message="sordsvc:CreateSalesOrderMsg"/> </operation>
The EBS flow includes the following steps:
The EBS passes the EBM to the routing rules.
The routing rules evaluator applies the relevant rules to the EBM to decipher the ABCS it should invoke and the end-point details.
In scenarios in which multiple instances for a single application occur, the EBS enriches the EBM header section of the document with details about the service provider and the end-point location.
The prebuilt integrations Oracle provides, leverage the AIA Configuration Properties file to identify the end-point location.
The EBS routes the message to the relevant ABCS.
The EBS receives the response from the service provider.
The EBS returns the response to the calling application.
For example, invoking the Query Customer Party operation of the Customer Party EBS invokes the Query operation of the Customer Party EBO.
Business requirements drive the need for different message exchange patterns. This section defines message exchange patterns for various EBS operations.
A synchronous operation waits for a response before continuing. This forces operations to occur in a serial order. Synchronous operations open a communication channel between the parties, make the request, and leave the channel open until the response occurs. This is effective unless large numbers of channels are left open for long periods. Also, the synchronous pattern may not be necessary or appropriate if the end user does not need an immediate response. In these cases, asynchronous operations may be more appropriate.
An asynchronous operation does not wait for a response before continuing. This allows operations to occur in parallel. Thus, the operation does not block or wait for a response. Asynchronous operations open a communication channel between the parties, make the request, and close the channel before the response occurs. Message correlation relates the inbound message to the outbound message. This is effective when large numbers of transactions take long periods to process. The asynchronous pattern is effective if the end user does not need immediate feedback. If the operations are short or must run in serial, synchronous operations may be more appropriate.
The EBS is designed to have multiple operations. Each operation executes the EBS for a particular business scenario requirement and is granular. Each operation can have the following interaction style or message exchange pattern:
Synchronous request - response
Fire-and-forget - no response
Asynchronous request - delayed response
For more information about design patterns, see "Working with AIA Design Patterns" and "Establishing Resource Connectivity" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
A synchronous request-response has two participants.
The requester sends a request and waits for a response message. The service provider receives the request message and responds with either a response or a fault. Both the request and the response messages are independent.
The operations in the portType have input, output, and fault. Example 3-2 is from the SalesOrderEBS.wsdl and illustrates a synchronous request-response operation.
Example 3-2 Synchronous Request/Response Operation
<!-- operation support for read/query --> <operation name="QuerySalesOrder"> <documentation> <svcdoc:Operation> <svcdoc:Description> This operation is used to query a SalesOrder EBO </svcdoc:Description> <svcdoc:MEP>SYNC_REQ_RESPONSE</svcdoc:MEP> <svcdoc:DisplayName>QuerySalesOrder</svcdoc:DisplayName> <svcdoc:LifecycleStatus>Active</svcdoc:LifecycleStatus> <svcdoc:Scope>Public</svcdoc:Scope> </svcdoc:Operation> </documentation> <input message="ebs:QuerySalesOrderReqMsg"/> <output message="ebs:QuerySalesOrderRespMsg"/> <fault name="fault" message="ebs:FaultMsg"/> </operation>
A fire-and-forget EBS operation pattern is asynchronous. TA request message is posted to an endpoint or placed in a channel/queue/topic. This pattern is also characterized as a one-way call.
In a fire-and-forget pattern, the requesting service invokes a one-way operation in an EBS. The EBS invokes the providing service. No concept of a response exists, not even an error. In the Order EBS WSDL, the portType defines the one-way request-only operation.
In a fire-and-forget pattern, a request presented to the provider cannot be re-presented. Errors in the provider service must be handled locally. This includes either retrying or terminating. In case the error cannot be handled locally, then compensation must be initiated, if required.
Figure 3-9, depicts the Order EBS fire-and-forget scenario. The Order EBS has two operations: Process Order Request and Update Order Request. Both of these fire-and-forget operations use one-way calls in the EBS WSDLs.
Example 3-3 is a sample from SalesOrderEBS.wsdl for a request-only operation.
Example 3-3 Request-Only Operation
<!-- operation support for creation --> <operation name="CreateSalesOrder"> <documentation> <svcdoc:Operation> <svcdoc:Description> This operation is used to create a SalesOrder EBO. </svcdoc:Description> <svcdoc:MEP>REQUEST_ONLY</svcdoc:MEP> <svcdoc:DisplayName>CreateSalesOrder</svcdoc:DisplayName> <svcdoc:LifecycleStatus>Active</svcdoc:LifecycleStatus> <svcdoc:Scope>Public</svcdoc:Scope> </svcdoc:Operation> </documentation> <input message="ebs:CreateSalesOrderReqMsg"/> </operation>
The operations in the portType have input only. This contract requires the invoker to make one-way calls. For Entity EBS, the WSDLs are part of the Foundation Pack Enterprise Service Library. For Process EBS, the WSDLs are hand-coded based on provided template WSDLs.
A request-delayed response EBS operation pattern is asynchronous. The requester sends the request message and sets up a callback for a response. The requester does not wait for the response after sending the request message. A separate thread listens for a response message. When the response message arrives, the response thread invokes the appropriate callback and processes the response. The EBS has a pair of operations-one for sending the request and another for receiving the response. Both operations are independent and atomic. A correlation mechanism establishes the caller's context.
In a request-delayed response pattern, the requesting service invokes a one-way request operation in an EBS. The requesting service waits for the response. The EBS invokes the providing service. The providing service, after ensuring that the request is serviced, invokes the response EBS. The response EBS pushes the response to the waiting requesting service. If an error occurs in the providing service, the response includes fault information. In the Customer EBS WSDL, the portType defines the one-way request and response operations. The one-way operation meant for response is defined in the portType having all the operations, which are Response.
In Figure 3-10, the usage of the Create Customer EBS Request depicts a one-way request and Create Customer EBS Response depicts a one-way response. The Customer EBS is based on the Customer EBS portType and has the operation Create Customer Request. The Customer EBS Response is based on the Customer EBS Response portType and has the operation Create Customer Response. Both are one-way calls in the EBS WSDL.
This pattern allows more flexibility in error handling. In case of an error, the provider sends a response to the requester service, which re-presents or resubmits the request. In some situations, the provider service can handle errors locally too, similar to the fire-and-forget pattern. The business use case scenario dictates the methodology. Figure 3–10 illustrates a one-way request and one-way response scenario.
To increase the reliability of message delivery, use persistence at strategic asynchronous points.
For more information about guaranteed message delivery designs, see "Configuring Oracle AIA Processes for Error Handling and Trace Logging" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
Example 3-4 is a sample from SalesOrderEBS.wsdl for an asynchronous request-response operation.
Example 3-4 Asynchronous Request-Response Operation
<!-- operation support for creation response--> <operation name="CreateSalesOrderResponse"> <documentation> <svcdoc:Operation> <svcdoc:Description> This callback operation will be used to provide the Create Sales Order Response </svcdoc:Description> <svcdoc:MEP>ASYNC_REQ_RESPONSE</svcdoc:MEP> <svcdoc:DisplayName>CreateSalesOrderResponse</svcdoc:DisplayName> <svcdoc:LifecycleStatus>Active</svcdoc:LifecycleStatus> <svcdoc:Scope>Public</svcdoc:Scope> <svcdoc:InitiatorService>SalesOrderEBS</svcdoc:InitiatorService> <svcdoc:InitiatorInterface>CreateSalesOrderRequestEBM</svcdoc:InitiatorInterface> <svcdoc:InitiatorOperation>CreateSalesOrderRequest</svcdoc:InitiatorOperation> </svcdoc:Operation> </documentation> <input message="ebs:CreateSalesOrderRespMsg"/> </operation>
For Entity EBS, the WSDLs are part of the Foundation Pack Enterprise Service Library. For Process EBS, the WSDLs are hand-coded based on provided template WSDLs.