Business Process Adaptations via Protocols - Semantic Scholar

Business Process Adaptations via Protocols Nirmit Desai [email protected] Department of Computer Science North Carolina State University January 12, 2006 Abstract Business process management in open environments poses special challenges. In particular, open environments are dynamic thereby requiring frequent changes in business processes. In current business process modeling approaches, such changes are handled in an ad hoc manner. It is not clear what needs to be changed and where, to accommodate a change. In this paper, we build on our previous work on business protocols to handle the challenge of design adaptability. The basic mechanism that facilitates such adaptability is that of protocol composition. We also provide a semantics for the protocols and their composition in causal logic. Through a real business scenario of auto-insurance claim processing, we demonstrate how a wide range of adaptations can be handled naturally and systematically via protocol composition. The illustrated adaptations have been prototyped.

1 Introduction Successful business process management requires that we support three key properties of open environments, namely, autonomy, heterogeneity, and dynamism. Supporting autonomy means that we model and enact business processes in a manner that offers maximal flexibility to the participants by only minimally constraining their behavior. Supporting heterogeneity means that we make few assumptions about the construction of the components for the parties, concentrating instead on characterizing the interactions among them. Interconnections among components, not the components themselves, are critical. Dynamism has two flavors. Membership dynamism means that the set of components may change. Components may be added and removed at either design-time (design-time membership dynamism) or run-time (run-time membership dynamism). Structural dynamism means that the set of interconnections is not fixed. Structural dynamism reflects changes in the business requirements; modern businesses face intense pressure and must repeatedly reconfigure themselves in order to thrive, if not to survive. Structural dynamism poses a difficult challenge, one that has not been adequately addressed in the literature, and is a major theme of this paper. 1

Z N-^ G B C#Y ^%e,QTS D a E%Y ^f ` 
       A

       


      
 

 ! "#$ %

B C


   +2(3 

D E F

"" 0 01. 0

G G

I

G

H

/   !   
+,- .   
ZS Y\[ [ S]Q_^ I Q C`

FKJMLON-P &'  
     


()     *    

Z6S [ Y Hacb Y ^2d [ Q C6` 76  .5 "6    !  .  " =?> @@ 
    0 0

&    4  

""1 09  !;:< "#


PQRQTSVU

0   .8  

5"6 7   8   3 " 8   
"#   WXQ E%Y H C Q C

    14
 

& 8   

3 4
 

Figure 1: CrossFlow Insurance Claim Processing In our previous work [11], we reported a methodology (named OWL-P) for developing business processes that supports autonomy and heterogeneity. The essence of OWL-P is an abstraction of business protocols. A business protocol is an abstract, modular, and publishable specification of rules that govern a business interaction among two or more roles. A protocol is abstract because it does not model the private business logic of the agents enacting the roles. It is modular because it achieves a specific goal which may be a part of another bigger goal. Due to their abstract and modular nature, it is possible to combine business protocols, each achieving a goal, to form a composite protocol that achieves a bigger goal. Each role’s perspective of a protocol is captured in its role skeleton. A role skeleton when integrated with the private business logic of an agent enacting the role yields the agent’s local process. A business process is an aggregation of the local processes of all the agents involved. In this way, protocols partition a process in a cross-cutting manner whereas conventionally, flows are taken as partitions. For instance, in Figure 1, each of the boxes represents a flow and would be the module of abstraction in conventional approaches, whereas OWL-P focuses on the interconnections among the boxes. Such interconnections, modeled as protocols are shown in Figure 3. Processes in open environments are inherently inter-organizational. For such processes, flow-based modeling is ill-suited due to the following reasons: Flexibility Flows specify a rigid sequence of tasks. There isn’t a way to tell if a deviation from such a sequence is significant. Also, as interactions are hidden inside the tasks, it is difficult to tell how a particular task affects a business partner and the contract between the partners. Reusability A task in the flow is an ad hoc mix of the reusable interaction pattern and 2

the proprietary business logic of the agent. It is not possible, for example, to reuse the box of AGFIL in Figure 1 to enact the process of another insurance company. Adaptability Suppose Lee CS wishes to change the way it interacts with the repairers. With flows, it is not clear how to rearrange the tasks to handle such a change. 1

Business Process

aggregation of

Concrete entity

1 2..*

implementation of

implementation of

Local Process 1 1

owns

1

1 Composite Skeleton

Agent

involves 1 Business Protocol

2..*

1..*

1 1..*

1..* defines

Role

1 1 Role Skeleton 2..*

1

1..*

derives 1

composed of

composed of

adopts

1..*

Abstract entity

Composite Protocol

1..*

1 derives

Figure 2: Conceptual model: business processes based on protocols Figure 2 shows the relationships among the OWL-P entities described above. The numbers on the edges indicate the multiplicity constraints as in UML class diagrams [22]. For example, one instance of business protocol derives at least two instances of role skeletons. Note that “instance” as used here does not mean an enacted instance of a protocol. Here, “business protocol” is a class of all business protocols, whereas a particular protocol, e.g., a payment protocol is an instance of this class. Boxed rectangles are abstract entities, which must be combined with business logic to yield concrete entities that can be fielded in a running system (rounded rectangles). Abstract entities can be published and reused. Roles are abstract, and are adopted by agents to enable concrete computations. This paper is about supporting structural dynamism and design-time membership dynamism. Change in business requirements is routine. An abstraction for modeling business processes must offer an elegant way of handling change. With conventional approaches, it is not clear how they would adapt to handle (1) exceptions, (2) changes 3

in business policies, and (3) changes in business models. Thus, our goal here is to show how these specific kinds of changes in the requirements can be systematically accommodated. To effectively demonstrate and evaluate our methodology, we consider an insurance claim processing case studied under the CrossFlow project [9]. Figure 1 shows the process flow. AGFIL is an insurance company in the Irish market that provides domestic and commercial insurance. The present scenario deals with automobile insurance. AGFIL underwrites the insurance policy and covers any losses incurred. Europ Assist provides a 24-hour help-line service for receiving claims. Lee CS is a consulting firm that coordinates with AGFIL and deals with repairers and assessors to handle the claims. A network of approved repairers provide the repair services. AGFIL holds ultimate control in deciding if a given claim is valid and if payment will be made to the repairer. Being a real-life business scenario previously studied by others, this example provides an independent and significant test-case for our approach. Organization. Section 2 introduces our language for specifying protocols and its semantics in Causal logic. Section 3 describes how protocol can be composed with composition axioms and what it means in Causal logic. Section 4 is the essence of this paper. It shows how protocol composition handles a variety of requirement changes at different levels of the business process. Finally, Section 5 surveys relevant literature and outlines a plan for future research.

2 Protocol Specification This section first introduces the Nonmonotonic Causal Logic (NCL) [13] and the action description language C+ based on it. Our language (OWL-P) for specifying protocols is described next. A transition system semantics for OWL-P is given by providing a mapping to C+.

2.1 Nonmonotonic Causal Logic In NCL, a causal rule of the form F ⇐ G expresses the fact that “there is a cause for F to be true if G is true” without dwelling on the actual cause of F . Here, F is called the head and G the body of the rule. The informal semantics of such rules can be summarized as “every fact that is caused obtains and every fact that is obtained is caused” [13, page 3]. The second half–every fact that obtains is caused reflects the principle of universal causation which is a practical rather than a philosophical choice. The signature of a causal theory is the set α of constants that occur in it. Each constant c is assigned a nonempty finite domain Dom(c) of symbols. An atom is of the form c = v where v ∈ Dom(c). An interpretation of α is an assignment c = v for each c ∈ α where v ∈ Dom(c). A formula in NCL is a combination of atoms formed using the connectives of classical logic. Constants in causal theories are either fluents or actions. A causal theory describes histories of length m + 1, (m ≥ 0), by creating for all i, (0 ≤ i ≤ m), a copy of every fluent and, for all i, (0 ≤ i ≤ m − 1), a copy of every action. The interpretation of 4

fluents for a particular i represents state si and the interpretation of actions in state si represents the transition to state si+1 . 2.1.1 NCL Model Semantics Let I be an interpretation of the signature α of a theory T . The reduct T I is the set of all heads whose bodies are satisfied by the interpretation I. If I is also a unique model of T I , then I is a model of T . As an example, consider the following theory T 1 consisting of rules R1 and R2. R1. p ⇐ q R2. q ⇐ q Intuitively, T I represents facts that are caused, according to theory T under interpretation I. Here, we consider all the possible interpretations to see which, if any, is a model of T1 : I1. {p = true, q = true}: T1I1 = {p, q}. I1 is a unique model of T1I1 . Therefore, I1 is a model of T1 . I2. {p = false, q = true}: T1I2 = {p, q}. I2 is not a model of T1I2 . Therefore, I2 is not a model of T1 . I3. {p = true, q = false}: T1I3 = {}. T1I3 has no models. Therefore, I3 is not a model of T1 . I4. {p = false, q = false}: T1I4 = {}. T1I4 has no models. Therefore, I4 is not a model of T1 . To see how NCL is nonmonotonic, consider a theory T2 consisting of the rule c = 1 ⇐ c = 1. The only model of T2 is I(c) = 1. Now consider a theory T3 such that it has two rules, c = 1 ⇐ c = 1 and c = 2 ⇐ true. Note that T2 ⊆ T3 . However, the only model of T3 is I(c) = 2. Thus adding new rules to an NCL theory may change its conclusions. 2.1.2 Action Descriptions in C+ C+ is a high-level action description language based on NCL. It is easier to specify theories in C+ than directly in NCL because of its concise notation. In this paper, we use only a small subset of C+ syntax. The syntax of this subset of C+ rules and how they translate to rules in NCL is discussed next. A formula in C+ is a propositional combination of constants which are either action constants or fluent constants. Actions in NCL are interpreted to be unit-length. An action constant being true represents the execution of the action. A fluent formula consists only of fluents. An action formula consists only of actions. Table 1 provides a translation of this subset to NCL rules. An action description D consisting of C+ rules is turned into a causal theory D m where m is the length of the history. The signature α of Dm then consists of i: c for every fluent c ∈ α for every 0 ≤ i ≤ m and i: c for every action c ∈ α for every 5

C+ syntax A1 causes A2 if F1 A1 causes F1 if F2 caused A1 if F1 caused F1 if F2 a1 :: action f1 :: inertialFluent

NCL translation i:A2 ⇐ i:A1 ∧ i:F1 i+1:F1 ⇐ i:A1 ∧ i:F2 i:A1 ⇐ i:F1 i:F1 ⇐ i:F2 a1 is an action symbol in the theory f1 is a fluent symbol in the theory, 0:f1 ⇐ 0:f1 , 0:¬f1 ⇐ 0:¬f1 , i+1:f1 ⇐ i:f1 ∧ i+1:f1 , i+1:¬f1 ⇐ i:¬f1 ∧ i+1:¬f1

Table 1: A translation of C+ constructs used in this paper to NCL rules. Each A k is an action formula, Fk a fluent formula, ak an action, and fk a fluent constant (k > 0). All constants c ∈ α are boolean, i.e., Dom(c)={false, true}.

0 ≤ i ≤ m − 1. The domain of i: c is the same as Dom(c). i: P means that i is inserted in front of every occurrence of every constant in P , where P is either a fluent or an action formula.

2.2 A Language for Protocol Specification A Protocol specifies a set of rules from a global viewpoint that govern the interaction among roles. These rules typically specify a choreography of the messages to be exchanged in a protocol. The meaning of a message exchange is given by its effects on the agents’ commitments. For example, a message may create, discharge, delegate, assign, or cancel a commitment. Here, we describe our language for specifying protocols. Each protocol specification P is a tuple hρ, S, M , R, Cond, Commi, where ρ is a set of participant roles, S is a set of slots, M is a set of messages, R is a set of causal rules, Cond is a set of commitment conditions, and Comm is a set of commitments. A message is of the form msg(ρi , ρj , s1 , s2 , . . . , sn ), where ρi , ρj ∈ ρ (i 6= j) are its sender and receiver roles, respectively, and sk ∈ S (1 ≤ k ≤ n) are its parameters. For each message msg, we add an action symbol msgA to denote the action of exchanging msg, and a fluent symbol msgF to record the fact that msg is exchanged. A commitment condition is an action symbol of the form cond(s 1 , s2 , . . . , sn ), where sk ∈ S (1 ≤ k ≤ n) are the parameters of cond. Commitments are fluent symbols of the form c(ρi , ρj , cond) (base level commitment) or cc(ρi , ρj , cond1 , cond2 ) (conditional commitment), where i 6= j and cond, cond1 , cond2 ∈ Cond. The former denotes that an agent adopting role ρi is obligated to an agent adopting role ρj for bringing about cond. The latter denotes that an agent adopting role ρi is obligated to an agent adopting role ρj to bring about cond2 if cond1 . Here, ρi is the debtor and ρj is the creditor, while cond1 is the precondition and cond2 is the condition. In the following, we use a \cdot (·) to mark parameters that are not relevant. Commitments are created, satisfied, and transformed in certain ways [31]. The following 6

OWL-P syntax cond(s1 , s2 , . . . , sn ) c(ρ1 , ρ2 , cond) cc(ρ1 , ρ2 , cond1 , cond2 ) msgA(ρ1 , ρ2 , s1 , s2 , . . . , sn ) msgF (ρ1 , ρ2 , s1 , s2 , . . . , sn ) msg(ρ1 , ρ2 , s1 , s2 , . . . , sn ) start ∧ F1 ⇒ msgA A1 ∧ F1 ⇒ msgA F1 ⇒ NMA1 A1 ∧ F1 ⇒ NMA1 msgF1 XOR msgF2 , msgF3 ⇒ msgA1 , msgF3 ⇒ msgA2

C+ mapping condition(iid, cond(s1 , s2 , . . . , sn )) :: action c(iid, ρ1 , ρ2 , cond) :: inertialFluent cc(iid, ρ1 , ρ2 , cond1 , cond2 ) :: inertialFluent act(iid, ρ1 , ρ2 , msg(s1 , s2 , . . . , sn )) :: action, ¬act(· · · , msg(· · ·)) causes ¬act(· · · , msg(· · ·)) f l(iid, ρ1, ρ2 , msg(s1 , s2 , . . . , sn )) :: inertialFluent act(· · · , msg(· · ·)) causes f l(· · · , msg(· · ·)) caused msgA if F1 ∧ ¬msgF A1 causes msgA if F1 ∧ ¬msgF caused NMA1 if F1 A1 causes NMA1 if F1 msgF3 ∧ ¬msgA2 ∧ ¬msgF1 ∧ ¬msgF2 causes msgA1 msgF3 ∧ ¬msgA1 ∧ ¬msgF1 ∧ ¬msgF2 causes msgA2

Table 2: OWL-P syntax and its mapping to C+ rules. A1 is an action formula (message actions, commitment conditions, or commitment operations), F 1 is a fluent formula (message fluents, commitments, or other fluents), and NMA1 is an action formula without messaging actions.

are the operations defined on conditional commitments: Op1. Op2. Op3. Op4. Op5. Op6. Op7.

cccreate(ρdb , ρcr , cond1 , cond2 ) establishes a conditional commitment. cccancel(·, ·, ·, ·) cancels the commitment. ccrelease(·, ·, ·, ·) releases ρdb from the commitment without it being fulfilled. ccdelegate(ρdb1 , ρcr , ρdb2 , ·, ·) replaces ρdb1 by ρdb2 as the debtor. ccassign(ρdb , ρcr1 , ρcr2 , ·, ·) replaces ρcr1 by ρcr2 as the creditor. ccdischarge(·, ·, ·, ·) denotes fulfillment of the commitment. cc2c(·, ·, ·, ·) denotes occurrence of the precondition.

A similar set of operations are defined for base-level commitments. A commitment is said to be active if it has been created, but not yet discharged. Discharge of a commitment is implicit and coincides with the satisfaction of the condition. The rules regarding discharge of a commitment are given below. Dis1. Dis2. Dis3.

c(ρdb ,ρcr ,cond)∧cond discharge(ρdb ,ρcr ,cond) cc(ρdb ,ρcr ,cond1 ,cond2 )∧cond1 create(ρdb ,ρcr ,cond2 )∧discharge(ρdb ,ρcr ,cond1 ,cond2 ) cc(ρdb ,ρcr ,cond1 ,cond2 )∧cond2 discharge(ρdb ,ρcr ,cond1 ,cond2 )

Rules Dis1, Dis2, and Dis3 correspond to operations cdischarge, cc2c, and ccdischarge, respectively. The protocol entities and commitment operations modeled in C+ are posted online [2] and not discussed here for brevity. 7

Table 2 presents the syntax and its mapping to C+ rules. The first six rows describe the mapping of the declarations. The declaration of msg maps to a causal rule that expresses the fact that all message actions are recorded in the history by inertial fluents. The message fluents cannot be explicitly caused in our syntax. This way, the message actions are stable, i.e., once they happen they remain in the history and cannot be retracted later. The two rules for the causation of message actions are mapped to C+ rules having an atom ¬msgF . This models our assumption that a message with identical parameters cannot be exchanged more than once. This assumption may be too limiting if the actions and fluents did not take a parameter iid to identify a unique protocol instance to which they belong (here the word “instance” is taken to mean an enacted instance of a protocol). A new instance of the protocol can be started by mechanisms external to our modeling here. Also, commitment fluents cannot be caused directly but only through the use of commitment operations. This allows us to support concurrent commitment operations.

2.3 Example Figure 3 shows scenarios from the protocols involved in the CrossFlow insurance example presented above. In the following, we provide specifications of these protocols as needed; the Appendices provide the specifications of Rep (administering repairs), Mon (monitoring outsourced handling), and Han (handling filed claims). For the ease of comprehension, Table 3 records the mapping of agents to the roles they adopt in various protocols presented in this paper. The codes in the brackets by the role names in Figure 3 are used as the debtor and creditor names in the commitments. Usually, each protocol is designed and maintained independently without assuming the existence of other protocols. Therefore, the ontologies of the protocols about similar concepts would differ. For example, driverID in Ins and driverNO in Rec refer to the same piece of information. As we shall see later, the composition axioms explicitly state which parameters are identified. On the other hand, two different protocols may use identical names for different concepts, e.g., the message pay in Han and Ins have quite different meanings. In this paper, we assume that no two protocols are identical and each protocol defines a unique namespace to which all names of the protocol belong. Below, we specify the insurance buying protocol (Ins ). The Buyer and the Seller roles engage in the Ins protocol for insuring the buyer. The rules for Ins are: Ins1. start ⇒ reqForQuoteA(B, S, driverID, coverage) Ins2. reqForQuoteF(B, S, driverID, coverage) ⇒ quoteA(S, B, driverID, policyNO, premium) Ins3. quoteA(S, B, driverID, policyNO, premium) ⇒ cccreate(S, B, subscribe(driverID, policyNO, premium), insurance) Ins4. quoteF(S, B, ·, policyNO, premium) ⇒ payA(B, S, policyNO, premium) Ins5. payA(B, S, policyNO, premium) ∧ quoteF(S, B, driverID, policyNO, premium) ⇒ subscribe(driverID, policyNO, premium) Ins6. ccreate(S, B, insurance) ∨ cc2c(S, B, ·, insurance) ⇒ cccreate(S, B, validServiceClaim, claimService) ∧ cccreate(S, B, reqForClaim, claimResponse) 8

Protocols

Bas Del

Ficp Fra Han Icp Ins Mon Out Pcsc Picp Rec Rep

AGFIL Insurer SuperCompany SuperCompany Insurer Company Insurer Seller Company Insurer Company Insurer Provider

Assessors

SubCompany Assessor Assessor Assessor Assessor

Agents Europ Assist Lee CS CallCenter SubCompany SubCompany SuperCompany SuperCompany CallCenter Consultant Consultant Handler CallCenter Consultant

CallCenter Assessor

CallCenter CallCenter

Consultant Consultant Consultant Consultant

Policy Holders Insured Client Client Client Client Insured Owner Insured Buyer Insured Owner Insured Reporter Owner

Table 3: A mapping of agents to the roles they adopt in various protocols discussed in the paper. The role names and their abbreviations: Assessor(A), Buyer(B), CallCenter(Ca), Client(Cl), Company(Com), Consultant(Con), Garage(G), Handler(H), Insured(Id), Insurer(Ir), Owner(O), Provider(P), Repairer(Rp), Reporter(Ro), Seller(S), SubCompany(Sb), SuperCompany(Sp)

Ins7. cdischarge(S, B, insurance) ⇒ ccdischarge(S, B, validServiceClaim, claimService) ∧ ccdischarge(S, B, reqForClaim, claimResponse) Ins8. C(S, B, insurance) ∧ ¬CC(S, B, validServiceClaim, claimService) ⇒ cccreate(S, B, validServiceClaim, claimService) Ins9. C(S, B, insurance) ∧ ¬CC(S, B, reqForClaim, claimResponse) ⇒ cccreate(S, B, reqForClaim, claimResponse) Rule Ins3 gives the meaning of quote message via creation of a conditional commitment, namely, that the insurance seller is committed to insuring the insurance buyer if the buyer subscribes for the insurance policy. The meaning of the subscribing condition is given by Rule Ins5; the buyer subscribes to the insurance by paying the quoted premium. Rule Ins6 means that to provide the insurance service, the seller must serve the buyer’s requests for handling the claim if the claim is valid, and the seller must respond to the claims filed by the buyer. Rule Ins7 means that once the insurance expires, the commitments to respond to the claims and provide service also expire. Rules Ins8 and Ins9 mean that as long as the insurance is valid, the commitments to respond to claims and provide service persist. Notice that the commitment condition insurance has no parameters. This is because it is not caused in this protocol and hence the designer cannot predict the relevant parameters for it. By deferring assignment of parameters to 9

Repairers

SubCompany Repairer Garage Repairer

Repairer Repairer

Ÿ¡  ¢2£ ¤¦¥n§,¨§7©ª#£ «¬K¢7¬­¯®§ƒ¥;£ °;£ ¨¢ª#£ «7¬ ±#² §,¨”³ gRh1ikjkl$mnh1lpong2jkq

r7s9t tur2h1v)mnh1lpopr7sq

Í «7¬7£ ªn«7¥#£ ¬·¸«7¶ªuµ«¶,¥’¨§,­ Î ¢7¬­  £ ¬· ±#Í «¬,³ ÇlpjșÉ$½.h l#ouÇq

wxzy{w$| }$~;w- €xzw ƒ‚,„;y1{6…  †z‡6ƒ‚,„6 ˆ1‰ { Š ‹’Œ| 1‚”“ }$†p… ‹p ‘,ƒ‚,„6~6w$ €6xpw ‚,„zy{…  †’‡;ƒ‚ƒ„; ˆ‰${Š ‹zy6yw-{6€x#~} ~w €6xzw ƒ‚,„#†#… ‹p ‘,7‚,„#y{…  †z‡#‚,Š ˆ1{|  ‰$ †#‹p|  {ˆ1} ~6wu €xnwƒ‚,„6†p… ‹# ‘,ƒ‚,„;y1{…  †z‡6ƒ‚,Š

 ˆ€{ †#xp}$†p… ‹p ‘,7‚,„#y1{6…  †p‡6ƒ‚,„6;Œ1{6| x6„;‹’yyw{€‹p… Š ‹zŒ| 1{w Ï;xzЋ’‡1} †#… ‹p ‘,7‚,„#y{…  †p‡#ƒ‚7„#Œ1{6| x;Š Ó ­¤Ô£ ¬,£ µ'ªu§7¥6£ ¬·Ô¥n§7©¢2£ ¥nµ ±6² §©³ Ñ Ò v™h1l#o Ñ q R g%h1i™s1É$lnhlpoug%ikq w$xpy1‹# wŽx#}†z… ‹# ‘7ƒ‚,„;y{…  †z‡#ƒ‚,Š

Æ ¢,¬­2  £ ¬·V°;£   §,­¯¨  ¢2£ ¤¯µ ±6Æ ¢7¬³ ¿_s lps1Àkhon¿_q

rƒj.v'Âz–™t m¾s1v)m’onr2jv™q

‹zˆ~… x#}$†p… ‹p ‘,ƒ‚ƒ„#y1{6…  †z‡6ƒ‚,Š

‹zŒ| Žx#6}$†p… ‹# ‘,7‚,„;~w €;xzw ƒ‚ƒ„#y{…  †’‡6ƒ‚,„6 ˆ‰${ Š

¼\s1vk½kt$h1lpo¾¼\q

r2jÊËiks9v)—opr7jÊÌq

wxzy6‹# w-x#~;}$†p… ‹z ‘,ƒ‚,„;y1{…  †z‡;7‚,Š w-x’y1‹# w-‚“ } †#… ‹# ‘7ƒ‚ƒ„py1{…  †’‡6ƒ‚,„6‹zyy;w-{€6‹#… Š

ÁÃÂ6ÂzhÂ6Â#j.lpo-Á\q

xzÄ-|  ‘‹’| x#} †#… ‹# ‘,ƒ‚,„;yw$ †#x#Š  ˆ9Ä-yxp†z| }-†’… ‹p ‘,ƒ‚,„;yw †px6Š

´ ¬µ¶,¥6£ ¬·¸© «2  £ ¨™¹»º,¶¹§,¥pµ ±´ ¬µ”³ •%–k—kh lpon•2q ˜'h1t$th9lpop˜™q

 ˆ Ä-yx#†z| x#~6}$†p… ‹# ‘,7‚,„#yw †’x6„6†p{ Ä-| Š ~xp‹#… }$†p… ‹p ‘,ƒ‚,„;yw$ †px6Š

w-xp6š){w›”Œ1{6| x#} ~6wu €x’w$œ „#†#{€6xzw-‹pžx;Š

Å  … … }$†p… ‹p ‘,ƒ‚ƒ„#yw †#x6„#‹zyyw{€‹p… Š y1‹’‡}-†p… ‹p ‘,ƒ‚,„;yw †#x6Š

6Œ1{;| xp}$~w €xzw œ$ƒ„;y{…  †z‡#‚,„zywuxn‘ Œ‘%Š y6‹z‡1} y1{…  †’‡6ƒ‚,„;yw$xp‘ Œ‘RŠ

Figure 3: Scenarios from the protocols corresponding to the insurance claim process of Figure 1 conditions not caused locally, we allow the protocol to be composed with other protocols in various ways depending on the application at hand. We shall see the details of this in Section 3.

2.4 Enacting a Protocol Enactment involves deriving role skeletons from the protocols, integrating them with the business logic of the agents adopting respective roles, and deploying them. Figure 4 depicts a typical usage scenario. These aspects are discussed in greater detail in [11] and some deployable examples are posted online [24, 25]. Here, we briefly discuss the integration of business logic with the protocols. Notice that slots driverID and coverage in Ins1, and slots policyNO and premium in Ins2 are not bound by the body. This may mean one of the two things: (1) the slots would be bound by another protocol that would be combined with this protocol before enactment, or (2) the slots would be bound by the business logic of the agents. The first case is discussed in Section 3. An example for the second case considering the role skeleton of an agent adopting the Seller role is here:

10

Software Designer

3 specify

AGFIL Composer

AGFIL Skeleton (Jess)

Axioms

2

Rec OWL-P

Del OWL-P

1 Protocol Repository I N S U R E D

Local Policy

+

Bas OWL-P

Ins OWL-P

register

+

AGFIL Local Process

Local Policy 7

6

4 5

Lookup Bas

Insured Skeleton (Jess)

OWLP2Jess

8 register

9

10 Insured Local Process

11

register

JMS JNDI Naming

Figure 4: A Typical Usage Scenario Seller skeleton rule (corresponding to Ins2): reqForQuoteF(driverID, coverage) ∧ quoteBL(driverID, coverage, policyNO, premium) ⇒ quoteA(driverID, policyNO, premium) Seller business logic stub (corresponding to Ins2): reqForQuoteF(’123456’, ’comprehensive’) ⇒ quoteBL(’123456’,’comprehensive’,’policy101’,’$239’) The fluents named with a trailing “BL” are asserted by the business logic. The trivial business logic stub rule in this example binds the policyNO and the premium in quoteA. Ideally, such values would be bound by consulting appropriate business rules.

3 Protocol Composition Any realistic business process would involve multiple interaction protocols. For example, AGFIL would need protocols for selling insurance policies and for receiving and handling claims. Here, we show how protocols can be combined to form a composite protocol. Let’s assume AGFIL outsources the help-line service for receiving claim reports to a call center, but handles the claims itself. The outsourcing can be modeled as commitment delegation in a generic protocol Del (Delegation of a business function to a partner) as follows: Del1. start ∧ CC(Sp, Cl, serviceReq, serviceRes) ⇒ offerDealA(Sp, Sb) Del2. offerDealA(Sp, Sb) ⇒ cccreate(Sp, Sb, commSub, commSuper) Del3. offerDealF(Sp, Sb) ⇒ acceptA(Sb, Sp) 11

Del4. offerDealF(Sp, Sb) ⇒ rejectA(Sb, Sp) Del5. acceptF(Sb, Sp) XOR rejectF(Sb, Sp) Del6. acceptA(Sb, Sp) ⇒ cccreate(Sb, Sp, commSuper, commSub) Del7. cccreate(Sb, Cl, serviceReq, serviceRes) ⇒ commSub Del8. cccreate(Sp, Sb, subCond, superCond) ⇒ commSuper Del9. acceptF(Sb, Sp) ⇒ delBusinessA(Sp, Sb) Del10. delBusinessA(Sp, Sb) ⇒ ccdelegate(Sp, Cl, Sb, serviceReq, serviceRes) ∧ cccreate(Sp, Sb, subCond, superCond) Del11. delBusinessF(Sp, Sb) ∧ CC(Sp, Cl, serviceReq, serviceRes) ⇒ ccdelegate(Sp, Cl, Sb, serviceReq, serviceRes) ∧ cccreate(Sp, Sb, subCond, superCond) AGFIL would play the superCompany and Europ Assist would play the subCompany roles. If AGFIL is committed to the client to respond to the calls (Rule Del1), AGFIL would offer a deal to Europ Assist that if Europ Assist commits to handling the calls (commSub) then AGFIL would commit to provide the requisite information for authorizing claims (commSuper, Rule Del2). If Europ Assist accepts the deal then AGFIL delegates its commitment to the client for responding to the calls (Rule Del10). Doing so creates the contractual commitments between AGFIL and Europ Assist (due to Rules Del7 and Del8). The contract between Europ Assist and AGFIL persists as long as AGFIL is committed to the client (Rule Del11). The claim receiving protocol Rec can be modeled as follows: Rec1. start ⇒ reportA(Ro, Ca, driverNO, policyNO, info) Rec2. reportF(Ro, Ca, ·, ·, ·) ⇒ authReqA(Ca, P, claimNO, driverNO, policyNO, info) Rec3. authReqF(Ca, P, ·, ·, ·, ·) ⇒ authOkA(P, Ca, ·, ·, ·, ·) Rec4. authReqF(Ca, P, ·, ·, ·, ·) ⇒ authNokA(P, Ca, ·, ·, ·, ·) Rec5. authOkF(P, Ca, ·, ·, ·, ·) XOR authNokF(P, Ca, ·, ·, ·, ·) Rec6. authOkF(P, Ca, ·, ·, ·, ·) ⇒ approvedA(Ca, Ro, driverNO, claimNO, policyNO) Rec7. authNokF(P, Ca, ·, ·, ·, ·) ⇒ deniedA(Ca, Ro, driverNO, claimNO, policyNO) Rec8. approvedF(Ca, Ro, ·, ·, ·) ⇒ notificationA(Ca, P, ·, ·, ·) Rules Rec3, Rec4, and Rec5 model the fact that actions authOkA and authNokA are mutually exclusive. The protocol for outsourced claim receiving and selling the insurance policies can be obtained by combining the Ins, Del, and Rec protocols appropriately yielding a new Bas (Basic insurance claim processing) composite protocol. As the ontologies of the protocols may not match, and they may have inter-dependencies, simply unioning the causal theories of the component protocols may not be enough. Specifically, some of the unbound slots of one protocol may have to be bound to slots of another protocol. Such constraints and dependencies are specified as a set of composition axioms. Below are a set of composition axioms for our example: . BasAx1. Bas.Insurer = Ins.Seller, Rec.Provider, Del.SuperCompany . BasAx2. Bas.Insured = Ins.Buyer, Rec.Reporter, Del.Client . BasAx3. Bas.CallCenter = Rec.CallCenter, Del.SubCompany BasAx4. Ins5.driverID ; Rec1.driverNO BasAx5. Ins5.policyNO ; Rec1.policyNO 12

BasAx6. Rec.reqForClaim → Del.serviceReq BasAx7. Rec.claimResponse → Del.serviceRes BasAx8. Rec.reportA(Ro, Ca, driverNO, policyNO, info) → Ins.reqForClaim(driverNO, policyNO, info) BasAx9. Rec.reportF(Ro, Ca, driverNO, policyNO, info) ∧ Rec.approvedA(Ca, Ro, claimNO, driverNO, policyNO) → Ins.claimResponse(driverNO, claimNO, policyNO) BasAx10. Rec.reportF(Ro, Ca, driverNO, policyNO, info) ∧ Rec.deniedA(Ca, Ro, claimNO, driverNO, policyNO) → Ins.claimResponse(driverNO, claimNO, policyNO) BasAx11. Rec.authReqA(Ca, P, claimNO, driverNO, policyNO, info) → Del.subCond(claimNO, driverNO, policyNO) BasAx12. Rec.authOkA(P, Ca, claimNO, driverNO, policyNO, info) ∧ Rec.authReq(Ca, P, claimNO, driverNO, policyNO, info) → Del.superCond(claimNO, driverNO, policyNO) BasAx13. Rec.authNokA(P, Ca, claimNO, driverNO, policyNO, info) ∧ Rec.authReq(Ca, P, claimNO, driverNO, policyNO, info) → Del.superCond(claimNO, driverNO, policyNO) BasAx14. Del.accept ≺ Rec.report The first three are Role definition axioms that define a new role specified on the left by identifying it with the roles on the right. Informally, the effect of these axioms is the substitution of the roles on the right by the roles on the left in the commitments and messages. Formally, say two protocols P=hρp , Sp , Mp , Rp , Condp , Commp i and Q=hρq , Sq , Mq , Rq , Condq , Commq i having |ρp | and |ρq | roles re. spectively, are being composed with n role definition axioms of the form ρ i = ρjp , k i ρq (0 ≤ i < n, 0 ≤ j < |ρp |, 0 ≤ k < |ρq |). Each ρ is distinct, and each ρjp and ρkq appears in exactly one axiom. Then, in the resulting composite protocol Rrd =hρrd , Srd , Mrd , Rrd , Commrd , Condrd i, the set of roles ρrd =ρ, therefore |ρrd |=n. Also, Srd =Sp ∪Sq , Condrd =Condp ∪Condq , and Rrd =Rp ∪Rq . With substitution, Mrd =(ρi /ρjp )Mp ∪(ρi /ρkq )Mq , and Commrd =(ρi /ρjp )Commp ∪(ρi /ρkq )Commq , where (a/b)E substitutes the name b in entity E by the name a. If the names of the entities in the two protocols conflict due to substitutions, the concerned entities can be renamed. Axioms BasAx4 and BasAx5 are Data flow axioms that specify the data flow from the slots on the left to the slots on the right (the slots on the right were originally unbound, see Section 2.4). Data flow composition is performed after the role definitions. Formally, data flow axioms are of the form rp .sp ; rq .sq , where rp ∈ Rp and rq ∈ Rq . Both rp and rq are of the form Ap ⇒ Cp and Aq ⇒ Cq respectively, where Ap , Aq (body), Cq , and Cq (head) are arbitrary formulas. Then, for the resulting composite protocol Rdf =hρdf , Sdf , Mdf , Rdf , Commdf , Conddf i, a new inertialFluent dfsp is defined. All the slots in parameters of Ap become the parameters of dfsp . A new causal law rdf of the form Ap ⇒ dfsp is added. Rule rq is modified to be rq0 of the form Aq ∧ dfsp ⇒ Cq . Hence, Rdf =Rrd ∪ {rdf } − {rq } ∪ {rq0 } and Sdf =(sp /sq )Srd . The rest of the entities are carried forward from the role definitions, i.e., E df =Erd , where E is ρ, M , Comm, or Cond. As an example, in BasAx4, an inertial fluent dfDriverID is defined. A causal rule:

13

payA(Id, Ir, policyNO, premium) ∧ quoteF(Ir, Id, driverID, policyNO, premium) ⇒ dfDriverID(driverID, policyNO, premium) is added and Rec1 is modified to be: start ∧ dfDriverID(driverID, policyNO, premium) ⇒ reportA(Id, Ca, driverID, policyNO, info) Thus, driverID in Rec1 will be bound to that in Ins5. Axioms BasAx6 to BasAx13 are Implication axioms. These axioms define the causation of the commitment conditions across protocols. Originally, these conditions were not caused locally and hence their precise meaning was unknown, e.g., reqForClaim in Ins (see Section 2.4). Implication composition is performed after the role definitions. Implication axioms come in two flavors. The first kind of implication axioms is of the form condp → condq , where condp ∈ Condp and condq ∈ Condq . Here, both of the conditions do not have parameters and cond q is simply renamed to condp . Hence, for the composite protocol Rim1 =hρim1 , Sim1 , Mim1 , Rim1 , Commim1 , Condim1 i, Condim1 =(condp /condq )Condrd . The rest of the entities are carried forward from Rrd , i.e., Eim1 =Erd , where E is ρ, S, M , R, or Comm. The second kind is of the form Ap → cond0q , where cond0q is of the form condq (s1 , s2 , . . . , sn ), Ap is an arbitrary formula consisting of constants of P, condq ∈ Condq , and si ∈ Sp (1 ≤ i ≤ n) are bound by Ap . Then, for the resulting composite protocol Rim2 =hρim2 , Sim2 , Mim2 , Rim2 , Commim2 , Condim2 i, Condim2 = (cond0q /condq )Condim1 and Rim2 =Rim1 ∪ {Ap ⇒ cond0q }. The rest of the entities are carried forward from Rim1 , i.e., Eim2 =Eim1 , where E is ρ, S, M , or Comm. As an example, for BasAx8, which is the second kind of implication axiom, the condition reqForClaim in Ins is modified to be reqForClaim(driverID, policyNO, info), and a new causal rule: reportA(Id, Ca, driverID, policyNO, info) ⇒ reqForClaim(driverID, policyNO, info) is added. Axiom BasAx14 is an Event order axiom that constrains the ordering among the events by specifying that a call center must have accepted the deal to handle calls before a policy holder can report claims. Event order constraints are effected after role definitions. Formally, an event order axiom is of the form msgF p ≺ msgFq , where msgp ∈ Mp and msgq ∈ Mq . To effect the constraint, a new inertial fluent eoMsg is defined having parameters identical to msgp . A causal rule reo of the form msgFp ⇒ eoMsg is added to the theory. For all rules rq of the form Aq ⇒ Cq where Aq and Cq are arbitrary formulas and Cq contains as one of its atoms msgAq , rq is modified to be rq0 of the form Aq ∧ eoMsg ⇒ Cq . Hence, for the resulting composite protocol Reo =hρeo , Seo , Meo , Reo , Commeo , Condeo i, Reo =Rrd ∪{reo }−{rq }∪{rq0 }. The rest of the entities are carried forward from Rrd , i.e., Eeo =Erd , where E is ρ, S, M , Comm, and Cond. For example, in BasAx14, an inertial fluent eoAccept is defined. A causal rule: 14

acceptF(Ca, Ir) ⇒ eoAccept is added. And the rule Rec1 is modified to be: start ∧ eoAccept ⇒ reportA(Id, Ca, driverNO, policyNO, info) This way, accept must happen before report. The causal rules for Bas are given in Appendix A. The types of composition axioms described here are not necessarily comprehensive. If deemed necessary, new types of axioms can be defined for other kinds of transformations. As we shall see later, Del is general enough to be reused for modeling various kinds of delegations. Composite protocols like Bas can be treated and enacted like other protocols.

4 Adapting Processes Here, by studying the case of insurance process, we show how OWL-P naturally allows process redesign through adaptation. We achieve this by applying our basic mechanism of protocol composition in a variety of ways. Each of the adaptations presented below feature varying degrees of autonomy, heterogeneity, and dynamism. In the following, we assume that a composite protocol Picp (Partial insurance claim processing) is constructed from the composition of Bas, Mon, Han, and Rep along with Del for partnership formation between AGFIL and Lee CS, Lee CS and the repairers, and Lee CS and the assessors. As a result of the partnerships and delegations performed by Del, the agents have persistent contracts among them as shown in Figure 5. For brevity, instead of describing how such commitments among the agents are created via various compositions of Del, we model the start of the protocols as being conditioned on the existence of such contracts, e.g., Fra15. Note that the role names in such commitments would not match those in Figure 5, and must be derived from Table 3. Appendices C, B, and D provide the specifications of the rest of the protocols in CrossFlow in this fashion. è'è'éê™ë ìpí$î1ìzï6ðzñ ò îó1ô’õïò ö’ôzè'ñ ðzò ÷Rìpözñ ðzò ÷Ró6ôpõ$ï;ò ö’ô;ø Ü Ù)ÝuÞ9Û-Øß å Ø ã Öæ Û-ØÛ è™è'é è'ð;ì’í-îìpõ$ôzþ#ÿ9ú6õ ñ ðzò ÷ì özñ ðzò ÷7êôzü$ëú#û1ü-ôzø ç2ݒݾØÝ’Ý á Û ' è  é ’ ö 6 ú  ÷ # ì $ í  î # ì ò  û
ü õ ðpûö’ô#ø ՔÖ;× × ÕØ;Ù1ÚØ;Û è'è'é ù7ìpèú#û1ì;ò û1ü-ë;ôzöpý êôzþ6ì ò û1ü ëôzöný ê'ôzünø

è™è'é$è'ú;÷2ì#è'ðzìü
è'ú6ûîì ü ëônõ$è'ú;û6î1ø

Õ á ÙÝuÞ9× Ú ÖÙ1Ú à#á9â%ã ÖÙä è'è'éè'ú6÷ì;è'úzû ì;öpú#û ü
6ñ ý ò û1óôpõï6ò özô;ì ë6ð ÿ9ú#õuóônõ-ï6ò özôzø

Figure 5: Contractual commitments among the agents adopting roles in Picp 15

4.1 Exception Handling        ! #" $  % &'( ) *

+-,$./102304+#05

F G $   H " $  % &F *

IKJ LMNPOQ ;R±m°³t­3® ²°º

¯°½ ½ ¶ °'µt²¶ «® ·¸V¹Vºf«·¥Í»3ÎB½ ¼

´m«'Ð3Ó>ÍB³±3°'³-­f® ²'°f¼ ¾ ¿KÀÁDÂÔ

Figure 7: Change in Business Policy (Insured(Id), Repairer(Rp), CallCenter(Ca), and Assessor(A) are not shown for Picp and Repairer(Rp) is not shown for Pcsc )

4.2 Changes in Business Policy In handling claims where the value of the car is less than the estimated cost of repairs, the insurance company may want to scrap the car, i.e., declare it a total loss. To settle this, it pays the insured party a sum equal to the value of the car and takes possession of the car instead of administering repairs. Also, if the damage is minor, the insured party may accept a cash settlement instead of having the car repaired. Here is the specification of a protocol Pcsc (shown in Figure 7) that specifies interactions for such a policy: Pcsc1. start ∧ CC(Rp, O, validServiceReq, claimService) ⇒ adviseScrapA(Con, Com, claimNO, value) Pcsc2. adviseScrapA(Con, Com, claimNO, value) ⇒ ccdelegate(Rp, O, Com, validServiceReq, claimService) 17

Pcsc3. adviseScrapF(Con, Com, claimNO, value) ⇒ settleA(Com, O, claimNO, value) Pcsc4. start ⇒ adviseCashA(Con, Com, claimNO, amount) Pcsc5. adviseCashA(Con, Com, claimNO, amount) ⇒ ccdelegate(Rp, O, Com, validServiceReq, claimService)) Pcsc6. adviseCashF(Con, Com, claimNO, amount) ⇒ cashOfferA(Com, O, claimNO, amount) Pcsc7. cashOfferA(Com, O, claimNO, amount) ⇒ cccreate(Com, O, acceptCash(claimNO, amount), settlement(claimNO, amount)) Pcsc8. cashOfferF(Com, O, claimNO, amount) ⇒ acceptA(O, Com, claimNO, amount) Pcsc9. cashOfferF(Com, O, claimNO, amount) ⇒ rejectA(O, Com, claimNO, amount) Pcsc10. rejectF(O, Com, claimNO, amount) XOR acceptF(O, Com, claimNO, amount) Pcsc11. acceptA(O, Com, claimNO, amount) ∧ cashOfferF(Com, O, claimNO, amount) ⇒ acceptCash(claimNO, amount) Pcsc12. acceptF(O, Com, claimNO, amount) ⇒ settleA(Com, O, claimNO, amount) Pcsc13. settleA(Com, O, claimNO, amount) ∧ acceptF(O, Com, claimNO, amount) ⇒ settlement(claimNO, amount) AGFIL would have delegated its conditional commitment CC(S, B, validServiceReq, claimService) to Lee CS, and Lee CS would in turn have delegated it to the repairers.

When the consultant advises to scrap the car, it fulfills its commitment to provide the consulting service and the commitment to service the claim falls back to the insurance company as the car is not to be repaired but to be paid for. Similarly, when the consultant advises a cash payment for a minor damage, and the insured party agrees to it, it fulfills the commitment for the consulting service and the insurance company becomes committed to paying the insurance holder. Rules Pcsc1 and Pcsc4 model these by delegation. Assuming that Picp is the current protocol of interaction among the partners, Pcsc can be composed with Picp yielding the composite protocol Icp (Insurance claim processing) that handles this policy change by the following composition axioms:

. IcpAx1. Icp.Insured = Picp.Insured, Pcsc.Owner . IcpAx2. Icp.Insurer = Picp.Insurer, Pcsc.Company . IcpAx3. Icp.Consultant = Picp.Consultant, Pcsc.Consultant . IcpAx4. Icp.Repairer = Picp.Repairer . IcpAx5. Icp.CallCenter = Picp.CallCenter . IcpAx6. Icp.Assessor = Picp.Assessor IcpAx7. Picp .claimNO ; Pcsc1.claimNO IcpAx8. Pcsc.adviseScrapA(Con, Com, claimNO, value) → Picp.consultingService(claimNO, ·) IcpAx9. Pcsc.adviseCashF(Com, O, claimNO, amount) ∧ Pcsc.acceptA(O, Com, claimNO, amount) → Picp.consultingService(claimNO, ·) IcpAx10. Pcsc.settlementA(Com, O, claimNO, amount) ∧ Pcsc.acceptF(O, Com, claimNO, amount) → Picp.claimService(claimNO, ·) IcpAx11. Pcsc.settlementA(Com, O, claimNO, amount) ∧ Pcsc.adviseScrap(Con, Com, claimNO, value) → Picp.claimService(claimNO, ·) Figure 7 shows the composition graphically. Notice how a business policy change 18

internal to AGFIL is accommodated across the business process. Here, structural dynamism emerges from the modified interconnections among the existing partners to handle the policy change. Support for heterogeneity is also featured due to the fact that a change of business logic internal to AGFIL could be accommodated.

4.3 Changes in Business Model Quite often enterprises change their business model to respond to changes in their business environment. Business process outsourcing (BPO) [15] has recently become a popular mode of conducting business. The composition of Bas discussed in Section 3 already illustrated this kind of adaptation. AGFIL outsourced the call reception to Europ Assist to focus on its core business of selling insurance policies. Thus, the business model of AGFIL changed to have a partnership with Europ Assist. Of course, here we are assuming that AGFIL originally handled the claims by itself some how. Obviously, a change in the business model is a big shift for an enterprise; new partnerships are formed and new interconnections among the parties emerge. Thus, such a change features not only structural dynamism, but also design-time membership dynamism.

5 Discussion and Future Work In this paper, we demonstrated the value of taking an interaction-oriented approach to adapting business processes. Business processes have been traditionally modeled as workflows. However, unlike OWL-P, workflows are task-based approaches. Such approaches suffer from the limited flexibility, resusability, and adaptability as outlined in Section 1. Also, they do not target the challenges of open environments. These factors make workflows unsuitable for handling inter-organizational processes. [18, 6]. Business Process Execution Language (BPEL) [4] (originally WSFL and FlowMark) provides a standardized way of specifying a composite service by orchestration of component services. Due to its grounding in Web services, BPEL addresses the challenge of heterogeneity better than workflows. However, the idea of orchestration itself is inherently centralized; the autonomy of the component services is compromised. Also, BPEL inherits the task-based philosophy from workflows; the tasks in workflows have become component services in BPEL. The strength of task-based modeling is that thinking in terms of tasks and flows is intuitive to the designers. However, such abstractions don’t lend themselves well when it comes to the challenges we target in this paper. Lastly, neither workflows nor BPEL allow systematic adaptations like OWL-P. Aspect-Oriented Software Development (AOSD) [1] is a software engineering paradigm focusing on the separation of concerns. AOSD first partitions the requirements in terms of aspects such as logging, security, and quality-of-service. Next, it shows how the aspects can be implemented in a modular manner and layered on top of each other. Doing so allows independent engineering of each of the partitions. Interaction protocols and business logic in OWL-P can be seen as two different aspects of a process. In principle, aspects can be layered, and reconfigured to allow adaptability. However, AOSD 19

applications have been limited to extra-functional aspects like logging, security, and quality-of-service. Also, the basic assumption that the aspects are independent, is too limiting. Component protocols themselves can be viewed as aspects of the composite protocols, and component protocols almost invariably have interdependencies. OWL-P handles such dependencies by the composition axioms; AOSD does not have a counterpart of such axioms. Vitteau et al. studied composing protocols from microprotocols in a bottom-up manner. Microprotocols can be composed in three ways: parallel, sequential, loop. However, they cannot be composed with dependencies among the events. Thus, microprotocols in a protocol cannot arbitrarily interleave. . Our composition axioms only define the dependencies, thus allowing more possibilities. Composite protocols can also be built in a top-down manner by associating refinements with abstract transitions in Colored Petri Nets [21]. Again, the refinements cannot interleave with the protocol and thus arbitrary dependencies cannot be handled. OWL-S [10] and the Semantic Web Services Framework (SWSF) [32] are two representative efforts in the semantic web services arena. modeling business processes. OWL-S includes a process model for Web services and uses semantic annotations to facilitate dynamic composition. Each atomic service is formalized via its IOPEs (Inputs, Outputs, Preconditions, and Effects). Service composition is thus reduced to planning. While dynamic service composition has some advantages, e.g., ability to replan, reselect, and rebind to services, it assumes a perfect markup and an ontological matching of the services being composed. For this reason, we do not emphasize dynamic service composition. Our goal is to provide a human designer with tools to facilitate service composition. OWL-S is not specifically geared towards supporting autonomy and dynamism. OWL-S services are similar to workflow tasks, only enhanced with semantic annotations. SWSF improves on the limitations of OWL-S. Specifically, SWSF explicitly models messages and interactions. Also, the language for specifying processes is highly expressive. However, such an expressiveness comes at the cost of comprehensibility, making it intimidating for a practitioner to specify a process in SWSF. Also, dynamism is not explicitly addressed in SWSF. Agents (and therefore interactions) are natural abstractions if the autonomy of the participants is to be supported. Several agent-oriented software methodologies like Tropos [5], Gaia [33], and others [16, 3] have emerged that support the modeling of inter-organizational applications such as business processes. In these approaches, however, protocols are designed from first principles usually depending on the organizational structure. As such, they do not exploit protocols as first-class abstractions. Our approach complements these methodologies by treating protocols as building blocks that can be composed and adapted. Also, some of the agent architectures are based on mentalistic notions of belief, desire, and intentions. Although such architectures allow a high degree of autonomy, they pose difficulties for compliance verification, which is crucial for open environments. OMG’s Model-Driven Architecture [23] has gained significant ground as a software development methodology recently. MDA promotes multiple levels of abstractions (or models) of a system, namely, Computation Independent Model (CIM), Platform Independent Model (PIM), and Platform Specific Model (PSM). Automatic transformations between these models can be defined, allowing a much better way of handling a change 20

at a particular level. In this regard, MDA is the most relevant effort when it comes to adaptation. The core of MDA is complementary to our approach in that OWL-P can adopt a model-driven development approach while supporting the challenges of the open environments.

5.1 Open Questions Business process adaptation in general is a tremendous research challenge. This paper is a first step in addressing it. Here, we discuss what important aspects of this challenge are left open by this paper. 1. Successfully handling the kinds of changes described in this paper takes more than a change of design. In particular, a change in the business model may trigger a variety of changes in the organization structure that are not captured by our current treatment of protocols. Sociological factors such as authority, responsibility, and trust are also relevant. Our current treatment of commitments and operations over them is a simplistic model of some of these. 2. The ability to adapt at run-time is crucial for the success of an enterprise [14, 30]. This does not necessarily mean the adaptation has to be automated. What it means, however, is that the enterprise must monitor the environment and anticipate the change. Doing so allows it to be prepared to adapt on-demand. How can we model such an enterprise? 3. What can be said about the relationships between the composite and the component protocols? For instance, does the composite protocol simulate (in the sense of process algebra [27]) each of the component protocols? Also, it is valuable to know what properties of the component protocols are preserved by protocol composition. In a similar vein, the ability to model check the composite protocols for various desired and undesired properties is crucial. 4. The kinds of composition axioms presented in this paper are not necessarily comprehensive. For instance, what if a message needs an additional parameter? Certainly, a new composition axiom for modifying the message parameters can be defined. However, it is useful to determine whether the set of composition axioms is adequate and comprehensive with respect to a set of desired adaptations.

5.2 Future Plan Each of the questions posed in Section 5.1 is an opportunity for future research. However, we plan to focus on questions 1 and 2. Taken together, these two questions define an area of research that studies the adaptivity of an enterprise. Here, adaptivity means the responsiveness to the changes, good or bad. Responding to good changes is tantamount to exploiting the opportunities, whereas responding to bad changes is tantamount to recovering from failures. What does it take to improve the adaptivity of an enterprise?

21

Here’s a real motivating business story of year 2000 [20, 30]. A Philips factory in New Mexico, USA, supplied two major mobile phone vendors, Ericsson and Nokia. A small fire broke out in this factory by a lightning bolt. The fire department moved quickly and the fire was out in less than 10 minutes. A routine investigation showed that the fire was minor and the damage superficial. Philips notified both Nokia and Ericsson about the incident promptly. Ericsson brushed aside the small incident as routine and waited for the upcoming shipments from Philips. Nokia on the other hand stayed in touch with Philips and monitored the situation actively. As the fate would have it, although the fire itself did not cause much damage, the water from the sprinkler system of the plant had severely damaged the clean rooms and ready-to-ship components of the plant. Philips either did not realize or did not communicate this news to its customers for weeks. Nokia was able to respond to this new development in various ways. Apparently, Nokia’s CEO had high-level talks with Philips executives to negotiate additional supplies of the needed component from other Philips plants. Nokia was also successful in finding alternative sources. By contrast, Ericsson did not find out about the extent of the damage until it was too late and by that time Nokia had already secured almost all the alternative supplies of the components from the market. It is widely believed that as a consequence, Ericsson was not able to supply as many phones to the market as Nokia (during the crucial Holiday season), and lost substantial market share and revenues to the tune of half a billion dollars. There are two orthogonal aspects of organizations that relate to adaptivity: structure and behavior [12]. Although adaptivity is inherently a behavioral concept, structure plays a crucial role in facilitating adaptive behavior. Question 1 above is about modeling the structure of organizations to be adaptive. Question 2 is about modeling the adaptive behavior of organizations. Organization Structure The structure of organizations is derived from relationships among their member agents. What way of modeling the relationships among the agents allows greater adaptivity of the organizations processes? Other researchers agree that organizations are structured along multiple aspects. However, as is evident from the many attempts to understand the concepts like power [19, 26], responsibility [17, 7, 29, 8], and influence[28] are closely related to each other. We aim to apply such concepts to model the relationships among the agents in an organization. Organization Behavior The behavior of an organization is derived from its interactions with its business partners. The behavior is adaptive if it is responsive to the changes in its environment. This paper described how the design of the processes can be adapted via protocol composition. However, mechanisms for monitoring not only the environment, but also the partners’ actions is vital to adaptivity. Also, the monitored information needs to be analyzed and decisions be made. Our goal is to integrate these mechanisms with the business processes. The questions to be answered are: 1. What are the relationships among the normative concepts such as power, responsibility, obligation, delegation, authority, and permission? Answering this question allows us to model the relationships among the members of the organizations. 22

2. How does the structure affect the behavior? Given the structure of the organization modeled by the relationships among the members, it should be possible to characterize the structures by characterizing their effects on the behavior of the organization. 3. Given a set of threats and opportunities, is there an ideal structure and behavior for responding to them? If so, how to derive it? Answering this question requires modeling threats and opportunities, and deriving the effects of structure and behavior on them. For example, should there be a snowfall, monitoring the weather forecast reduces the risk of a driving accident. Another good response to snowfall could be to choose an all-wheel drive vehicle. Is one better than the other? 4. Given the current structure and behavior of an organization, and the desired structure and behavior of it, how to carry out the adaptation? Answering this question would require technical details of the modeling techniques for structure and behavior. Specifically, the models should be conducive to such transformations.

6 Acknowledgments We thank Amit Chopra for help with formulating some of the examples presented in this paper in C+. This research was partially supported by the NSF under grant DST0139037 and by DARPA under contract F30603-00-C-0178.

References [1] Aspect oriented http://aosd.net.

software

development

community

and

conference.

[2] OWL-P upper ontology in C+, 2006. http://www4.ncsu.edu/∼nvdesai/qual/. [3] Federico Bergenti, Marie-Pierre Gleizes, and Franco Zambonelli, editors. Methodologies and Software Engineering for Agent Systems. Kluwer, 2004. [4] BPEL. Business process execution language for web services, version 1.1, February 2005. www-106.ibm.com/developerworks/webservices/library/ws-bpel. [5] Paolo Bresciani, Anna Perini, Paolo Giorgini, Fausto Guinchiglia, and John Mylopolous. Tropos: An agent-oriented software development methodology. Journal of Autonomous Agents and Multi-Agent Systems, 8(3):203–236, May 2004. [6] Christoph Bussler. The role of B2B protocols in inter-enterprise process execution. In TES ’01: Proceedings of the Second International Workshop on Technologies for E-Services, pages 16–29, 2001.

23

[7] Laurence Cholvy, Fr´ed´eric Cuppens, and Claire Saurel. Towards a logical formalization of responsibility. In Proceedings of International Conference on Artificial Intelligence and Law, pages 233–242, 1997. [8] Rosaria Conte and Mario Paolucci. Responsibility for societies of agents. Journal of Artificial Societies and Social Simulation, 7(4), 2004. [9] CrossFlow consortium / AGFIL. Insurance (motor damage claims) scenario. Technical report, CrossFlow consortium, 1999. Document identifier: D1.a, http://www.crossflow.org. [10] DAML-S. DAML-S: Web service description for the semantic Web. In Proceedings of the 1st International Semantic Web Conference (ISWC), July 2002. Authored by the DAML Services Coalition, which consists of (alphabetically) Anupriya Ankolekar, Mark Burstein, Jerry R. Hobbs, Ora Lassila, David L. Martin, Drew McDermott, Sheila A. McIlraith, Srini Narayanan, Massimo Paolucci, Terry R. Payne and Katia Sycara. [11] Nirmit Desai, Ashok U. Mallya, Amit K. Chopra, and Munindar P. Singh. Interaction protocols as design abstractions for business processes. IEEE Transactions on Software Engineering, 31(12):1015–1027, 2005. [12] Gary Dressler. Organization Theory: Integrating Structure and Behavior. Prentice-Hall, 1986. [13] Enrico Giunchiglia, Joohyung Lee, Vladimir Lifschitz, Norman McCain, and Hudson Turner. Nonmonotonic causal theories. Artificial Intelligence, 153(12):49–104, 2004. [14] Kenyon B. De Greene. The Adaptive Organization: Anticipation and Management of Crisis. Wiley, 1982. [15] Paul Harmon. Business Process Change: A Manager’s Guide to Improving, Redesigning, and Automating Processes. Morgan Kaufmann, 2002. [16] Brian Henderson-Sellers and Paolo Giorgini. Agent-Oriented Methodologies. IDEA Group Publishing, 2005. [17] Nicholas R. Jennings. On being responsible. In Eric Werner and Yves Demazeau, editors, Decentralized AI-3, pages 93–102. Elsevier, 1992. [18] Nicholas R. Jennings, Peyman Faratin, Timothy J. Norman, Paul O’Brien, and Brian Odgers. Autonomous agents for business process management. International Journal of Applied Artificial Intelligence, 14(2):145–189, 2000. [19] Andrew J. I. Jones and Marek Sergot. A formal characterisation of institutionalized power. Journal of the IGPL, 4(3):429–445, 1996. [20] Almar Latour. Trial by fire: A blaze in albuquerque sets off major crisis for cell-phone giants. Wall Street Journal, January 2001. 24

[21] Hamza Mazouzi, Amal El Fallah Seghrouchni, and Serge Haddad. Open protocol design for complex interactions in multi-agent systems. In Proceedings of the First International Joint Conference on Autonomous Agents and Multiagent Systems, pages 517–526, 2002. [22] Object Management Group (OMG). Unified Modeling Language (UML), Version 2.0. http://www.omg.org/technology/documents/formal/uml.htm. [23] OMG. MDA: Model driven architecture. http://www.omg.org/mda. [24] OWL-P Examples. Business protocols http://research.csc.ncsu.edu/mas/OWL-P/.

modeled

[25] OWL-P Project. Software, tools, http://projects.semwebcentral.org/projects/owlp/.

and

with

owl-p.

documentation.

[26] Ingmar P¨orn. The Logic of Power. Basil Blackwell, 1970. [27] Milner Robin. Communicating and Mobile Systems: the pi-Calculus. Cambridge University Press, 1999. [28] Filipe Santos and Jos´e Carmo. Indirect action, influence, and responsibility. In Michael Brown and Jos´e Carmo, editors, Deontic Logic, Agency, and Normative Systems, Workshops in Computing, pages 194–215. Springer, 1996. [29] Filipe Santos, Andrew Jones, and Jos´e Carmo. Responsibility for action in organizations: A formal model. In Ghita Holmstr¨om-Hintikka and Raimo Tuomela, editors, Contemporary Action Theory, volume 2, pages 333–350. Kluwer, 1997. [30] Yossi Sheffi. The Resilient Enterprise: Overcoming Vulnerability for Competitive Advantage. MIT Press, 2005. [31] Munindar P. Singh. An ontology for commitments in multiagent systems: Toward a unification of normative concepts. Artificial Intelligence and Law, 7:97–113, 1999. [32] SWSF Committee. SWSF: www.daml.org/services/swsf/.

Semantic

web

services

framework.

[33] Franco Zambonelli, Nicholas R. Jennings, and Michael Wooldridge. Developing multiagent systems: The gaia methodology. ACM Transactions on Software Engineering Methodology, 12(3):317–370, 2003.

A

Protocol Bas

Bas1. start ⇒ reqForQuoteA(Id, Ir, driverID, coverage) Bas2. reqForQuoteF(Id, Ir, driverID, coverage) ⇒ quoteA(Ir, Id, driverID, policyNO, coverage) 25

Bas3. quoteA(Ir, Id, driverID, policyNO, premium) ⇒ cccreate(Ir, Id, subscribe(driverID, policyNO, premium), insurance) Bas4. quoteF(Ir, Id, ·, policyNO, premium) ⇒ payA(Id, Ir, policyNO, premium) Bas5. payA(Id, Ir, policyNO, premium) ∧ quoteF(Ir, Id, driverID, policyNO, premium) ⇒ subscribe(driverID, policyNO, premium) Bas6. ccreate(Ir, Id, insurance) ∨ cc2c(Ir, Id, ·, insurance) ⇒ cccreate(Ir, Id, validServiceClaim, claimService) ∧ cccreate(Ir, Id, reqForClaim(driverID, policyNO, info), claimResponse(driverID, claimNO, policyNO)) Bas7. cdischarge(Ir, Id, insurance) ⇒ ccdischarge(Ir, Id, validServiceClaim, claimService) ∧ ccdischarge(S, B, reqForClaim(driverID, policyNO, info), claimResponse(driverID, claimNO, policyNO)) Bas8. C(Ir, Id, insurance) ∧ ¬CC(Ir, Id, validServiceClaim, claimService) ⇒ cccreate(Ir, Id, validServiceClaim, claimService) Bas9. C(Ir, Id, insurance) ∧ ¬CC(S, B, reqForClaim(driverID,policyNO,info), claimResponse(driverID,claimNO,policyNO)) ⇒ cccreate(S, B, reqForClaim(driverID, policyNO, info), claimResponse(driverID, claimNO, policyNO)) Bas10. start ∧ dataFlowPolicyNO(driverID, policyNO, premium) ∧ dfDriverID(driverID, policyNO, premium) ∧ eoAccept ⇒ reportA(Id, Ca, driverID, policyNO, info) Bas11. reportF(Id, Ca, ·, ·, ·) ⇒ authReqA(Ca, Ir, claimNO, driverID, policyNO, info) Bas12. authReqF(Ca, Ir, ·, ·, ·, ·) ⇒ authOkA(Ir, Ca, ·, ·, ·, ·) Bas13. authReqF(Ca, Ir, ·, ·, ·, ·) ⇒ authNokA(Ir, Ca, ·, ·, ·, ·) Bas14. authOkF(Ir, Ca, ·, ·, ·, ·) XOR authNokF(Ir, Ca, ·, ·, ·, ·) Bas15. authOkF(Ir, Ca, ·, ·, ·, ·) ⇒ approvedA(Ca, Id, driverID, claimNO, policyNO) Bas16. authNokF(Ir, Ca, ·, ·, ·, ·) ⇒ deniedA(Ca, Id, driverID, claimNO, policyNO) Bas17. approvedF(Ca, Id, ·, ·, ·) ⇒ notificationA(Ca, Ir, ·, ·, ·) Bas18. start ∧ CC(Ir, Id, reqForClaim(driverID, policyNO, info), claimResponse(driverID, claimNO, policyNO)) ⇒ offerDealA(Ir, ca) Bas19. offerDealA(Ir, Ca) ⇒ cccreate(Sp, Sb, commSub, commSuper) Bas20. offerDealF(Ir, Ca) ⇒ acceptA(Ca, Ir) Bas21. offerDealF(Ir, Ca) ⇒ rejectA(Ca, Ir) Bas22. acceptF(Ca, Ir) XOR rejectF(Ca, Ir) Bas23. acceptA(Ca, Ir) ⇒ cccreate(Ca, Ir, commSuper, commSub) Bas24. cccreate(Ca, Id, reqForClaim(driverID, policyNO, info), claimResponse(driverID, claimNO, policyNO)) ⇒ commSub Bas25. cccreate(Ir, Ca, subCond(claimNO, driverID, policyNO, info), superCond(claimNO, driverID, policyNO, info)) ⇒ commSuper Bas26. acceptF(Ca, Ir) ⇒ delBusinessA(Ir, Ca) Bas27. delBusinessA(Ir, Ca) ⇒ ccdelegate(Ir, Id, Ca, reqForClaim(driverID, policyNO, info), claimResponse(driverID, claimNO, policyNO)) ∧ cccreate(Ir, Ca, subCond(claimNO, driverID, policyNO, info), superCond(claimNO, driverID, policyNO, info)) Bas28. delBusinessF(Ir, Ca) ∧ CC(Ir, Id, reqForClaim(driverID, policyNO, info), claimResponse(driverID, claimNO, policyNO)) ⇒ ccdelegate(Ir, Id, Ca, reqForClaim(driverID, policyNO, info), claimResponse(driverID, claimNO, policyNO)) ∧ cccreate(Ir, Ca, subCond(claimNO, driverID, policyNO, info), superCond(claimNO, driverID, policyNO, info)) 26

Bas29. payA(Id, Ir, policyNO, premium) ∧ quoteF(Ir, Id, driverID, policyNO, premium) ⇒ dfDriverID(driverID, policyNO, premium) Bas30. payA(Id, Ir, policyNO, premium) ∧ quoteF(Ir, Id, driverID, policyNO, premium) ⇒ dfPolicyNO(driverID, policyNO, premium) Bas31. reportA(Id, Ca, driverID, policyNO, info) ⇒ reqForClaim(driverID, policyNO, info) Bas32. approvedA(Ca, Id, driverID, claimNO, policyNO) ∧ reportF(Id, Ca, driverID, policyNO, info) ⇒ claimResponse(driverID, claimNO, policyNO) Bas33. deniedA(Ca, Id, driverID, claimNO, policyNO) ∧ reportA(Id, Ca, driverID, policyNO, info) ⇒ claimResponse(driverID, claimNO, policyNO) Bas34. authReqA(Ca, Ir, claimNO, driverID, policyNO, info) ⇒ subCond(claimNO, driverID, policyNO, info) Bas35. authOkA(Ca, Ir, claimNO, driverID, policyNO, info) ∧ authReqF(Ca, Ir, claimNO, driverID, policyNO, info) ⇒ superCond(claimNO, driverID, policyNO, info) Bas36. authNokA(Ca, Ir, claimNO, driverID, policyNO, info) ∧ authReqF(Ca, Ir, claimNO, driverID, policyNO, info) ⇒ superCond(claimNO, driverID, policyNO, info) Bas37. acceptF(Ca, Ir) ⇒ eoAccept

B Protocol Han Han1. start ∧ CC(A, H, inspectReq(claimNO, price), inspectRes(claimNO, price)) ⇒ estimateA(G, H, claimNO, price) Han2. estimateA(G, H, claimNO, price) ⇒ cccreate(G, H, acceptEstimate(claimNO, price), performRepair(claimNO)) Han3. estimateF(G, H, claimNO, price) ⇒ dealA(H, G, claimNO, price) Han4. estimateF(G, H, claimNO, price) ⇒ noDealA(H, G, claimNO, price) Han5. dealF(H, G, claimNO, price) XOR noDealF(H, G, claimNO, price) Han6. dealA(H, G, claimNO, price) ⇒ cccreate(H, G, performRepair(claimNO), payment(claimNO, price)) Han7. dealA(H, G, claimNO, price) ∧ estimateF(G, H, claimNO, price) ⇒ acceptEstimate(claimNO, price) Han8. dealF(H, G, claimNO, price) ⇒ billA(G, H, claimNO, price, approval) Han9. billA(G, H, claimNO, price, approval) ∧ dealF(claimNO, price) ⇒ performRepair(claimNO) Han10. billF(G, H, claimNO, price, approval) ⇒ payA(H, G, claimNO, price) Han11. payA(H, G, claimNO, price) ∧ billF(G, H, claimNO, price, approval) ⇒ payment(claimNO, price) Han12. estimateF(G, H, claimNO, price) ⇒ inspectA(H, A, claimNO, price) Han13. inspectF(A, H, claimNO, price) ⇒ inspectedA(A, H, claimNO, price, cost) Han14. inspectA(H, A, claimNO, price) ⇒ inspectReq(claimNO, price) Han15. inspectedA(A, H, claimNO, price, cost) ∧ inspectF(A, H, claimNO, price) ⇒ inspectRes(claimNO, price)

27

C

Protocol Mon

Mon1. start ∧ CC(Com, Con, consultingService(claimNO, quote), payForService(claimNO, quote)) ⇒ handleA(Com, Con, claimNO, policyNO) Mon2. handleF(Com, Con, claimNO, policyNO) ⇒ invoiceA(Con, Com, claimNO, quote, approval) Mon3. invoiceF(Con, Com, claimNO, quote, approval) ⇒ authorizePayA(Com, Con, claimNO, quote) Mon4. invoiceA(Con, Com, claimNO, quote, approval) ∧ handleF(Com, Con, claimNO, ·) ⇒ consultingService(claimNO,quote) Mon5. authorizePayA(Com, Con, claimNO, quote) ∧ invoiceF(Con, Com, claimNO, quote, approval) ⇒ payForService(claimNO,quote)

D

Protocol Rep

Rep1. start ∧ CC(Rp, O, validServiceReq, claimService(claimNO, policyNO)) ⇒ repairReqA(O, Rp, claimNO, policyNO) Rep2. repairReqA(O, Rp, claimNO, policyNO) ⇒ cccreate(O, Rp, repairServed(claimNO, policyNO), affirm) Rep3. repairReqF(O, Rp, claimNO, policyNO) ⇒ repairedA(Rp, O, claimNO, policyNO) Rep4. repairedF(Rp, O, claimNO, policyNO) ⇒ repairOkA(O, Rp, claimNO, policyNO, approval) Rep5. repairedF(Rp, O, claimNO, policyNO) ⇒ repairNokA(O, Rp, claimNO, policyNO) Rep6. repairOkF(O, Rp, claimNO, policyNO, approval) XOR repairNokF(O, Rp, claimNO, policyNO) Rep7. repairedA(Rp, O, claimNO, policyNO) ∧ repairReqF(O, Rp, claimNO, policyNO) ⇒ repairServed(claimNO, policyNO) Rep8. repairOkA(O, Rp, claimNO, policyNO, approval) ∧ repairedF(Rp, O, claimNO, policyNO) ⇒ affirm(claimNO, policyNO) Rep9. repairNokA(O, Rp, claimNO, policyNO) ∧ repairedF(Rp, O, claimNO, policyNO) ⇒ affirm(claimNO, policyNO) Rep10. repairOkA(O, Rp, claimNO, policyNO) ∧ repairedF(Rp, O, claimNO, policyNO) ⇒ claimService(claimNO, policyNO)

28