Event-driven service coordination for business process integration in ubiquitous enterprises

Computers & Industrial Engineering 57 (2009) 14–26

Contents lists available at ScienceDirect

Computers & Industrial Engineering journal homepage: www.elsevier.com/locate/caie

Event-driven service coordination for business process integration in ubiquitous enterprises Jaehyun Kong a, Jae-Yoon Jung b, Jinwoo Park c,* a

Department of Industrial Engineering, Seoul National University, Seoul, Republic of Korea School of Mechanical and Industrial System Engineering, Kyung Hee University, Kyongki-do, Republic of Korea c Department of Industrial Engineering, Seoul National University, San 56-1, Silim-Dong, Gwanak-Gu, Seoul 151-742, Republic of Korea b

a r t i c l e

i n f o

Article history: Available online 17 September 2008 Keywords: Ubiquitous enterprise Event-driven computing Service-oriented architecture Business process integration Active rule

a b s t r a c t The Internet has improved service-oriented enterprises to allow for real-time enterprises, collaborative process management, and supply chain integration. However, ubiquitous enterprise environments are becoming more and more complicated since a variety of communication devices are emerged and interconnected to the existing enterprise systems. Service-oriented architecture based on web services technology provides a promising platform from which enterprises can coordinate seamlessly with e-Services in heterogeneous information systems. Nevertheless, adopting the architecture for ubiquitous enterprise environments poses some challenges since the wireless/wired systems around the enterprise may dynamically interact in the network and cause a considerable amount of meaningful state changes (called ‘‘events”). In this paper, a methodology that uses event-driven service technology and active rule processing is introduced for business process integration of ubiquitous enterprises. The event-driven approach to business process integration can supplement the service-oriented enterprise architecture by facilitating real-time event processing and distributed service coordination. We illustrate the proposed architecture by applying it to an international post-sales service company that sells electronic products. Ó 2009 Published by Elsevier Ltd.

1. Introduction Pervasive computing has motivated companies to create realtime enterprises. A representative technology for this idea is automatic identification and data capture (AIDC) using radio-frequency identification (RFID). RFID technology is also being adopted in manufacturing and service industries, such as at Hewlett–Packard, Boeing, and General Motors, as well as in the logistics industry, such as at Wal-Mart, Metro, and Tesco, for the purpose of improving costs, visibility, and productivity. Although there are different opinions about return on investment and time to market at present, most academics and practitioners agree that AIDC using RFID technology is essential for controlling and managing enterprise resources in real-time (Huang, Zhang, & Jiang, 2007; Zang & Fan, 2007). This research addresses business process integration in ubiquitous enterprise environments, which are becoming more and more complicated with the increasing adoption of a variety of computing and communication systems. The ubiquitous enterprises of the future have four characteristics that distinguish them from traditional manufacturing enterprises. First, event-driven architecture will lead to effective enterprise application integration (Luckham, 2002). Many more systems will take part in enterprise networks * Corresponding author. Tel.: +82 2 880 7179; fax: +82 2 889 8560. E-mail address: [email protected] (J. Park). 0360-8352/$ - see front matter Ó 2009 Published by Elsevier Ltd. doi:10.1016/j.cie.2008.08.019

and exchange complex information continuously in real-time. For instance, equipment, products, parts, and operators will be tagged with RFID sensors and disperse detailed real-time events anytime and anywhere to workers in the enterprises. How to filter the huge real-time events and exploit the information will be a critical factor for success in realizing ubiquitous enterprises. Second, a variety of heterogeneous systems will enable real-time communication on the Internet. Wired information systems have already been stably implemented with web-based technology (Apte, Deutsch, & Jain, 2005; Pashtan, Heusser, & Scheuermann, 2004; Pashtan, Kallipara, & Pearce, 2003). We can expect that convergence networks will be developed on the basis of web technology since wireless and mobile devices should be seamlessly integrated and communicate effectively with wired systems. Third, enterprise systems and organizations will provide their own functionality in a decentralized and autonomous manner. The large amount of data and information from distributed sources will become more difficult to manage in real-time, and the data rush will be increasingly accelerated (Bechini, Cimino, Marcelloni, & Tomasi, 2007; Cao, Zhang, Li, & Wang, 2005). Finally, the situation requires collaborative environments in which decentralized systems can accomplish their own business rules independently while they flexibly communicate with each other if specific needs arise. This research proposes a methodology for event-driven business process integration for ubiquitous enterprise environments.

J. Kong et al. / Computers & Industrial Engineering 57 (2009) 14–26

The ubiquitous collaborative process comprises e-Services and uWork. e-Services are considered automated activities which can be provided by well-defined application services, while u-Works are defined as manual activities which can be supported by ubiquitous computing devices such as RFID sensors. The two kinds of activities in distributed workspaces are coordinated in a decentralized collaboration network based on event-driven rule processing. The collaborative service interaction models are implemented by using event-driven web services technology. The proposed architecture has the following benefits listed below. (1) Event-based extensible collaboration. The architecture adopts the publish/subscribe mechanism using event notification, instead of the request/response mechanism, which existing service-oriented architecture have adopted. The approach helps to transfer real-time information in a timely manner to more event subscribers and allows other systems to join and leave dynamically while reacting to events of interest. (2) Seamless integration of heterogeneous systems. The architecture adopts event-driven web services technology, such as WS-Eventing and WS-ECA languages, as well as fundamental standards such as WSDL, SOAP, and UDDI. This adoption enables companies to develop fully decoupled integration of dynamically participating systems on the web. (3) Decentralized and autonomous service coordination. The architecture adopts distributed event-driven rule processing, not centralized service composition as used in WS-BPEL and WSCDL. The active rules can be modified independently and be executed in distributed service systems. It also helps more passive web services to react in a timely way to filtered events in real-time. This paper is organized as follows. We first discuss related work on event-based systems in Section 2. The concept of event-driven service computing is introduced, and a comparison with existing service-oriented architecture is presented in Section 3. In Section 4, the event-driven architecture of business process integration for ubiquitous enterprises is proposed, along with a case example of a post-sales service company. Subsequently, in Section 5, we describe how the business process can be separated into distributed collaboration models with the example service process. The prototype system, implemented in the case example, is described in Section 6, Section 7 concludes the paper.

2. Related work Event-based computing is an effective means of integrating distributed heterogeneous systems since it enables system components to interact by generating and receiving event notifications (Mühl, Fiege, & Pietzuch, 2006). Therefore, a large amount of research on event-based systems (EBS) has been conducted in widely varying areas such as database management systems (Dayal et al., 1998; Gehani, Jagadish, & Shmueli, 1992), enterprise systems (Cilia & Buchmann, 2002), and artificial intelligent applications (Liu, Sun, Dix, & Narasipuram, 2001), among others. In recent years, eventbased research has been adopted to improve the effectiveness and flexibility of complex enterprise systems. A representative trial for event-based systems is the analysis of event patterns, which involves using a template that matches certain sets of events (Luckham, 2002). The event patterns can be used to activate business rules by detecting characteristic event matching of numerous data, which have been collected by various sensors (Zang & Fan, 2007). Such event-driven approaches can be adopted to achieve various objectives in business environments. In particular, we assume that complicated service coordination in ubiquitous enterprises can be

15

one of the successful applications of event-driven service computing, as a lot of service devices and applications dynamically interact with each other to realize enhanced business environments. For this reason, we provide architecture that makes distributed systems integrate seamlessly in ubiquitous enterprise environments in which various events are generated and exchanged. Efforts to integrate distributed systems have been ongoing since the last decade. In particular, the multi-agent approach, which provides collaborative planning, scheduling, and evaluation, has often been adopted for autonomous monitoring and controlling of distributed resources (Jia, Fuh, Zhang, & Nee, 2004; Maturana & Norrie, 1996). Furthermore, we can construct real-time knowledgebased systems for dynamic logistic processes (Chow, Choy, & Lee, 2007) and monitor and control home appliances (Son, Kim, Shin, & Shin, 2006) using multi-agent technologies, because of the development of ubiquitous technologies such as RFID and sensor technologies. A multi-agent paradigm is useful for collecting data and controlling systems in distributed environments. Nevertheless, the approach was not standardized for enterprise application integration or business process integration, and it is not either flexible or extensible to adopt in ubiquitous enterprise environments. Concomitantly, service-oriented architecture (SOA) has received attention as a suitable architecture for integrating platform, protocol, and legacy systems. SOA is suitable for modern enterprise architecture because it aims for flexibility and adaptability through loosely-coupled integration by utilizing system implementation technology such as web services paradigms. Unfortunately, the SOA is not adequate for the ubiquitous enterprises examined in this paper, because the request/respond mode that SOA mainly adopts is sometimes inefficient at managing numerous enterprise events and adopting real-time AIDC technology. Recently, eventdriven architecture (EDA) has been proposed to meet the needs of the existing SOA. The architecture proposed in this paper attempts to create an architecture that can complement the existing SOA in ubiquitous enterprises based on an event-driven approach and reactive rule processing. The AIDC technologies that have been of interest for the last decade in enterprise environments are anticipated to facilitate inventory management, quality management, production tracking, security management, and factory automation, among other areas (Udoka, 1991, 1992). Although RFID technology was not applicable in practice in the 1990s because of the high price of RFID readers and tags, it is now considered a representative AIDC technology in various areas, such as manufacturing, logistics, health care, and national defense. Previous research on RFID technology includes monitoring present states through capturing real-time data collected by readers (Zang & Fan, 2007), providing real-time solutions in monitoring business processes (Chow et al., 2007), and dispatching jobs to business process in real-time (Huang et al., 2007). This research focuses on business process integration through realtime coordination using RFID technology. Many industry-driven standards for electronic product code (EPC) have been developed by EPCglobal to support the use of RFID in today’s fast-moving, information-rich, trading networks (EPCglobal, 2007). The standards, which include tag identity, data capture, data exchange, and architecture framework, help in the exchange of product history information and additional product information on the basis of web services technology. Moreover, major IT vendors provide solutions for managing information collected by RFID (for instance, Sun EPC Network, SAP Auto-ID Infrastructure, IBM WebSphere RFID Premises Sever, among others). However, the solutions do not yet perform functions beyond filtering and duplicate removal (Zang & Fan, 2007). The architecture proposed in this paper aims to support business process integration on the basis of real-time events filtered by such solutions.

16

J. Kong et al. / Computers & Industrial Engineering 57 (2009) 14–26

3. Event-driven services computing Service-oriented computing (SOC) is considered an effective technology for integrating distributed information systems in enterprise environments. SOC based on web services technologies mainly adopts the request/response mechanism by which a requester invokes an application service of a distributed service provider and receives the corresponding response message from the application. However, such service pulling is often inefficient in ubiquitous enterprise environments as the environments become more and more complex and because rapidly change to satisfy various business needs. For this reason, event-driven approaches were introduced to complement SOC in ubiquitous enterprise environments, for they allow service applications to be fully decoupled through event notification. In this section, a conceptual model of event-driven service computing is presented with related technology. A comparison of the existing service architecture and the proposed event-driven approach is provided. 3.1. Conceptual model In ubiquitous enterprises, a variety of sensors and controllers exchange significant information with one another to implement a timely and responsive enterprise environment. This requires an architecture that enables service applications to react to events. Such events are delivered continually and automatically from various internal or external business event sources including information systems, such as enterprise resource planning (ERP) and supply chain management (SCM) systems, and real-time sensors, such as RFID tags. Since the sources generate a considerable number of events in real-time, it is a crucial to recognize the events and perform the appropriate business actions. Fig. 1 shows the conceptual model of event-driven service computing in such business environments. The collection of real-time events is called the event cloud. The aim of event-driven service computing is to detect significant events from the event cloud, determine the business rules by using active rule engines, and finally perform the appropriate actions, such as service invocation. The complex event processing proposed by Luckham (2002) is one methodology for managing the event cloud. In contrast with Luckham’s study, this research focuses on service coordination for business process integration by processing realtime events in distributed and decentralized information systems. In our model, events include the information sent from ubiquitous sensors, such as RFID tags, as well as real-time data generated

service invocation

service

from enterprise applications. In addition, we assume that the services that can be invoked by active rules do not include only individual web services, but in addition the composed services of implementing business process languages such as WS-BPEL and WS-CDL. Since this research adopts web services technology for event-driven computing, event-driven rules can cover enhanced services based on web services invocation. The role of active rule engines is to trigger an appropriate action by recognizing and processing real-time events in the event cloud. The active rule takes an event-condition-action (ECA) form, and on specific events or event patterns it activates specific actions if certain conditions are satisfied. The rule engines play a significant role, because the extremely passive services in existing SOC are enabled to react to real-time events to coordinate their own services in a distributed and decentralized manner. The types of reaction include service invocation and event notification. 3.2. Event-driven web services technology Web services technologies have been extended to overall enterprise information systems based on Internet protocol for the purpose of achieving interoperability among heterogeneous systems. The initial outstanding web services specifications, WSDL, SOAP, and UDDI, are fundamental for the service description and messaging protocols, even though REST and AJAX have emerged as new approaches for lightweight and asynchronous web services communications. Furthermore, this service coordination technology has provided users with advanced services in the service-oriented computing paradigm. For instance, business process standard languages, such as WS-BPEL (Jordan et al., 2007) and WS-CDL (Kavantzas et al., 2005), have enabled the orchestration and choreography of web services (Peltz, 2003) and have facilitated the coordination of application services of internal organizations and business partners according to their business logics or trading contracts. In recent years, a number of event-based web services technologies have been proposed. Web service standards, such as WS-Eventing (Box et al., 2006) and WS-Addressing (Gudgin, Hadley, & Rogers, 2006), are increasing the adaptability of web services technology to distributed service systems by supporting endpoint descriptions and communication mechanisms among them, respectively. In particular, WS-Eventing provides the rich protocol required for the publish/subscribe mechanism used in web services technology. The functions of the protocol, which are defined in SOAP messages, include subscribe, unsubscribe, renew, get state, among other functions. The property is based on the assumption that distributed sys-

service invocation

Active Rule Engine service

event notification

event notification event subscription

event notification

event publication

event notification

event notification External Event Sources

Event Cloud

Internal Event Sources event notification

event notification event subscription

event notification

event notification

service

event publication event notification

Active Rule Engine service invocation

service service invocation

Fig. 1. Conceptual model of event-driven service computing.

17

J. Kong et al. / Computers & Industrial Engineering 57 (2009) 14–26

tems may dynamically integrate with other systems. We can extend the notification message in the standard to any domain. In addition, WS-ECA rules (Jung, Park, Han, & Lee, 2007) have been proposed to coordinate ubiquitous services. WS-ECA describes ECA rules, which define the reactive behaviors of various web service interactions. The ECA rules are triggered by internal events of service applications or external events from other applications. The triggered rules, when their condition parts are satisfied, will be activated to execute their actions. Specifically, service events are defined to catch the timing of invoking specific services and finishing the service, and external events are exploited to respond to event notifications which received from external systems. These events can be integrated into web service event technology, WS-Eventing and WS-Addressing, to implement eventdriven service systems in ubiquitous enterprise environments. Fig. 2 shows the schema of the rule language. The schema of the rule language consists of four basic elements: event, condition, action, and variable. In the event parts, primitive events, such as time, service, internal, and external events, play a role in triggering ECA rules, and these can be combined to express composite events by using logical operators (disjunction, conjunction, sequential, and negation operators). Action parts have similar structures, including primitive and composite ones. Primitive actions in WSECA rules can invoke an application service and create an external or internal event. Variables are used to assign or exchange temporary values in the rule. Detailed information about these rules can be found in a previous study (Jung et al., 2007). The mechanism of WS-ECA rules support service interaction in two ways: through service invocation and event notification. Service invocation is the general concept of the existing web services

architecture for using the request/response mechanism. Event notification is the means of implementing event-driven service interactions, and in this paper we use the publish/subscribe mechanism based on the WS-Eventing standard. Since the event notification technique is considered fully decoupled and reactive compared to the service invocation technique, event-driven architecture is emerging to supplement service-oriented architecture in which service activation is very passive (Chandy, 2006; Hanson, 2005; Michelson, 2006). Furthermore, the publish/subscribe mechanism of WS-Eventing standards is effective in ubiquitous environments in which a system event may affect many unknown devices. In our proposed architecture, the two approaches to service interaction are complementary, so that service invocation can be used to request public services and event notification can be used to inform others that significant events have occurred. 3.3. Service pulling vs. event pushing Service coordination, such as that between WS-BPEL and WSCDL, has facilitated enhanced service applications in SOA environments. The techniques are generally divided into two types: service orchestration, which organizes inner enterprise resources into the business process, and service choreography, which describes business transaction procedures between independent service providers. Both types have adopted the request/response mechanism of requesting particular services and responding to the corresponding results of the request. They are considered part of the service pulling method, as shown in Fig. 3(a). The figure illustrates an example of WS-BPEL as a service coordination language. The mechanism requires the centralized engine to coordinate different business log-

WS-ECA

Event

Condition

variable

Action

device variable event variable Primitive event Time

Composite event absolute

disjunction

periodic

Primitive action

Composite action

conjunction

invokeService

disjunction

relative

sequential

createExtEvent

conjunction

service

before

negation

createIntEvent

internal

after

external Fig. 2. Schema of WS-ECA rules.

event sources

pub/sub request/ response deployed services

(a) service pulling (e.g. WS-BPEL)

active rules

hidden reaction

(b) event pushing (e.g. WS-ECA)

Fig. 3. Service pulling and event pushing.

18

J. Kong et al. / Computers & Industrial Engineering 57 (2009) 14–26

Table 1 Comparison between service pulling and event pushing Category

Service pulling

Event pushing

Communication method

Request/response mechanism

Publish/subscribe mechanism

Initiation

Initiated by service request

Initiated by event notification

Action

Invoke well-defined services of providers one by one

Push events to multiple distributed event-based systems

Applications

Proper to robust business transactions

Proper to complicated business environments such as ubiquitous enterprises

Base technology

WS-BPEL, WS-CDL, WSCI, BPML

WS-Eventing, WS-ECA

ics, such as those of BPEL engines. They invoke individual services only when they need specific help with the deployed service. The business logic is processed according to the business process in WS-BPEL. In contrast, the approach to event-driven service coordination adopts the event pushing method illustrated in Fig. 3(b). The event sources send their event messages to subscribed recipients whenever their states change or new events are generated. The role of processing the event message is assigned to the decentralized rule engines in the recipients. WS-ECA language can be used to implement the business rules for the purpose of hidden reaction. In summary, the service pulling mechanism requires the centralized coordination engine, which controls all the procedures in the business activities, while the event pushing mechanism contains the decentralized services, which react with each other according to their own business rules. Let us compare the two interaction methods based on their web services technology (see Table 1). Basically, service pulling assumes the request/response mechanism while the event pushing does the publish/subscribe mechanism. For this reason, for service invocation, we should know where and which services exist in the business environments and how we can invoke the services (for instance, input parameters and the schema). However, it is quite inefficient and labor-consuming to determine these parameters in ubiquitous enterprises since the environments may have a lot of services and event sources that are dynamically emerging and disappearing. In contrast, for event pushing, we have to know only the schema of the event of interest, which enables service sources to spread their real-time events to multiple event sinks more conveniently. The event sinks are decided by the subscription mechanism, which is supported by the WS-Eventing standard along with other message specifications, such as unsubscription, renew, and notification. In addition, service pulling is initiated by service requests when the request recognizes the business demands, while event pushing is performed by service providers themselves as soon as they receive the events. This property enables decentralized service coordination through the event pushing method. In addition, service pulling is effective in robust enterprise applications requiring business transactions. In contrast, event pushing is more appropriate for complicated and dynamic business environments. In summary, the event pushing method is a more suitable architecture for ubiquitous enterprise environments since it allows distributed systems to deliver their real-time events to more unspecified recipients and coordinate their services in an independent and decentralized manner. 4. Architecture for ubiquitous enterprise We assume that business processes in ubiquitous enterprises are composed of two types of activities: e-Services and u-Works. On the one hand, e-Service is the automated activity that is imple-

mented on the basis of service-oriented computing. Many service coordination languages like WS-BPEL are assumed to call the services via SOAP messages that incorporate WSDL descriptions. On the other hand, ubiquitous work, abbreviated u-Work, is defined as the task that a human worker accomplishes in the environment that is supported by ubiquitous computing devices, such as RFID technology. For instance, repair operators in a ubiquitous service company manually diagnose problems with electronic products in the workspace, which is equipped with RFID readers to trace the RFID tagged products and identify the states of manual activities. In this section, an architecture for ubiquitous enterprises is presented, and a case example of an international post-sales service company is introduced to illustrate business process integration based on the proposed architecture. 4.1. Event-driven service architecture The architecture for event-driven service coordination assumes the u-Work meta model shown in Fig. 4. The u-Process element is composed of e-Services and u-Works, which are automated and manual activities, respectively. The rule element coordinates the two types of activities by invoking services or generating events, and the events, in particular, can be generated by both u-Sensors and other rules. The rule can be triggered by single events and event patterns when its condition is satisfied. Event patterns (i.e. composite events) are composed of primitive events accompanied with (logical, temporal, and context) operators. The u-Work meta model differs from general work models. uWork is not directly associated with worker, time, location, product, and state. Instead, the u-Sensor plays the role of the mediator, and detects information about who, when, where, what, and how, to generate the events to trigger the business rules. For instance, when a repair operator brings a product to his/her worktable at a specific time, the sensor on the worktable will detect the operator and the product and then generate events that contain the data of worker, time, location, product, and state. In those ways, events from the sensors execute the ubiquitous process, which is composed of u-Works and e-Services. The architecture for event-driven service coordination is illustrated in Fig. 5. In the center of the architecture, a workflow management system (WFMS) is located for the purpose of integrating business processes in the overall enterprise. On the one hand, WFMS interacts with information systems providing various e-Services, such as ERP, SCM, warehouse management (WM), and other legacy applications. On the other hand, the WFMS is also supported by AIDC systems, such as RFID readers offering real-time events for u-Services. It may interact with the systems of external business partners in order to obtain useful information about RFID tagged products (for instance, product manufacturing history) by implementing the EPCglobal standards such as EPC information services EPCIS (2007). To conduct real-time interactions among the enterprise systems including WFMS, both interaction methods, service pulling and event pushing, can be used through web services technology. In particular, active rule engines (ARE) can play a leading role in implementing service invocation and event notification, while detecting real-time events and performing the appropriate actions in each information system. The proposed architecture is based on three assumptions to transform traditional service companies into ubiquitous enterprises: (1) All products have been tagged with item-level RFID in factories. They can be identified in each step of the business process, such as during unloading and shipping.

19

J. Kong et al. / Computers & Industrial Engineering 57 (2009) 14–26

Worker detect who u-Process

u-Work

u-Sensor

detect when

Time

use detect where generate

monitor

Location detect what

Event trigger execute

detect how

Product

generate State e-Service

use

Rule

Event Pattern

invoke Logical operator use

trigger

Conditon

Operator

Temporal operator

Context operator

Fig. 4. u-Work meta model.

ERP ARE

S

SCM ARE

S

service invocation

S

WMS ARE

S

S

Legacy ARE

S

S

S

event notification S

S

S

S

ARE WFMS

S

S

S

ARE

S

Active rules

ARE S EPCIS Server

S

Real-time data

Workflow

ARE AIDC System (i.e. RFID reader)

EPC network standards

air interface

S

Partners

service invocation event notification service

Ubiquitous Work Space Fig. 5. Event-driven service architecture for ubiquitous enterprises.

(2) The RFID readers in the steps are connected to an application level event (ALE) server, which sends the filtered event messages to pre-subscribed information systems such as ERP, SCM, WMS, and legacy systems. (3) The EPCIS server can communicate with the servers of business partners and check for detailed service information, such as the warranty period of each product or the service policy for each client. The first assumption is straightforward since many market researchers forecast that the electronic product industry will be

the industry in which manufacturers will adopt the RFID tags in item-levels the fastest. The second assumption is currently being put into practice in companies that are adopting RFID technology in manufacturing and logistics. The number of RFID signals is enormous, and the RFID middleware such as ALE servers is generally used to filter and gather significant information about RFID tagged products. The last assumption has been promoted by EPCglobal, and many solution vendors have already started to provide the EPCIS servers that could support business partners in querying and discovering information about the production and logistics of business partners.

20

J. Kong et al. / Computers & Industrial Engineering 57 (2009) 14–26

4.2. Example of an ubiquitous enterprise In this section, an international post-sales service company is introduced as an example of business process integration. This example will be used to illustrate event-driven service coordination for ubiquitous enterprises in this paper. The company provides European clients (generally, value-added retailers) with repair service for various electronic products that are manufactured in Asia. The core business process of the repair service was depicted in BPMN notation (OMG., 2006), as shown in Fig. 6. The process is composed of eleven activities, which are executed by humans or automated systems. First, clients register the repair requests of their products through web pages or call centers. After a client finishes the registration of the products that require repairs, an identification number is issued for the repair request. Next, as soon as the products arrive at the service company, workers unload the items and compare them to the product list in the registration. If the delivered products are inconsistent with the list, they ship them back. Otherwise, inspectors diagnose the problems and find which parts to substitute for repair. They then check the stock of the parts to substitute. If the necessary parts are not in stock, they order the parts from the factories in Asia and wait for their arrival. If they already hold or have restocked the parts, engineers repair the items and workers finally ship them to the client. The activities of the process can be divided into manual activities (i.e. u-Works) and automated activities (i.e. e-Services), as shown in Fig. 7. In particular, u-Works, such as ‘unload items’, ‘ship back’, ‘restock’, ‘ship items’ and ‘carry parts’ activities in the warehouse and ‘diagnose problems’ and ‘repair items’ activities in the repair center, are supported by RFID readers. By utilizing RFID tags and readers, we can recognize and record significant data about u-Works in physical business processes, such as products, workers, time, location, and motion. For example, the start of the activity ‘diagnose problems’ can be recognized by

capturing a new event through the RFID reader of the worktable as soon as the operator brings an RFID tagged product to the table for repair. In addition, it can be ascertained which operator is repairing the product by determining the location of each worker in the same way. Moreover, the data can be integrated into e-Services to accomplish the business process efficiently. In the ‘‘check stock” e-Service of the figure, as soon as the event of an operator finishing the diagnosis is generated, the workflow engine automatically invokes the ‘‘stock checking service” of the Warehouse Management System. 5. Ubiquitous service coordination 5.1. Service coordination model In this section, we present a distributed collaborative process model of implementing event-driven service coordination in ubiquitous enterprises. The model is composed of three sub-models from the macro view of business processes to the micro view of executable rule descriptions. First, a global process model is described to express overall collaboration of multiple organizations or systems. The model is then decomposed to local process models and message exchange models according to the workspaces in which each activity (e-Service and u-Work) is accomplished. Finally, the two models are transformed into ECA rules, which can be executed in active rule engines.

d Global process model. The model is defined as a directed graph denoted as W = . In the model, A is a set of activities required in the collaboration, T(A/AF)(A/AS) is a set of control flow relations that express control flow among the activities (herein, ASA are the starting activities, and AFA are the finishing activities), and split: A?{AND, XOR, OR} and

same to registration?

register repairs

unload items

parts in stock? Yes

check item list

diagnose problems

Yes

check stocks

No

repair items

ship items

restock

carry parts

No

ship back

order parts

Fig. 6. An example of a repair service process.

Fig. 7. Automated and manual activities in the repair service process.

J. Kong et al. / Computers & Industrial Engineering 57 (2009) 14–26

join: A?{AND, XOR, OR} are the split behavior and the join behavior, respectively, expressing special types of control flows. In addition, S is a set of local workspaces in any one of which an activity can be executed, and ctrl: A?S is the function of mapping from an activity to a workspace. d Local process model. A local process model is executed in only one workspace, while a global process model may be executed in more than workspace. Therefore, a local process can be controlled based on its control flow in a workspace, and it interacts with another local process through the message flow. A local process model has a similar structure to that of a global process model, and it is denoted as WL = , where AL is a set of activities in WL, but not TTL, because additional dependencies are created when a global process is separated into multiple local processes. The method of separation is described in the ProcessLocalization algorithm. d Message interaction model. The model is defined as M = , where AM is a set of activities generating M, E is a set of events that are contained in the message and are sent to another local process, and D is the destination activity of the message. Note that AAL, but not TTL because additional dependencies are created when a global process is separated into multiple local processes. To discover local process and message interaction models from a global process model, the ProcessLocalization algorithm is adopted in this paper. This algorithm was developed in our previous work to decompose a global business-to-business process model into local sub-processes (Jung, 2005). It supports the discovery of sub-processes that will be executed by distributed workflow engines in individual companies. Fig. 8 shows the algorithm. The algorithm starts with a global process model W to extract local process models LP and message interaction models M. In the first step, the algorithm appends all starting activities as2AS(W) to a new queue Q (Line 3). Next, the algorithm searches control

21

flows and message flows through a breadth-first-search algorithm (Lines 4–19). For each activity a in Q, the workspace of a is compared to that of each precedent activity of a in W, apre2Apre(a). If two workspaces of a and apre are different (i.e. wksp(a)–wksp(apre)), a new message flow from apre to a (X(apre, a)) is created and inserted into the message set M, because two activities should be considered different local processes (Line 7). If the two workspaces of a and apre are the same and the local process of a is not yet assigned, the process of apre is assigned to that of a (Line 8) i.e. they are considered the same local process. If two workspaces a and apre are the same, but the two local processes of a and apre have been assigned differently, the processes should be merged into one because they are executed for a global process in the same workspace. Therefore, the process of apre is removed, and the processes of all a0 2A(proc(apre)) are changed to proc(a) (Lines 9– 12). The update is caused by the fact that an activity may have more than one precedent activity whose local processes are not the same. However, if a is a starting activity and it does not have any precedent, a new local process WL is created and added into LP, and WL is assigned to the process of a (Lines 14–17). Finally, all successive activities asuc2Asuc(a) are appended to Q for the purpose of continuing breadth-first-searches in the While statement (Line 18). After local process and message interaction models are extracted from the global process in the algorithm, the models are transformed into ECA rules that can be executed in active rule engines. The rules include flow constraint rules, e-Service interaction rules, and u-Sensor detection rules. Flow constraint rules are used to manage control flows in the workspace and message flows among other workspaces. e-Service interaction rules are designed to perform service request and responses with service-oriented information systems, while u-Sensor detection rules are defined for u-Work to catch data and ubiquitous computing devices including RFID. Both e-Service and u-Work have starting and ending constraints, which change the state of the activity to Ready and End, respectively. Fig. 9 shows the state diagram of e-Service and u-

Fig. 8. ProcessLocalization algorithm.

22

J. Kong et al. / Computers & Industrial Engineering 57 (2009) 14–26

STATE

RULE (e-Service)

5.2. Example of service coordination

RULE (u-Work)

Not Ready flow constraint rule (starting constraints)

flow constraint rule (starting constraints) Ready e-Service interaction rule (service request)

u-Sensor detection rule (starting point) Executing

e-Service interaction rule (service response)

u-Sensor detection rule (ending point) Completed flow constraint rule (ending constraints)

flow constraint rule (ending constraints) End

Fig. 9. State transition diagram of e-Service and u-Work.

Work. Both are changed from Not Ready to Ready by satisfying their starting constraints, and they are finally performed from Completed to End by processing their ending constraints in order to make other activities Ready. The two kinds of constraints are modeled in flow constraint rules. e-Service and u-Work can then be enacted in the local process by combining the flow constraint rules to e-Services and u-Works, respectively. The e-Service interaction rule sends a request message in the Ready state to change the state of e-Service into Executing. If the response message is received from the service provider, the state can be changed to Completed. In contrast, the u-Sensor detection rule does not directly execute u-Work. Instead, it only recognizes the change of u-Work and then changes the state to enact the local process. The U-Sensor detection rule also changes the state of u-Work from Ready to Executing and again from Ready to Completed by detecting sensor data, such as that generated by RFID readers.

A1

A2

A3

A4

The global process model of the case in Section 4.2 is fully described in Fig. 10. The model contains 11 activities and 11 transitions including two XOR splits and an XOR join. There are four workspaces: customer support system S1 and warehouse management system S2 provide the automated services for the collaborative process, while shipping center S3 and repair center S4 are the workspaces where human operators work to perform the manual activities. In detail, {A1, A3} are executed in S1, {A6, A7} in S1, {A2, A5, A8, A9, A11} in S3, and {A4, A10} in S4. The model is decomposed into four local process models using the ProcessLocalization algorithm. Fig. 11 shows the local process and message interaction models. Each workspace has a local process model, some activities of which may have message interaction as a message source or destination. Note that the relations of splitL and joinL are AND constraints in default. In other words, if an activity has a split or join relation in the global process model, the relation of the activity in the local process model has the same constraint (e.g. XOR splits of A3, and A6, and XOR join of A10). However, if an activity has more than one outgoing transition or message (e.g. A1 and A2), the AND constraint is assigned to its splitL relation in default. joinL relations are handled in the same way (e.g. A3 and A5), and the AND constraint is assigned to it by default. Next, each local process model is transformed into three types of ECA rules: flow constraint rules, e-Service interaction rules, and u-Sensor detection rules. First, let us describe the flow constraint rules of W1 in workspace S1. The first activity A1 does not have any starting constraints, but it has two ending constraints: one is to generate a control flow toward activity A3 and the other is to send a message flow to activity A2 in workspace S3. For the last activity of W1, the starting constraint of A3 is to receive a control flow from A1 and a message flow from A2 of S3, and its ending constraint is to send a message flow to either A5 of S3 or A4 of S4 because of XOR splitL. The constraints of local process W1 can be transformed into the flow constraint rules as shown in Fig. 12.

A6

A5

Activity (A) A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11

Activity name Register repairs Unload items Check item list Diagnose problems Ship back Check stocks Order parts Restock Carry parts Repair items Ship items

Transit ion (T) A2 A3 A4, A5 A6 A7, A10 A8 A9 A10 A11

split

A7

join

ctrl S1 S3 S1 S4

XOR

XOR

XOR

Workspace (S) S1 S2 S3 S4

S3 S2 S2 S3 S3 S4 S3

Fig. 10. Global process model W of the case in Fig. 7.

A10

A11

A8

A9

Workspace name Customer support system Warehouse mgt system Shipping center Repair center

23

S1

J. Kong et al. / Computers & Industrial Engineering 57 (2009) 14–26

A1

A3

M1 S2

M2 A6

M3

A7

M4

S3

M7 A2

A5

M5

M6

A8

A9

A11

M8

S4

M9 A4

Workspace Local process Activity Transit (WL) (AL) ion(TL) S1 W1 A1 A3 A3 S2 W2 A6 A7 A7 W3 A2 A5, A8 S3 A5 A8 A9 A9 A11 A11 S4

W4

A4 A10

A10

splitL joinL AND XOR XOR

AND

AND AND

Message (M) M1 M2 M3 M4 M5 M6 M7 M8 M9

A10 XOR

Fig. 11. Local process and message interaction models.

Fig. 12. Flow constraint rules.

Source (AL) A1 A2 A3 A3 A4 A6 A7 A9 A10

Destination (D) A2 A3 A4 A5 A6 A10 A8 A10 A11

24

J. Kong et al. / Computers & Industrial Engineering 57 (2009) 14–26

Fig. 13. e-Service interaction rules.

Fig. 14. u-Sensor detection rules.

Secondly, e-Service interaction rules are created for A1 and A3 because they are automated activities. The rules are described in Fig. 13. The two rules in Fig. 13 (a) change the state of A1 from Ready to Executing by event ‘‘service.request” and again from Executing to Completed by ‘‘service.response”. The two rules in Fig. 13 (b) invoke the service of A3 as soon as its state is changed

to Ready, and then after receiving the response, its state is changed again to Completed. Fig. 14 shows the example of u-Sensor detection rules of uWorks A2 and A5. The rules in Fig. 14 change the states of A2 and A5 from Ready to Executing and from Executing to Completed by corresponding events.

Fig. 15. Example of business process integration.

J. Kong et al. / Computers & Industrial Engineering 57 (2009) 14–26

6. Prototype system for ubiquitous service coordination In this section, the prototype system of the example case is illustrated. The example process is executed through e-Services, which are provided by automated information systems (the customer support system and the warehouse management system) and u-Works, which are manual works supported by RFID sensors (in the shipping center and the repair center). As shown in Fig. 15, the process is initiated when an operator in the call center registers the repair request to the web-based customer support system, which is the e-Service ‘‘register repairs”. However, the u-Work ‘‘diagnose problem” activity is a manual task tracked by RFID readers in the repair center. In Fig. 15, tasks with antenna notations are u-Works, while the ones without the notations are e-Services. The u-Works in the process can be supported by RFID applications. A prototype of RFID application has been developed using ALR-9800 readers and UHF Gen2 tags of an RFID vendor, Alien Technology. The system is composed of two sub-systems: RFID Manager and u-Work Support System. The RFID Manager was developed in Microsoft C# programming language based on .NET

25

framework using the library provided by Alien Technology, and the u-Work user interface was developed for web browsers. Fig. 16 illustrates the ubiquitous workspace of the u-Work ‘‘diagnose problems” activity supported by the developed prototype application. In the repair center, RFID tags are attached to operators and products. RFID readers recognize the identification data of operators and products and send them to the RFID Manager. The reader under the worktable can then recognize the product on the table, which means that the operator is working the ‘‘diagnose problems” activity. In addition, the operator can be supported by the user interface of the u-Work Support System of providing helpful information on the work. In the RFID Manager, the identification data of operators are used for authentication and authorization in the service process and those of the products are used to obtain the repair history from business partners through EPCglobal Network standards. The information is provided to the u-Work Support System. As illustrated in the figure, the user interface of the prototype provides useful information for repair. The information includes the identification of the worker, the work name recognized by

Fig. 16. u-Work ‘‘diagnose problems” supported by RFID technology.

26

J. Kong et al. / Computers & Industrial Engineering 57 (2009) 14–26

the workspace, the detailed model information of the product, the reference documents related to the model, the customer information, and the model repair history received form business partners. 7. Conclusions Recently, the application of ubiquitous computing technologies, such as RFID sensors, has enabled real-time enterprise by facilitating visibility, traceability, and controllability. Since information systems in the ubiquitous enterprise create a considerable number of events, an effective and reactive event processing technique is required to coordinate existing business services. In this research, we propose event-driven service coordination architecture for ubiquitous enterprises to implement business process integration. The proposed architecture can be an effective means of implementing real-time enterprises since the approach aims at fully decoupled integration based on event notification in a decentralized and autonomous manner. In the architecture, the collaborative process is assumed to be composed of e-Services and u-Works. Especially, u-Works are supported by AIDC systems such as RFID applications. The events of u-Works are integrated with those of e-Services based on event-driven rule processing to coordinate manual and automated activities in the process. Our approach was proposed to address the architecture for ubiquitous enterprises. Compared to the traditional communication paradigm, such as multi-agent techniques, the service-oriented architecture based on web services technology, which is adopted for our architecture, is nowadays regarded as the most effective technology for enterprise application integration, since it assumes flexible and extensible XML-based message exchange over the HTTP protocol, and it has evolved with a variety of WS-* standards in wide areas, such as WS-Addressing, WS-ECA, WSBPEL, and WS-Policy. Furthermore, the ubiquitous paradigm requires more complicated and reactive communication architecture beyond the existing service-oriented architecture. For the reason, we suggested the event-driven service coordination for ubiquitous enterprises. In addition, we described the mechanism of integrating the event notification to business process integration based on ECA rules. As a result, the primitive events, such as RFID sensors, can also interact with information systems to enact collaborative business process of combining u-Works and e-Services. We illustrated the event-driven architecture for business process integration with a case example of a post-sales electronic products service company. In addition, a prototype system was implemented to support u-Work with RFID technology in the service process. More importantly, the system can be extended to improve productivity and effectiveness by exchanging real-time process information with business partners. Acknowledgements This work was supported by the Korea Research Foundation Grant funded by the Korean Government (MOEHRD, Basic Research Promotion Fund) (KRF-2008-331-D00709). We would also like to acknowledge financial and administrative supports provided from ‘Seoul R&BD Program’ sponsored by the Seoul Metropolitan Government, ‘Brain Korea 21 Project’ sponsored by the Korean Research Foundation, and ASRI(Automation and Systems Research Institute) in Seoul National University. References Apte, N., Deutsch, K., & Jain, R. (2005). Wireless SOAP: Optimizations for mobile wireless web services. In Proceedings of world wide web conference (WWW2005) (pp. 1178–1179). Japan.

Box, D., Cabrera, L. F., Critchley, C., Curbera, F., Ferguson, D., Graham, S. et al. (2006). Web services eventing. W3C member submission. Available from http:// www.w3.org/Submission/WS-Eventing/. Bechini, A., Cimino, M. G. G. A., Marcelloni, F., & Tomasi, A. (2007). Patterns and technologies for enabling supply chain traceability through collaborative ebusiness. Information and Software Technology, 50(4), 342–359. Cao, J., Zhang, S., Li, M., & Wang, J. (2005). Distributed design process coordination based on a service event notification model. Concurrent Engineering: Research and Applications, 13(4), 301–310. Chandy, K. M. (2006). Event-driven applications: Costs, benefits and design approaches. Gartner Application Integration and Web Services Summit. Available from http://www.infospheres.caltech.edu/papers/Gartner_20060620. pdf. Chow, H. K. H., Choy, K. L., & Lee, W. B. (2007). A dynamic logistics process knowledge-based system – an RFID multi-agent approach. Knowledge-Based Systems, 20(4), 357–372. Cilia, M., & Buchmann, A. (2002). An active functionality service for e-business applications. ACM SIGMOD Record, 31(1), 24–30. Dayal, U., Blaustein, B., Buchmann, A., Chakravarthy, U., Hsu, M., Ledin, R., et al. (1998). The HiPAC project: Combining active databases and timing constraints. ACM SIGMOD Record, 17(1), 51–70. EPCglobal homepage. Available from http://www.epcglobalinc.org/. EPCIS (2007). EPC information services (EPCIS) version 1.0 specification. EPCglobal ratified standard. Available from http://www.epcglobalinc.org/standards/epcis. Gehani, N. H., Jagadish, H. V., & Shmueli, O. (1992). Event specification in an active object-oriented database. In Proceedings of the 1992 ACM SIGMOD international conference on management of data. California: San Diego (pp. 81–90). Gudgin, M., Hadley, M., & Rogers, T. (2006). Web services addressing 1.0- core. W3C recommendation. Available from http://www.w3.org/TR/ws-addr-core/. Hanson, J. (2005). Event-driven services in SOA: Design an event-driven and service-oriented platform with Mule. JavaWorld. Available from http:// www.javaworld.com/javaworld/jw-01-2005/jw-0131-soa.html. Huang, G. Q., Zhang, Y. F., & Jiang, P. Y. (2007). RFID-based wireless manufacturing for walking-worker assembly islands with fixed-position layouts. Robotics and Computer-Integrated Manufacturing, 23(4), 469–477. Jia, H. Z., Fuh, J. Y. H., Zhang, Y. F., & Nee, A. Y. C. (2004). An adaptive and upgradable agent-based system for coordinated product development and manufacture. Robotics & Computer-Integrated Manufacturing, 20(2), 79–90. Jordan, D., Evdemon, J., Alves, A., Arkin, A., Askary, S., Barreto, C. et al. (2007). Web services business process execution language version 2.0. Committee specification, OASIS. Available from http://xml.coverpages.org/WS-BPELCS01.pdf. Jung, J. -Y. (2005). Design and analysis of B2B collaborative process using process choreography and workflow clustering. Ph.D. Thesis, Seoul National University, Korea. Jung, J.-Y., Park, J., Han, S.-K., & Lee, K. (2007). An ECA-based framework for decentralized coordination of ubiquitous web services. Information and Software Technology, 49(11–12), 1141–1161. Kavantzas, N.Kavantzas, N., Burdett, D., Ritzinger, G., Fletcher, T., Lafon, Y., & Barreto, C. (2005). Web services choreography description language version 1.0. W3C candidate recommendation. Available from http://www.w3.org/TR/ws-cdl-10/. Liu, K., Sun, L., Dix, A., & Narasipuram, M. (2001). Norm based agency for designing collaborative information systems. Information Systems Journal, 11(3), 229–247. Luckham, D. (2002). The power of events: An introduction to complex event processing in distributed enterprise systems. Addison-Wesley: Pearson Education. Maturana, F. P., & Norrie, D. H. (1996). Multi-agent mediator architecture for distributed manufacturing. Journal of Intelligent Manufacturing, 7(4), 257–270. Michelson, B. (2006). Event-driven architecture overview: Event-driven SOA is just part of the EDA story. White paper, Patricia Seybold Group. Available from http://www.psgroup.com/detail.aspx?ID=681. Mühl, G., Fiege, L., & Pietzuch, P. (2006). Distributed event-based systems. Verlag Berlin Heidelberg: Springer. OMG. (2006). Business process management notation specification. OMG adopted specification. Available from http://www.bpmn.org/. Pashtan, A., Heusser, A., & Scheuermann, P. (2004). Personal service areas for mobile web applications. IEEE Internet Computing, 8(6), 34–39. Pashtan, A., Kallipara, S., & Pearce, M. (2003). Adapting content for wireless web services. IEEE Internet Computing, 64(5), 79–85. Peltz, C. (2003). Web services orchestration and choreography. IEEE Computer, 36(10), 46–52. Son, M., Kim, J., Shin, D., & Shin, D. (2006). Research on smart multi-agent middleware for RFID-based ubiquitous computing environment. Lecture Notes in Computer Science, 4088, 787–792. Udoka, S. J. (1991). Automated data capture techniques: A prerequisite for effective integrated manufacturing system. Computers & Industrial Engineering, 21(1-4), 217–221. Udoka, S. J. (1992). The role of automatic identification (Auto ID) in the computer integrated manufacturing (CIM) architecture. Computers & Industrial Engineering, 23(1-4), 1–5. Zang, C., & Fan, Y. (2007). Complex event processing in enterprise information systems based on RFID. Enterprise Information Systems, 1(1), 3–23.