Method and system for business-policy driven grouping of service invocations
Original Publication Date: 2009-Mar-12
Included in the Prior Art Database: 2009-Mar-12
Business services typically have a price associated with their invocation that consists of a fixed and a variable portion. Grouping multiple invocations of the same service will typically involve the fixed portion only onced, effectively allowing to share it across all the service invocation. The invention describes how business policies can be used for such grouping, and for splitting the fixed cost across the involved parties, resulting in a reduced service invocation cost.
Method and system for business -policy driven grouping of service invocations
Business services typically have a price associated with their invocation. A portion of this price often is fixed, while another portion is variable, or their may be discount schemes where larger orders achieve higher discounts. For example, the price for the business service "order a book" has a fixed price for the delivery, and a variable price for the book(s) ordered. When this service is called multiple times in a certain time period in a certain organization, it is efficient to combine those book orders into a single one, invoke the service only once, and share the fixed portion of the price appropriately. Whether or not such service invocations are combined at all, what the associated quality of service are (e.g., how long am I willing to wait for a book to pay less for delivery), and how the fixed price overhead is split among involved parties (e.g., if an order is triggered earlier because someone needs to book more urgently they take a higher portion of the overall price) is defined by business policies.
We presume a repository keeping meta-data about business services. This repository is augmented (or already supports) the specification of arbitrary policies for services (today's policies include, e.g., transactionality). The ability to support grouping policies is added as a capability of the meta-data and the repository. When a BPM engine invokes a service, it checks the grouping policy. Note that this requires asynchronous service invocation, a feature common in BPM service invocations (and uncommon anywhere else - a BPM engine would be a preferred embodiment of the invention, but it applies for other environments supporting asynchronous service invocations, too). Note that the policy could also be overridden at invocation time, e.g., because a particular service is needed more urgently...