| Oracle® Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack 11g Release 1 (11.1.1.5.0) E17363-03 |
|
 Previous |
 Next |
| Oracle® Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack 11g Release 1 (11.1.1.5.0) E17363-03 |
|
Previous |
Next |
This chapter introduces Enterprise Business Services (EBS) and explains why EBS are needed to facilitate an integration. The chapter then discusses the types of EBS as well as the types of operations that can exist for these services. Finally, it provides a high-level overview of the tasks involved in the creation of enterprise business services.
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.
EBS are the foundation blocks in the Oracle Application Integration Architecture (AIA). EBS represent the application or implementation-independent web service definition for performing a business task. The architecture facilitates distributed processing using 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 that are applicable for each operation of a service.
An EBS is self-contained; that is, it can be used independent of any other services. In addition, it can also be used within another EBS. Because EBSs are business-level interfaces, they are standard service definitions that can be implemented by the applications that want to participate in the integration. 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 EBS has a well-defined interface described in XML. This interface description is composed of all details required for a client to independently invoke the service.
These services expose coarse-grained, message-driven interfaces for the purpose of exchanging data between applications, both synchronously and asynchronously. The request-specific and response-specific payload for each of the services is defined as an Enterprise Business Message (EBM). The EBM typically contains one or several instances of a single Enterprise Business Object (EBO), which forms the crux of the message, the action to be performed, and the metadata about the message specified in the message header section.
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 that are delivered by AIA. Any back-end implementations that can support the interface standards defined by an EBS can automatically be considered as 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 Verb associated with the operation.
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 of a payload. 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 by the operation. The concept of a verb was originally introduced by the Open Applications Group Integration Specification (OAGIS) in their business object document (BOD) definitions and has been adopted with some modifications in the EBO definition.
Strictly speaking, the significance of a verb to identify the action to be performed by an operation is not applicable in a service-oriented web services environment because the operation definition of a web service assumes this responsibility. However, not all integrations are using web services, and message-oriented integration scenarios still exist that may require the processing action to be identified within the message.
Verbs are also critical to define the semantics of the operation to be performed and to 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.
All of the standard activities that need to be performed using an EBO are brought together under an entity service. 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.
The standard activities in an entity-based EBS are:
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 of the activities uses the relevant EBM that represents the activity-specific view of the EBO as input and output.
Entity services expose operations that act on a specific EBO.
Entity services have the following characteristics:
Each of the business object entities has a corresponding EBS; all of the actions that can be performed on this object are exposed as service operations and are part of this EBS.
The entity operations consist of standard Create, Read, Update, and Delete (CRUD) operations that are similar across services as well as 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 the request to the appropriate application-specific Application Business Connector Service (ABCS) containing the actual implementation.
Figure 3-1 illustrates the EBS logical components and EBS physical implementation of entity services.
All of the business activities that need to act upon a particular business object to fulfill a specific business process are brought together under a process service. 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 Person EBS.
These interfaces are described using an implementation-agnostic approach. For the interface to be application-independent, the EBS expects an EBM to be passed as the input. In cases in which the EBS is expected to return a response, it sends a relevant EBM as the response. Hence, these interfaces are participating-application agnostic.
Process services expose operations related to an enterprise business process.
Process services have the following characteristics:
Each EBF has a corresponding EBS; all of the actions that can be performed on this flow are exposed as service operations and are part of this EBS.
Process services are implemented as Mediator routing services.
Process services receive and return messages in the form of EBMs.
Operations exposed on the EBS initiate cross-functional Enterprise Business Flows (EBFs) that coordinate complex long-lived flows that span 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 Entity Services, a Process Service can act on more than one EBO.
Figure 3-2 illustrates the EBS logical components for process services.
Figure 3-3 illustrates the EBS physical implementation of process services.
The EBS architecture enables:
Reuse of the available assets.
Substitution of one service provider with another without any impact on the client.
Content-based selection of the service provider.
The EBS is a web service. Like any other web service, the interface definitions for the EBS are defined in Web Service Definition Language (WSDL). The list of EBS-specific business activities (service operations), the input and output arguments for each of these service operations (input and output messages) are specified in the WSDL. As 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?".
AIA enables you to decouple the requester's 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 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.
This architecture enables cross-application business processes to use these EBS without regard to which application vendor is actually providing the implementation or which of the multiple deployments that might exist is responsible for processing the request and providing the response.
To achieve the loose coupling, some aspects of the service interactions must be tightly coupled between the requester and the service provider. 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 either the name of the EBS, the service operation, or the structure of the data formats will certainly impact 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 as well as the deployment that is 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.
Figure 3-4 and Figure 3-5 show how EBS enables the loose coupling of requesters with the actual 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.
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 process of integrating applications from multiple vendors. Business processes always use the services of the EBS.
For more information, see Section 3.1, "Introduction to EBS".
EBSs have application-independent interfaces. They are used by BPEL processes to interact with different applications. This helps cross-application processes to be application-independent. The EBM containing the EBO is the payload of the EBS and contains business-specific messages.
Within a cross-application business process, the EBO is used as the structure that holds the in-memory representation of the message that is sent back and forth between applications.
The process flow diagram shown in Figure 3-6 illustrates how a business process is initiated by a request coming from a participating application.
Figure 3-7 is a sequence diagram that shows the occurrence of events that lead to a successful initiation of a BPEL process.
This diagram illustrates how to keep the BPEL processes application-independent.
For the BPEL processes to remain application-independent, they should not contain any steps that are relevant to any one 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. Every action that can be done on an EBO is accomplished by defining and implementing a corresponding service operation within the EBS. The EBS is a very lightweight service. It is implemented as a Mediator routing service. Every service operation must have its own set of routing rules.
Example 3-1 shows the interface definition for each of the actions 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 as well as 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 to be delivered by Oracle 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.
Steps 5 and 6 occur only in the case of an integration scenario that uses the request-reply pattern. The activity diagram shown in Figure 3-8 illustrates the steps that are performed by an EBS:
For example, clients that want to invoke the Query operation on Customer Party should invoke the Query Customer Party operation of Customer Party EBS service.
Business requirements drive the need for the use of different message exchange patterns. This section defines the various message exchange patterns that can be implemented for various operations of EBSs.
A synchronous operation is one that waits for a response before continuing on. This forces operations to occur in a serial order. People often say that an operation blocks or waits for a response. Synchronous operations open a communication channel between the parties, make the request, and leave the channel open until the response occurs. This method is effective unless large numbers of channels are being left open for long periods of time. In this case, asynchronous operations may be more appropriate. Also, the synchronous pattern may not be necessary or appropriate if the end user does not need an immediate response.
An asynchronous operation is one that does not wait for a response before continuing. This allows operations to occur in parallel. Thus, the operation does not block or wait for the response. Asynchronous operations open a communication channel between the parties, make the request, and close the channel before the response occurs. Message correlation is used to relate the inbound message to the outbound message. This method is effective when large numbers of transactions occur that could take long periods of time to process. In the case in which the operations are short or need to run in serial, synchronous operations may be more appropriate. The asynchronous pattern is effective if the end user does not need immediate feedback.
The EBS is modeled to have multiple operations. Each operation leads to the execution of the EBS for a particular business scenario requirement and is granular in nature. Each operation can be modeled to have the following interaction style or message exchange pattern:
Synchronous request - response
Fire-and-forget
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 EBS operation pattern is synchronous in nature. The 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. After sending the request message, the requester waits until the service provider responds with a message. 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 in nature. This is an event that leads to a request message being 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 even in the case of an error. In the Order EBS WSDL, the one-way operation meant for request is defined in the portType having all the operations, which are either request-response or request only.
In the case of a fire-and-forget pattern, once the request is made and presented to the provider, it cannot be re-presented. In case of any error in the provider service, it has to be handled locally. This includes either retrying or terminating. In case the error cannot be handled locally, then compensation must be initiated, if required.
In Figure 3-9, the usage of the Order EBS depicts a fire-and-forget scenario. The Order EBS has two operations-Process Order Request and Update Order Request. Both of these operations are in a fire-and-forget pattern using the 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 necessitates the invoker to make one-way calls. This could be a request-only 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 template WSDLs provided.
A request-delayed response EBS operation pattern is asynchronous in nature. In this situation, 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 would have a pair of operations-one for sending the request and another for receiving the response. Both of the operations are independent and atomic. A correlation mechanism is used to establish 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 is sent with fault information populated. In the Customer EBS WSDL, the one-way operation meant for request is defined in the portType having all the operations, which are either request-response or request-only. The one-way operation meant for response is defined in the portType having all the operations, which are Response.
In the diagram, 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 modeled as one-way calls in the EBS WSDL.
This pattern allows for more flexibility in error handling. In case of an error, a suitable response can be sent to the requester service and the request re-presented or resubmitted to the provider after error correction. In some situations, an error in the provider service can be handled locally too, similar to the fire-and-forget pattern. The methodology to be followed is dictated by the business use case scenario. Figure 3–10 illustrates a one-way request and one-way response scenario.
To increase the reliability of message delivery, a need exists to resort to 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 async 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 template WSDLs provided.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|