Execution system for distributed business ... - Semantic Scholar

Future Generation Computer Systems 17 (2001) 1009–1021

Execution system for distributed business processes in a virtual enterprise Luis M. Camarinha-Matos∗ New University of Lisbon, Faculty of Sciences and Technology, Quinta da Torre, 2825 Monte Caparica, Portugal

Abstract New cooperative approaches for manufacturing and service industries, as represented by the virtual enterprise paradigm, are enabled by the recent advances in communication technologies, computer networks, and logistics. The implantation of this paradigm requires the design and development of a flexible execution environment to support the distributed business processes that materialize the cooperation in a network of enterprises. A configurable architecture for such execution system is proposed focusing the support for multi-level process coordination. A set of examples to illustrate the adopted concepts and developed tools are discussed. © 2001 Elsevier Science B.V. All rights reserved. Keywords: Virtual enterprise; Distributed business process; Workflow; Coordination

1. Introduction The recent advances in communication technologies and network computing are having a major impact in the organization of the industrial manufacturing processes. In this context, the paradigm of virtual enterprise (VE) represents a major area of research and technological development for industrial enterprises and an important application area for web-based cooperative environments. A virtual enterprise is usually defined as a temporary alliance of enterprises that come together to share their skills, core competencies, and resources in order to better respond to business opportunities, and whose cooperation is supported by computer networks [4,5,10]. Two keyword elements in this definition are the networking and the cooperation. As a result of the emergence of new economic paradigms and their corresponding market characteristics, there is a clear ∗

Tel.: +351-21-2498517; fax: +351-21-2941253. E-mail address: [email protected] (L.M. Camarinha-Matos).

trend for the manufacturing business processes not to be carried out by a single enterprise any more. In order to reach world class, companies are forced to embark in cooperation networks where every enterprise is just one node adding some value (a step in the manufacturing chain) to the entire production cycle. As such, in virtual enterprises, manufacturers and service industries do not produce complete products or services in isolated facilities. Rather, they operate as nodes in a network of suppliers, customers, engineers, and other providers of specialized service functions. Business processes (BP) take place, therefore, in a distributed environment of heterogeneous and autonomous nodes. The materialization of this paradigm, although enabled by recent advances in communication technologies, computer networks, and logistics, requires an appropriate architectural framework and support tools. Namely, it requires the definition of a suitable open reference architecture for cooperation, the development of a flexible and configurable BP supporting platform, and the development of appropriate interoperation protocols and mechanisms.

0167-739X/01/$ – see front matter © 2001 Elsevier Science B.V. All rights reserved. PII: S 0 1 6 7 - 7 3 9 X ( 0 1 ) 0 0 0 4 4 - 9

1010

L.M. Camarinha-Matos / Future Generation Computer Systems 17 (2001) 1009–1021

This paper, an extended and revised version of a presentation at the HPCN-Europe 2000 conference [6], presents an overview of the requirements for a VE infrastructure and describes one solution focused on the coordination aspects, based on developments in the framework of the Esprit PRODNET II, INCO MASSYVE, and IST FETISH-ETF projects.

2. Coordination in a virtual enterprise 2.1. The need for coordination Coordination of processes and activities has been identified as a key element in the operation of virtual enterprises [2,4,5,12]. Coordination has to do with the proper management of dependencies among activities [13] and correspond, in accordance with the view of [9], to the process of “gluing” together active pieces (enterprise activities) with a purpose. From a bottom-up perspective, activities carried out by a company are usually organized in “clusters” of inter-related activities called processes (business processes). The composition of each process is designed in order to achieve a (partial) specific goal. When a business process is executed by a virtual enterprise, parts of the decomposition of this BP (i.e., sub-processes) are assigned to different enterprises, becoming a distributed business process (DBP). When properly “orchestrated”, a combination of various processes taking place in different members of the VE will lead to the achievement of the global goal of the VE. Alternatively, a CIM-OSA-like top-down view can be considered according to which a VE business process or DBP can be decomposed into a hierarchy of sub-business processes and enterprise activities. The enterprise activities, that are supported by the CIM-OSA’s Implemented Functional Operations, or the PRODNET’s services [4], represent the basic building blocks (libraries of services) of each enterprise per se, and the VE as a whole have to actually realize the assigned processes. 2.2. Need for multi-level coordination As it is implicit in the notion that a VE business process can be decomposed into a hierarchy of

sub-business processes, the coordination issues must be analyzed at different levels of abstraction. The problem of the supervision or coordination of the BP at its various levels of decomposition becomes even more important in this context where the BP definition and enactment is not limited to a single organization but instead a set of autonomous, distributed and heterogeneous nodes have to cooperate. This need is clearly illustrated by the PRODNET pilot demonstration [4] of manufacturing a bicycle in a VE environment. According to this example, different parts of the full manufacturing process may be assigned to different members of the VE according to their core skills, resources and roles in the VE. For instance, one node A becomes responsible for assembling all components in a final product, another node B is responsible for manufacturing the metallic parts, a node C supplies the plastic components, a node D produces moulds for plastic components, etc. Once a global business process is defined and scheduled, and responsibilities are assigned to each individual partner, the successful achievement of the common goal — delivery of the final product to the client — depends on the proper and timely operation of each VE member (and each supporting service in each VE member). A delay in one node, if not taken care of in time, may jeopardize the common goal. Therefore, one enterprise may assume the role of VE coordinator and manage (supervise) the interdependencies among the various (distributed) BPs. On the other hand, inside each company, the (local) assigned business process(es) may, on its (their) turn, be decomposed into several sub-processes whose activities are supported (performed) by various service functions available in the enterprises. For instance, a “produce bike frame” process may involve: “Receive order from the coordinator (via EDI)”, “design frame” (using a CAD system); “generate process plan” (using a CAPP system), “plan production” (using a PPC system), “supervise production” (using a shop-floor control system); “send periodic progress reports to the VE coordinator” (using the ERP/PPC system), etc. This “decomposition” process may continue and some activities may imply a sequence of


Fig. 1. VE execution system.

fine-grained activities. For instance, the “receive order” process can be decomposed into: “Identify arriving message”, “parse order coded in EDIFACT format”, “temporarily store order data”, “ask advise from human operator on what to do with the order”, “notify ERP/PPC of the order arrival”, etc. The interdependencies (sequence/parallelism, synchronization, data flow, precedence conditions) among these activities, at the various levels of abstraction, need to be properly managed. Some projects, such as VIVE [19], have devoted some effort to the identification of the major BPs and their decomposition for some key areas of manufacturing. However, although important, modeling BPs brings little benefit to the actual operation of the VE if not supported by an execution infrastructure — the VE execution system (Fig. 1). Considering the distributed nature of a VE, the structure of a minimal VE execution system should comprise: a process execution and coordination system, a distributed information management system, and a safe communications infrastructure. The enterprise resources (enterprise applications, human resources, machines, etc.) will carry out the actual execution of enterprise activities under the control of the process execution and coordination system. By analogy with the computer systems, this infrastructure can be seen as the “operating system” of the VE. One aspect to emphasize here is the heterogeneity of the processing nodes/VE members. The enterprises that combine efforts to form a VE pre-exist and

1011

have their own legacy systems and distinct enterprise culture. Therefore, in addition to requirements of interoperability, it is also necessary to support a high degree of configurability in order to cope with the particular context of each enterprise. Interoperability is reflected as a requirement to adopt industry standards such as WPDL (or PIF) for process definition, EDIFACT for the exchange of business messages, STEP for the exchange of technical product data, etc. The configurability characteristic shall provide a flexible way to adapt the behavior of the execution system to the specificity of each local enterprise and to hide, to some extent, this specificity from the other members of the network. Another characteristic of this environment is the hybrid nature of the execution system. Some processes may be carried out automatically by services offered by enterprise applications (ERP — enterprise resources planning system, PDM — product data management system, etc.), while other processes are performed by humans. It may also happen that a given process is executed differently (automatically or human-based) if assigned to different enterprises. 3. A coordination kernel 3.1. Multi-level coordination Taking these requirements into account, the PRODNET project [4] designed and developed a prototype of an execution infrastructure for distributed BPs. From the activity/process coordination point of view, the PRODNET coordination subsystem considers three levels of abstraction (Fig. 2): • Core cooperation layer (CCL). The CCL is responsible for the basic interactions among VE members offering support for safe communications, exchange of business messages, sharing and management of cooperation information, federated information queries, etc. • Enterprise management functionalities (EMF). The EMF is responsible for the coordination of activities at the enterprise level. In other words, the EMF deals with coordinating the responsibilities of the enterprise towards the accomplishment of its assigned BPs or contracts with the VE and other VE-partners.

1012


Fig. 2. Multi-level coordination.

Fig. 3. Coordination and hierarchies of BPs.

• Virtual enterprise management functionalities (VMF). The coordination aspects at the VE level are considered in the third level. In principle, only the node playing the VE coordinator role will use this layer to monitor, assist, and modify the necessary activities related to the VE goal achievement. The VE management functionalities (VMF) layer resorts to the services provided by the CCL and EMF of its node to communicate with the other nodes of the VE.

C (in Fig. 3) coordinates sub VE1 and is a member of sub VE2. Under this model, the formation of a sub-consortium inside a VE follows a similar process as the formation of the VE itself. In other words, a VE may recursively give raise to internal sub-VEs.

Although in its current implementation only three levels are considered, the model can be easily generalized to any number of levels in order to cope with any BP tree. In fact, in addition to the VE coordination role, responsible for the global BP, other enterprises may assume the role of coordinators of sub-business processes that might be decomposed and performed by a sub-consortium of enterprises. This idea of dynamic formation of sub-consortia inside a community of cooperating agents (a VE) in order to coordinate sub-business processes being exploited by the MASSYVE project [17,18]. These sub-consortia are formed for the sole purpose of facilitating the coordination of activities involved in the related sub-business processes. Once a sub-business process ends, the sub-consortium “dissolves” and its members may become involved in other sub-consortia dynamically formed as the execution of the VE BPs evolves. For instance, enterprise

The two main components of the PRODNET coordination kernel are the local coordination module (LCM) [4] and the federated distributed information management system (DIMS) [1]. Similar to some other projects (e.g., NIIIP, VEGA, WISE), PRODNET adopted a workflow-based approach for coordination of VE-related activities. Combined with a graphical specification language and a graphical editor, this approach proved to be an efficient way to implement flexible and easily re-configurable, by non-programmers, activity coordination strategies. In this way, the needs of different companies and different business processes can be properly accommodated. The integration and management of the VE information is supported in PRODNET by an innovative distributed/federated information management approach [1]. The federated database approach has proven to provide particularly attractive features

3.2. Coordination in PRODNET


1013

addressing some challenging information management criteria such as the openness, autonomy, heterogeneity, and information privacy, which are the main pre-conditions for trust building among SMEs involved in a virtual organization domain. The very tight integration of activity coordination and federated information management provides a sound basis to support the advanced VE coordination functionalities. LCM is responsible for the control flow while DIMS supports the associated data flow. Another major component of the PRODNET execution system is the PRODNET communications infrastructure (PCI) [15], which is responsible for providing communication channels between VE members and a set of functionalities to guarantee safe communications, authentication, auditing services, heuristics for communication channel selection, etc. This three-module-based execution environment is complemented by a library of service functions

that support the activities at each level of abstraction (Fig. 4). For instance, at the CCL level, services for processing EDIFACT and STEP messages are offered. At the EMF level services such as product negotiation or issuing product purchase order can be found. At the VMF level services related with the VE global coordination, such as getting production status from VE members or search for new partners, are included. A network of cooperating nodes (network of enterprises) therefore composes the execution environment for DBPs in PRODNET and each node includes the coordination kernel, the safe communications infrastructure, and the support service functions. In terms of implementation it is necessary to take into account that enterprises come together to form a VE pre-exist have their own legacy systems (ERP/PPC, SCM, CAD, CAPP, PDM, etc.). Therefore, the implantation of the BP execution environment has to take into account the migration of these legacy systems, as they will support many of the necessary services. Following a common procedure in systems integration, PRODNET “recovers” the existing legacy applications by adding to them a new layer (the PRODNET Cooperation Layer or VE execution system) and by establishing the necessary mappings between this layer and the enterprise applications (Fig. 5). The interoperation between PCL and legacy applications is supported by a client–server interaction. PCL provides a “client library” which guarantees the communication from the legacy applications to PCL. Each legacy application provides a similar library to PCL.

Fig. 4. Examples of services at different abstraction levels.

Fig. 5. The PRODNET execution environment.

1014


with the WfMC reference model [20], but including some adaptations to the VE environment is developed (Figs. 6 and 7). The following modeling primitives are supported:

Fig. 6. Graphical process modeling primitives.

Current trends, such as the OAG initiative [14], towards the “componentization” of enterprise applications and definition of standard interoperation mechanisms among these functions, raise the expectation that future enterprise applications can be seen as a library of service functions that can be flexibly used by the coordination system. 3.3. Graphical modeling of BPs For the modeling of BPs a graphical language and an associated editor that borrows many ideas from the workflow management systems, trying to be compliant

• Sequences of activities that might invoke external services or other sub-activities. • Sub-workflow definition, a mechanism to support nested BPs definition. • Data flow management for parameter passing when activating services/sub-activities, i.e., data that is essential for the process execution control flow. This is the explicit data exchange. A form of implicit data exchange is also supported by the DIMS module. • Splits and joins that can be subjected to the logical operators AND/XOR. • Simple and conditional transitions. • Temporized and cyclic activities, providing the high-level coordination facility that is needed for instance in the case of monitoring contract clauses among VE members. • Flexible configuration of catalogs of support services and relevant data. Hierarchical BPs can be represented using the concept of sub-workflow as illustrated in Fig. 8. Sub-workflows also provide a basic degree of reusability in the model, since a sub-workflow can be used several times in a workflow model like a

Fig. 7. Graphical business process model editor.


1015

Fig. 8. Activity implemented as sub-workflow.

Fig. 9. BP edition and execution environment.

sub-routine. The more frequent tasks can be modeled as sub-workflows and used as many times as necessary. This feature allows the creation of a library of sub-workflows (templates) that model the processes frequently performed. The graphical process editor associated to LCM supports a fundamental characteristic in a VE environment that is the ability to comply with a gradual migration of the company’s legacy business practices towards a VE environment operation. In a first step, it is necessary to guarantee that the company’s privacy, autonomy as well as its way of making business will be preserved, as far as possible. When the level of trust between the enterprise and the VE partners increases, or a better understanding of the VE operation is achieved, a new behavior of the cooperation layer can be defined by a BP expert without the need of programming. One of the reasons to adopt a workflow-based modeling approach instead of a more specialized language for coordination such as LINDA or MANIFOLD [3] is because it is easy to use by BP experts with limited programming skills. The output of the graphical editor is stored as a WPDL file, following the WfMC proposed syntax [20].

ule that supports a user interface with a graphical visualization of (and interaction with) the processes under execution (Fig. 9). In addition to supporting the modeling primitives described above, the coordination engine supports:

3.4. BP execution The LCM includes the process executor (enactment engine) and a monitoring and event notification mod-

• Workflow instances and memory spaces: For each execution of a workflow model, an instance is created with its memory space. The explicit data flow associated to an instance (relevant data) is only valid inside the memory space of that instance. • As an enterprise may be involved, at the same time, in various VEs, there is also a memory space separation per VE participation. • Management of waiting lists: Each time an instance of a workflow model needs to wait for the conclusion of an external service it is put in a waiting list. Waiting lists are also used for instances waiting for temporized activities. Signals can be sent to the waiting lists manager to provoke changes in the status of workflow model instances. 3.5. BP creation One important question in DBP modeling is to determine who is responsible for the creation of BP models and instances. The answer depends on the particular type of VE. Different VE organizations may consider different actors in this process and different coordination rules [5]. Some possibilities are:

1016


• Centralized planning: In a tightly integrated operation of the VE, the VE coordinator or business broker may plan the whole BP and send it to the VE members. In this case it is necessary to take into account the visibility rights of the VE members. Should a VE member see the whole plan or just the part it is responsible for? • Adaptable mobile agents: Another area to be explored is the application of mobile agents to facilitate the adaptation/optimization of the BPs to the conditions of the VE. For instance, an intelligent mobile agent can carry a macro plan (abstract BP definition) and detail it once it arrives at a specific VE member according to the specific conditions it finds there. One work in this direction, although applied to remote supervision/tele-operation, can be found in [7,8]. • Cooperative planning: Another alternative is to consider a cooperative BP planning by several VE members. In this case it is necessary to implement a shared planning space for the BP model design, a feature not implemented in the current version of graphical BP editor but that could be easily developed on top of the PRODNET distributed information management system [1]. • Hierarchical planning: Finally, the typical case is one in which only the abstract model of the BP (the first few decomposition levels) is planned by the partner that identified the business opportunity (broker or VE coordinator). The level of detail of this model is just enough to allow the identification of the necessary partners/skills and main resources and the distribution of sub-BPs among these partners [2]. Taking the example of Fig. 3, the VE coordinator could, for instance, decompose the BP0 into BP1, BP2 and BP3. The VE members assigned to their execution could do further decomposition of these BPs. Once a VE member receives a BP, it can detail this BP according to the internal capabilities (skills, manufacturing processes and resources) of the company. For instance, the enterprise C could decompose BP2 into BP2.1 and BP2.2. One question in this case is: should the VE members notify the VE coordinator of the actual decomposition they have performed? If the coordinator is informed, or if at least a simplified version of the decompo-

sition is received, the monitoring activity performed by the coordinator can be simplified. For instance, at the current stage, in order to query a VE member about the status of a given process, like the status of a specific order, the querying member must be aware of the possible states considered by the internal ERP/PPC system of the queried member. 4. An example In order to illustrate the operation of the described execution system, let us consider an example of two enterprises involved in the business process of developing a new bicycle and that have to cooperate in the design of a component (a pedal, for instance). In this scenario, enterprise A prepares a first model of the desired component using a CAD system and defines some additional characteristics for this part using a PDM (product data management) system. This technical specification is then sent to enterprise B. Enterprise B might accept the proposed design or suggest changes that have to be negotiated with enterprise A until an agreement is reached. In order to support this process, there is a need for a core service (i.e., a service at the CCL level) that takes care of sending out a message with the technical specifications of the required part. A solution for that can be the encapsulation of a STEP model in an EDIFACT CONDRA message. Fig. 10 shows a simplified process model for this task. As illustrated in this figure, the implementation of a core service resorts to other more basic services (the auxiliary services) offered by the PRODNET infrastructure such as EDI BuildMessage, DIMS AttachReferences, etc. Different implementation solutions can be devised for this core service. For instance, the product model may be sent using a proprietary format (agreed between the two companies) without resorting to EDIFACT. In a similar way, specific processes have to be modeled, at the CCL level, for each of the core services supported by the enterprise cooperation layer. Examples are: Send order, Receive order, Order acceptance, Send delivery record, etc. The graphical process editor provides a flexible tool for a system manager (BP expert) to define the set of core services for each enterprise as well as the set of available auxiliary services in the installed


Fig. 10. Example of core service (CCL-level process).

infrastructure. In the same way, but not necessarily following the same models, it is necessary to define the core services of enterprise B. It is important to note that it is not the sender who decides which applications/services will be used on the receiver’s side. A message is sent independently of the type of processing that the destination will apply. A lookup table at each site establishes this correspondence (Fig. 11). It is, however, necessary that all members of the VE share a common taxonomy of message types. If a standard protocol is used (like EDIFACT), the common set of types is guaranteed. For proprietary types, it is necessary to reach an agreement among all VE members. It is at configuration time, when the behavior of the coordination module is

Fig. 11. Association of message types to process models.

1017

defined, that a specification of which local processes are triggered by each type of arriving message is made. In fact this is necessary even when the messages are EDIFACT-based as only a subset of EDIFACT messages are used for each of the two enterprises. In this way, the enterprise keeps its autonomy not only in terms of deciding the specific structure of its processes (which can evolve), but also in terms of deciding which processes to apply for each type of event. In our opinion this is a more pragmatic solution when compared to other approaches as the one proposed by the WISE project [2]. In WISE, companies declare (register) their services in a global catalog that is then used by the BP modeler to build BP models. Using this basic level of the cooperation layer it is possible to implement cooperation processes between enterprises. If no other higher level services are available, then the coordination of the higher level processes has to be done by the human operators or to be supported by some hard-coded fixed procedures implemented in the interface of the enterprise applications. For instance, the core service presented in Fig. 8 could be invoked by a PDM application or explicitly launched by the PDM user. This was the situation implemented in the PRODNET demonstrator that was sufficient to demonstrate how complex cooperation scenarios can be implemented on top of a basic infrastructure [4]. If the second coordination level (EMF) is available, then it is possible to implement a flexible, automatic or computer-assisted coordination mechanism for higher-level processes. For instance, Fig. 12 illustrates a simple enterprise-level process describing the steps involved, from the enterprise A side, in the negotiation of a part with company B. In this example, the activities “design model” and “prepare PDM data” are performed by services offered by the enterprise applications CAD and PDM, respectively. An alternative to a direct invocation of a CAD (or PDM) application can be the activation of a user interface program that notifies the human operator about the tasks to be done (see the event notifier component in Fig. 9). In this way, the same basic modeling and control mechanisms can be used for automatic or manual (computer-assisted) systems. This example also shows that the same workflow-based modeling mechanisms can be used to model this type of BP.

1018


Fig. 13. Generic “wait answer” process iteration.

Fig. 12. Example of an EMF-level process.

The activity “send product model” is performed by the core service described above (Fig. 10). This example illustrates how lower level processes can support a higher level process. The instantiation of a lower level workflow model is done following the same invocation mechanism used to call application services, i.e., some input and output parameters are used to establish the interaction between the two processes in a similar way as the invocation of a procedure in a traditional programming language. The LCM engine interprets the process description language, assuring the proper parameter passing in the right memory space and right VE space. The “inspection” step can be performed by another process, the “monitoring process”. This can be a generic process used whenever some acceptance (or cancellation) is required from a VE partner, as illustrated by Fig. 13. This process periodically checks for a termination event that lets the calling process finish. Examples of termination events are a signal coming from a lower level process (CCL event) or information provided by a user interface (for the cases that a confirmation arrived by fax or phone). If no termination event arrives during a specified time period, a notification is sent out (by e-mail, for instance). For the particular example of product negotiation, a specific process considering several iterations could be

used (Fig. 14). In this case the answer from enterprise B can be a simple acceptance, a proposal for a design modification in the part (that enterprise A may accept or propose another alternative, initiating a new cycle), or a simple refusal (unable to perform the required task). Examples of coordination at the upper level (VE level) are shown in Fig. 15. Two supervision processes are illustrated here. These processes use lower level processes (such as product negotiation). In the implemented coordination system the process execution history can be maintained, resorting to services of DIMS, to be used for auditing purposes or data mining towards process performance improvement.

Fig. 14. Example of negotiation.


1019

Fig. 16. Loosely constrained BPs.

Fig. 15. Examples of BPs at the VEF level.

5. Further aspects in BP execution 5.1. Loosely constrained BPs Once a VE infrastructure is available, more integrated cooperation forms can be supported. That is the case, for instance, of concurrent or collaborative engineering where teams of engineers, possibly located in different enterprises, cooperate in a joint project such as the co-design of a new product. A large number of computer supported cooperative tools are becoming widely available for synchronous cooperation. Some examples are teleconference, and chat tools combined with application sharing mechanisms. Considering the geographical distribution, the autonomy of the VE members, the local corporate cultures, and also the individual working preferences of the team members, it is likely that most of the activities will be carried out in an asynchronous way. In order to assure the proper progress in this loosely coupled environment it is necessary to implement some form of coordination of activities for these collaborative processes. In the case of processes mainly executed by humans, the workflow type of control is too rigid. People like to keep their freedom regarding the way they work. Product design, like any other creative process, evolves in a kind of non-deterministic flow. It is therefore necessary to also support loosely constrained sets of business processes (Fig. 16). Another aspect is the

representation of temporal interdependencies among activities. For instance, in the case of the processes “Product Design” and “Process Planning”, although they can proceed with some degree of concurrency (i.e., process planning can start once a first draft of the product is made), Process Planning cannot finish before Product Design finishes. At least some details of the process plan definitely depend on the final commitments of the product model. Several approaches to develop flexible workflow systems have been proposed [11]. One solution for the coordination flexibility was first introduced in the CIM-FACE system [16]. In this system, instead of rigid precedence rules, other types of relationships, inspired in the Allen’s temporal primitives, are possible: start before, finish during, start after, finish after, do during, etc. Other constraints such as pre- and post-conditions can be specified. These mechanisms, previously developed in CIM-FACE, are not included, however, in the current implementation of LCM. In order to support coordination when the execution entities are human operators, probably resorting to some legacy tools (CAD, CAPP, PDM), some human front-ends (Business Plan Assistants in the CIM-FACE terminology) are necessary. These front-ends represent the human actors in the cooperative team and interact with the BP executing/coordination infrastructure. The coordination system is responsible for keeping track of the global execution status and to guarantee the pre-conditions required for any “intervention” of any actor in the common BPs. 5.2. BP allocation The experience with the PRODNET infrastructure showed that one of the elements of diversity is the set of available services (and resources) in each enterprise. Therefore it makes sense to consider two phases in the BP definition:

1020


• Creation of the BP model (or edition of templates). • Allocation of services/resources to the execution of the BP activities. In order to facilitate the allocation phase, the BP modeling phase can specify the types of services (and interfaces) adequate to execute each activity. The identification of concrete services is made when specific instances of the BP model are created. This approach is being implemented in a new version of the coordination system being developed in the IST FETISH-ETF project. Besides the service types, the BP edition phase could allow the inclusion of other embedded knowledge that would facilitate the BP instantiation and execution. For instance, clauses for error recovery could be included in order to facilitate the run-time conflict resolution. In the context of a DBP to be executed by a VE, the allocation of services can proceed in two phases: • Assignment of BPs to VE members. • Allocation of enterprise resource/services, by each VE member, to the activities of the (sub)BPs assigned to the enterprise. These functionalities require a change of the modeling tool developed in PRODNET II. Further developments in this direction, being pursued in the MASSYVE project, include the addition of a flexible scheduling mechanism to the VE members and services allocation steps. In the MASSYVE [17,18] approach, both the members of a VE and the resources inside each VE member are represented as agents. The allocation of a BP/EA to a specific agent is based on the contract-net/negotiation paradigm. Based on this paradigm, tasks are announced to potential candidate agents. Candidate agents, the ones that are able to fulfill the task requirements, submit bids to the contractor agent that decides to which one to assign the task. One important aspect here is the conflict resolution. Conflicts may occur as a result of changes in the BPs specifications, changes in BP priorities, temporary failure or unavailability of resources, etc. Such situations may affect the overall BP execution and therefore the achievement of the VE goal. The negotiation paradigm provides a flexible mechanism for conflict resolution starting from the lowest possible level. The

agent that faces/detects a problem will try to solve the problem at its level, trying to sub-contract another agent, and only in case of failure the problem is passed to the next level. 6. Conclusions and further work A flexible and open execution environment is a fundamental requirement for the implementation of virtual enterprises. The PRODNET II project developed an example of such infrastructure that combines diverse support technologies and addresses a wide range of requirements set by the VE paradigm with particular focus on the characteristics of SMEs. In particular, the workflow-based multi-level coordination approach developed by PRODNET II seems particularly adapted to the configurability and flexibility requirements. The essential features that validate the model are implemented and tested in the PRODNET demonstration scenario, based on a Windows-NT environment; however further work is required namely in terms of flexible planning and scheduling of distributed business processes. The MASSYVE and FETISH-ETF projects are addressing these issues and an effort towards an integration of results of the three projects is being pursued. Acknowledgements This work was funded in part by the projects Esprit PRODNET II, INCO MASSYVE, and FETISH-ETF. The author also thanks the valuable contributions of his partners in the mentioned projects consortia. References [1] H. Afsarmanesh, C. Garita, L.O. Hertzberger, Virtual enterprises and federated information sharing, in; Proceedings of the Ninth IEEE International Conference on Database and Expert Systems Applications, DEXA’98, Vienna, Austria, August 1998, pp. 374–383. [2] G. Alonso, et al., The WISE Approach to Electronic Commerce, February 15, 1999. http://www.inf.ethz.ch/ department/IS/iks/reearch/wise.html. [3] F. Arbab, What do you mean, Coordination? Bulletin of the Dutch Association for Theoretical Computer Science, March 1998.

L.M. Camarinha-Matos / Future Generation Computer Systems 17 (2001) 1009–1021 [4] L.M. Camarinha-Matos, H. Afsarmanesh (Eds.), Infrastructures for Virtual Enterprises — Networking Industrial Enterprises, Kluwer Academic Publishers, Dordrecht, 1999. ISBN 0-7923-8639-6. [5] L.M. Camarinha-Matos, H. Afsarmanesh, C. Garita, C. Lima, Towards an architecture for virtual enterprises, J. Intelligent Manuf. 9 (2) (1998) 189–199. [6] L.M. Camarinha-Matos, C. Lima, Towards an execution system for distributed business processes in a virtual enterprise, in: High Performance Computing and Networking, Lecture Notes in Computer Science, No. 1823, Springer, Berlin, 2000, pp. 149–162. ISSN 0302-9743. [7] L.M. Camarinha-Matos, W. Vieira, Adaptive mobile agents for telerobotics and telesupervision, in: Proceedings of INES’98 — IEEE International Conference on Intelligent Engineering Systems, pp. 79–84. [8] L.M. Camarinha-Matos, W. Vieira, Intelligent mobile agents in elderly care, J. Robotics Autonomous Syst., 27 (1–2) (1999) 59–75. ISSN 0921-8890. [9] N. Carriero, D. Gelertner, Coordination languages and their significance, Commun. ACM 35 (2) (1992) 97–107. [10] H.T. Goranson, Agile Virtual Enterprises: Cases, Metrics, Tools, Quorum Books, 1999. [11] P. Heinl, S. Horn, S. Jablonski, J. Neeb, K. Stein, M. Teschke, A comprehensive approach to flexibility in workflow management systems, in: Joint Conference on Work Activities Coordination and Collaboration, San Francisco, USA, 1999. [12] A. Klen, R. Rabelo, L.M. Spinosa, A.C. Ferreira, Integrated logistics in the virtual enterprise: the PRODNET-II approach, in: Proceedings of IMS’98 — Fifth IFAC Workshop on Intelligent Manufacturing Systems, Gramado, Brazil, 9–11 November 1998. [13] T.W. Malone, K. Crowston, The interdisciplinary study of coordination, ACM Comput. Surv. 26 (1) (1994) 87–119. [14] OAG — Open Applications Integration White Paper, Open Applications Group, 1997. [15] A.L. Osorio, C. Antunes, M. Barata, The PRODNET communication infrastructure, in: Infrastructures for Virtual

[16]

[17]

[18]

[19] [20]

1021

Enterprises, Kluwer Academic Publishers, Dordrecht, 1999. ISBN 0-7923-8639-6. A.L. Osorio, L.M. Camarinha-Matos, Support for concurrent engineering in CIM-FACE, in: Balanced Automation Systems, Chapman & Hall, London, 1995, pp. 275–286. R. Rabelo, L.M. Camarinha-Matos, H. Afsarmanesh, Multi-agent-based agile scheduling, J. Robotics Autonomous Syst., 27 (1–2) 1999 15–28. ISSN 0921–8890. R. Rabelo, L.M. Camarinha-Matos, R. Vallejos, Agent-based brokerage for virtual enterprise creation in the moulds industry, in: E-business and Virtual Enterprises, Kluwer Academic Publishers, Dordrecht, 2000, pp. 281–290. ISBN 0-7923-7205-0. VIVE–VIVE Reference Model, 1999. www.ceconsulting.it/ VIVE/Results/default.html. WfMC — Workflow Management Coalition. The Workflow Reference Model, Document No. TC00-1003, Issue 1.1, Brussels, November 29, 1994.

Luis M. Camarinha-Matos is an Associate Professor at the New University of Lisbon where he is the Head of the Robotics and CIM group. He has been involved, both as Technical and Scientific Coordinator and as researcher, on several international research projects (ESPRIT, IST, INCO, ECLA, TEMPUS, COMETT, and LEONARDO programmes) in the areas of virtual enterprises, multi-agent systems, intelligent manufacturing systems and machine learning. Currently he is also the Coordinator of the IFIP COVE initiative for the harmonization of infrastructures for virtual enterprises and electronic business. He has served as General Chairman, Program Chairman, and Program Committee member of many conferences and was one of the Founders and Chairman of the steering committee of the BASYS and PRO-VE conference series.