Design

Commitments for Flexible Business Processes
Amit K.Chopra Department of Computer Science North Carolina State University Raleigh,NC27695-7535,USA akchopra@
Munindar P.Singh Department of Computer Science North Carolina State University Raleigh,NC27695-7535,USA
singh@
Abstract
Current approaches of specifying business processes de-scribe the implementation of a process rather than the in-teractions that are expected from the agents that participate in it.This means that the specification is neitherflexible, nor reusable.We propose an approach of developing busi-ness processes from commitment-based protocols.Our ap-proach results in protocols that are reusable across appli-cations and processes that areflexible.An essential ingredi-ent of our approach is developing an operational semantics of commitments that allows contextual(policy-specific)rea-soning about them.
1.Introduction:Challenges in Business Pro-
cess Design
Cross-enterprise business processes involve a number of components that are independently designed and represent the interests of autonomous parties,and yet,have to inter-act coherently.Current approaches allow the specification and enactment of a business process,however,they spec-ify the implementation of a process rather than the interac-tions that are expected of it.More specifically,they rely on workflow abstractions that support the perspective of only one participant.They,therefore,support neither reusability, norflexible execution in the face of exceptions or opportu-nities that frequently arise in open,dynamic systems. Interactions in business processes are typically long-lived so that they can be organized in the form of pro-tocols.Protocols offer the level of abstraction that natu-rally supports local perspectives as they specify the interac-tion(the what)rather than implementation(the how).Thus, protocols naturally maximize the autonomy of the partici-pants.For this reason,protocols can serve as building blocks
helps alleviate the concerns described above.Protocols can be designed so that they are general enough to be reusable across mitments also provide the basis for checking an agent’s compliance with a protocol[2].Yet, reasoning about the commitments involved in the protocol lendsflexibility to the process.
Consider a simple e-commerce protocol enacted be-tween two agents,a merchant and a customer,where the merchant promises to deliver the goods if the cus-tomer paysfirst.Now if the merchant receives payment, but is unable to ship the goods,then it represents a viola-tion of its commitment,and therefore,the protocol.How-ever,the merchant’s policy is so encoded that in such situa-tions,it sends a refund or delegates the delivery to another merchant.Note that delegations or refunds are not spec-ified in the protocol;they still represent violations of the the protocol.Therefore,either or both of these alterna-tives,might be unacceptable to the customer.However,the merchant,in trying to take these alternative steps,is rea-soning about its commitments so as tofind a somewhat sat-isfactory solution to the exception.Exception handling like this is certainly preferable to the situation where the mer-chant does not know how to handle a failure to deliver goods and does nothing,or aborts the transaction.It is pos-sible to add the‘delegate’and‘refund’computations to the protocol itself,but that would be a manifestation of a par-ticular agent’s policy in the protocol,making the protocol unwieldy and less reusable.
The most important point to note here is the separation of interaction and control.Control resides with the policies whereas the protocol merely specifies the interaction and its semantics.This allows the reusability of the protocol in an-other context and keeps the handling of exceptions and op-portunities in the policies.
3.From Declarative to Operational Seman-
tics
Our design methodology involves taking declara-tive commitment-based specifications of protocols and ex-tracting operational specifications of role skeletons from them(see Figure2).Agents are built out of business pol-
icy specifications and role skeletons.Policies are used to control the interaction.The business process itself re-sults from the interaction of all the agents involved.
While a declarative semantics is appropriate for protocol specification,an operational semantics is more appropriate for role specification.This is because role skeletons are lo-cal in nature and the operational semantics better captures the interaction between roles.More importantly,declara-tive specifications allow for partial descriptions of systems which is good for global specifications like protocols;the rest of the system description isfleshed out with respect to the policies of individual agents,that is,in an operational setting.The operational specifications can then be used to reason about an agent’s commitments with respect to its policies.
We are developing a model of commitments and busi-ness processes in the-calculus[1].The-calculus is a pro-cess algebra for modeling concurrent processes whose con-figuration,that is,communication links,may change at run time.An agent’s role skeletons are encoded as-processes.
Before a transition,every skeleton consults with a-process called the commitment-collector(in the sense of a garbage collector)that looks at the state the skeleton is in,deter-mines its outstanding commitments,and takes steps to exe-cute,that is,satisfactorily handle those commitments in ac-cordance with its policies.The commitment-collector could also proactively poll the state of the skeleton depending upon the timeouts of commitments.We can thus view the agent as a virtual commitment machine that executes com-mitments.
References
[1]municating and Mobile Systems:the pi-
Calculus.Cambridge University Press,1999.
[2]M.P.Singh.Agent communication languages:Rethinking the
principles.IEEE Computer,31(12):40–47,Dec.1998.
[3]P.Yolum and mitment machines.In Pro-
ceedings of the8th International Workshop on Agent The-
ories,Architectures,and Languages(ATAL-01),pages235–
247.Springer-Verlag,2002.
2
Permission to make digital or hard copies of all or part of
this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the
full citation on the first page. To copy otherwise, to republish,
to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
AAMAS'04, July 19-23, 2004, New York, New York, USA. Copyright 2004 ACM 1-58113-864-4/04/0007...$5.00。