Protocol-Based Business Process Modeling and Enactment Nirmit Desaiy Department of Computer Science North Carolina State University Raleigh, NC 27695-7535, USA
[email protected] Abstract Business processes are conventionally modeled as monolithic flows that capture the desired business logic. However, developing process flows is challenging. Because a flow specifies what its participants should do, it restricts the autonomy of its participants, thus limiting their ability to exploit opportunities or accommodate exceptions according to their business preferences. We take a dual perspective wherein business processes are modeled as compositions of (instantiated) business protocols. Each business protocol specifies interactions among its partners; each protocol serves a unique business purpose, e.g., processing a payment or shipping an item. Thus, modularizing a monolithic business process via business protocols allows clear separation of concerns for modeling and enacting the process. We develop an approach in which protocols are compiled into local skeletal flows for each participant that can be fleshed out with local business logic as needed. Such flows are naturally distributed but can be enacted using commercial business flow engines. Thus, our protocol-based approach combines the benefit of improved modeling with simplified implementations.
1. Introduction Service-oriented computing is a promising paradigm for achieving rich collaborations among heterogeneous and autonomous business partners. Business processes reflect the composite business flows involving the interacting partners. Conventionally, a business process is modeled directly in terms of the flow of its execution. Such a flow corresponds to a conceptually centralized view of the given global process. Although, there can be some value in developing such y
This research was partially supported by the NSF under grant DST0139037 and by DARPA. The first author is a Full-time student.
Munindar P. Singh Department of Computer Science North Carolina State University Raleigh, NC 27695-7535, USA
[email protected] centralized views, they suffer from the following major shortcomings:
Centralized modeling ignores the perspectives of the partners and thus conflicts with their autonomy. Due to the restrictions on the autonomy, a participant may be prevented from exploiting business opportunities or handling exceptions in a manner that respects its business policies.
Trying to encode all the business interactions monolithically, yields a flow that is more complex than necessary. The lack of modularity of such a flow makes it difficult to predict and verify its behavior, especially in the face of business exceptions.
Business processes involve a combination of local, domain specific reasoning by the various partners as well as interactions among them. The domain-specific reasoning can be accomplished in the usual manner and is not of interest in this paper. The interactions among business partners can be specified via business protocols. Protocols enable components to be developed independently with the expectation that they can function together. In a broader sense, directly developing composite business flows is harder than modeling individual business protocols and then putting them together. Thus, protocol-based process modeling can be viewed as a structured approach wherein protocols are granules. Several business protocols have been defined. Some of the most well known are NetBill [4], Secure Electronic Transactions [13], Internet Open Trading Protocol (IOTP) [10], Escrow [6], and some of the so-called interaction protocols specified by FIPA [8]. The MIT Process Handbook [11], and RosettaNet [12] are other examples of specification efforts with a reference to business protocols. The Business Process Execution Language for Web Services (BPEL4WS or BPEL) is a leading emerging standard for processes [1]. Abstract BPEL includes rudimentary protocols, which too are modeled as processes whose variables are bound late to values. The present paper goes beyond BPEL by providing a more thorough treatment of proto-
cols. The Web Services Conversation Language (WSCL) describes conversations in which a given service may participate [9]. These conversations capture one service’s requirements for its invokers, and are not true protocols in the sense of independent specifications of interactions. Protocols would impose requirements on all partners, not just on the users of a particular service.
approach and suggests potential directions for further research.
2. Motivation and Concepts Serious applications of Web services involve complex processes, which are realized through composed services. Current process approaches take a logically centralized view of composition, and provide scripting languages to specify how a composed service may be implemented from existing services, rather than what interactions are expected from the partners involved in the composition. Consequently, existing approaches fail to adequately accommodate the essential properties of business partners—their autonomy (freedom of action), heterogeneity (freedom of design), and dynamism (freedom of configuration). There are two key requirements for managing business processes.
Contributions, Scope, and Significance Our main contribution is a protocol-based approach for the specification and enactment of business processes. Our approach begins with an identification of the protocols using which different participants in a business process interact. For example, a merchant and a customer may interact with each other using a negotiation protocol; the merchant, customer, and payment agency may interact via an escrow protocol; and, the merchant, customer, and shipper may interact through some specialized logistics protocol. Importantly, a party may participate in multiple protocols at the same time; some protocols can involve more than two parties. We develop a technique that maps each protocol into the local skeletal flows of its participants. The skeletal flows of the participants, when executed together, realize the original protocol. Such local skeletal flows, one for every business protocol the participant participates in, can be fused together and augmented with domain-specific reasoning to produce local flows that each partner can execute. For concreteness, our tool renders the skeletal flows in BPEL. The resulting flows can be naturally executed via a commercial BPEL engine so that each partner produces the right (relative to the given protocol) messages directed at other partners and interprets the messages received from other partners. The present work is significant because it yields a new approach for the specification and enactment of business processes that is based on protocols. Just as network protocols enabled the expansion of the lower layers of Web architectures, business protocols enable the development of processes involving autonomous, heterogeneous business partners. For this reason, we expect to see an increasing set of business protocols to be published and custom protocols to be designed in narrow domains. This will further increase the significance of our contributions for developing processes based on protocols.
Modeling: Model processes in a decentralized manner that accommodates the participants’ views. For example, a supply chain is a process whose overall flow is just one view; equally important are the participant’s perspectives, which govern their respective actions.
Enacting: Support enactment of processes in a distributed manner. That is, there would be no central engine that orchestrates the actions for all participants.
The above requirements are met by introducing business protocols. Protocols encapsulate chunks of interactions that take place in a process. Thus they are logically decentralized. For example, a payment protocol between a customer and a merchant would be specified independently of the merchant’s inventory fulfillment protocol for ordering goods from its suppliers. Further, protocols specify what rather than how, leaving the local decision-making up to each partner. Thus protocols naturally maximize the autonomy, heterogeneity, and dynamism of the interacting partners. Conceivably, each party may impose its local constraints and preferences about which protocol steps it would or would not exercise. For example, a merchant may accept only cash for discounted goods and a customer may prefer to pay for goods after using them for a month. Figure 1 shows our conceptual model for a protocolbased treatment of business processes. Boxed rectangles are abstract entities (interfaces), which must be implemented to yield configurable entities that can be fielded in a running system (rounded rectangles). Abstract entities should be published, shared and reused among the process developers. For simplicity, we specify a protocol as a finite state machine that we term as P-FSM. A P-FSM encodes the actions of two or more roles, who would be bound to specific partners when a process is enacted. A P-FSM describes the
Organization of this Paper Section 2 introduces the concepts of our approach and frames them in a conceptual model. Section 3 introduces business protocols and how they are specified and interpreted. Section 4 presents our skeleton generation process, establishes its correctness, and shows how it is implemented in a prototype based on commercial BPEL tools. Section 5 describes some relevant literature, identifies some challenges associated with the
2
for such a supplier would be composed from the P-Skels for a trading buyer and a shipping customer. This C-Skel specification could be published and then reused for other suppliers. Figure 2 schematically illustrates our approach for enacting a sample supply chain process.
Figure 2. Example: Enactment of supply chain process
Figure 1. Conceptual model
nature of the coupling among the participant roles from a global perspective. Whereas a P-FSM specifies the protocol from the global view, a protocol skeleton (P-Skel) specifies the protocol from the perspective of one of the participant roles. In essence, each P-Skel defines the behavior of the respective role with respect to the given protocol. Intuitively, a P-FSM corresponds to a set of P-Skels, one for each role involved in the P-FSM. A P-Skel specifies behavior without regard to actual configuration and implementation, which would be needed to flesh out the local business logic and extrafunctional requirements such as performance and messaging reliability. An agent is an implementational entity, something that can represent a real-world, autonomous, heterogeneous business partner with its local business rules and configurations. For example, an agent may represent a specific merchant. Obviously, an agent may participate in multiple business protocols by adopting a role in each of them, e.g., a bookstore may adopt the role of a seller while interacting with customers and the role of a buyer while interacting with publishers. When an agent needs to participate in multiple protocols, a composite skeleton (C-Skel) can be created from the PSkels, one P-Skel for each of the roles that the agent plays in the given protocols. For example, in a supply chain process, a supplier would be a merchant when interacting with a retailer in a trading protocol and would be a client in a shipping protocol for sending goods to the retailer. The C-Skel
A local flow is an executable realization of a C-Skel, which has been completed by inserting the appropriate local business logic. An agent would enact its local flow based on its C-Skel and its local business logic. A local flow may be represented in a conventional flow language—we use BPEL in our prototype. A business process, then, is the aggregation of the local flows of all the agents participating in it. Conversely, a business process is (an implementation of) the composition of multiple business protocols. For example, a supply chain business process would be the aggregation of the business flows of the consumer, the retailer, the supplier, and the manufacturer. It is also a composition of the protocols involved. With this motivation, this paper studies P-FSMs and the generation of P-Skels from P-FSMs for multiparty protocols. We also enact a simple business process having just one constituent protocol, i.e., NetBill, and two agents Customer and Merchant. This enables us to demonstrate the complete cycle of our approach, except that we defer the treatment of C-Skel composition to future work.
3. Business Protocols Each state of a P-FSM corresponds to a state of the modeled interaction. Each edge of a P-FSM corresponds to a state transition based on a message from one role to another (internal actions of a partner are not modeled). A well-
3
designed protocol would constrain the communications of the different parties only to the extent necessary to ensure some desired property. In a P-FSM, the protocol states are distinguished but their content is not explicitly modeled. Thus, the states are simply represented via numbers or other meaningless labels. Edges are labeled as (s ; r ): Mk . An edge with such a label is interpreted to mean that it is a state transition corresponding to role s sending a message Mk to role r .
If a role is a sender for more than one out-edge from a state, it will follow only one edge. For example, in state 2, the merchant will either send an offer (edge 2 ! 3) or send goods (edge 2 ! 8), but not both.
Concurrent actions by multiple roles are possible. For example, in state 2, the merchant may send either one of its allowed messages while the customer sends an accept (edge 2 ! 9). For the purpose of brevity, we do not present our treatment for this situation in this paper.
3.1. NetBill Protocol
4. Generating Local Flows We use the NetBill protocol [4] to demonstrate our approach. NetBill is an e-commerce protocol for open trading on the Internet. We focus on the core interactions between two roles, called Customer and Merchant, respectively. We use an enhanced version of NetBill that offers additional choices to the participants, which enable them to respond better to opportunities and to better handle any exceptions that may arise [2]. Figure 3 shows a P-FSM, which we take as our point of departure. (M, t
p cce
9
(M, C): Offer
,
(C
:A M)
1
er
ds
Coordination requirements for each role need to be clearly specified to achieve correct protocol execution without compromising autonomy. To meet this objective, we present an algorithm to derive protocol skeletons (P-Skels), for each role involved in P-FSM.
2 (M
,C
(C, M
):
): Acc
ds
): Goo
,M
4.1.1. Algorithm A P-FSM shown can be represented as a set of edges T = f j = hsi ! sj ; s ; r ; Mk ig. Each tuple corresponds to an edge in the P-FSM; si ; sj 2 S and S is the set of all states in the P-FSM; Mk 2 M and M is the set of all distinct messages in the P-FSM; s is the role that sends message Mk ; r is the role that receives message Mk and all s ; r 2 < where < is the set of all roles. Below, s1 and sn refer to the start and the end states, respectively. And, * functions as a generic wildcard, referring to a role, message, or state as clear from the context. A skeleton for role is defined as SK = hA ; E i. Here, A is a set of messages that role can send, i.e., the actions of . That is, for each message Mk that role sends,
s
4
t
en
8
m
):
y Pa
,M
): Pay
(C
ment
t
ep
cc
): A
(C, M
Go
od
ept
(M, C
5
Goo
uest
): Off
3
4.1. Skeleton Generation C):
): Req
(M, C
(C
(M ,C ): Go od s
(C, M
A P-FSM specifies a protocol. It can be published and accepted as a standard. The low-level details of a standardized protocol (e.g., message formats) are not considered here. Each participant playing a role in a protocol would need to determine what behaviors were allowed to it by the given protocol. Thus it would be able to take correct actions that together with the correct actions of others would realize a correct protocol execution.
eipt
): Rec
(M, C
6
7
Figure 3. Enhanced NetBill protocol
3.2. Understanding P-FSMs
Ak =
Some important points about the semantics of P-FSMs are as follows.
fa
k
j
ak = hr ; CS ; N S ig
Here role r is the receiver of the message Mk ; CS is the state of the protocol from the view of role in which is allowed to send the message; and, N S is the state of the protocol from the view of role after sending this message. Similarly, E is a set of messages that role can receive, i.e., the events that fields. That is, for each message Mk that role receives,
Although the states are formally treated as if they are meaningless, behind the scenes, the designer would intend some distinct meaning for each state in a P-FSM. For example, even though states 5 and 8 have identical in and out edges, in state 5, the customer is committed to send payment in response of received goods, but not so in state 8.
Ek =
4
k
fe
j
ek = hs ; CS ; N S ig
Here s is the sender of message Mk ; CS is the state of the protocol from the view of role in which is allowed to receive message Mk ; and, N S is the state of the protocol from the view of role after receiving this message. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
multiparty protocols as well. We define a computation as a sequence of transitions si sj where si , sj S . Lemma 1 hr ; si ; sj i 2 Aks Mk i 2 T P ROOF.
Partition (T)
fg, Ek fg For all 2 < and all Mk 2 M For all = hsi ! sj ; s , r ; Mk i 2 T Aks Aks [ hr ; si ; sj i, CS fg CurrentState(si ; r ; CS ) For all cs 2 CS Ekr Ekr [ hs ; cs; sj i
)
CurrentState(si ; ; CS)
hr ;
If si = s1 Then CS CS [ s1 return For all sh such that hsh ! si ; s , r ; i 2 T If s = _ r = Then CS CS [ si Else CurrentState(sh ; ; CS )
Figure 4 describes our algorithm to generate skeletons for each role from the P-FSM represented by T . The basic idea is to populate action sets Ak and event sets Ek with correct values for each role and each message Mk . This algorithm handles multiparty protocols; its correctness is discussed in Section 4.2. Table 1 shows the skeleton for the customer role in the NetBill P-FSM. Actions for Customer hM; hM;
hM; hM;
1; 2i
5; 6i, hM; 8; 6i
Events for Customer
Mk
eC k
1; 3i, hM; 2; 3i
1; 8i, hM; 2; 8i, hM; 4; 5i, hM; 9; 5i hM;
2
Aks
;
4.2.1. Soundness We prove that if a path p = s1 si sn is allowed by the generated skeletons, it will be allowed by T . Let p be allowed by the generated skeletons. Let si sj be a computation step in p. Since the generated skeletons allow si sj , we must have s , r , and Mk such that, hr ; si ; sj i s r 2 A k and hs ; CSr , sj i 2 Ek . By Lemma 1, hr ; si ; sj i s 2 A k ) hsi ! sj ; s ; r , Mk i 2 T . Since this holds for all si sj in p, this means p is allowed by T .
1; 9i; hM; 2; 9i, hM; 3; 4i hM;
EC :
offer goods receipt
; ;
aC k
request accept payment
si ; sj i
Lemma 2 If hsi ! sj ; s ; r ; Mk i 2 T then, 9cs = CSr such that hs ; cs; sj i 2 Ekr P ROOF. Here CSr is r ’s view of the current state of the protocol. Let sx ! sy be the most recent computation in which r participated. Therefore, CSr = sy . It is given that at state si ; s sends Mk to r realizing the computation si sj . Since si is the current state of the protocol from the global perspective, which is the same as the perspective of the current sender s , si sj must follow sx sy . Therefore, sy si occurs in the protocol path. If r has not participated in any computation yet, CSr = s1 . For any si , s1 si holds. Now, in the skeleton generation algorithm, on line 9 a call si , currentState(si; r , ) will be made and because sy during the backward chaining from si ; sy will be found. So, hs ; sy ; sj i will be added to Ekr and because sy = CSr , 9cs = CSr such that hs ; cs; sj i 2 Ek r
Figure 4. Algorithm to generate all skeletons
Mk
sj ; s ; r ,
Line 7 in Figure 4 is the only way to add tuples to Aks . The only source of these tuples is T as is evident from line 6. Hence, hr ; si ; sj i 2 Aks ) hsi ! sj ; s ; r , Mk i 2 T . ( As evident from line 6 of Figure 4, all the tuples 2 T are added to Aks . Hence, hsi ! sj ; s ; r , Mk i 2 T )
Ak
AC :
, hsi !
4.2.2. Completeness We prove that if a path p = s1 si sn is allowed by T , it will be allowed by the generated skeletons. Assume that p = s1 si sn is the protocol path allowed by T . Therefore, there exists hsi ! sj ; s ; r , Mk i 2 T . By Lemma 1, hsi ! sj ; s ; r , Mk i 2 T ) hr ; si ; sj i s 2 A k . And by Lemma 2, hsi ! sj ; s ; r ; Mk i 2 T then, r 9cs = CSr such that hs ; cs; sj i 2 E k . So the path p will also be allowed by the generated skeletons.
6; 7i
Table 1. NetBill Customer Skeleton
4.2. Correctness Here, we prove that the skeletons generated by our approach are sound and complete with respect to the input P-FSM. That is, the generated skeletons when executed together realize the same computations as the input P-FSM, and realize no other computations. These proofs apply to
4.2.3. Coordination Compliance Verification As described in Section 2, when an agent needs to participate in multiple protocols, a composite skeleton (C-Skel)
5
can be created from the P-Skels, one P-Skel for each of the roles that the agent plays in the process. As P-Skels are publishable entities, and anyone can publish them, the P-Skels being composed for yielding a C-Skel may not be compliant with each other. Therefore, we must verify whether the collection of these skeletons is compliant with respect to coordination. The Ping-Pong algorithm of Figure 5 verifies the coordination compliance among the given skeletons. The basic idea is to traverse through the edges from the start state and see if all possible paths reach one of the end states. Ping traverses a step forward by effecting an allowed action (sending a message) and Pong receives these actions as allowed events and traverses a step forward. If Ping-Pong runs through silently, it means that all actions are handled by corresponding events and therefore the given skeletons are compliant. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Verify(SK)
CS s1 For all 2
