In our example scenario, an organization wishes to create a new intermedi-ary service which handles order management. In this organization, the IT department is slowly adopting a service-oriented approach to its information systems. They already converted a legacy system used for inventory man-agement into a service. The other services to be used in this new composite service are already published by the bank and shipper. Figure 4.1 illustrates the business protocols (defined in Section 3.2.2) of the involved services.
In Figure 4.2 the composition process is illustrated. It consists of two phases, namely synthesis and selection. In the synthesis phase the services together with the business rules and target business protocol are combined.
The result of the synthesis phase is a set of valid alternative orchestrators.
In the selection phase, from this set the most preferred orchestrator is chosen based on policies. We describe below in detail the three models we use for representing the requirements and wishes of an organization, namely target business protocol, business rules and policies.
4.2.1 Target Business Protocol
The target business protocol, also called the goal business protocol, repre-sents the communication between the customer and the, to be composed,
Figure 4.2: Hybrid Service Composition
orchestrator. Like the business protocols specified by the service providers this is a bilateral communication protocol.
The difference between our target business protocol and the target busi-ness process that is commonly used in automatic composition is that our approach allows for more flexibility. In the target business process, see for instance Berardi et al. (2003), Pathak et al. (2008) or Gerede et al. (2004), all actions are specified and the goal is to delegate all actions of the tar-get specification to services that are capable of executing these actions. In our approach, by using a target business protocol instead of a target busi-ness process we specify only the external behavior and thereby create more flexibility in the structure of the internal business process.
In Figure 4.3 we specify the target protocol for the retailer. This protocol is structured as follows: First, the retailer expects a catalog request from the customer, after receiving this request, the retailer sends back the catalog and waits for an order from that customer. Based on this order, the retailer either accepts or rejects the order by sending an accept message or reject message respectively.
Figure 4.3: Target protocol of the retailer
4.2.2 Business Rules
As described in the introduction to this chapter, if only services are used in the synthesis process, then the internal structure of the orchestrator must be a complete match with what is offered by these services. To provide an organization with the means to assemble a service that is more than a collec-tion of other services we incorporate business rules. The standard definicollec-tion of a business rule (c.f. (Charfi & Mezini, 2004; Rosenberg & Dustdar, 2005;
Cibrán et al., 2007; van Eijndhoven et al., 2008)) is defined by the Business Rules Group as: “a statement that defines or constraints some aspect of the business. It is intended to asset business structure or to control or influence the behavior of business” (BRG, 2000).
Incorporating rules in a service composition process requires business rules to be expressed in an executable format. We presume that an analysis phase has been done and that a set of business rules in the form of if/then statements is the result of that phase. We also assume that this analysis encompasses aspects such as further decomposition into atomic parts and whether rules cannot work together (conflicts). We focus on the implemen-tation phase where emphasis is put on how to incorporate business rules in the automatic composition process.
Several classification schemas exist for business rules. Although multi-ple types of rules have been distinguished, such as constraint rules, action-enabler rules, computation rules and inference rules (von Halle, 2001), in this thesis we primarily study inference rules, also called decision rules. An in-ference rule is defined as “a statement that tests conditions and upon finding them true, establishes the truth of a new fact” (von Halle, 2001). Inference rules represent the (automated) decisions made in a business process and
capture an important aspect of business logic. In this thesis, we focus on maintaining consistency with respect to data (information) and the decisions made based on that data. For this reason, we limit ourselves to inference rules and leave the other types of rules for future work.
In our running example, we use two business rules. In the specification of the target protocol of the retailer (Figure 4.3), the retailer sends either an orderReject or an orderAccept message to the customer. The decision whether an order should be accepted or rejected is a business rule. The business rules for our running example, in text and XPath notation are:
1. If the product is available and the customer’s creditworthiness is okay and the shipper sent a shipmentquote, then the customer’s order is accepted.
if availability/Availability[available = true] and shipmentQuote/ShipmentQuote[shipmentID > 0] and
(accCredib/AccCredib[balance > 0] then //acceptance := true
2. If either the product is not available, the customer’s balance is not good or the shipper cannot ship, then the order is rejected.
if availability/Availability[available = f alse] or accCredib/AccCredib[balance < 0] or
shipmentQuote/ShipmentQuote[shipmentID <= 0]
then //rejected := true
Although we focus on inference rules, our approach can easily be extended to cover the other types. Limitations on what kind of rules can be expressed, can be drawn from the representation of the rules, in our case the subset of XPath described in Section 3.4.1.
Translating Business Rules in Guarded Automata
We assume that business rules are available in an executable format (Xpath), however, they cannot directly be used for synthesis. In Chapter 3, we ex-pressed business protocols and the business process using Finite Automata (FA), therefore if business rules are to be incorporated in the composition process, they must be expressed using FA as well. The advantage of trans-lating business rules in automata is that it allows us to build further on
existing automatic synthesis approaches based on automata, especially (Be-rardi et al., 2003; Gerede et al., 2004)).
We formally define a business rule as follows:
Definition 17. (Business rule)
A business rule is a guarded automaton < M, S, s0, F, T > where M ={m}, S = {s1, s2}, s0 = s1, F = {s2} and T = {t} and the transition is of the form: t =< s1; (m; ϱ); s2 >, where ϱ is the transition guard. The transition changes the state of the automaton from s1 to s2. The message is defined as m =< rec, sen, g > where rec = sen is the orchestrator and g is the MSL type of the message, defined in Definition 9.
Recall from Section 3.4.1 that we model a guard as ϱ≡ (ϱ1 ⇒ ϱ2), where ϱ1 is a boolean XPath expression (W3C, 1999) on the message classes, and ϱ2 is an assignment of the form p← exp where p is a XPath location path and exp is an XPath location path or an XPath expression. Using this format, we can directly translate a business rule to a guarded automaton containing only one transition, which consists of the condition of the rule (mapped to the guard ϱ1) and the action of the rule (mapped to the assignment ϱ2).
In Figure 4.4, in WSAT syntax (Fu et al., 2004e), we illustrate the busi-ness rule for accepting an order. The full description of the guarded automata representing both business rules can be found in Appendix C.
States{sbr21,sbr22}, InitialState {sbr21}, FinalStates{sbr22}, TransitionRelation{
t_br21{ sbr21-> sbr22: accept,
Guard{ $availability/Availability[available = true] and
$accCredib/AccCredib[balance > 0] and
$shipmentQuote/ShipmentQuote[shipmentID > 0]
=>
$accept[ //acceptance:= true]}
} }
Figure 4.4: Business rule for accepting an order
When business rules are used in a composition process, they are often
not recognizable in the resulting model. As we describe in the following, by representing the business rules as one transition automata, we do not lose the track of the rules during the composition process and are able to locate where the rules are triggered.
4.2.3 Policies
In some situations, there are multiple variants of orchestrators that can be composed from the set of services, business rules and target protocol. In such a situation, a choice has to be made which alternative is preferred over another. To make such a choice we use policies. Policies allow the developer to select the best orchestrator for what he defines as best. Policies are used where a choice is to be made between valid alternatives. Policies specify the precondition and post-condition of a choice, i.e. providing a set of alterna-tives and the selected candidate. A policy can be implemented in different ways. We provide the developer with a few example strategies for making the choice, but also allow the developer to define his own implementation for making the choice. We define below three example strategies that can always be applied .
First Occurrence: The first option is taken.
Random: The option is randomly chosen.
Interactive: The decision is presented to the developer, who then must decide which option is chosen. If this strategy is chosen then the se-lection phase will be semi-automatic. How to present this choice in a user-friendly way is beyond the scope of this thesis.