B2B Relationships: Defining Public Business Processes using Interaction Protocols

Transcription

1 B2B Relationships: Defining Public Business Processes using Interaction Protocols Pablo David Villarreal 1, Enrique Salomone 1,2, Omar Chiotti 1,2 1 GIDSATD Research Group Universidad Tecnológica Nacional - Facultad Regional Santa Fe Lavaisse (3000) Santa Fe - Argentina pvillarr@frsf.utn.edu.ar FA: INGAR-CONICET Avellaneda 3657 (3000) Santa Fe - Argentina {salomone,chiotti}@ceride.gov.ar Abstract Several collaborative business models have appeared recently to improve supply chain management. They are supported by Business-to-Business (B2B) relationships among enterprises. The challenge of B2B applications is to fulfill the requirements of autonomy, decentralization, peer-to-peer interactions and negotiation imposed by collaborative models to manage public processes. In this work we describe the use of interaction protocols to define and manage public processes in B2B relationships. Different aspects for representing interaction protocols in the context of B2B relationships are discussed. In addition, we provide an example of a public process modeled with an interaction protocol, which is defined graphically using AUML and textually using ebml BPSS. Finally, we include a discussion of the benefits of the interaction protocols for modeling public processes in B2B relationships. Keywords: e-business, business process, interaction protocol, workflow.

2 1. Introduction The arrival of the Internet, Web technologies and distributed systems has enabled organizations to conduct businesses electronically, thus originating the Business-to-Business (B2B) E-Commerce. In B2B relationships, interaction is an important challenge. Interactions in B2B applications occur in three layers: communication, content, and business process [13]. In the business process layer, B2B relationships require the management of two types of business processes: private processes and public processes. Private processes are processes of the enterprise itself and they are managed by each enterprise in an autonomous way. Private processes are supported within the enterprises using traditional Workflow Management Systems (WfMSs), ERP systems or proprietary systems. Instead, public processes span organizational boundaries. They belong to the enterprises involved in a B2B relationship and have to be agreed and jointly managed by the partners. Generally, activities of public processes are abstract and they are supported by private processes. A clear separation between private and public processes enables organizations to abstract the management of their internal processes from the management of processes across enterprises. Collaborative business models have been proposed in several application domains, like supply chain management [16]. These collaborative models are supported by B2B relationships and include public business processes that have to be jointly managed by partner organizations. Besides, some collaborative models require organizations to establish an independent B2B relationship with each partner, allowing organizations to collaborate in a partner-to-partner way. From the point of view of information systems, these collaborative models impose several challenges to support the management of public business processes in B2B relationships: Autonomy, which implies that enterprises should be able to behave as autonomous entities, hiding their internal decisions, activities and processes. Information systems that manage B2B relationships in each enterprise have to be independent. Decentralized management of the business processes jointly managed by the enterprises. Peer-to-Peer interactions among the enterprise systems that manage B2B relationships. This means that systems have to interact in a direct way without mediation of an independent third party system. Negotiation has to be included in the public process management. Although Workflow and Web Service Composition approaches have been proposed to manage public processes, they present shortcomings to achieve the capabilities of autonomy, decentralization, P2P interaction and negotiation. For fulfilling these requirements, in [18] we have presented an approach based on Interaction Protocols to model and manage public processes. The purpose of this paper is to discuss the modeling of public business processes using Interaction Protocols. We describe the definition of interaction protocols through the use of graphical and textual modeling languages. Section 2 discusses different aspects required to represent interaction protocols in B2B environments. Section 3 describes the graphical and textual representation of an interaction protocol using Agent UML (AUML) and ebml Business Process Specification Schema (BPSS). Section 4 details related work on workflow and Web Services Composition. Section 5 evaluates benefits of the interaction protocols to model public processes. Section 6 presents conclusions and future works. 2. Interaction Protocols for B2B Relationships Interaction Protocols have been used in the area of multi-agent systems to represent interactions among agents [1]. In the context of B2B relationships, an interaction protocol allows to model and manage the interactions among the enterprises involved in a B2B relationship. These interactions represent public business processes that enterprises agreed on the collaboration. In this way, adapting this concept to B2B relationships, an interaction protocol describes a high-level communication pattern through an admissible sequence of messages between enterprises having different roles [18]. The main objective of interaction protocols is to abstract public processes from the services to be invoked within each enterprise for executing the internal activities supporting public processes. Different from communication protocols used to manage message exchange on networks, interaction protocols have a high abstraction level. A message of an interaction protocol does not represent a message on the network. A message of an interaction protocol is implemented using a low-level communication protocol, which can involve a set of messages on the network. According to the three layers of B2B applications [13], interaction protocols occur in the business process layer while communication protocolos occur in the communication layer.

3 The main elements of an interaction protocol are: roles, messages, conditions, control flows, logical connectors and deadlines [1]. A role represents the responsibility, in terms of a messages sequence that an enterprise performs in a B2B relationship. Messages express interactions and contain a semantics defining their type. A message can represent business information, decision, proposal, acceptation, rejection or acknowledgment. A message can be asynchronous or synchronous. Conditions can be defined on messages to represent when a message can be sent. An interaction protocol has two control flows. One represents the control flow of the messages, which defines parallel or alternative messages of each interaction protocol step. The second represents the internal execution flow of a role that describes the different reactions of the role to the incoming messages. Basic Logical connectors, as AND, OR, and OR, are used to define control flows. Deadlines can be defined on messages representing the time that a role has to send a message. Following, we describe and discuss several aspects required to model interaction protocols in B2B relationships Graphical Languages for Modeling Interaction Protocols To enhance the business process design activity, a graphical modeling language is required to define interaction protocols. There exist different graphical languages or notations candidate to specify interaction protocols. Examples are AUML [1], Petri Nets and statecharts. Their advantages and disadvantages have been studied in the context of agent interactions in multi-agent systems [15]. We propose to use Agent UML (AUML) as graphical modeling language because it has enough expressiveness and it is based on UML [14], which is a widely known language used in software engineering and has been also applied to model business processes. In addition, due to the main objective of AUML was to model interaction protocols, it provides all the graphical elements required to express interaction protocols. In AUML, we can define an interaction protocol through a protocol diagram, which is an extension of the sequence diagram of UML 1.x [14]. Roles are represented by a rectangular box indicating the enterprise that performs the role (Figure 1.a). Role lifeline defines the time period during which the enterprise participates in the protocol. Lifelines are represented by vertical dotted lines. The lifeline may split up into two or more lifelines, using logical connectors, to show AND and OR parallelism and decisions, corresponding to branches on the incoming message flow (Figure 1.b). Logical connectors are also used to define parallelism and decisions in the message flow (Figure 1.c). A thread of interaction, which is represented by a bar on the lifeline, shows the period during which the enterprise role is performing some private activities or processes to react to an incoming message or to send a message. An asynchronous message is drawn as. A synchronous message is drawn as. A repetition of messages is represented by an arrow ending in a thread of interaction which is, according to the time axis, before or after the current time point. Deadlines are represented by comments on the arrows. Conditions can be added on messages using brackets. Enterprise A Object1 / Role-1 Message-1 (Content-1) Enterprise B / Object2 Role-2 Msg-1 Msg-2 Msg-1 Msg-2 Msg-1 Msg-2 Message-2 (Content-2) Msg-3 Msg-3 Msg-3 AND OR OR AND OR OR (a) (b) (c) Figure 1. AUML Protocol Diagram Notations Interaction Protocols and B2B Standards B2B standards have been proposed to exchange messages among enterprises in B2B relationships. Therefore, B2B standards can be used to implement and exchange messages defined in interaction protocols. Enterprises should agree on the B2B standard to be used to exchange interaction protocol messages. In this way, enterprises can implement independent and different systems to jointly execute the same interaction protocols without the use of a proprietary lowlevel communication protocol. There is a large number of B2B standards. These B2B standards can consist of the specification of the following elements [4]:

4 A machine-processable textual definition language to define public processes. An exchange sequence, which defines the possible transactions required by each message and the constraints of the message, like time-outs and performance. The structure of the business documents involved in the message content. The form in which messages are packaged and transported on the networks using a particular communication protocol, like HTTP, SMTP and so on. Security mechanisms for messages. All these elements of the B2B standards are required to implement interaction protocols. Some standards (e.g., eco and cml) specify only those elements that define business documents. Other B2B standards specify most of these required elements, for example ebml ( and RosettaNet ( A message is the atomic unit of the interaction protocols. However, when we implement them with B2B standards, each interaction protocol message can consist of one or more transaction messages. Transaction messages allow keeping a message as an atomic unit through the use of acknowledges or responses. For example, in ebml, an interaction protocol message is implemented with a Business Transaction, which consists of a requesting activity, a responding activity, and one or two document flows between them and additionally business signals. In a Business Transaction one role performs the requesting activity and another one performs the responding activity. There is always a request document flow, which represents the sending of the interaction protocol message with its content. A response document can be required if it is defined. Each document flow can have associated business signals acknowledging the document flow. In this way, by implementing interaction protocols with ebml, each message can consist of one or two document flows and one or more business signals. RosettaNet uses a similar approach through Partner Interface Processes (PIPs) Semantics of the Message Types An important issue in modeling of interaction protocols is the use of semantics for the messages. There are several requirements as regards the semantics of the messages. Messages should be defined according to a semantics understood by the enterprises involved in the interaction protocol. This semantics should be clear and should define the complete set of message types that can be used. The message types should represent different intentions that an enterprise wishes to be expressed in the processes. Intentions are important to describe negotiations. Besides, the semantics of the messages should be based on formalisms and should be separated of the message content definition. Message content defines the business document type that is transported by the message. The semantics of the message content is different and independent from the semantics of the message type. These semantics are defined in an independent way. Several B2B standards allow implementing messages of the interaction protocols. Some B2B standards define the set of message types together with their content, like RosettaNet ( Other B2B standards define the set of verbs that can be used to define messages, like OAGIS ( However, these verbs are not defined with a formal semantics. Another alternative is to agree with the partners the semantics of the message types. There are several B2B standards that can be used to define particular messages and business documents, like ebml or also OAGIS. The above alternatives are not suitable because they do not allow reusing the interaction protocol definition. To do so, we have two possibilities: using a set of message types like the common messages or using a universally accepted standard to specify the semantics of the message types, both with the objective of abstracting the protocol definition from the specific B2B standards. The last option is not feasible because today there is no way to do that. But we can follow the former option. Therefore, we need to use a rich set of message types, which can be extensible and can provide the basic message types suitable to express any type of business process, including negotiation processes. Today, there is no organization or consortium that provides a B2B standard with message types that satisfy these semantic requirements. This is mainly due to the fact that most of the B2B standards provide generic specifications with the purpose of defining any type of business processes. Hence, as set of message types we propose to use the communicative (speech) acts or performatives defined by FIPA Agent Communicative Language (FIPA ACL) [7], which is a standard language used to express interactions among

5 software agents. This set of communicative acts fulfills the requirements we pursue with respect to the semantics of the interaction protocol messages. The use of communicative acts allows to model enterprise interactions focusing on the communication aspects of the public business processes. In addition, communicative acts enable the definition of negotiation in public processes because they represent intentions of the enterprises. 3. Modeling Public Business Processes with Interaction Protocols In the modeling of interaction protocols, two types of languages are required: a graphical modeling language and a textual modeling language. The former has the objective of providing an intuitive semantics allowing business process designers to define and understand a public process for representing interactions between partners. The second language allows enterprises to exchange interaction protocol definitions, which can be processable and understood by the enterprise information systems for the execution of the interaction protocol. In our research, we use AUML to graphically specify interaction protocols and we use ebml BPSS [3] like the textual modeling language. The main difference between interaction protocols and other approaches for modeling public processes is that interaction protocols do not define activities or services. Modeling the processes with interaction protocols we mainly focus on the messages that have to be sent and received by the enterprise roles in each step of the business process. In this way, we can keep hidden the details of how each enterprise manages the private activities or processes required to send or receive a message. In order to exemplify the modeling of an interaction protocol, we describe one that represents the public process Collaborative Production and Capacity Planning defined by the Partner-to-Partner Collaborative Model [17]. This collaborative model was proposed to carry out business processes among manufacturing enterprises that can belong to different supply chains. The model consists of public business processes that partners jointly carry out in a decentralized way. This collaborative model requires enterprises to establish an independent B2B relationship with each partner, collaborating in a partner-to-partner way Defining an Interaction Protocol with AUML The graphical definition of this interaction protocol using an AUML protocol diagram is shown in Figure 2. This interaction protocol has two roles, provider and customer, that are performed by enterprise A and enterprise B respectively. The objective of this public process is that enterprises A and B agree on a mid-range supply plan of a certain product. The process starts when the customer role sends two parallel messages with business information: inform(salesdata) and inform(mid-range Requirement Plan). Once the supplier receives these messages, its private processes are invoked for reviewing the internal Aggregated Production Plan and then both plans are compared. All these private processes are not defined by the interaction protocol because they are private aspects of the supplier. They are executed during the time represented by the interaction thread. After comparing the plans, the supplier decides whether to propose a Mid- Range Supply Plan or refuse the customer plan because it cannot be satisfied. This is defined with a logical connector OR, which represents that only one of the two alternative messages can be sent. This decision has to be done before the time indicated by a deadline. The customer has two interaction threads that represent the incoming messages. If the supplier proposes a plan, the customer executes its private processes and can decide among three alternatives: accept the supplier plan, reject the supplier plan, or make a counterproposal offering an alternative plan. The last two alternative messages represent a repetition of messages. This means that the supplier again executes its private processes to determine whether to propose a plan or to reject the customer plan. In the other case, when the customer receives a message refuse (Midrange Requirement Plan), the customer can propose an Alternative Mid-Range Requirement Plan or can inform a failure in the negotiation because consensus has not been achieved. In both cases, the customer has to respond before a deadline. Finally, if the customer accepts the supplier plan, the supplier can inform that the status of the supply plan agreed with the customer passes from proposed to agreed. This occurs if the supplier still considers this plan as feasible. Otherwise, the supplier informs a failure indicating that the supply plan cannot be satisfied.

6 Protocol: Collaborative Production and Resources Planning - P2P Collaborative Model Enterprise A/ Supplier Supplier Enterprise B/ Customer Customer Inform(SalesData) Inform(Mid-Range Requirement Plan) Refuse(Unfeasible Mid-Range Requirement Plan) (Date of the last received message) + 5 days Propose(Mid-Range Supply Plan) Accept-Proposal(Mid-Range Supply Plan) Reject-Proposal(Unfeasible Mid-Range Supply Plan) Propose(Alternative Mid-Range Requirement Plan) Propose(Alternative Mid-Range Requirement Plan) Failure(Negotiation Without Consensus) Failure(Unfeasible Mid-Range Supply Plan) Inform-Done(Agreed Mid-Range Supply Plan) (Date of the last received message) + 5 days Figure 2. Interaction Protocol: Collaborative Production and Resources Planning 3.1. Defining Interaction Protocols with ebml BPSS ebml is a set of specifications for enabling B2B interactions among enterprises through the exchange of ML-based messages. The ebml BPSS (Business Process Specification Schema) specification [3] enables the definition of public business processes. ebml BPSS uses the concept of Business Collaborations to represent public processes. A Business Collaboration consists of a set of roles that interact through Business Transactions by exchanging Business Documents. Collaborations can be: Multiparty, which involve more than two roles; or Binary, which are between two roles. Collaborations are expressed as a set of Business Activities, which can be a Business Transaction or another Business Collaboration. Within a Binary Collaboration, activities are ordered using a Choreography, which consist of a set of Transitions between Business Activities. A Business Transaction Activity executes a Business Transaction. Business Transactions consist of a requesting role and a responding role executing one or two Business Document flows. It may also be supported by one or more Business Signals, like receipt acknowledgment. The mapping of a specification of an interaction protocol in AUML to ebml BPSS is carried out in the following way. In ebml BPSS, an interaction protocol is defined using Business Collaborations. A Binary Collaboration is used if an interaction protocol involves two roles. A Binary Collaboration implementing an interaction protocol can be defined by nested Binary Collaborations, which can represent a part of the message sequence that contains a logical connector. Transitions between Business Transaction Activities are used to express the choreography of the message sequence of the interaction protocol. Each message of an interaction protocol is implemented by a Business Transaction Activity defining the Business Transaction to be executed and the direction of the message through the Authorized Roles. Therefore, a message of an interaction protocol is also implemented through a Business Transaction. This is because both are used like atomic units. A business document of a message of an interaction protocol is implemented defining a Business Document and indicating its use in the Requesting Business Activity of the Business Transaction that implements the interaction protocol message. Figure 3 shows a part of a definition in ebml BPSS of the interaction protocol described above with AUML. The interaction protocol is defined using the Binary Collaboration Collaborative Capacity and Production Planning IP, which contain nested Binary Collaborations. The Binary Collaboration BC:Customer Information specifies the nested Binary Collaboration representing the first two messages of the interaction protocol, which are sent in a parallel way using an

7 AND connector. This choreography is indicated with the Fork and Join Transitions. The Binary Collaboration BC:Supplier Response specifies the next nested Binary Collaboration representing the second message sequence where the supplier can response with a refuse or a propose. In the Binary Collaboration BC:Customer Information the Business Transaction Activities Inform SalesData and Inform Mid-Range Requirement Plan represent the respective messages of the interaction protocol. The Business Transaction Inform SalesData defines the business document Sales Data, which is the content of the message Inform(SalesData) from the interaction protocol. <!-- Business Documents --> <BusinessDocument name="sales Data"/> <BusinessDocument name="inform Mid-Range Requirement Plan"/>... <Package name="interactionprotocols"> <!-- BC representing the First flow of messages with an AND connector --> <BinaryCollaboration name="bc:customerinformation"> <InitiationgRole name="customer"/> <RespondingRole name="supplier"/> <BusinessTransactionActivity name="inform SalesData" businesstransaction="inform SalesData" fromauthorizedrole="customer" toauthorizedrole="supplier"/> <BusinessTransactionActivity name="inform MidRangeRequirementPlan" businesstransaction="inform MidRangeRequirementPlan" fromauthorizedrole="customer" toauthorizedrole="supplier"/> <Fork name="fork:customer Information" nameid="fork:customer Information"/> <Join name="join:customer Information" nameid="join:customer Information" waitforall="yes"/> <Start tobusinessstate="fork:customer Information"/> <Transition frombusinessstate="fork:customer Information" tobusinessstate="inform SalesData"/> <Transition frombusinessstate="fork:customer Information" tobusinessstate="inform MidRangeRequirementPlan"/> <Success frombusinessstate="join:customer Information"/> </BinaryCollaboration> <!-- the rest of the flows of messages as binary collaborations -->... <!-- Binary Collaboration representing the complete Interaction Protocol (IP) --> <BinaryCollaboration name="collaborative Capacity and Production Planning IP"> <InitiationgRole name="customer"/> <RespondingRole name="supplier"/> <CollaborationActivity name="customer Information" binarycollaboration=" BC:CustomerInformation" fromauthorizedrole="customer" toauthorizedrole="supplier"/> <CollaborationActivity name="supplier Response" binarycollaboration="bc:supplierresponse" fromauthorizedrole="supplier" toauthorizedrole="customer"/>... <Transition frombusinessstate="customer Information" tobusinessstate="supplier Response"/>... </BinaryCollaboration> <!-- Here are all the Business Transactions needed to define the messages of the IP --> <BusinessTransaction name="inform SalesData" isguaranteeddeliveryrequired="true"> <RequestingBusinessActivity name=""> <DocumentEnvelope businessdocument="sales Data"/> </RequestingBusinessActivity> </BusinessTransaction>... </Package> Figure 3. An Interaction Protocol Definition with ebml BPSS.

8 Although in this way we can define an interaction protocol, some of its elements cannot have a direct mapping into ebml BPSS. Issues are the specification of OR connectors and control flows. To express these issues, its suitable to separate the message sequence into several Binary Collaborations. ebml BPSS does not have an element to express OR connectors explicitly. To do that, we have to set NO the attribute waitforall of a Join Transition. This defines an OR condition, where one or more incoming transitions can proceed. Therefore, to define an OR condition we have to add a ConditionExpression in the transitions that define the sending of each message. Furthermore, in contrast to ebml, interaction protocols do not require an end join after a fork. Besides, with ebml the control flow of the incoming messages, that is, the internal control flow of the roles is implicitly defined. 4. Related Works on Workflows and Web Services Composition Workflow Management Systems (WfMSs) [19] have been successfully used by organizations to manage their private processes. However, traditional WfMSs are not appropriate to manage public business processes [6]. For this purpose, a number of approaches have been proposed based on adaptations or extensions on traditional workflow concepts. They have been classified in four types [18]: Split and Deploy, Composition, Subcontracting, and Public and Private. Split and Deploy uses a top-down approach to model a global process, which encompasses the public process as well as private processes. The global process is split into sub-processes that are then deployed in each enterprise. This approach is used by Distributed Workflow Systems [13]. Composition uses a bottom-up approach, defining a global process from segments exposed and offered by each participanting enterprise. An example of this approach is WISE [11]. Subcontracting uses a hierarchical process approach to model a main process, which is composed of activities and subprocesses that are subcontracted. This approach is used in CrossFlow [8]. The three above approaches are not suitable to manage B2B relationships based on collaborative models. They do not fulfill the autonomy and decentralization requirements of collaborative models. These approaches are suitable to manage business processes in B2B relationships based on e-marketplaces, where an architecture hub-and-spoke is used and the management is centralized. Public and Private manages B2B relationships explicitly separating between public and private processes, which are managed in an independent way. An example is the inter-enterprise collaborative business process management [6]. Each execution of a public process does not consist of a unique process instance but of peer process instances run by Collaborative Processes Managers (CPMs) of the participating parties. Although this approach supports a decentralized management and peer-to-peer interactions, the CPMs (which are independent WfMSs) have to interoperate implementing a proprietary low-level communication protocol. Web Service Composition is about orchestration of Web Services. Enterprises offer Web Services that applications running in another enterprise could invoke without extensive integration efforts. Enterprises expose its functionalities (activities) through Web Services and agree on a public process that defines the control flow of these Web Services. Examples of platforms for specifying, enacting and monitoring of composite services are eflow and SELF-SERV. In eflow [5] the execution of the processes is based on a centralized process engine. This is in contrast with peer-to-peer interactions supported by the interaction protocols. SELF-SERV [2] uses peer-to-peer interactions among the nodes that expose Web Services for the execution of the processes. However, Web Services Composition has several similarities with the workflow composition approach because it uses a bottom-up approach to model business processes. In addition, it requires enterprises to expose their functionality, which is not required in interaction protocols. 5. Evaluation of the Interaction Protocols to Model Public Processes When enterprises use workflow or Web Services composition approaches, modeling of public processes focuses on activities or services performed by enterprises. This requires defining interdependencies and control flows of activities or services. Some activities or services represent the information exchange and other represent enterprise tasks required to produce or consume the exchanged information. The last types of activities or services can be abstract, in the sense that they imply the invocation of private processes. However, it is not suitable to define these activities or services in public processes because they are private aspects of each enterprise. Enterprises could define in different ways the

9 necessary activities or services with their interdependences and control flows. The activities or services that need to be defined are those representing the information exchange. In contrast, when we model a public business process with an interaction protocol, we focus on the messages exchanged by enterprises for interacting among them and the messages orchestration. In this way, activities or services that each partner has to perform to send or receive messages are not defined in interaction protocols and are kept hidden to its other partners. Therefore, interaction protocols enable greater enterprise autonomy because each enterprise hides its internal activities, services and decisions required to support public processes. In addition, with interaction protocols we focus on the semantics of each message selecting the most appropriate message type to express each interaction. This is achieved by using communicative acts. Furthermore, the message semantics allows expressing the intentions of the enterprises to include negotiations in public processes. In this way, interaction protocols provide a high abstraction level in the modeling of public processes. Beside, B2B interactions do not require representing the five perspectives supported by a workflow model: functional, behavioral, informational, operational and organizational [9]. All these perspectives are important to support private processes but not to support public processes. Operational perspective is not required in public processes. The knowledge of private applications that an enterprise uses to support public processes is not suitable. The knowledge and visibility of these private resources by enterprise partners reduce the enterprise autonomy. Furthermore, according to the above discussed, the functional perspective, which specifies the workflow activities, is not required. Instead, an interaction protocol includes only perspectives required in B2B interactions. A behavioral perspective is supported through the definition of a message control flow and an internal control flow of the roles. The informational perspective is supported through the definition of the message content. The organizational perspective is also included since the roles performed by enterprises in B2B relationships are specified. From the information systems point of view, interaction protocols provide several benefits for enterprises to interoperate while they keeping independent Interaction Protocol Management Systems (IPMSs). Enterprises do not need to use the same IPMS type. The use of the same language to define interaction protocols enables IPMSs to interpret and execute the same interaction protocols. The independence of IPMSs is achieved exchanging messages through a B2B standard. Finally, IPMSs do not require transfering instances because messages, which have to be sent or received in each execution step, are known according to the protocol definition. Instead, workflow approaches require that enterprises use the same WfMS because different WfMSs cannot interoperate since they use a different semantics to define the control flow [10]. Therefore, workflow instances cannot be transferred among WfMS. A proposal to solve this problem is to use a communication protocol to synchronize instances among WfMSs [6]. However, this communication protocol is a proprietary low-level protocol that WfMSs of enterprises have to implement. 6. Conclusions and Future Works Interaction protocols enable the modeling and management of public business processes, which are agreed by heterogeneous and autonomous partners for achieving a goal in B2B relationships. Interaction protocols provide the high abstraction level required to model interactions representing public processes. When we model public processes with interaction protocols, we focus on messages exchanged by enterprises. We do not need focus to the activities or services defined by enterprise to support public processes. Hiding these private aspects of enterprises from their partners enables greater enterprise autonomy when managing public processes. Interaction Protocols also enable the implementation of interaction protocol management systems that fulfill requirements of collaborative business models. On the one hand, we have discussed different aspects required to represent interaction protocols in B2B relationships. An important aspect is the use of an appropriate semantics for the messages. According to the requirements identified about the semantics of the messages, we have selected the FIPA communicative acts library to define interaction protocol messages. In this way, we have a rich set of message types, which are based on formalisms. FIPA communicative acts enable the definition of interaction protocols in B2B relationships without taking into account the B2B standards that will be used to implement them. Hence, we can achieve independence between interactions protocols and B2B standards. This independence provides several benefits. This enables the reuse of interaction protocols. Enterprises can implement an interaction protocol with different partners using different B2B standards. In addition, this independence provides a more abstraction level, because we can concentrate on the intentions expressed by enterprises to negotiate in public processes without taking into account details of implementation. Also, the use of

10 communicative acts enables multi-agent systems technology and B2B standards to be brought together for providing advanced solutions to B2B environments. This also allows enterprise systems that support B2B relationships to understand the same interaction protocol independent of the different technologies used to build them. On the other hand, we have described the modeling of interaction protocols using graphical and machine-processable representations. The use of graphical modeling languages allows enhancing the design of public processes using interaction protocols. Like a graphical modeling language we have described the use of AUML. The most important feature of AUML is its expressiveness, which allows a better understanding of the public processes with interaction protocols. In addition, we have described the representation of interaction protocols using ebml BPSS like a machine-processable language. In this way it is possible to define interaction protocols with a B2B standard like ebml, which is appropriate to implement business-to-business information systems. This language also allows independent systems of each enterprise to interpret and execute the interaction protocols agreed between the partners. Although we have discussed several aspects for modeling interaction protocols in B2B relationships, there are others that require to be studied. One of them is the inclusion of verification and validation techniques when we model interaction protocols. Future works will also focus on approaches to integrate public processes and private processes within enterprises. References [1] Bauer, B., Müller, J.P. and Odel, J. Agent UML: A Formalism for Specifying Multiagent Software Systems. International Journal of Software Engineering and Knowledge Engineering, Vol. 11, No. 3, pp.1-24, [2] Benatallah, B., Dumas, M., Sheng, Q.Z. The SELF-SERV Environment for Web Services Composition. IEEE Internet Computing, IEEE Society, Jan/Feb issue, pp 40-48, [3] Business Process Project Team, ebml Business Specification Schema Version 1.01, UN/CEFACT and OASIS, [4] Bussler, C. The Role of B2B Engines in B2B Integration Architectures. ACM SIGMOD Record, Special Issue on Data Management Issues in E-Commerce, vol. 31, no. 1, March [5] Casati, F., Ilnicki, S., Jin, L.J., Krishnamoorthy, V. and Shan, M.C. Adaptive and dynamic service composition in eflow. Proc. of Int. Conference on Advanced Information Systems Engineering (CAiSE), Springer Verlag, Stockholm, Sweden, [6] Chen, Q. and Hsu, M. Inter-Enterprise Collaborative Business Process Management. Proceedings of International Conference on Data Engineering (ICDE 2001), Germany, [7] FIPA (Foundation for Intelligent Physical Agents). FIPA Communicative Act Library Specification [8] Grefen, P., Aberer, K., Hoffner, Y., Ludwig, H. CrossFlow: Cross-Organizational Workflow Management in Dynamic Virtual Enterprises. Int. J. of Computer Systems Science & Engineering, Vol. 15, No. 5, , [9] Jablonski, S. and Bussler, C. Workflow Management: Modeling Concepts, Architecture and Implementation. International Thompson Computer Press, London, UK, [10] Kiepuszewski, B., ter Hofstede, A.H.M., and van der Aalst, W.M.P. Fundamentals of Control Flow in Workflows. Acta Informatica, 2003 (to appear). [11] Lazcano, A., Alonso, G., Schuldt, H. and Schuler, C. The WISE approach to Electronic Commerce. International Journal of Computer Systems Science and Engineering, Special issues on Flexible Workflow Tecnhology Driving the Networked Economy, Vol. 15, No. 5, [12] Luo, Z. Knowledge Sharing, Coordinated Exception Handling, and Intelligent Problem Solving for Cross- Organizational Business Processes. PhD dissertation. Dpto. Computer Science, Univ. of Georgia (2001). [13] Medjahed, B., Benatallah, B., Bouguettaya, A., Ngu, A.H.H. and Ahmed, K.E. Business-to-Business Interactions: Issues and Enabling Technologies. The VLDB Journal, Springer, to appear, [14] OMG. Unified Modeling Language Specification, Version 1.4. September 2001, ftp://ftp.omg.org/pub/docs/formal/ pdf. [15] Paurobally, S., Cunningham, J. and Jennings, N.R. Developing Agent Interaction Protocols Using Graphical and Logical Methodologies. Workshop on Programming Multi-Agent Systems: languages, frameworks, techniques and tool (ProMAS 2003). AAMAS Australia, [16] Villarreal, P., Caliusco, M.L., Galli, M.R., Salomone, H. and Chiotti, O. Descentralized Process Management for Inter-Enterprise Collaboration. Vision, Special Issue on Supply Chain Management, Vol 7, pp Editor: B.S. Sahay, Management Development Institute, Gurgaon, India, 2003.

11 Sahay, Management Development Institute, Gurgaon, India, [17] Villarreal, P., Caliusco, M.L., Zucchini, D., Arredondo, F., Zanel, C., Galli, M.R., and Chiotti, O. Integrated Production Planning and Control in a Collaborative Partner-to-Partner Relationship. In S. Sharma & J. Gupta (eds.), Managing E-Business in the 21 st Century. Heidelberg, Australia. (in press) (2003) [18] Villarreal, P., Salomone, H.E. and Chiotti, O. Managing Public Business Processes in B2B Relationships using B2B Interaction Protocols. I Conferencia Latinoamericana de Informática (CLEI 2003), Bolivia, [19] Workflow Management Coalition (WfMC).