(Final Part of the discussion of Batch Processing and SOA.)
A web service access pattern is usually designed for "online" or real-time(ish) access. Most web services are designed for single request / single transaction access. A account record is requested, a customer record is updated, a transaction of some sort is executed. Rarely are services designed to handle multiple requests, 10, 100, 1000, 10,000 in a single service connection.
Further reinforcing the single operation model of most web services is the communication pattern. Most services are firmly operating in a request/reply pattern – regardless of whether the actual transaction operation is a query or update, whether the reply is a simple acknowledgement or a complete data response.
Therefore, if a batch of requests comes in, the ESB is intermediating between communication patterns. On one side is a single request, a “file” with many requests (tens to millions). On the other side is a service model that accepts single requests. As each request has a communications and processing overhead, as an example 50ms (a normal TCP/IP request/reply overhead), a moderate batch of 100,000 requests would have a time impact of 80 minutes only for the communications. If the actual transaction processing was another 50ms (that would be a very fast transaction), the total time would increase to 160 minutes or 2.6 hours.
This intermediation between communication models causes a significant time overhead, as well as utilizing a significant amount of resources in the ESB environment for minimal benefit. Further, the time overhead can create competition between batch jobs.
These are risks that have to be mitigated when using this pattern.
In summary, SOA and Batch are not well suited for each other. However, all too often we find this pattern developing or being pushed from the 'reuse' mindset. If you find yourself here, be careful to manage and mitigate the model conflicts.
A web service access pattern is usually designed for "online" or real-time(ish) access. Most web services are designed for single request / single transaction access. A account record is requested, a customer record is updated, a transaction of some sort is executed. Rarely are services designed to handle multiple requests, 10, 100, 1000, 10,000 in a single service connection.
Further reinforcing the single operation model of most web services is the communication pattern. Most services are firmly operating in a request/reply pattern – regardless of whether the actual transaction operation is a query or update, whether the reply is a simple acknowledgement or a complete data response.
Therefore, if a batch of requests comes in, the ESB is intermediating between communication patterns. On one side is a single request, a “file” with many requests (tens to millions). On the other side is a service model that accepts single requests. As each request has a communications and processing overhead, as an example 50ms (a normal TCP/IP request/reply overhead), a moderate batch of 100,000 requests would have a time impact of 80 minutes only for the communications. If the actual transaction processing was another 50ms (that would be a very fast transaction), the total time would increase to 160 minutes or 2.6 hours.
This intermediation between communication models causes a significant time overhead, as well as utilizing a significant amount of resources in the ESB environment for minimal benefit. Further, the time overhead can create competition between batch jobs.
These are risks that have to be mitigated when using this pattern.
In summary, SOA and Batch are not well suited for each other. However, all too often we find this pattern developing or being pushed from the 'reuse' mindset. If you find yourself here, be careful to manage and mitigate the model conflicts.