38 Improving Service Performance with Split-Join
This chapter provides an overview of Split-Joins and illustrates static and dynamic Split-Join scenarios.
Oracle Service Bus's advanced mediation feature, called Split-Join, helps you improve service performance by concurrently processing individual messages in a request. This topic, which describes Split-Join, includes the following sections:
38.1 Introduction to Split-Join
Oracle Service Bus's Split-Join feature lets you split a service payload, such as an order, into individual messages for concurrent processing. Concurrent processing, as opposed to sequential processing, greatly improves service performance. Split-Join achieves this task by splitting an input message payload into sub messages (split), routing them concurrently to their destinations, and aggregating the responses into one overall return message (join). This process of payload splitting and response aggregation is called a Split-Join pattern.
Split-Joins are particularly useful for optimizing overall response times in scenarios where payloads delivered by faster systems are being directed to responding services on slower systems. Without Split-Join, individual messages in a payload are normally resolved in sequential order by the recipient, which can take a long time if the responding system is slow. (The overall response time is the sum of the individual response times for each message.) With Split-Join, multiple messages are processed simultaneously, which reduces burden on the responding system and greatly enhances response times. (The overall response time is roughly that of the longest individual message's response time plus some minor system overhead.)
There are two patterns supported by the Split-Join feature:
38.1.1 Static Split-Join
The static Split-Join branches from the main execution thread of an Oracle Service Bus message flow by splitting a payload into a fixed number of new branches according to the configuration of the Split-Join. At design time you determine the number and variety of services to be invoked.
38.1.1.1 Static Split-Join – Sample Scenario
A telco company might want to employ static Split-Join when processing a customer's order for a communications services package. In this case, the customer might sign up for DSL and voice services all at once. Rather than executing each request in the payload separately in order, the telco can execute the messages in parallel using a callout from the Oracle Service Bus message flow to a Split-Join employing the static Split-Join pattern.
Static Split-Join is the ideal pattern in this case because the developer knows there will always be exactly two incoming service requests for this particular service package: DSL and voice. Splitting the requests into parallel branches allows them to be processed concurrently, which improves the overall response time for processing the payload. After all messages have been processed, the generated responses are aggregated back into one reply in the execution thread.
Figure 38-1 illustrates a static Split-Join that splits two known service requests, DSL activation and phone activation, processes each request in parallel, and joins the responses into a single reply.
Figure 38-1 Static Split-Join – Known number of service requests
Description of "Figure 38-1 Static Split-Join – Known number of service requests"
38.1.2 Dynamic Split-Join
The dynamic Split-Join branches from the main execution thread of an Oracle Service Bus message flow by dynamically creating new branches according to the contents of the incoming payload. The dynamic Split-Join uses conditional logic to determine the number of branches to create. All requests are handled simultaneously, and the responses are aggregated into a single reply.
38.1.2.1 Dynamic Split-Join – Sample Scenario
A company might want to use dynamic Split-Join when placing automated stationery orders for its employees. If the orders are automatically placed every week based on employee submissions, there is no way of knowing how many individual orders are placed in any one weekly order. Rather than placing each order separately, the company could use dynamic Split-Join to place the orders concurrently using a callout from the Oracle Service Bus message flow to a Split-Join employing the dynamic Split-Join pattern.
Dynamic Split-Join is the ideal pattern in this case, because the developer has no way of knowing how many orders will be submitted each week. The dynamic Split-Join loops through all the orders and places them in parallel. The developer can also limit the number of orders processed. After all of the orders have been processed, the generated order responses are aggregated back into one reply in the execution thread.
Figure 38-2 illustrates a dynamic Split-Join that splits 15 orders, processes them concurrently, and joins the responses into a single reply.
Figure 38-2 Dynamic Split-Join – Unknown number of service requests
Description of "Figure 38-2 Dynamic Split-Join – Unknown number of service requests"
38.1.3 Split-Join Framework
A Split-Join, which takes the form of a .flow file in Eclipse, is based on a WSDL operation. The Split-Join is wrapped in a WSDL-based business service that communicates across a FLOW transport, which is a dedicated transport for Split-Joins. The business service is invoked from a proxy service. Figure 38-3 illustrates the Split-Join framework.
38.2 Developing Split-Joins
You create and configure Split-Joins in Eclipse, then import them into the Oracle Service Bus Administration Console for use in runtime configuration. For information on developing Split-Joins, see "Working with Split-Join" in the Oracle Fusion Middleware Developer's Guide for Oracle Service Bus.