<%BANNER%>

Meta-Rule Enhanced Interoperation of Rules and Processes for Achieving Dynamic Inter-Organizational Collaboration

Permanent Link: http://ufdc.ufl.edu/UFE0043932/00001

Material Information

Title: Meta-Rule Enhanced Interoperation of Rules and Processes for Achieving Dynamic Inter-Organizational Collaboration
Physical Description: 1 online resource (157 p.)
Language: english
Creator: Xiao, Xuelian
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2012

Subjects

Subjects / Keywords: collaboration -- events -- interorganization -- metarules -- processes -- rules
Computer and Information Science and Engineering -- Dissertations, Academic -- UF
Genre: Computer Engineering thesis, Ph.D.
bibliography   ( marcgt )
theses   ( marcgt )
government publication (state, provincial, terriorial, dependent)   ( marcgt )
born-digital   ( sobekcm )
Electronic Thesis or Dissertation

Notes

Abstract: In today's complex and changing world, government and business organizations worldwide often find the need to share their resources and coordinate their activities in order to solve many complex problems and stay competitive. Resource sharing should not be limited to data and computing resources. The sharing and interoperation of organizational policies, constraints, regulations and processes are also very important for achieving inter-organizational collaboration. Organizational resources as well as organizations' partnership can change at any time in a dynamic environment. Thus, inter-organizational processes that carry out inter-organizational collaboration and coordination must be dynamically constructed and processed. This work aims to research on and develop an integrated rule and process specification language, an Event-Triggered Knowledge network (ETKnet 2.0) system, and a meta-rule enhanced, distributed rule processing and process enactment technique to achieve the sharing and interoperation of organizational resources, and the dynamic construction and processing of inter-organizational processes for achieving inter-organizational collaboration and coordination. The integrated specification language is for use by collaborating organizations to independently specify 1) events of common interest, 2) policies, constraints and regulations in terms of different types of business rules (integrity constraints, derivation rules and action-oriented rules), 3) manual/automated operations, and 4) workflow processes. A process is defined in the form of a structure of activities, which invoke different kinds of rules and/or automated/manual operations. An action-oriented rule, when triggered by an event instance, can enact a process, which may contain rules to conditionally enact other processes, making rules and processes interoperable. The specified rules and processes are automatically translated into Java code and then packaged as Web services for their uniform discovery, processing, sharing and interoperation in a Web service infrastructure. The meta-rule enhanced, distributed rule processing and process enactment technique implemented in ETKnet 2.0 enables the dynamic construction of inter-organizational processes in a declarative way, and the processing of inter-organizational processes in a decentralized way. Meta-rules are used to enforce some constraints in the processing of distributed rules and processes defined by collaborating organizations. The introduction of meta-rules also allows collaborating organizations to conduct "what-if" analyses to test or exercise their collaboration in a changing environment. The proposed specification language, the network system, and the rule processing and process enactment technique are applied in two application areas, namely e-government and e-business, to demonstrate their utilities for inter-organizational collaboration and coordination.
General Note: In the series University of Florida Digital Collections.
General Note: Includes vita.
Bibliography: Includes bibliographical references.
Source of Description: Description based on online resource; title from PDF title page.
Source of Description: This bibliographic record is available under the Creative Commons CC0 public domain dedication. The University of Florida Libraries, as creator of this bibliographic record, has waived all rights to it worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law.
Statement of Responsibility: by Xuelian Xiao.
Thesis: Thesis (Ph.D.)--University of Florida, 2012.
Local: Adviser: Su, Stanley Y.

Record Information

Source Institution: UFRGP
Rights Management: Applicable rights reserved.
Classification: lcc - LD1780 2012
System ID: UFE0043932:00001

Permanent Link: http://ufdc.ufl.edu/UFE0043932/00001

Material Information

Title: Meta-Rule Enhanced Interoperation of Rules and Processes for Achieving Dynamic Inter-Organizational Collaboration
Physical Description: 1 online resource (157 p.)
Language: english
Creator: Xiao, Xuelian
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2012

Subjects

Subjects / Keywords: collaboration -- events -- interorganization -- metarules -- processes -- rules
Computer and Information Science and Engineering -- Dissertations, Academic -- UF
Genre: Computer Engineering thesis, Ph.D.
bibliography   ( marcgt )
theses   ( marcgt )
government publication (state, provincial, terriorial, dependent)   ( marcgt )
born-digital   ( sobekcm )
Electronic Thesis or Dissertation

Notes

Abstract: In today's complex and changing world, government and business organizations worldwide often find the need to share their resources and coordinate their activities in order to solve many complex problems and stay competitive. Resource sharing should not be limited to data and computing resources. The sharing and interoperation of organizational policies, constraints, regulations and processes are also very important for achieving inter-organizational collaboration. Organizational resources as well as organizations' partnership can change at any time in a dynamic environment. Thus, inter-organizational processes that carry out inter-organizational collaboration and coordination must be dynamically constructed and processed. This work aims to research on and develop an integrated rule and process specification language, an Event-Triggered Knowledge network (ETKnet 2.0) system, and a meta-rule enhanced, distributed rule processing and process enactment technique to achieve the sharing and interoperation of organizational resources, and the dynamic construction and processing of inter-organizational processes for achieving inter-organizational collaboration and coordination. The integrated specification language is for use by collaborating organizations to independently specify 1) events of common interest, 2) policies, constraints and regulations in terms of different types of business rules (integrity constraints, derivation rules and action-oriented rules), 3) manual/automated operations, and 4) workflow processes. A process is defined in the form of a structure of activities, which invoke different kinds of rules and/or automated/manual operations. An action-oriented rule, when triggered by an event instance, can enact a process, which may contain rules to conditionally enact other processes, making rules and processes interoperable. The specified rules and processes are automatically translated into Java code and then packaged as Web services for their uniform discovery, processing, sharing and interoperation in a Web service infrastructure. The meta-rule enhanced, distributed rule processing and process enactment technique implemented in ETKnet 2.0 enables the dynamic construction of inter-organizational processes in a declarative way, and the processing of inter-organizational processes in a decentralized way. Meta-rules are used to enforce some constraints in the processing of distributed rules and processes defined by collaborating organizations. The introduction of meta-rules also allows collaborating organizations to conduct "what-if" analyses to test or exercise their collaboration in a changing environment. The proposed specification language, the network system, and the rule processing and process enactment technique are applied in two application areas, namely e-government and e-business, to demonstrate their utilities for inter-organizational collaboration and coordination.
General Note: In the series University of Florida Digital Collections.
General Note: Includes vita.
Bibliography: Includes bibliographical references.
Source of Description: Description based on online resource; title from PDF title page.
Source of Description: This bibliographic record is available under the Creative Commons CC0 public domain dedication. The University of Florida Libraries, as creator of this bibliographic record, has waived all rights to it worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law.
Statement of Responsibility: by Xuelian Xiao.
Thesis: Thesis (Ph.D.)--University of Florida, 2012.
Local: Adviser: Su, Stanley Y.

Record Information

Source Institution: UFRGP
Rights Management: Applicable rights reserved.
Classification: lcc - LD1780 2012
System ID: UFE0043932:00001


This item has the following downloads:


Full Text

PAGE 1

1 META RULE ENHANCED INTEROPERATION OF RULES AND PROCESSES FOR ACHIEVING DYNAMIC INTER ORGANIZATIONAL COLLABORATION By XUELIAN XIAO A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULF ILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY UNIVERSITY OF FLORIDA 2012

PAGE 2

2 201 2 Xuelian Xiao

PAGE 3

3 To my family

PAGE 4

4 ACKNOWLEDGMENTS First of all, I would like to thank my advisor, Dr. Stanley Y. W. Su for his constant guidance support and encouragement. I am privileged to have such a distinguished advisor, who is patient, helpful and encouraging. He gave me extensive advice and insight during the course of my research work. He showed infinite patience with me, for which I will be eternally grateful. I would also like to thank Dr. Howard Beck, Dr. Randy Chow, Dr. Shigang Chen, and Dr. Herman Lam for being a part of my PhD committee. I would like to thank my research teammates Jeff DePree Chen Zhou and Seema Degwekar for w orkin g with me in this research project. Also s pecial thank to Jeff DePree for helping me correct gramma tical errors in my dissertation draft I want to express my deepest love to my husband, Ming Zhang, without whose encouragement I would have never completed this important step in my life; also for bringing me our little angel Olivia, who is giving me the most happiness in the world. I am also very grateful for my parents who have been support ing me in all possible ways, and for my sister, who has been takin g care of our parents while I am far away from home. I would also like to thank my mother in law for her support Without my Big thanks also go to all of my friends, who have always cheered me on and make my life in Gainesville so wonderful. Finally, t his R&D work is supported by NSF under grant IIS 0534065.

PAGE 5

5 TABLE OF CONTENTS page ACKNOWLEDGMENTS ................................ ................................ ................................ .. 4 LIST OF TABLES ................................ ................................ ................................ ............ 7 LIST OF FIGURES ................................ ................................ ................................ .......... 8 ABSTRACT ................................ ................................ ................................ ................... 10 CHAPTER 1 INTRODUCTION ................................ ................................ ................................ .... 12 2 RELATED WORKS ................................ ................................ ................................ 22 2.1 Business Rule Language Design ................................ ................................ ...... 22 2.1.1 G eneral Purpose Rule Specification Languages ................................ ..... 22 2.1.2 Our Own Earlier Effort ................................ ................................ ............. 26 2.2 Integration of Business Rules in Business Pro cess Application ........................ 27 2.3 Dynamic Construction and Execution of Inter organizational Processes .......... 31 3 INTEGRATED RULE AND PROCESS SP ECIFICATION LANGUAGE (IRPSL) .... 37 3.1 Operations ................................ ................................ ................................ ........ 38 3.2 Rules ................................ ................................ ................................ ................. 39 3 .2.1 Integrity Constraints ................................ ................................ ................. 3 9 3.2.2 Derivation Rules ................................ ................................ ...................... 40 3.2.3 Action Oriented Rules ................................ ................................ ............. 40 3.3 Processes ................................ ................................ ................................ ......... 41 3.3.1 Structural Constructs Defined in a Process ................................ ............. 41 3.3.2 An Example of a Process ................................ ................................ ........ 44 3.4 Events ................................ ................................ ................................ ............... 44 3.5 Sharable Operations, Rules and Processes as Web Services ......................... 45 3.5.1 Operations as Web Services ................................ ................................ ... 47 3.5.2 Rules as Web Services ................................ ................................ ........... 47 3.5.3 Processes as Web Services ................................ ................................ .... 49 4 ETKNET2.0 S YSTEM A RCHITECTURE AND ITS EVENT TRIGGERED PROCESSING T ECHNIQUE ................................ ................................ .................. 58 4.1 ETKnet2.0 System Architecture ................................ ................................ ........ 58 4.2 Event triggered Rule Processing and Process Enactment Technique .............. 61 4.2.1 Event Instance and Event Data ................................ ............................... 62 4.2.2 Triggers ................................ ................................ ................................ ... 62 4.2.3 Applicability of Rules ................................ ................................ ............... 64

PAGE 6

6 4.2.4 Event Triggered, Distributed Rule Processing and Pro cess Enactment Technique ................................ ................................ ................................ ..... 65 4.3 The Need to Enhance the Rule Processing and Process Enactment Technique ................................ ................................ ................................ ............ 67 5 META RULE ENHANCED DYNAMIC CONSTRUCTION AND PROCESSING OF INTER ORGANIZATIONAL PROCESSES ................................ ....................... 69 5.1 Meta rules ................................ ................................ ................................ ......... 70 5.1.1 Meta rules on Selection Constra ints ................................ ........................ 70 5.1.2 Meta rules on Structure Constraints ................................ ........................ 71 5.1.3 Meta rules on Priority Constraints ................................ ........................... 72 5.2 Application of Meta rules ................................ ................................ .................. 72 5.2.1 Application of Meta rules on Selection Constraints ................................ 73 5. 2.2 Application of Meta rules on Structure Constraints ................................ 73 5.2.3 Application of Priority Meta rules ................................ ............................. 74 5.3 Meta rule Enhanced Rul e Processing and Process Enactment Technique ...... 75 5.3.1 Determining the Applicable Rules and their Processing Order/Structure ................................ ................................ ............................. 75 5 .3.2 Meta rule Enhanced Rule Processing Technique ................................ ... 81 6 C ASE STUDY 1: OPERATING PROCEDURE ................................ ................................ ................... 88 6.1 Events, Rules, Operations, Processes and Meta rules Used to Implement NPDN' s SOP ................................ ................................ ................................ ....... 89 6.1.1 Operations, Rules and Processes ................................ ........................... 92 6.1.2 Ev e nt and Meta rules ................................ ................................ .............. 97 6.2 A Scenario on Dynamic Construction and Processing of Inter organizational Collaboration ................................ ................................ ................................ ....... 97 7 CASE STUDY 2: AN EXAMPLE SCENARIO IN THE E BUSINESS DOMAIN ..... 110 8 CONCLUSION AND FUTURE WORK ................................ ................................ .. 120 APPENDIX A T HE XML SCH EMA OF IRPS, META RULES AND EVENT DATA ...................... 126 B T HE D EFINITION OF ORGANIZATIONS AND ENTITIES USED IN NPDN SOP 145 LIST OF REFERENCE S ................................ ................................ ............................. 150 BIOGRAPHICAL SKETCH ................................ ................................ .......................... 157

PAGE 7

7 LIST OF TABLES Table page 6 1 Meta rules related to the gl ................................ ...... 102

PAGE 8

8 LIST OF FIGURES Figure page 3 1 Examples of manual operation and automated operation ................................ .. 52 3 2 An example of action oriented rule whose action part is to invoke an operation. ................................ ................................ ................................ ........... 52 3 3 An example of action oriented rule whose action part is to invoke a process. .... 53 3 4 An example process named ExampleOnTriageLabReceivingSample ................................ ............. 54 3 5 An example of an event named ................................ ................. 54 3 6 The routine for creating OWSs, RWSs and PWSs. ................................ ............ 55 3 7 General structure of code for an action oriented rule. ................................ ........ 55 3 8 General structure for generated invoker thread class code. ............................... 55 3 9 General structure for a process code ................................ ............................... 56 3 10 The algorithm for generating code for the switched construct. ........................... 57 4 1 The architecture of ETKnet2.0 system, and its local and remote calls among distributed components ................................ ................................ ...................... 68 5 1 Algorithm to determine the applicable rules and construct a processing graph. ................................ ................................ ................................ ................. 84 5 2 rule. ................................ ............... 84 5 3 Algorithm for processing conditional suppression meta rule. ............................. 85 5 4 rule. ................................ ................. 85 5 5 rule. ................................ 86 5 6 rule. ................................ ... 86 5 7 rule. ................................ ..................... 87 6 1 NPDN Triage Lab rules on receiving a new sample (1) ................................ .... 104 6 2 NPDN Triage Lab rules on receiving a new sample (2) ................................ .... 104 6 3 NPDN Triage Lab rules on receiving the confirmed result. ............................... 105

PAGE 9

9 6 4 SPRO rules on being informed of a presumptive positive sample in the system and the confirmed result. ................................ ................................ ...... 105 6 5 SPHD rules on being informed of the confirmed result. ................................ .... 105 6 6 NPDN Regional Hub Lab rules on receiving a presumptive positive sample and being informed of the confirmed result. ................................ ..................... 106 6 7 NPDN Reg ional Director rules. ................................ ................................ ......... 107 6 8 APHIS PPA CDD rules on the receipt of a presumptive positive sample, and the release of the confirmed result ................................ ................................ .. 107 6 9 NIS, EDP and RPM rules on receiving the confirmed result. ............................ 108 6 10 Part of event data transmission, rule processing and process enactment in the NPDN Domain. ................................ ................................ ........................... 108 6 11 The processing graph generated by the Host in the seventh round ................. 109 7 1 fu lfilling an online order with the help of partners. ................................ ............. 117 7 2 ................................ ................................ .................. 118 7 3 The interactions between the retailer and its suppliers to completing an online order. ................................ ................................ ................................ ...... 119

PAGE 10

10 Abstract of Dissertation Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy META RULE ENHANCED INTEROPERATION OF RULES AND PROCESSES FOR ACHIEVING DYNAMIC INTER ORGANIZATIONAL COLLABORATION By Xuelian Xiao May 201 2 Chair: Stanley Y. W. Su Major: Computer Engineering In today's complex and changing world, government and b usiness organizations worldwide often find the need to share their resourc es and coordinate their activities in order to solve many complex problems and stay competitiv e. Resource sharing should not be limited to data and computing resources. The sharing and interoperation of organizational policies, constraints, regulations and processes are also very important for achieving inter organizational collaboration. Organizat ional resources as well as organizations' partnership can change at any time in a dynamic environment. Thus, inter organizational processes that carry out inter organizational collaboration and coordination must be dynamically constructed and processed. Th is work aims to research on and develop an integrated rule and process specification language, a n Event Triggered Knowledge network (ETKnet 2.0) system, and a meta rule enhanced, distributed rule processing and process enactment technique to achieve the sh aring and interoperation of organizational resources, and the dynamic construction and processing of inter organizational processes for achieving inter organizational collaboration and coordination. The integrated specification

PAGE 11

11 language is for use by colla borating organizations to independently specify 1) events of common interest, 2) policies, constraints and regulations in terms of different types of business rules (integrity constraints, derivation rules and action oriented rules), 3) manual/automated op erations, and 4) workflow processes. A process is defined in the form of a structure of activities, which invoke different kinds of rules and/or automated/manual operations. An action oriented rule, when triggered by an event instance, can enact a process, which may contain rules to conditionally enact other processes, making rules and processes interoperable. The specified rules and processes are automatically translated into Java code and then packaged as Web services for their uniform discovery, processi ng, sharing and interoperation in a Web service infrastructure. The meta rule enhanced, distributed rule processing and process enactment technique implemented in ETKnet 2.0 enables the dynamic construction of inter organizational processes in a declarativ e way, and the processing of inter organizational processes in a decentralized way. Meta rules are used to enforce some constraints in the processing of distributed rules and processes defined by collaborating organizations. The introduction of meta rules also allows collaborating organizations to environment. The proposed specification language, the network system, and the rule processing and process enactment technique are ap plied in two application areas, namely e government and e business to demonstrate their utilities for inter organizational collaboration and coordination.

PAGE 12

12 CHAPTER 1 INTRODUCTION Government organizations worldwide are facing many complex problems such as disease detection and control, border control, immigration, disaster assistance and recovery, and terrorism. The solutions to these and other problems require these organizations to collaborate, share their resources, and coordinate their activities rapid ly and effectively. In the business area, t he rapid globalization also requires business organizations to share their resources and collaborate with one another in a timely manner in order for them to stay competitive and to be successful. In a collaborati ve environment, resource sharing should not be limited to data and computing resource s The sharing and interoperation of organizational policies, constraints, regulations and processes are also very important for achieving inter organizational collaborati on Hence, there is a need for a high level specification facility for collaborating organizations to specify their sharable data, application operations, business rules and processes, and a way to make these resources sharable and interoperable to support seamless collaboration and coordination among organizations Organizational p olicies, constraints and regulations have been specified in terms of different types of rules ( Business Rules Group, 2000; Rouvellou et al., 2000; Sowa, 2000) : integrity constra ints ( Ullman, 1982) derivation rules ( Ullman, 1988) and action oriented rules ( Widom and Ceri, 1996) Business rules model organizational knowledge in a declarative way. Their specifications are easier for non technical users to understand than the progr amming code that implement them. Organizational behaviors that can be expressed in terms of m anual operation s automated operation s and process es are defined using a workflow specification language such as the Workflow

PAGE 13

13 Process Definition Language (WPDL) ( W fMC,1998) or a business process modeling language such as the Business Process Modeling Notation (BPMN) ( OMG, 2009 b ) or the Web Service Business Process Execution Language (WSBPEL) (OASIS 2007) D ata, rules and business processes are usually managed by different types of software systems such as a database management syst em (e.g. MySQL), a rule management JBoss Enterprise BRMS ), and a workflow management system (e.g. One problem with this traditional method of data, rules and processes management is that it is costly to develop/purchase and maintain different kinds of software systems. What is more, it is difficult to make these systems, as well as the data, operations, rules and processes that they manage, interoperable. By interoperability, we mean that the availability of some data may require some knowledge rules to be activated automatically. The processing of these rul es may infer more data or enact some business processes, which perform some manual or automated operations. The rule activation and process enactment would produce new data, which may require additional rules and processes to be activated. This type of int eroperation can continue until all relevant operations, rules and processes have been performed. Business rules can be used in business process modeling as shown in (Bae et al., 2004; Charfi and Mezini 2004; Eijndhoven van Lacob, and Ponisio 2008 ; Kapp el, Rausch Schott, and Retschitzegger, 2000; Knolmayer, Endl, and Pfahrer, 2000; Meng et al., 2006). It has been recognized that combining business process modeling and business rule specification is beneficial (Herbst et al., 1994 and

PAGE 14

14 2010; Recker et al., 2005). However, these works either model business processes entirely by using business rules ( Kappel, Rausch Schott and Retschitzegger 2000; Knolmayer, Endl and Pfahrer, 2000 ), or use business rules ( especially ECA rule) to handle exceptions (Bae et al., 2004), or achieve process adaptability at various points of process execution (Charfi and Mezini 2004; Eijndhoven van Lacob, and Ponisio 2008 ; Meng et al. 2006; Rosenberg and Dustdar 2005). In the se works, business rules and business processes are defined by different definition languages or handled by different execution engines. They are not fully integrated and specified in a single specification language. Recent efforts reported in (Graml, Brac ht and Spies 2008; Milanovic and 2009 ) have started to investigate the integration of process oriented business process modeling with rule oriented business process modeling. Milanovic and (2009) point out process oriented business process modeling and business rule specification is one of the most They propose a hybrid language named rBPMN by integrating the existing process modeling language BPMN with the existing rule spe cification language REWERSE I1 Rule Markup Language (R2ML) (Rewerse Working Group I1, 2006). In rBPMN, a business rule is used to represent a small chunk of business logic and a business process is modeled by the process modeling language BPMN. Business ru les are in corporated in the BPMN s element named Gateway, and are executed presumably by invoking an existing rule execution engine. However, no implementation of such an engine was mentioned in their publications In our work, we aim to use business rule s to model entire business logics, regulations and processes. A process can be specified by a structure of different types of rules and

PAGE 15

15 manual/automated operation s by using structural constructs, and is enacted by an action oriented rule. Rules and processe s are all automatically translated into Java code and wrapped and executed as Web Services. Our work provides a new way to fully integrate the rule specification and the process modeling. We argue that it is beneficial to come up with more ways to fully in tegrate the two. Another important issue that needs to be addressed is the dynamic nature of government/business organizations and their collaborative relationship data, policies, constraints, regulations, services and processes can change at any time. Process changes become necessary when for example, new policies come into effect business goals need to be modified and temporary partnerships need to be created This means that the rules and processes which capture organizations resourc es knowledge and collaborative activities, will need to allow for modifi cations and/or additions to occur at any time Traditionally, an inter organizational process is pre defined at build time, and processed by a workflow management system or a business process management system at runtime O nce defined, it is difficult to make change s to accommodate the changing demands The need for flexible process modeling and execution has long been recognized by the workflow and business process communities. Meetin g this need will enable organizations to adapt to changing environments and partnerships as pointed out in (Heinl et al., 1999). Systems developed in the business process management domain have widely adopted the workflow technology. A business process mo del specifies precisely how a given set of activities should be performed (i.e. the order of processing these activities is explicitly defined). T h is modeling approach makes a business process definition very

PAGE 16

16 rigid, and hence difficult to capture and adapt to the changing demands of business and business organizations (Nurcan, 2008) Several past efforts have attempted to overcome this limitation ( Eijndhoven van, Lacob and Ponisio 2008 ; Meng et al. 2006 ; Mller, Greiner and Rahm, 2004) T here are also eff orts to find alternative ways from different perspectives to model and enact inter organizational processes that achieve inter organizational collaboration ( Alexopoulou et al. 2008; Asunction Lacob and van Sinderen 2010 ; Blake and Gomaa, 2005 ; Buhler an d V idal 2004; Grefen, 2009a; Orriens and Yang 2006 ) To some degree, these existing approaches still require that a global specification of inter organization al collaborati ve activities be defined in advance. The global specification can be a complete in ter organizational process but augmented with flexible elements like business rules, to make the process adaptive. T he global specification can also be an abstract one for example defining by an e contract ( Kutvonen, Metso and Ruokolainen, 2005) which define s the agreement and/or behavior of collaborating organizations and is later decomposed into the local processes defined by the involved collaborating organizations However, i n a dynamic environment, organization s can join or leave a collaboration fe deration freely. The participating organization s may be anonymous to one another and may not have the global knowledge about the ir collaboration It is difficult to design a global specification in advance in such an environment. To address the above chall enges, we have developed in this work an integrated rule and process specification language for collaborating organizations to specify their organizational policies, constraints, regulations and processes. We also developed a meta rule enhanced, distribute d rule processing and process enactment technique to

PAGE 17

17 enable the interoperation of organizational data, rules and processes, and the dynamic construction and processing of inter organizational processes without having to defin e a global specification in adv ance We first introduc e an XML based I ntegrated Rule and Process S pecification L anguage (IRPSL) (Chapter 3) for specifying business rules and processes The language provides a declarative way to specify human and organizational knowledge and collaborati ve processes. Distinct from the traditional process specification language, a process in our language can be defined as a structure of activities that can activate three types of business rules (integrity constraint rules, derivation rules and action orien ted rules), manual operations and automated operations. An action oriented rules to further enact other processes, which make rules and processes interoperable. The rul es and processes specified in our language are first automatically translated into Java code and then packaged and exposed as Web services for their uniform discovery, processing, sharing and interoperation among collaborating organizations in a Web servic e infrastructure. Our work provides a new way to combine business rule specification and business process modeling by extending process modeling to include rule specifications and by extending rule specifications to enact processes. The advantages of our approach are as follows. First, rules and processes are defined in an integrated specification language. It is not necessary for organizations to treat rules and processes as separated entities and define them by using two different specification languages Second, the defined rules and processes can be uniformly processed as Web services to enable their interoperability. They do not have to be processed

PAGE 18

18 separately by a rule processing engine and a workflow/business process processing system. In this work we also have implemented a distributed Event Triggered Knowledge network 2.0 (ETKnet2.0) system ( C hapter 4) based on the meta rule enhanced, distributed rule processing and process enactment technique mentioned before. In addit i on to the facilities for collaborating organizations to define rules, processes and manual or automated operations, the system also provides the facility for these organizations to define different types of events. Here an event is anything of common interest to these organization s, such as the outbreak of a disease, the placement of an order, the announcement of a new product or service, a change in the internal state of a database, or a real world incident or a slip in a production schedule. Sharable events, rules and processes are registered at the Host site of ETKnet2.0. Hence they are searchable and accessible by all end users of collaborating organizations. We further allow organizations to subscribe to events, and define triggers to link events to rules. When an event occurs (i.e. an event instance), data relevant to that event instance (i.e. the event data) is transferred to all the subscribers through an event notification mechanism. Additionally, the event data is automatically sent to the network sites of organizations th at contain rules, which can make use of the event data (or part of it) as their input data ( Chapter 4). We call these rules "applicable rules" (i.e., applicable to the event instance ). The processing of these rules may enact organizational processes defin ed by collaborating organizations. These processes may contain different types of rules and operations. The data produced by these rules and operations may in turn activate other distributed rules and processes. The above interoperations will continue

PAGE 19

19 unti l all rules, operations and processes that are relevant to an event instance have been performed. We also introduce meta rules to enforce some constraints in processing distributed rules and processes upon an event occurrence. They can be used to specify t he constraints on the selection and execution of applicable rules (Chapter 5). For example, a meta and rule C is not selected, r use meta rules to achieve the desired collaboration without precisely predefin in g global inter organizational processes. We call the above distributed processing technique the "meta rule enhanced event triggered, distributed rule processing and process enactment technique". The adaptation to changing execution contexts is achieved by 1) using flexible constructs in the specification language such as conditional branches in the activi ty structure of a process ; 2) allowing organizations to define meta rules to specify the desired collaboration without precisely predefining inter organizational processes; 3 ) allowing organizations to add/ change their business rules processes and meta ru les at build time as well as runtime ; 4 ) dynamically constructing and processing inter organizational processes to achieve resource sharing and collaboration among organizations. Collaborating organizations can also use meta anal yses to test or verify their assumptions of their collaborative relationship. We have evaluated our research results in two application domains. The first application of our developed technology is in the e government domain. We use IRPSL and the ETKnet2.0 Chain of Custody and Chain of Communication Standard Operating Procedure (NPDN

PAGE 20

20 SOP) ( National Plant Diagnostic Network 2008 Diagnostic Network. We test and evaluate our system by creating application scenarios to exercise the Standard Operating Procedure and by conducting a field test with the participation of the NPDN staff. The second application is in the e business domain. We use a scenario abstracted fr om the real e business world to demonstrate the general application of the developed technology and thus its boarder impact. The significance and contributions of this research can be summarized as : It provides a new way to integrate business rule specific ation and business process modeling. Our integrated rule and process specification language allows the business rules, processes and operations of collaborating organizations to be defined in an integrated manner and thus facilitates their interoperability Their high level specifications are easier for the users of these organizations to understand, modify and use than the program code that implement them. The automatic translation of three different types of rules and p rocess es into Web services allows t hem to be discovered, shared and processed uniformly in a Web service infrastructure just like other Web services. Organizations do not have to write programming code to implement them. The event triggered, distributed rule processing and process enactment technique allows for the inter operation of sharable data, different types of rules, processes and operations, without having to use multiple rule engines and business process execution systems. The use of meta rules to enforce constraints in the process ing of distributed rules and processes provides an alternative way of dynamically constructing an inter organizational process at runtime. Meta rules are also useful for organizations to perform "what if" analyses to exercise or test their collaboration in a changing environment. S ince new rules processes and meta rules can be introduced and existing rules processes and meta rules can be modified at any time, the implemented system is very flexible and can easily adapt to changes in business and collabor ative agreement between organizations. It is also a very general system and can be applied in different application domains such as the e government and e business domains as shown in this dissertation as well as the e learning domain presented in (DePree, Su and Xiao, 2009; DePree, Xiao and Su, 2010). Also, the system is highly scalable since the software components of the system can be easily replicated at different network sites with the growth of the number of member organizations.

PAGE 21

21 The rest of this PhD dissertation is organized as follows. Chapter 2 surveys some related works and points out the main differences between them and our work. Chapter 3 details the specification language IRPSL with examples, and shows how rules and processes can be automatical ly translated into Java code, and packaged and exposed as Web services. Chapter 4 presents the architecture of our distributed network system, and how inter operation of sharable knowledge can be achieved by its event triggered, distributed rule processing and process enactment technique. Chapter 5 explains the use of meta rules to enhance the rule processing and process enactment technique to achieve the dynamic construction and processing of inter organizational processes. Chapter 6 covers the implementat ion of NPDN SOP using our integrated specification language and our meta rule enhanced distributed rule processing and process enactment technique, and the results of a field test of the developed system carried out by the NPDN staff. Chapter 7 covers ano ther application of the developed technology in the e business domain that uses our language and system to achieve inter organizational collaboration. The C hapter 8 summarizes our research problems, our approaches to solve these problems and our main rese arch contributions. Some issues for future research are also presented in this chapter.

PAGE 22

22 CHAPTER 2 RELATED WORKS We survey some research works in three areas that are related to our work: business rule language design, the integrati on of business rule s in business process application, and the dynamic construction and execution of inter organizational business processes. 2.1 Business Rule Language Design A b usiness rule is a statement that defines or constrains some aspect of the business. It is intended t o assert business structure or to control or influence the behavior of the business Business Rules Group 2000) Business rules describe business logic, policies, regulations and processes that apply to business organizations. A business rule language is a formal specification that is designed to formalize the understand. Several industry standards have been established for business rule language specifications. Some r esearch works have also proposed their own rule languages. We briefly describe them below 2.1. 1 General Purpose Rule Specification Languages Simple Rule Markup Language(SRML) SRML ( Cover, 2001) proposed by ILOG, S.A. in 2001, aims to address the proble m of sharing rules among applications that use different java rule engines. It was realized that Java rule engines on the market at that time had their own set of Java APIs, and their own proprietary rule languages. SRML is provided as an interlingua for r ule exchange between these rule engines It describes a generic rule language consisting of a subset of language constructs

PAGE 23

23 common to the popular forward chaining rule engines. Rules in this language have a condition part and an action part. The action in the action part can include variable declarations and assignments, as well as the traditional assert ion retract ion and modif ication statements of rule languages However, the action part of our language can express much more complex structures Other type s of rules supported in our work are not specifiable in this language. Rule Markup Language (RuleML) RuleML ( Rule Markup Language Initiative 2010) was launched in 2000 by the Rule Markup Language Initiative, formed by an open network of individuals and groups from both industry and academia, and is still evolving I ts main goal is to provide a basis for an integrated rule markup approach T his is achieved having all participants collaborate in establishing translations between existing tag sets and in converging on a shared rule markup vocabulary It aim s to cover the entire rule spectrum, from derivation rules to transformation rules to reaction rules. Transformation rules could be conversely reduced to derivation rules over special relations that have an extra argument for transformation values. Based on its latest version (v1.0), its current design has well defined derivation rules, but reaction rules are only briefly mentioned and their definitions and syntaxes are not provided. O ur specificatio n language adopts some syntactic constructs from its d erivation rule s specification. Extensible Rule Markup Language (XRML ) XRML (Lee and Sohn, 2003) is designed for knowledge sharing between human and software agents. It is an extension of XML with add itional capabilities for representation of rules. Therefore, it can represent and process rules that are implicitly embedded in a web page. It has three

PAGE 24

24 components: the Rule Identification Markup Language (RIML) which can be used to specify rules in a web page, the Rule Structure Markup Language (RSML) which converts rules embedded in the web into a formal structure usable by an expert system, and the Rule Triggering Markup Language (RTML), which defines the conditions under which those rules will be trigge red. This language only supports deductive rules. Semantic Web Rule Language (SWRL ) SWRL (Horrocks et al., 2003) aims to extend the set of the Web Ontology Language (OWL ) ( McGuinness and Van Harmelan, 2004) axioms to include Horn like (deductive) rules. R ules in SWRL are expressed in terms of OWL constructs like individuals, properties, literals and classes. Rules are in the form of an implication between an anteced ent and a consequent. The antecedent is the rule body, and the consequent is the rule head. It means that when the conditions specified in the rule body are true, the conditions specified in the rule head must also be true. While SWRL is not a standard, it is a widely used language supported by several commonly used reasoners, like Pellet (Sirin et al., 2007). Rule Language in OWL (ROWL) ROWL (Gandon, Sheshagiri and Sadeh 2004) is developed by the mobile commerce lab at Carnegie Mellon University for representing user preferences (including complex privacy/confidentiality preferences) in the con text of their pervasive computing work. It allows for the specification of deductive rules (in the form of Horn clauses) using an ontology in OWL and provides the facility for translating these rules into Java Expert System Shell (JESS) rules. Semantics of Business Vocabulary and Rules (SBVR) SBVR ( OMG, 2008 ) is an adopted standard of the Object Management Group ( O MG) intended to be the basis for a formal and detailed natural language declarative description of a complex entity,

PAGE 25

25 such as a business. SBVR co ntains a vocabulary for conceptual modeling and captures expressions specified in this vocabulary as formal logic structures. The SBVR vocabulary allows one to formally specify representations of concepts, definitions, instances, and rules of any knowledg e domain in a natural language. These features make SBVR well suited for describing business domains and requirements for information systems to implement business models. schema includes the syntax es of constraints and d e rivation rules. Production Rule Representation (PRR) PRR (OMG, 2009a) was defined by vendors of business rules engines such as ILOG, Fair Isaac, LibRT, IBM, Pega, Corticon, TIBCO, academic community (RuleML.org), and UML tool vendors. The current version is now adopted as an OMG st andard, and a formal model for production rules. A production rule is a statement of programming logic that specifies the execution of one or more actions in the case that some data conditions are satisfied. It is typically if [condition] t hen [action list] Some implementations extend this if [condition] then [action list] else [alternative action list] The latter production rule can be represented by two condition action rules in ou r language: one with the condition being true and the other with the condition being false. What is more, t he action clause in our action oriented rule can activate a process with a much more complex structure than is possible with PRR. REWERSE I1 Rule Mar kup Language (R2ML) R2ML (Rewerse Working Group I1, 2006) was originally developed by the REWERSE Working Group I1 to support rule interchanges between different systems and tools. It is also a comprehensive rule modeling language, which integrates the Ob ject Constraint Language (OCL), SWRL,

PAGE 26

26 and RuleML. Its latest version can support four kinds of rules: derivation rules, production rules, integrity rules and Event Condition Action (ECA) rules. Its specification includes metamodel, an XML based textual con crete syntax, and a graphical concrete syntax. A complete reference for R2ML can be found in (Rewerse Working Group I1, 2006). The above general purpose rule languages support only one or at most two types of rules that are supported by our rule language or have limited support for structuring a set of rule s ( Bry et al. 2006 ) such as R2ML In practice, structuring a set of rules and treating it as a reusable modul e is very important for reducing the complexity of a business process specification and the t ediousness of rewriting the same rules in different business process specification s Compared with the above mentioned rule languages, our language provides good support for not only different types of rules, but also the specification of processes, which are structures of different types of rules and/or operations and can be enacted using action oriented rules. Thus, individual rules as well as structures of rules and operations modeled as processes can be made reusable. 2.1. 2 Our Own Earlier Effort The r ule specification language reported in (Degwekar, 2007) is our earlier effort on rule language design. It can be used to specify three types of rules: constraint rules, logic derivation rules and action oriented rules. The language also supports the specif ication of a "rule structure" by using four structural constructs: link split and join and or join The action clause of an action oriented rule can only be a primitive operation. In our language IRPSL, we adopt and support the specifications of the sam e types of rules. However, separate from our earlier work, an action oriented rule can

PAGE 27

27 enact either a primitive operation or a workflow process. A workflow process can be specified as a complex structure of activities that invoke different types of rules, and/or manual and/or automated operations. Thus, the rule structure of our earlier work is a special case of our workflow process. The structural constructs allowed in our process definition are: Sequential Switched Unordered Selective Repeated AND/OR /XOR Split AND/OR Join Furthermore, different from our earlier work, which aims to enhance knowledge sharing among organizations, our current work aims to achieve, not only knowledge sharing, but also dynamic and flexible inter organizational process mod eling and execution. 2.2 Integrati on of Business Rules in Business Process Application The works on using business rules in business process application can be categorized based on the two approaches used. One approach is to model business processes using only business rules. This approach is taken in ( Bry et al., 2006 ; Kappel, Rausch Schott and Retschitzegger 2000; Knolmayer, Endl and Pfahrer 2000; Zeng et al. 2002) These works consider only one type of rule (i.e., the action oriented rule). For example ( Knolmayer, Endl and Pfahrer, 2000) demonstrates how workflow patterns, including sequence, parallel, alternative and iteration, can be modeled by Event Condition Action Alternative action (ECAA) rule s Taking the sequential order as an example, it can b e specified by an ECA A On (the termination of the predecessor) If (condition) Then (execute the successor) Else (do nothing) these works, business process enactment is achieved by using reasoning algorithms. However, the ex ecuti on of a business process by using reasoning algorithms might lead to some unexpected behavior hard to determine upfront Milanovic and 2009) and the entire process specification in terms of rules will be rather long and

PAGE 28

28 difficult to read b ecause each rule only captures a small chunk of business logic and there are many rules needed to model a process. Di stinct from this approach, our work extends a rule language to incorporat e process enactment in a n action oriented rule, and a process is d efined by a structure of rules of different types and/or manual/automated operations/services. Business process enactment is achieved by a distributed rule processing and process enactment technique (Chapter 4) instead of using reasoning algorithms. The o ther approach to using business rules in business process application s is to incorporate business rules in business process modeling and enactment. Bae et al. (2004) incorporate ECA rules in a process model to deal with the exceptions thrown during a workf low enactment. Muller, Greiner and Rahm (2004) use ECA rules to specify exceptions and support workflow adaptation. Meng et al. (2006) incorporates ECA rules in process modeling by introducing the Before Activity Event After Activity Event and External E vent in the workflow modeling language WPDL. These events can trigger the processing of business rules during the enactment of a workflow process to enforce business constraints and policies, and hence dynamically change the execution behavior of an inter organizational business process. Works in ( Charfi and Mezini 2004 ) and ( Rosenberg and Dustdar 2005 ) incorporate different types of rules in a BPEL process. However, in ( Charfi and Mezini 2004 ), rules are represented as an aspect and are hard coded in th e process using aspect oriented programming ( AOP ) Rosenberg and Dustdar ( 2005 ) proposes to incorporate rules by introducing before / after intercepto r in a BPEL process specification Business rules associated with the before interceptor are executed before the actual BPEL activit y and those associated with the after

PAGE 29

29 interceptor are executed after the BPEL activit y. These two works only provide an execution infrastructure rather than a formal specification language Eijndhoven van Lacob. and Ponisio ( 2008 ) propose a method to implement the variable parts (called variation points) of a process flow by using so called workflow patterns discussed in ( Russell et al. 2006 ) and then by represent ing these patterns using business rules in order to make the busine ss process flexible. The business rules used in the examples given in the paper are ECA rules; no other kinds of rules are discussed. Furthermore, the work presents a method on how to implement business processes, rather than a specification language that incorporates three types of rules in process modeling as proposed in our work. Graml, Bracht and Spies (2008) point out that it is beneficial to incorporate business rules in business process modeling. It uses examples to demonstrate how to express three g roup patterns (control flow decisions, data constraints and process composition) by using three kinds of business rules (derivation, constraint and ECA rules). However, the work does not provide a formal specification language to couple business rules and business processes. Such a language is said to be its future work. The work presented in ( Milanovic and 2009 ) is very relevant to our s but using totally different methods It proposes a Rule Based BPMN (rBPMN) language. To the best of our knowled ge, rBPMN is the only language beside ours that is designed to support the integration of rule specification and process modeling. rBPMN combines the specification facilities of two existing languages: BPMN (OMG, 2009b) and R2ML (Rewerse Working Group I1, 2006). It Gateway which is used for control flow by defining a new element named RuleGateway to refer to R2ML

PAGE 30

30 rules. In this way, an R2ML rule can be placed into a process model to model a small chunk of business logic rBPMN i s designed to support a rule enhanced process orchestration and choreography modeling as presented in ( M 2009; M and independently. rBPMN integrates rule spec ification and process modeling by incorporate rules, while our language achieves the integration by extending an action and by including rules in a process model (i.e., r ules are integral parts of a process structure rather than things appended to a process structure). Although our language does not support ECA rule directly as in R2ML its function can be achieved by using our Trigger element, which can link an event to a n action oriented rule (Chapter 4). The inter organizational process is explicitly modeled in the language rBPMN, whereas it can be achieved through our event triggered rule processing and process enactment technique (Chapter 4). Also, the execution of rul es in rBPMN is presumably achieved by making Web service calls to some existing rule engine. There is no evidence that an engine has been implemented to process the language rBPMN In our case, we have implemented a rule server, which can be replicated and installed at the network sites of collaborating organizations for processing different types of rules and business processes in a distributed manner. Our work distinguishes itself from the approaches discussed above by using three kinds of rules to speci fy organization al policies : regulations, cons traints, and workflow processes; not just to handle exceptions, but to specify control flow such as synchronizations or asynchronizations, and model small chunks of business logic What

PAGE 31

31 is more, our work formall y defines an integrated specification language, which enables a complex business process to be defined as a structure that contains different types of business rules and manual/automated operations interconnected by a variety of structural constructs. The defined processes as well as the rules specified in them are automatically translated into Java code and exposed as Web services for their reuse and interoperation. 2.3 Dynamic Construction and Execution of Inter organizational Process es Systems in the bu siness process management domain have widely adopted the workflow technology. Workflow Management Systems (WFMS) have been positioned as appropriate technological solutions for integrating process islands at a high level [Reijers, 2006]. There are also eff orts to develop alternative techniques to coordinate activities across organizational boundaries using techniques that are event driven (Alexopoulou et al., 2008), rule based (Meng et al., 2006 ; Orriens and Yang 2006 ) agent based (Blake and Gomaa, 2005 ; Buhler and Vidal, 2004; Jiang Dignum and Tan, 2011 ; Taveter and Wagner, 2001 ) contract driven (Grefen et al. 2000 ; Kutvonen, Metso and Ruokolainen, 2005), and service oriented (Asunction, Lacob and van Sinderen 2010; Grefen et al. 2000 ; Grefen et al., 2009a, 2009b, Kapuruge, Han. and Colman, 2010). Some works apply multiple techniques. In this section, we give an overview of the existing works on dynamic/flexible inter organizational process modeling and execution that are related to our work, and point out their differences and similarities with ours. An early effort on cross organizational workflows was undertaken in the Workflow based Internet SErvice (WISE) project ( Alonso et al., 1999; Lazcano et al., 2001). WISE provides an Internet based software infrastructure for supporting business to business

PAGE 32

32 electronic commerce within a so called trading community Companies in a trading community can post their services in a catalogue so that other companies can search and find them. However, in WISE, cross organizational business processes that describe the cooperation between organizations are specified at process definition time. They are manually defined by process designers who explicitly incorporate other ses. CrossFlow ( Grefen et al. 2000 ) goes a step further toward cross organizational collaboration. It aims to develop and implement a mechanism for connecting Workflow Management Systems (WfMS) used in different organizations. The organizational collabor ation is based on a dynamic service consumer/provider paradigm. An organization (the service consumer) outsources a pre defined part of its business process to an organization that can perform this service (the service provider). The interaction between a service consumer and a service provider is based on an electronic contract, in which relevant details of service offerings are specified. Service offerings and service requests are later matched according to their well defined interfaces through a matchmak ing facility presented in ( Klingemann, Wsch and Abere, 1999 ). In CrossFlow, cross organizational process enactment is performed by linking the workflow management infrastructures of the involved organizations. In our work, the activities and services are specified by different kinds of rules and processes. These rules and processes are converted into and exposed as Web services, which can be searched and processed uniformly in the Web service infrastructure. The cross organizat ional process can either be explicitly defined in our language at build time, or dynamically constructed at runtime.

PAGE 33

33 DynaFlow presented in (Meng et al., 200 6 ) uses the concepts of event, rule and triggers to achieve flexible and adaptive workflow processin g. This work extends the definition of activities in WPDL to include Before Activity Event, After Activity Event and External Event, and to also define triggers that link events with rules. During the execution of a workflow process, these events are poste d to trigger some action oriented rules, which perform operations to adapt the workflow instance to suite the changing business environment, report the processing milestones of an enacted business process, and/or handle an exception condition. In DynaFlow, inter organizational processes are pre defined. The system uses only action oriented rules in action alternative our work. The action clause of a rule can only perform a single ope ration, whereas it can enact a process in our work. Besides user defined triggers that explicitly link events with rules, our system can automatically create triggers if the data associated with events can provide the input data for rules. Furthermore, the dynamic and adaptive inter organizational processes can be constructed and enacted at runtime in our work. Alexopoulou et al. (2008) propose an event based approach to compose a business process at runtime. The main idea of th is approach is to use event c hains to compose business processes An event may either initiate an action, or cause another event, or both. Every Event A ction (EA) pair constitutes an autonomous relationship, and is pre defined at build time The event in an EA pair can be an actual si ngle event or a conceptual single event. The latter is a complex event (David, 2002) which is defined by an expression containing a number of events and logical operators such as AND, OR and XOR. A business process is then the event action sequences that a re

PAGE 34

34 involved at runtime. A conceptual architecture for an event based IT infrastructure is proposed in the paper, but no implementation is discussed T he cross organizational issue is not specifically addressed in this paper. In our work, an event instance can trigger different kinds of rules, and processes enacted by action oriented rules. An inter organizational business process is either explicitly defined in our language, or dynamically constructed through multiple rounds of rule processing and process e nactment that are triggered by an event instance. Based on the agent oriented and service oriented technologies developed on top of an Internet infrastructure, CrossWork (Grefen et al., 2009a, 2009b) presents a system for collaborating organizations to cr eate and operate an Instance Virtual Enterprise (IVE). Like CrossFlow, it aims to connect the workflow management systems and/or the business management systems of different organizations. An inter organizational process is defined at build time in the fol lowing way. A pre defined high level goal is first decomposed into a set of operational business goals with the help of a domain expert, and the partners that can fulfill these goals are selected in the market by the system with the assistance of a market expert. Later, the system retrieves the semi automatically composes a structured global business process based on these local business processes by using the algorithm pr esented in (Eshuis and Grefen, 2009). The algorithm first automatically constructs an abstract dependency graph by using the input/output dependencies among these local services/processes, and then a concrete dependency graph is generated with the help of the domain expert by specifying the branch type such as split or join. A structured global business process is

PAGE 35

35 then generated based on the concrete dependency graph Therefore, the global business process is explicitly specified at build time All the sele cted partners execute their respective local business processes according to this global business process. Although our work also makes use of input/output dependencies to determine the rule/process dependencies, an inter organizational process is construc ted dynamically at runtime. What is more, the branch types, which are specified manually in this related work, are automatically generated at runtime by using meta rules introduced in our work. Our system provides a mechanism to dynamically construct a glo bal/inter organizational business process at runtime without having to define a dependency graph at build time. Aiming to increase the flexibility of enterprise application integration, Asunction, Lacob and van Sinderen (2010) integrate enterprise applic ations based on a goal based, model driven and service oriented framework presented in (Iacob and Jonkers, 2008). In particular, the organization requirements are first specified as goal models (Lamsweerde, 200 8 ) at a high level. Those parts that are more likely to change over time are separated from a process, and are specified in terms of business rules. A rule engine exposes its functions as Web services. These business rules are then execut ed by making Web service calls to the rule engine and hence are incorporated into the definition of the business process as services In our work, processes are enacted through action oriented rules, and rules are automatically converted into Java code and packaged as Web services. At run time, these Web services are executed without the use of a rule engine.

PAGE 36

36 To summarize the main differences between our work and the works surveyed in this chapter (i.e., our main contributions), our work introduces a new integrated specification language, which can be used to define an organizational business process or an inter organizational process by a structure having a mixture of different kinds of business rules and manual/automated operations connected by a variety of structural constructs. Action oriented rules specified in a p rocess can in turn activate other processes. Business rules and processes defined by different organizations are automatically converted into Java code and exposed and executed uniformly as Web services in a Web service infrastructure without having to use different types of rule engines and a workflow management or business process execution system. Organizations can add and change their business rules and processes at any time. Inter organizational processes can either be predefined or constructed at run time using an even triggered, distributed rule processing and process enactment technique introduced in this work. This processing technique is further enhanced by the use of meta rules to enforce constraints on the selection and execution of distributed, applicable rules that are triggered by an event instance. The distributed network system that implements this enhanced processing technique enables government/business organizations to share not only data and application operations but also business rules and business processes. The enhanced processing technique also enables the flexible and dynamic construction and execution of inter organizational processes needed to achieve inter organizational collaboration and coordination.

PAGE 37

37 CHAPTER 3 INTEGRATED RULE AND PROCESS SPECIFIC ATION LANGUAGE (IRPS L) In this chapter, we present the language IRPSL with examples, and show how operations, rules and processes can be automatically translated into code, and packaged and exposed as Web services. This piece of work ha s been published in (Xiao et al., 2008; Xiao, DePree and Su, 2011). A business rule is a declarative statement that specifies business logic, constraints, policies or regulations that an organization must apply or enforce in order to achieve its business o bjectives. There are three popular types of business rules that are commonly used in current rule based systems (Business Rules Group, 2000; Rouvellou et al., 2000; Taveter and Wagner, 2001): integrity constraints, derivation rules, and action oriented rul es. Integrity constraint rules (Ullman, 1982), originally used in database systems, specify the condition(s) to which some data must adhere as required by an application. Derivation rules, commonly used in expert systems for decision support (Ullman, 1988) are also known as inference rules or deductive rules. They define how new knowledge can be inferred from the current knowledge (Business Rules Group, 2000). Action oriented rules define the actions that an organization must perform under certain conditio ns. They are commonly used in an event condition action (ECA) system. Business rules model organizational knowledge and behaviors in a declarative way. A business process consists of a structure of activities that should be carried out in a specific order we extend the traditional workflow process specification by including not only manual operations and automated operations, but also three types of business rules. We also

PAGE 38

38 take advantag e of the existing Web Service Business Process Execution Language (WS BPEL) (OASIS, 2007) and the Workflow Process Definition Language (WPDL) (WfMC, 1998) by combining the control patterns(or structural constructs) offered by these two languages and adopti ng them in our language for specifying the business processes of collaborating organizations. We extend the action clause of an action oriented rule to allow the invocation of either a primitive operation or a process. The latter can contain different typ es of rules and/or operations. In this way, we achieve the integration of business rule modeling and business process modeling. Furthermore, operations, processes and different kinds of rules can interoperate. For example, an action oriented rule may enact a process, which may invoke other rules and operations to produce new data that can serve as the input to some other rules or operations. 3.1 Operations Operations can be manual operations or automated operations. A manual operation is a task that has to be done off system. Each manual operation should be assigned to a certain role(s) and/or a specific person. The system that we developed will send a notification with instructions via email to all the people who play the role(s) or to a specific person. In the former case, one of them can choose to perform the operation. After performing the operation, the performer needs to log into the system to report its completion and provide the data resulting from the operation. The specification of a manual operatio n includes input data items, output data items (if any), operation instructions that will be sent to the performer(s). An automated operation is executed automatically by the system. It can be either a Web service call, a call to a local

PAGE 39

39 program, a rule ac tivation, or a posting of an event to indicate its occurrence. Its metadata includes input data items and output data items (if any). Examples of a manual operation TriageLab_Inform_Campus_Safety_Office_Of_Housing_Suspected_Sample() automated oper Retrieve_Lab_Information() 1. The manual npdn.Sample operation instructions and the input data values to all the users who play the role npdn.Sample.labId npdn.General.has_distance_diagnosis_capability prefix (entity name) and use the attribute name directly in the following section). It will invoke the piece of local program code that accesses the database to retrieve the has_distance_diagnosis_capability return these two values. 3. 2 Rules 3. 2 1 Integrity Constraints The enforcement of an integrity constraint ensures that any change to data does not break the data consistency requirement imposed by an application. Since we use an object oriented model to model the data transferred between organizations, constraints attribute constraint) or on the relationship between attributes (i.e. inter attribute constraint). The former limits the acceptabl e values that an attribute may have. and

PAGE 40

40 The latter states the relationship between attribut es Order.itemAmount Item.unitPrice < Customer.creditLine Sample.class ification = ). We use the same syntax as that used in our previous work (Degwekar, 2007) to specify these two types of constraints. 3. 2 .2 Derivation Rule s A derivation rule produces new data if some preconditions on existing data are satisfied, which is also known as an inference rule, or a deductive rule. I t captures implicit knowledge that can be derived from existing knowledge. This kind of rule has the following form: P Q which means that, given that the body of the implication P is true (i.e., data expressed by P exist in the current data set), the he ad or conclusion Q is also true (i.e. data expressed by Q should be added to the current data set.). One example of this rule type is Customer.numOfPurchase > 3 Customer.discountLevel = 3 We use the same syntax for the specification of this type of rule as that used in (Degwekar, 2007). 3. 2 .3 Action Oriented Rules Action oriented rules are used for invoking actions in response to the occurrence of events. They are generally expressed in the form of event condition action (ECA) rules or event action (EA) rules (Krishnamurthy and Rosenblum 1995) An ECA rule states that when an event E occurs, the action A should be executed if the condition C is evaluated to true. Like the work in (Lee, Su and Lam, 2004), we separate the event specification E from the CA rule specification to allow events and rules to be independently defined by different organizations. An event defined by one organization can be conditionally linked to the rules defined by the same or other organizations using

PAGE 41

41 triggers ( Chapter 4 ) in ord er to coordinate the actions taken by collaborating organizations. The condition part is optional. In IRPSL, the action clause of an action oriented rule can enact either a single operation or a process. The latter is a structure of activities that can act ivate three types of business rules, manual operations and/or automated operations. Examples of action oriented rules are shown in Figure 3 2 and 3 3. SPRO_Prepare_For_Response_Plan is the name of a manual operation Process ExampleOnTriageLabReceivingSamp le is the name of a process. Its definition is shown in Figure 3 4. It is required that the operation and process have been defined and exposed as Web services ( refer to the following subsections for details) before they can be referenced by the action cl auses of these rules. 3. 3 Processes A workflow process is modeled by a structure of activities, each of which can invoke a rule, manual operation or automated operation It is enacted by a n action oriented rule. 3. 3 .1 Structural Constructs Defined in a P rocess By integrating the proc ess patterns defined in WPDL (WfMC, 1998) and WS BPEL (OASIS, 2007) we use the following structural constructs for defining processes : Sequential, Switched, U nordered, Selective, R epeated, AND/OR/XOR split and AND/OR join. Sequential Construct It specifies a sequential execution order between two activities. The second activity is activated after the completion of the first one. Switched Construct It specifies a conditional processing of activities. It is similar to the s witch statement in a programming language. The conditions specified on the

PAGE 42

42 branches of this structural construct are evaluated in the order in which they appear, and the first activity whose condition is evaluated to true will be activated. If no condition al branch is taken, then a default branch is taken. Unordered Construct The activities listed in this construct may be executed in any order, but not concurrently. Selective Construct This construct allows a number of activities to be selected randomly f rom a set of activities for execution in an unordered fashion. The exact number is specified in the NUM field of this construct. Repeated Construct This construct specifies that either a single activity or an ordered set of structural constructs, which ma ke references to either activities or other structural constructs, should be processed repeatedly as long as a specified data condition evaluates to true at the beginning of each iteration. Split Construct This construct is used to specify that several a ctivities can be executed in parallel. There are three types of split: AND Split, OR Split, and XOR Split. The AND Split specifies that all successor activities can be executed in parallel after the completion of the predecessor. The OR Split specifies tha t a specified number of activities can start their execution in parallel after the completion of the predecessor. The specific number is given in the NUM field of the construct. Furthermore, these activities have to satisfy the data conditions specified fo r their processing. The XOR Split is very similar to the switched construct. The differences are that, in the XOR Split, there is no default branch and only one (not in any specific order) can be activated. Thus, zero or one of the successor activities may be executed.

PAGE 43

43 Join Construct. This construct specifies a synchronization point. There are two types of Join constructs: AND Join and OR Join. In an AND Join, the successor activity can only be executed after the completion of all of its predecessors. In a n OR Join, the successor activity can only be executed if the specified number of predecessors has been completed and the data conditions associated with their outgoing transitions are satisfied. The number is given in the NUM field of the construct. A pr ocess can thus be viewed as a directed graph, with some combination of three kinds of rules, automated operations and/or manual operations as its nodes, which are connected by the constructs mentioned above. In order to describ e a process in a graph more e asily, we also introduce auxiliary activity node s: Dummy activity and Route activity. The Dummy activity invokes nothing in its body. The Route activity is used to indicate what the construct that follows belongs to. It can be a selective router, unordered router or repeated router. The rules and operations referenced in a process can be defined by the same organization as th e one that defines the process They can also be defined by other organizations. meta data (input data items, output data items (if any) and location where the operations/rules are defined) are included in the specification of a process. The inputs of a process are the union of the inputs of its rules and operations (i.e., the data needed t o process the rules and operations ), and its output s are the union of the output s of these rules and operations (i.e., the data produced by the rules and operations ). However, if an input data item of a rule/operation is in the output data set of the rules /operations that precede it (i.e., the data item is produced by preceding

PAGE 44

44 3. 3 .2 An Example of a Process Figure 3 4 shows an example process. It is an example taken from the implementation of NPDN SOP ( National Plant Diagnostic Network 2008 ) (Chapter 6 ). The process describes the procedure after a Triage Lab receives a suspected sample from a sample submitter. In this process, firstly, the automated operation Retrieve_Lab_I nformation() has_distance_diagnosis_capability Examine_Sample() operation which in structs the users to examine the received sample. After the operation Sample.classification Derivation Rule1 Split construct is next. In t Store_Sample() Store_Sample_In_Secure_Place() TriageLabCARule2 after the completion Store_Sample_In_Secure_Place() split construct, whose branches include three action oriented rules, TriageLabCARule3 TriageLabCARule 4 TriageLabCARule 5 These branches are synchronized by an action T riageLabCARule 6 procedure to prepare a follow up diagnosis request, including the packing and shipping Inform_Campus_Safety_Office() TriageLabCARule 6 3. 4 Events We sep arate the Event part from the Condition Action part of an Event Condition Action rule to allow these two parts to be defined by different organizations

PAGE 45

45 independently. An event can be anything of interest to collaborating organizations that occurs at a part icular point in time. Examples of events include the announcement of a special sale, the breakdown of a delivery truck that can affect a delivery schedule, the breakage of a machine that can affect a production schedule, the receipt of a new sample that ca lls for its diagnosis. Each event is defined by a name, a human readable description of its meaning, and a schema that specifies the data entities and their attributes. For example, Figure 3 5 shows (Triage Lab receiv i ng a new suspected sample) ( Chapter 6 ) When the event occurs, the data values generated for these data items local or global. A local event is only of interest to the organization that defines it. Its occurrence may trigger some rules defined by the site that defined the event A global event is of interest to some or all of the collaborating organizations. Its occurrence may trigger the processing of rules and processes defined by these interested organizations. All global events are published at the host site of a collaborative federation, and are thus searchable and sharable by collaborating organizations. An organization can subscribe to an event and receive its event data when that event occurs by defin ing a trigg er ( Chapter 4), which conditionally links an event to a knowledge rule. Hence, a global event which occurs at one site can automatically trigger the processing of applicable rules defined by all sites, including the site of the event occurrence. 3. 5 Sharab le Operations, Rules and Processes as Web Services In a distributed, collaborative environment, operations, rules and processes are defined independently by collaborating organizations. We need a way to uniformly process them and make them interoperable. T he approach we take is first to translate the defined operations, rules and processes into Java code, and then package them as

PAGE 46

46 services are then deployed on the s erver at the site that defined them, and their metadata, including their names, input data items and output data items are also stored in a local database. OWSs, RWSs and PWSs are created in th e way show n in Figure 3 6 When operations, rules and processes are defined through the user interface, their specifications are stored in XML specification files. These specifications are used to generate Java source code files (lines 1 5) Each source co de file contains an interface (header) file and an implementation file. The implementation file is the source code generated from the specification of an operation/process/rule. Each operation/rule/process is translated and packaged as a web service with a Web service operation implemented by a method in the Java language. The specification of input more than one data item is included in the output parameters, then the meth od returns a java.util. HashMap data structure in the Java language. The source code is then compiled to generate the corresponding Java class file s (line 6). After this translation process, configuration files required for their successful compilation and deployment as Web services are then created (line 7) These configuration files would depend on the specific application framework used. In our work, we deploy these Web services on the Sun Application Server 9.0. The configuration files include web.xml, sun web.xml, config.xml and jaxrpci ri.xml, which are needed for a web application deployed on the Sun Application Server. Line 8 calls

PAGE 47

47 wscompile command of the Sun Application Server to generate a WSDL file, a model file and a mapping file After al l these files are ready, they are then packed as a deployable package and deployed to Sun Application Server ( line 9). 3. 5 .1 Operations as Web Services Manual operations and automated operations defined in IRPSL are all exposed as Web services. The Web ser vice operation of a n IRPSL manual operation will send an operation instruction to all possible performers, and wait for one of them, who takes on the responsibility of performing the operation, to indicate its completion and enter the data resulting from t he operation into the system. The Web service operation of an IRPSL automated operation is to execute the local programming code or invoke a Web service. The OWS has an operation/method with the same name as that of the manual or automated operation. For e xample, if an IRPSL operation named myOp is defined, then the generated Web service will have a method named myOp and the name of the myOpClass The Java code method that implements the OWS operation sends an email to notify the operation indication of completion, if the operation is a manual operation, or to invoke a Web service, or a local program code, if it is an automated operation. The method also has the input data items of the IRPSL operati on as its parameters, and returns the values of the data items that are specified in the Returns field of the IRPSL operation specification. 3. 5 .2 Rules as Web Services We use the same algorithm used in (Degwekar, 2007) to translate an integrity constrai nt rule or a derivation rule into Java code. We define the input of a constraint rule as all of the attributes that are referenced in the rule. The output is the truth value

PAGE 48

48 indicating whether the constraint is satisfied or not. The input and output inform ation of this and other rules, as well as processes, are used by the system to determine the applicability of rules and processes to an event instance (Chapter 4 ). Each integrity constraint rule is represented as a Web Service with an operation named check The Java code method which implements the RWS s operation examines the supplied value of input and returns a Boolean value which is true if the constraint is satisfied or false otherwise. All data items referenced in the rule constitute the in put to Java code method This input is also the input of the RWS operation. Each derivation rule is represented as a Web Service with an operation named implies The Java code method implies( ) which implement s the RWS operation examines the inp ut data to determine if the body of the implication is true. If so, it returns the values of data items specified in the head of the implication. All data items referenced in the body other data item) of the head constitute the input to the method This input is also the input of th e RWS operation, as well as the input of the rule Each action oriented rule is represented as a Web Service with an operation named perform Figu re 3 7 shows the general structure of the generated Java code for an action oriented rule The Java code, which implements this operation (i.e. the method perform( ) in the figure) examines the input data to see if the condition is satisfied. If so, the I RPSL operation/process specified in the action clause is executed by invoking the corresponding OWS/PWS and the output of the invocation is returned. The input of the action oriented rule is the union of the data items referenced in the condition clause, and the input data items of the IRPSL operation/process specified in

PAGE 49

49 the action clause. The output of the action oriented rule is the output of the IRPSL operation / process referenced in the action clause. We require the following precondition to be met in order for the generate d RWS of an action oriented rule to work correctly : The IRPSL operation or process referenced in a n action oriented rule must have already been defined and deployed as a Web s ervice before the rule is defined. The OWS/PWS must use th e name of the IRPSL operation / process as the name of its Web s ervice operation Hence, the execution of the operation/process given in the action oriented rule is achieved by invoking the corresponding OWS/PWS with the same name ( the name of the Web servic e of an op eration named myOp is myOpClass ) 3. 5 .3 Processes as Web Services A process is defined as a structure of activities. Each activity can be a rule or an r ule. We use A WS to refer to the generated Web service of an activity We require the following precondition to be met to generate a PWS. The activity referenced in a process specification must have already been defined and deployed as a n AWS before the pro cess is defined. The AWS must have the same name as the name of the activity. The PWS has the same name as the process, and has a n operation named perform The Java method perform( ) that implements the PWS operation takes in all the input data items requi red by all the activities in the process (if an input data item required by an activity can be produced by its ancestor activity, then it will not be included in the method s input) and returns the output data items produced by all these activities by add ing them to a hash table data type in the Java language named java.util.HashMap.

PAGE 50

50 Figure 3 8, 3 9 show the general structure for a process code generated by our algorithm. Before implementing the method perform( ) our algorithm first defines an invoker thr ead callActivityName process specification (here AcitivityName shall be replaced by a real activity name ). Since each activity is executed by invoking the corresponding AWS the invoker is actually a Web service call, but is wrapped in a Java thread class as shown in Figure 3 8 An invoker thread object will be created for each activity instance (an activity may be referenced more than once) in the process specification. The structure of activities that defines a process is decomposed into a set of structural constructs that form the structure. Each structural construct specifies a sequential, switched, unordered, selective, repeated, AND/OR/XOR Split, or an AND/OR Join relationship between two or mo re activities or constructs. Programming code that will cause the activity to be executed in the manner specified by the construct is then generated for each construct. The Java code method that implements the PWS operation is constructed by put ting together all the code generated for these constructs. The method is, essentially, a do while loop. The loop keeps on toBeExecuted need to be executed, until the vecto r is empty. When an activity instance is ready for toBeExecuted corresponding invoker thread object is started. Once the thread is finished, it will be removed from this vector, and it member variables and used by the activity instances that follow the current activity

PAGE 51

51 instance. The predecessor(s) specified in a structural construct are invoked first, followed by the successor(s) speci fied in the same construct. Besides the completion of the predecessor(s), the processing of a successor would depend on whether the data condition specified for the transition between the predecessor and the successor is satisfied. It also depends on wheth er its processing will follow the restriction that is inherent in the structural construct. For example, the successor in the AND Join construct can only be processed after the completion of all the predecessors. Only one successor can be executed after th e completion of the predecessor in the XOR Split construct. Our algorithm checks whether an activity invoker thread has been started or is_started and is_finished These tw o variables have the value 'false' before the thread is started, and the value of is_started becomes 'true' after the thread is started and the value of is_finished becomes 'true' when the thread terminates successfully. In order to avoid the situation tha t a condition is not satisfied first but becomes satisfied later when the data gets updated by the subsequent activities, we introduce a vector named terminatedEvent vector no matt er whether it can be executed or not. By doing so, we can make sure that each activity instance is only checked once for its execution. For illustration purposes, we show the algorithm for generating code for the switched construct in Figure 3 10

PAGE 52

52 Figure 3 1. Examples of manual operation and automated operation Figure 3 2. An example of action oriented rule whose action part is to invoke an operation.

PAGE 53

53 Figure 3 3. A n example of action oriented rule whose action part is to invoke a process.

PAGE 54

54 Figure 3 4. An example process named ExampleOnTriageLabReceivingSample Figure 3 5 An example of an event name d

PAGE 55

55 Figure 3 6 The routine for creat ing OWSs, RWSs and PWSs. Figure 3 7 General structure of code for an action oriented rule. Figure 3 8. General str ucture for generated invoker thread class code (it is a part of generated process code showed in Figure 3 9).

PAGE 56

56 Figure 3 9. General structure for a process code

PAGE 57

57 Figure 3 10 The algorithm for gener ating code for the switched construct.

PAGE 58

58 CHAPTER 4 ETKNET2.0 SYSTEM ARC HITECTURE AND ITS EV ENT TRIGGERED PROCESSING TECHNIQUE In this chapter, we present an implemented system, named Event Triggered Knowledge Network 2.0 (ETKnet2.0), and the event triggere d rule processing and process enactment technique for achieving the interoperation of event data, knowledge rules, operations and processes, and the dynamic construction and enactment of inter organizational processes. A part of this work has been publishe d in (Su et al., 2011; Xiao, DePree and Su, 2011). 4.1 ETKnet2.0 System Architecture ETKnet2.0 has the similar architecture as that of our earlier system ETKnet (Degwekar, 2007; Degwekar and Su 2008 ; Su et al. 2008 ). It is a peer to peer server based sys tem as shown in Figure 4 1. Each organization, called a collaborating site, has identical software installed on it. The software components include a User Interface, a Rule Server, an Event Server, and a database system. The User Interface provides facilit ies for the users of each organization to define events, event data, triggers, rules, operations, processes and meta rules. It generates language specifications for internal processing based on what has been defined. This tool is important and useful becau se, in a distributed, collaborative environment, it gives the flexibility and power to specify business logic, policies, regulations, constraints and processes of individual organizations. In addition to the above facilities for knowledge management, the U ser Interface also provides facilities for configuration management, administrative management, task management and ontology management. It has been developed by another student, Jeff DePree, in our research group, so it will not be covered in this dissert ation.

PAGE 59

59 The Rule Server component is responsible for managing the operations, rules, processes and meta rules defined at each site, for translating the defined operations, rules and processes into Java code and packaging them as Web services, and for invok ing the applicable rules at that site after receiving an event notification and the event data. The Event Server component is responsible for managing the events and triggers defined at that site. When an event occurs at that site, the Event Server will ac t as the coordinator of a dynamic inter/intra organizational process construction and processing session initiated by the event instance. One of the collaborating sites plays the role of Host for the collaborative federation. The Host has an additional so ftware component: a Web Service Registry. The specifications of sharable operations, rules and processes of all the collaborating organizations are registered with the Web Service Registry. Therefore, they are searchable and sharable by members of the fede ration. The Rule Server component of the Host, named the Host Rule Server, is responsible for carrying out the registration of sharable operations, rules and processes in the Web Service Registry. Meta rules defined by collaborating organizations are made available to the Host but are not registered with the Web Service Registry because they are not converted into Web Services at design time. Rather, they are interpreted at run time. Since the Host has all the information about sharable rules and meta rules it also determines those distributed rules that are applicable to an event instance and their processing structure based on the meta rules and the event data sent from the coordinator. The Event Server component, named the Host Event Server, is responsib le for registering global events

PAGE 60

60 and triggers, and forwarding the event data received from the coordinator to the Host Rule Server. Another additional software component at the Host is the Ontology System. The Ontology System is responsible for semantic ma tching among entities and attributes. The collaborating organizations might use their own terms to define events, operations, rules and processes. It is often the case that the terms they use have semantic discrepancies. Thus, an ontology management system is needed to reason over the underlying meanings of the terms used, and resolve the semantic discrepancies among them. This part of the work is done by another member in our group as shown in (Zhou et al., 2010). This dissertation will not address ontolog y issues. We shall assume that the semantic ambiguities and inconsistencies of all the data items used by the collaborating organizations can be resolved by querying the ontology management system. The underlying implementation method that we use is as fol lows: when we save the metadata of events, operations, rules and processes, we also save the corresponding unique object ids used and stored in the ontology management system. When we search for specific data items, we use their object ids to do the matchi ng. We have implemented the ETKnet2.0 system in the Java language and have hosted it on the Sun Application Server Platform Edition 9. The Event Server and the Rule Server at each site are implemented using the Enterprise JavaBean 2.1 framework. We publish ed the Web services that implement application operations, rules and processes in the private Web Service Registry of the Host. The registry makes use of a MySQL database to store the Web services' meta information, including inputs, outputs, and their WSD

PAGE 61

61 Event Server and the Rule Server to store the meta information of events, triggers, rules, processes and operations locally. 4.2 Event triggered Rule Processing and Process Enactment Technique Trad itionally, data, operations, knowledge rules and processes have been managed by different types of software systems such as database management systems, rule processing systems, application systems and business process execution systems (or workflow manage ment systems). These systems, and the data, rules and processes they manage, do not interoperate. By interoperation, we mean that, for example, the availability of some data may cause business rules to be activated automatically. The processing of business rules may in turn enact some processes, which perform some manual or automated operations. The operations may then produce data, which may subsequently cause additional rules to be evaluated. Also, an inter organizational process is usually pre defined an d processed by a business will not work well in a loosely coupled collaborative environment because the business rules and processes and other resources of collaborating org anizations can be removed and/or updated at any time. It is costly to redefine and process an inter organizational process each time an organizational resource has been changed. Also, automatic runtime modification of the process to accommodate changes is not simple and may not be workable if the changes to the pre defined process are drastic. Ideally, an inter organizational business process should be constructed and processed dynamically. In this section, we explain our event triggered distributed rule pr ocessing and process enactment technique, and show how it can achieve the interoperation of

PAGE 62

62 sharable data, rules and processes. This technique can also be used to achieve dynamic construction and processing of inter organizational processes. 4.2.1 Event In stance and Event Data When an event occurs, it forms an event instance and the data associated with the event instance constitute the event data. The event data include all the data items that are assigned value s upon an event occurrence and those data th at are added and/or modified later during the processing of rules, which are either explicitly or implicitly triggered by the event instance ( the details will be given below ). Event data are saved in an XML document, which is transmitted between collaborat ing organizations during the collaboration session triggered by the event instance. The XML schema of the event data is provided in Appendix A. In ETKnet2.0, an event instance can be posted either synchronously or asynchronously. If an event instance is po sted asynchronously, the procedure is returned immediately without waiting for the result of processing the event instance. If it is posted synchronously, the procedure waits for the result. When an event instance is posted synchronously, a time interval c an be specified. If the time interval is expired but the event processing is still not finished, the current event processing result (if any) is returned. 4.2.2 Triggers As we have explained before, we separate the Event part from the Condition Action part of an event condition action rule. These two parts can be defined independently by collaborating organizations. A trigger is a specification in the format of Condition ; Event ; Rule which conditionally links an event to a rule. It states that if the eve nt data associated with an event instance satisfies a certain data condition, the

PAGE 63

63 specified rule should be processed. The Condition part could be null. In that case, the rule is processed unconditionally upon the occurrence of the event. The condition part is useful if an organization wants to be notified only when the event data satisfies a certain condition. For example, a supplier might want to be notified with a quote request event for a quantity above a certain level. An organization can explicitly def ine a trigger to link a local event with a rule defined by the organization itself, or by some other organization. It can also define a trigger to link a global event defined by another organization with a rule defined locally. Multiple triggers defined by many organizations can link the same event to different rules. The occurrence of an event will trigger the processing of all these local and global rules as well as the processes enacted by action oriented rules. The above approach maximizes sharing of ev ents, rules and processes. Defined triggers are called explicit triggers and the organizations that define the rules are explicit subscribers Triggers can also be automatically and dynamically generated by the system. If the event data items associated w ith an event instance can provide the input data required by a rule, we regard this rule as potentially applicable to the event. The applicability of rules will be explained in detail in the next section. The processing of applicable rules and the processe s enacted by them may change the event data or produce new data, thus adding new information to the event data. System defined triggers are called implicit triggers and the organizations that have applicable rules are implicit subscribers When an event oc curs, the event data will be inclusion of implicit subscribers in event notification and event data transfer is important

PAGE 64

64 because these organizations may not know o f the existence of the event nor its occurrence, or may not know that the event data can provide input to their rules to produce useful data and/or to enact relevant processes. 4.2.3 Applicability of R ules We have explained how rules can be translated into Java code and exposed as RWSs and PWSs in C hapter 3 Each rule has a set of input data items and a set of output data items. Its applicability to an event instance is determined by the Host using a syntactic matching process followed by a semantic matchin g process. The syntactic matching is based on the names of data entities and their attributes referenced in the two sets: the event data item set and the rule s input data item set. It checks whether the entity and attribute names of the event data item se t is a superset of those entity and attribute names referenced in If not, the rule is not applicable. If so, the event data can potentially provide the input data needed to process the rule However, this matching process ca n on ly determine if the rule is "potentially applicable" because the data values of the event data and the rule's input data have not been considered. The semantic matching process is thus carried out to determine if the data condition(s) specified by the rule can be satisfied by the event data values. If so, the rule is said to be "applicable" because the rule can be processed to produce new data or modify the event data. The syn tactic matching process enables our system to pre filter out those distribute d rules the inputs of which cannot be satisfied by the event data. T he semantic matching process enables the system to identify those distributed rules that are truly applicable. Thus, the event data can be transferred to only those sites that have applic able rules. These two matching processes allow the system to avoid

PAGE 65

65 unnecessary processing of business rules that are not truly applicable, and to save data transmission time. 4.2.4 Event Triggered, Distributed Rule Processing and Process Enactment Techniqu e Similar to the ETKnet system, the ETKnet2.0 system processes distributed rules using an event triggered mechanism. When a global event occurs at a site the site becomes the coordinator of the collaboration and knowledge sharing session. The event data sites that have applicable rules. These sites are the explicit and implicit subscribers of the event. When the subscriber sites receive the event data, the applicable and most up to date rules are activated automatically by their corresponding Rule Servers. The processing of these rules may in turn enact business processes specified in action oriented rules to perform the manual and/or automated operations and/or rules tha t define the processes. The execution of rules and operations may produce new data and/or update the existing event data. After processing all of the applicable rules, the explicit and implicit subscriber sites would return the new and/or updated data to t he coordinator. When the coordinator receives these data from the subscriber sites, it merges the returned data with the original event data to form a new version of the event pplied to process this new version. This processing produces yet another new version of the event data, which may cause some other rules at the same and/or different sites to become applicable. In that case, the coordinator will send the new version to exp licit and implicit subscribers in another round of event notification and rule processing. Multiple rounds can take place until no new data and/or updated data have been

PAGE 66

66 generated and no applicable rules can be found. At that time, the collaboration and kn owledge sharing session terminates. Through this event triggered processing of distributed organizational rules and embedded processes, ETKnet2.0 achieves the interoperation of sharable data, rules, operations and processes and dynamically constructs and e nacts an inter organizational process that carries out inter organizational collaboration or coordination. The above processing technique allows all explicit/implicit subscriber sites to be notified of the event occurrence. The ETKnet 2.0 system also supp orts a restricted event notification. That is, only a subset of subscriber sites are notified. This is achieved Host then only checks the global rules defined by thes e restricted sites. This processing technique is useful when the coordinator wants only a subset of subscribers to be notified of the event occurrence and to receive the event data. Our event triggered rule processing and process enactment technique enable the processing of all applicable rules and organizational and predefined inter organizational processes and operations. After rules processing session is finished, all relevant organizations and their staffs will received all the data associated with the original event as well as the data generated by these rules, processes and operations. We should also point out here that the above distributed rule processing technique produces a similar effect to that of a logic based deductive system in that rules are repeatedly processed as new data are produced in the previous round of rule processing. However, the main differences are that our system processes three different types of business rules and business processes in an integrated and

PAGE 67

67 interoperable fashion, a nd rules and processes are distributed and processed uniformly as Web services in a Web service infrastructure. 4.3 The Need to Enhance the Rule Processing and Process Enactment Technique In our system, an organization can define an inter organizational pr ocess that contains a structure of rules and operations shared by multiple organizations. This kind of predefined inter organizations know ahead of time to be useful and should be carried out up on the occurrence of an event. At runtime, our current event triggered rule processing and process enactment technique may trigger other distributed applicable rules that are not involved in predefined inter organizational processes. The multiple rounds of rule processing and pre defined processes enacted by these rules constitute an inter the fly. However, the above approach of constructing an inter organizational process may not be adequate to set up a desirable interaction among organizations. As the application environment changes, collaborating organizations may want to enforce some constraints in processing those applicable rules that are not embedded in pre defined inter organizational processes. For example, in a certain circumstance, collaborating organizations may want to ensure that Rule A defined at one site be processed before Rule B of another site; or they may want rule B not to be processed at all even though it is applicable to an event instance; or they may want to give a higher priority to an organization over other(s); i.e., the rules (and the processes activated by them) provided by one organization is more important or reliable than some other organization(s ) In order to constrain the processing of distributed rules that have been rules A

PAGE 68

68 meta rule is a specification of a constraint on the execution of applicable rules or a constraint on the priorities of applicable sites. We shall explain the meta rules, as well as the meta rule enhanced, dynamic construction and enactment of inter organizational process in detail in Chapter 5 Figure 4 1. The architectur e of ETKnet2.0 system, and its local and remote calls among distributed components.

PAGE 69

69 CHAPTER 5 META RULE ENHANCED DYNAMI C CONSTRUCTION AND P ROCESSING OF INTER ORGANIZATIONAL PROCE SSES In Chapter 4 we explained our event triggered rule processing and proc ess enactment technique. We also pointed out that the processing technique can, not only achieve the interoperation of sharable data, rules, operations and processes, but also trigger the processing of applicable distributed rules, which may or may not be referenced in pre defined inter organizational processes. Those distributed rules that are not referenced in pre defined processes are processed at different sites in parallel (i.e., not in a specific order or structure). As we pointed out in Chapter 4 su ch an order or structure may be needed in some situations. One way to enforce their order/structure of processing is to put them in a pre defined, inter organizational process as explained in Chapters 3 and 4. However, such a process is static and not eas y to change. Some rules even cannot be decided at build time. Another method that we propose here is to introduce "meta rules" to constrain the processing of these rules. A meta rule is a specification of a constraint on the execution of applicable rules o r on the priorities of collaborating organizations. It can be introduced or removed at any time (i.e., dynamically) with the agreement of collaborating organizations. Meta rules are optional. They can be defined for an event by collaborating organizations and are interpreted at runtime to enforce the order/structure of rule processing when the event occurs. Their use is a flexible way to capture and react to the changing requirements of collaboration in a dynamic environment because they can be introduced, modified and removed at runtime.

PAGE 70

70 Organizations can also use meta distributed rules and processes that have been defined. These organizations may suspect or assume, but not necessarily be sure that, by ap plying some constraints in the processing of distributed, applicable rules, they may produce some desirable data and/or achieve some desirable inter organizational interactions. Meta rules can be used to verify their suspicions or assumptions. 5.1 Meta r ul es A meta rule is a specification of a constraint on the execution of applicable rules or on the priorities of collaborating organizations. There are three types of constraints that can be specified by meta rules: selection constraint, structur e constraint and priority constraint. Selection constraints specify whether applicable rules should be conditionally or unconditionally selected for execution. Structur e constraints specify the execution order/structure of applicable rules. Priority constraints speci fy the priorities of organizations; thus the precedence of the meta rules defined by them ( Section 5.2.3 ). 5.1.1 Meta rules on S election C onstraints Selection constraints can be specified by three meta a rule and the conditional suppression meta rule. Their syntaxes are defined as follows. Suppress (A 1 n ) It specifies that any rule in the set (A 1 n ) (n>=1) should not be selected. Onetime (A 1 n ) It specifies that any rule in the set (A 1 n ) (n>=1) can only be executed once in multiple rounds of rule execution triggered by an event instance

PAGE 71

71 If (ConditionExpr) then Suppress(B 1 m ) It is called the conditional suppression meta rule. It specifies C ondition Expr is eval uated as true, then all the rule s in the set (B 1 m ) (m>=1) should not be selected. The definition of ondition in the Backus Naur Form (BNF) syntax is RuleBooleanExpr {and/or RuleBooleanExpr} |ConditionExpr {and/or ConditionExp B oolean expression of rule s and defined as RuleBooleanExpr := enclosed by them can appear zero or more times. The square brackets denote that an item enclosed by them is optional ; i.e. the item can appear either zero or one time. The meta rule are special cases of the conditional suppression meta rule. In the above definitions of meta rules as well as the ones given later, by sayi ng that a rule is selected, we mean that the rule is selected for processing from the set of rules that has been determined to be applicable to an event instance using the syntactic and semantic matching processes introduced in our work. All applicable rul es that are not suppressed by meta rule(s) are processed by the system. 5.1.2 Meta rules on S tructur e C onstraints Structur e constraints can be specified by three meta rules: the rule, and th meta rule. Their definitions are shown below: Prerequisite (and(A 1 ...,A n ), B) It is also called the and Prerequisite meta rule. It specifies that rule B can only be processed if all of rules A 1 n have been processed (n>=1). If n is equa l to 1, then the constraint can be rewritten as Prerequisite(A 1 B).

PAGE 72

72 Prerequisite(or(A 1 n ), B) It is also called the or Prerequisite meta rule. It specifies that rule B can only be processed if one of A i (1<=i<=n) has been processed (n>1). Order (A 1 n ). For any i and j, where 1 <= i < j <= n A i should be processed before A j We note here that we do not have to use a structur e constraint to specify the parallel execution of rules because our event triggered, distributed rule processing and proce ss enactment technique explained in Chapter 4 executes all applicable rules in parallel by default. 5.1.3 Meta rules on P riority C onstraints A priority constraint specifies the relative priorities assigned to collaborating organizations as shown below: Pr iority((O 1 n ) > (O n+1 n+m ) > ... > (O p+1, p+k )) Organizations shown in the inner pair of parentheses have the same priority, and the set of organizations shown on the left of ">" has a higher priority than the one shown on the right. If no pr iority is assigned to an organization, then it is given the lowest priority. The priorities of organizations determine the precedence of meta rules defined by them (more details will be given below). 5.2 Application of Meta rules After determining the ap plicability of rules by the syntactic and semantic matching processes, meta rules are applied to filter out some of these applicable rules and/or enforce their processing order/structure.

PAGE 73

73 5.2.1 Application of M eta rules on S election C onstraints Meta rules on selection constraints are first applied to filter out some rules from the set of applicable rules resulting from the syntactic and semantic matching processes. They are applied in the following ways: Suppress (A 1 n ) Rules A 1 n will be suppre ssed, that is, removed from the set of applicable rules in each round of rule processing. Onetime(A 1 n ) For any rule A i ( 1<=i<=n ), if it has been executed in a previous round, then it will be removed from the set of applicable rules in the current rou nd as well as in the subsequent rounds. Conditional suppression meta rule i.e. (B 1 m 1 m are removed from the set of applicable rules in the current and/or later rounds. Otherwise, those rules in (B 1 m ) that are applicable in the current round can be selected. A rule specified in a RuleBooleanExpr is evaluated as true if it is either applicable in the current round or has been execut ed in a previous round. "Not RuleA" in a RuleBooleanExpr is evaluated as true if RuleA is neither applicable in the current round nor has been executed in an earlier round. 5.2.2 Application of M eta rules on S tructur e C onstraints Meta rules on structur e co nstraints are used to enforce the processing order/structure of the applicable rules determined by the syntactic and semantic matching processes and the selection constraints. Prerequisite(and(A 1 n ), B) This meta rule is applied only if rule B is appli cable in the current round. If all rules A 1 n either have been processed in the previous round(s) or are applicable in the current round, then B is processed right after

PAGE 74

74 those A i is delayed until all A i (1<=i<=n) have been processed. If there is any A i that is never triggered, then rule B will not be processed. Prerequisite(or(A 1 n ), B) This meta rule is applied only if rule B is applicable in the current round. If there is a rule A i (1<=i<=n) that has been processed in an earlier round, then rule B is p rocessed just like any other applicable rule. If A i is applicable in the current round, B is processed right after A i If none of A 1 n were processed in an earlier round delayed. The delayed rule B will not be processed if none of A 1 ....A n are executed at the end of rule processing. Order (A 1 n ) For any pair (A i A j ) where (1<=i
PAGE 75

75 processing order/structure of the remaining applicable rules. Among the meta rules on rule and the conditional suppression meta rule because if a rule spec rule is suppressed, there is no need to enforce the one rule has a higher precedence than the conditional suppression meta rule because the former can be viewed a s a special case of the latter that has "True" as its condition specification. Among the meta rules on structur e rule and met a rule because the former will be enforced across multiple rounds of rule processing rule has rule because the former specifies a stronger precondition than the latter. In a specific round of rule processing, meta rules are applied according to their precedence. The meta rule with a higher precedence is applied first. 5.3 Meta rule Enhanced R ule P rocessing and Process E nactment T echnique In this sub section, we explain how meta rules and meta rule enhanced rule processing and process enactment techniques are implemented in our system. We also explain how they can achieve the dynamic construction and processing of inter o rganizational processes. 5.3.1 Determining the A pplicable Rules and their P rocessing O rder/ S tructure Like the definitions of rules and processes, the specifications of meta rules are xml based. Their schemas are given in Appendix A. A priority meta rule is associated with a global event, which can only have one such meta rule. We assume that there is a

PAGE 76

76 high level decision body that makes such priority decisions for collaborating organizations. Priority meta rules for global events, if defined, are registere d with the Host. Other types of meta rules can also be defined for a global event. They can be defined by the organization that defines the event, or by some other organization s After a meta rule is defined, it is stored at the local site and also regist ered with the Host site. At design time, when an organization defines a meta rule other than a priority meta rule, the Host will check if the rule conflicts with any other meta rule that has been defined for a global event. If so, the conflict will be bro ught to the attention of and resolved by the person or persons who defined them. For example, the meta rule in meta rules cannot be determined at design time because the applicability of rules can applicable in the current round of rule but not B are applicable. The former requires that A be processed right before C but the latter requires that A should be defer red until B is processed. For those conflicts that cannot be determined at design time, they will be detected at runtime by the Host. These conflicts are resolved by disabling the meta rule with a lower precedence in the current round of rule processing. I f conflicting meta rules have the same precedence, then the one applied later will be disabled. The Host will send a notification to all the

PAGE 77

77 organizations that defined conflicting meta rules. They can then resolve their differences offline and modify their rules. At runtime, when a global event occurs at a site, the site becomes the coordinator for processing the event instance and the distributed rules triggered by the event. As explained, the coordinator gets applicable site and applicable rule informatio n from the Host by sending it the event data in an XML file. This file contains a data field named es whose processing have been delayed. When the Host receives the event data from the coordinator, it first performs the syntactic and semantic matching processes, as we have explained Chapter 4 to determine which distributed rules are applicable to the event instance. We shall call this set of applicable rules the applicable rules set Then the Host would follow the algorithm shown in Figure 5 1 and apply the meta rules that have been defined for the event on this set of applicable rules to remove thos e rules that need to be suppressed in the current round, and construct the processing order/structure for the remaining applicable rules (lines 9 28 of the algorithm). The processing order/structure is represented by an acyclic directed graph G. Each ap plicable rule has a vertex in the graph. If there is an edge going from vertex v i to vertex v j then rule v i is processed before rule v j Applicable sites at this time are those sites that define the applicable rules whose corresponding vertices have no in coming edges in the processing graph. The processing graph is finally converted into an XML document. Each vertex and its

PAGE 78

78 ch specify the rule that the vertex represents, including the rule name and the site that defined the rule. The sub element hat this rule immediately follows in the graph. meta applicable rule, which stores all the meta rules that have been applied and are related to this rule. Meta rules are applied in descending order of their precedence. As we have explained before, their precedence are determined first by the priorities of organizations that define them, and then by their rule types. If a meta rule tries to suppress or defer an associated meta meta rule(s) that has been applied so far; i.e., it conflicts with the meta rule(s) that have higher precedence than it. If a meta rule adds an edge that introduces a cycle in G, then it c onflicts with the meta rule(s) that have been applied; i.e., the latter has a higher precedence than the former. We can use the depth first search method to check whether a directed graph has a cycle. When a conflict is detected, the meta rule with a lower precedence is disabled in the current round and also saved to the log. The organization that defines the disabled meta rule will be informed. 1 n rule, A i (1<=i<=n) is removed from the d meta empty ( Figure 5 2). A conditional suppression meta ression meta rule is a Boolean expression of rules,

PAGE 79

79 1 and (A 2 or (Not A 3 1 1 previous round or is in the applicable 3 3 is neither in the applicable rules set nor has been executed in an earlier round. If the condition is satisfied and rule B i meta B i satisfied b ut rule B i meta i will be selected. If this meta rule has ever been applied successfully for at least one B i then it is added to meta as true in the conditional expression. Figure 5 3 shows the algorithm to process a conditional suppression meta rule. For each rule A i 1 n meta meta rules rule is shown in the Figure 5 4. A Prerequisite(and(A 1 ,..,A n ), B) meta rule will be applied only if rule B is applicable in the current round as shown in the algorithm given in Figure 5 5. Otherwise, this meta rule is ignored and A 1 ,..,A n execution is satisfied (i.e., all the rules A i ed from vertex A i to vertex B for each A i the new edge introduces a cycle into the graph, then t his meta rule is ignored in this round. All edges that have been added for this meta rule will be removed from G (lines 2 18 of algorithm). The algorithm also adds this meta associated meta rule sets of all applicable rules A i (1<=i<=n) and rule B if this meta rule is applied

PAGE 80

80 successfully. If there is a rule in (A 1 ,..,A n associated meta rules t is empty (i.e., rule B is not referenced in any meta rules is satisfied) (lines 23 (i.e., there is a rule in (A 1 ,..,A n associated meta rule is meta rule is ignored in the current round because removing rule B may cause a conflict in the meta rules that have been applied before. A Prerequisite(or(A 1 n ), B) meta rule will be applied only if rule B is applicable in the current round. Otherwi se, the meta rule is ignored and rules A 1 n are processed normally. This meta rule is implemented using the algorithm shown in Figure 5 6. If none of rules A i ass ociated meta rules i (1<=i<=n) are in associated meta rules empty, then this meta rule is ignored in the current round. Otherwise, it is implemented as a Prerequisite(A j B), where A j is the rule that has been executed in a previous round ( if there is such a rule) or is applicable in the current round. An Order( A 1 n ) meta rule will enforce the processing order of each pair of rules (A i A j ) (1<=i
PAGE 81

81 A j i n the graph, and adding an edge
will not introduce a cycle to the graph, then add the directed edge to the graph. If adding the edge would introduce a cycle in the processing graph G, then this meta rule is ignored in the current round. 5.3.2 Meta rule E nhanced R ule Processing T echnique At runtime, when a global event occurs at a site, the site becomes the coordinator for processing the event instance and the distributed rules triggered by the event. The coordinator sends the even t data to the Host site to get applicable rules and their processing structure. After receiving event data from the coordinator, the Host carries out the syntactic and semantic matching processes and uses meta rules to determine the applicable rules and t heir processing order/structure in a processing graph. The Host returns the processing graph in an XML document, the applicable rule and applicable site information (at this time, applicable sites are only those sites that have applicable rules without inc oming edges in the processing graph) to the coordinator. The coordinator then sends the event data and the processing graph to the applicable sites. After a site receives the event data from another site (it could be the coordinator or any other applicable site), it will execute its global and local applicable rules. A new thread is created to determine the applicability of local rules and process these rules. Since the data produced by processing the local rules will not be included in the event data sent to execution in the following explanation. Again, since the Host has checked the global sary to check the applicability of global rules and enforce the meta rules again after a site

PAGE 82

82 receives the event data. The receiver site can process its global rules according to the received processing graph directly. After a site receives the event data and the processing graph from a site (it could be the coordinator or any other site, or even the same site), it checks whether its applicable rules can be executed right away. An applicable rule can be executed only if the site has received all the event d in the processing graph, or if the rule has no predecessor rules. Otherwise, it stores the received event data in a static hash table, which will later be merged with other received event data that are nee ded for processing this applicable rule at this site. For each applicable rule, when it is processed, the site checks whether the rule has any successor rule(s) in the processing graph that needs to be executed. If so, it sends the updated event data and t he processing graph to the site(s) that define the successor rule(s). If there is no successor rule, then the site will send the updated event data, along with the executed rules, back to the coordinator. The coordinator then merges all the returned event data to create a new version of event data (the coordinator knows it has received all the event data by checking whether the executed rules cover all the applicable rules in this round). If the new version contains any update or addition to the original e vent data, or the version of event data to the Host to start a new round of rule processing and process enactment. If the version of the event data at the beginning of the current round has not been changed by the current round of rule processing and process enactment and there are no deferred rules, the process triggered by the event instance terminates. This is

PAGE 83

83 because all the rules that are applicable to the current vers ion of event data have been processed and the processed rules and the processes enacted by these rules have not added any new information that warrants another round of rule processing. The syntactic and semantic matching processes introduced in this work identify those distributed rules that are applicable to the event data upon an event occurrence. The processing of these rules and static processes enacted by them forms an inter organizational process, which can be further refined by meta rules. Since me ta rules can be added, modified and removed at runtime, the refined inter organizational process can be more accurate in capturing and carrying out the desired collaborative operations of organizations, and more flexible and suitable for managing the busin ess of these organizations in a dynamic environment. In Chapter 6 and Chapter 7 we will use two example scenarios taken from e government domain and e business domain to demonstrate the applications of our specification language, processing technique and system.

PAGE 84

84 Figure 5 1. Algorithm to determine the applicable rules and construct a processing graph. Figure 5 rule.

PAGE 85

85 Figure 5 3. Algorithm for processing conditional suppression meta rule. Figure 5 rule.

PAGE 86

86 Figure 5 r ule. Figure 5 rule.

PAGE 87

87 Figure 5 rule.

PAGE 88

88 CHAPTER 6 CASE STUDY 1: NATIONAL PLANT DIAGN OSTIC NETWORK' S STANDARD OPERATING PROCEDURE The United States Department of Agriculture, Cooperative State Research, Education and Extension Service (USDA, CSREES) launched a multi year national project in May 2002 to build the National Plant Diagnostic Network (NPDN). NPDN includes five regions: the Great Plains Diagnostic Network (GPDN), the Northeastern Plant Diagnostic Network (NEPDN, the North Central Plant Diagnostic Network (NCPDN), the Southern Plant Diagnostic Network (SPDN), and the Western Plant Diagnostic Ne twork (WPDN). The University of Florida was selected as the regional center of SPDN. The specific purpose of NPDN is to provide a nationwide network of public agricultural institutions with a cohesive, distributed system to quickly detect high consequence pests and pathogens that have been introduced into agricultural and natural ecosystems, identify them, and immediately report them to appropriate responders and decision makers (The United States Department of Agriculture, Cooperative State Research and Ed ucation and Extension Service, 2002). NPDN defines a document of Custody and Chain of Communication Standard Operating Procedure (SOP) ( National Plant Diagnostic Network 2008 ) to specify the constraints, policies, regulations and procedures on 1) how a di sease sample should be transferred, and diagnosed in different levels of diagnostic labs after its collection; 2) how related labs/offices can communicate with one another about the sample status and diagnosis results effectively. We have identified the ne ed for event notification, automatic event data delivery, and distributed processing of knowledge rules and processes in order to achieve close communication and coordination among these organizations. We have applied the results of our R&D efforts in the definition and enactment of the SOP. Our

PAGE 89

89 technology will enable the organizations (labs) in NPDN to effectively share their event data, knowledge rules, operations and processes, provide a timely exchange of information about any disease or pest outbreak, and receive assistance on appropriate emergency response, thus establishing better communication, coordination and collaboration among them. To demonstrate and evaluate the integrated rule and process specification language, the distributed processing tech nique, and the system architecture we have implement ed the SOP using our language and have run through several test scenarios with NPDN members from University of California at Davis and Kansas State University. The participants agree that, overall, the E TKnet2.0 system provides an efficient way to keep people engaged in the SOP by facilitating and guiding the communication channels. It helps each participant kno w who should do what and when. It provides a good framework for communication and helps partici pants understand how the SOP works. It can be a good training tool as well as a useful tool for exercises and/or the management of actual events (Su et al., 2011) 6.1 Events, R ules Operations, P rocesses and Meta rules Used to Implement NPDN's SOP The re are several categories of organizations/labs/offices involved in the operation of the SOP, including the Triage Lab, NPDN Regional Hub Lab, Expert Lab, State Plant Regulatory Official ( SPRO ) State Plant Health Director ( SPHD ) National Identification S ervice ( NIS ) Confirming Diagnosis Designate ( CDD ) Emergency and Domestic Programs ( EDP ) and Regional Program Manager ( RPM ). Their names and functions are listed in Appendix B. Each state has its growers, pest advisors or other sample submitting entities to collect and submit samples to a triage lab designated to receive and examine suspect

PAGE 90

90 samples. After the triage lab receives the sample, the following procedure is followed according to the NPDN SOP ( National Plant Diagnostic Network 2008). The triage lab's diagnostician would examine the sample. If the sample is determined to be of suspect regulatory significance, then the triage lab would send this presumptive positive sample to the NPDN Regional Hub Lab or CDD according to the requirement and notify the related staffs/labs of the presumptive positive sample being in the system. Once the NPDN Regional Hub Lab receives a presumptive positive sample, the diagnostician of the lab would examine the sample with or without the collaboration of a Local Expert, and then send the sample to the CDD according to the requirement The CDD conducts a confirming diagnosis of the received presumptive positive sample. After a confirmed result is released, a ll other interested organizations are informed of i t by designated organizations in the following order : CDD first informs the NIS of a confirmed diagnostic result. Then NIS emails the result to the EDP staff. The EDP staff forwards the result to the appropriate APHIS PPQ headquarters and RPMs, the state o f origin SPHD and the SPRO After the RPM gets the confirmed result, he/she contacts the SPHD and SPRO to determine who will contact the triage lab with the result. The SPHD or SPRO contacts the triage lab with the result accordingly The triage lab should also ac knowledge to related labs the receipt of the result and contact the Campus Safety Officer and the regional Hub Lab if it is engaged. At the same time, after the regional director gets the result, he/she contacts the regional directors in other regi ons with the confirmed result if engaged. Each organization/lab/office is a network site in ETKnet2.0. It defines its own events, operations, rules, processes and triggers to be processed at its network site.

PAGE 91

91 Figure s 6.1 6.9 show the rules, operations an d processes defined by various organizations/labs/offices needed to implement the SOP. The defined operations, rules and processes are translated into program code and packaged as Web services using the methods explained in Chapter 3. The program code of t hese Web services resides at the network sites where operations, rules and processes are defined. The meta data of shared operations, rules, and processes are registered with the private registry installed at the Host site. In order to implement the NPDN SOP using our language, IRPSL, we also define npdn.Sample (simply called Sample in the remainder of this chapter) is used to describe a sample in the system. The attribute combination ( localLabSampleID, labID, sampleDate ) is the unique identifier of a sample instance The entity npdn.Result (Result) is used to describe the diagnosis result of a unique sample. The entity NPDN.Pac k ingRequirement ( Pack ingRequirement ) is the packing requirement for a sample that will be shipped to another lab. The SOP has different packing requirement s for plant samples and insect samples. The entity npdn.Shipment ( Shipment ) denotes the shipping resu lt of a sample that is sent to another lab to do further diagnostics. The entity npdn.ResponsePlan ( ResponsePlan ) is used to describe the response information that SPRO and SPHD should have if the presumptive positive sample in the system is confirmed to b e positive The entity npdn.General includes all the program variables that are used to save the value s generated by operations or rules during the ir execution. The detailed specifications of these entities are given in Appendix B.

PAGE 92

92 In the following sectio ns, we explain the operations, rules and processes defined for implementing the SOP. We will not explain the details of operations here due to space limitations. Basically, an automated operation is the Java code that performs a specific task such as query ing the database, assigning values to data items, or invoking a Web Service. A manual operation is implemented by sending an email notification to persons who play a specific role(s) that is suited to perform the task. After the completion of a manual oper ation, the person who committed to perform the task should log in to ETKnet2.0 to indicate the task's completion and provide the data produced in the task. 6.1.1 Operations, Rules and Processes NPDN Triage Lab Once the Triage Lab receives a new suspected sample, an automated operation named configuration information, including the lab id, and whether the lab has the distant diagnosis capability. The sample is then examined by the manual operation to be done. The procedure terminates after storing the sample by the manual operation Store_Sampple() Inform_Termination() Otherwise, the operation asks the staff to store the sample in a secure location. After the sample has been examined, its status will be changed accordingly as specified in derivation rule1 The guides the staff to inform other related organizations of the fact that a presumptive positive sample is in the system. The above two rules are shown in

PAGE 93

93 Figure 6 1. If it is appropriate to conduct the distant diagnosis to the sample then the CA rule TriageLabCARule 4 carry out different operations ac cording to whether the lab has the distant diagnostic capability. The packing and shipping requirement and procedure are specified in the rule 6 Finally, the manual operation Inform_Campus_Safety_Office TriageLabCARule7 n otifies the triage lab staff to contact the Campus Safety Officer to inform him/her of the presumptive positive TriageLabDR6 TriageLabDR7 status accordingly after the Triage Lab ships the sample to the next lab. The details of these rules are shown in Figure 6 2 Once the triage lab receives the message on the confirmed diagnostic result of the suspect ed sample, it first acknowledges to the related organizations that it has received the result, and also notifies the Regional Hub Lab, if it is involved and has not been informed, of this confirmed result TriageLabCARule8 If a portion of sample was retained in the lab, then rule Rule9 guides the triage lab staff to deal with the TriageLabCARule10 a record to NPDN databases at state, regional and national level. The above rules are shown in Figure 6 3. SPRO Once the SPRO is informed that a suspected sample is in the system he/she contacts the SPHD to discuss plans and prepare for a response. This is expressed by the rule shown in Figure 6 4 Once the SPRO gets the confirmed diagnostic result, he/she conducts the manual operations

PAGE 94

94 SPRO_Discuss_GrowerSubmitter_Notification_Process_With_SPHD() to inform other organizations of the confirmed triage lab_gets_result is described in the rule SPROCARule3 shown in Figure 6 4 SPHD Once the SPHD is informed of a suspected sample in the system, he/she performs the manual operation SPHD_Contact_ARD_Of_Presumptive_Sample() inform related organizations of the presumptive positive sample in the system. This SPHDCARule1 6 5 Once SPHD gets the result, if he/she is the person who has been determined to be the one to contact the triage lab about the result, then he/she performs the operation SPHD_Inform_TriageLab_Of_Result() triagelab_gets_result created with true as its value. The above procedure is describe d in the rule SPHDCA Rule2 shown in Figure 6 5 NPDN Regional Hub Lab Once the Regional Hub Lab receives a suspected sample from Triage Lab, the procedure that needs to be carried out is specified by the HubLabCA Rule1 HubLabCA Rule 3 HubLabCA Rule 4 6 6 I t first performs a diagnosis of the sample ( ) with the assistance of a local expert ( ). It then informs the related organizations of the preliminary result to dete rmine if it is necessary to conduct a further diagnosis. This is done by a manual operation Contact_Director_CDD_with_preConclusion() HubLabCARule3 procedure that needs to be carried out, if it is necessary to conduct a further diagnosis

PAGE 95

95 The first four derivation rules are used to determine the packing and shipping requirements, which are needed Packing_Sample() Shipping_Sample() HubLabCARule4 carried out, if it is not necessary to conduct a further diagnosis. It sets the status of the sample to "confirmed" and the triage lab is informed by a manual operation. Once the Regional Hub Lab receives the confirmed result, the process that needs to be carried out is spe HubLabCA Rule2 Figure 6 6): The Hub Lab first informs its own retained sample, submits Form4, which is a r eport o n the i dentification of a s elect a gent or t oxin in a c linical or d ia gnostic l aboratory if necessary, and then informs its own Campus Safety Officer of the result. NPDN Regional Director Once the NPDN Regional Director is informed of a presumptive positive sample in the system, as described in the rules RegionalDirectorC ARule1 RegionalDirectorCARule 2 RegionalDirectorCARule5 RegionalDirectorCARule 3 7 he/she forwards the message to the NPDN Program Leader, and gets instructions on whether to inform other regional directors and other labs. If the confirmation will take more than 7 days or it is deemed appropriate to contact other regional directors, the NPDN Regional Director would inform other regional directors of the presumptive positive sample in the system. Once the NPDN Regional Director knows the confirmed result he/ she first informs the Program Leader of the result, and, if deemed appropriate, also contacts other regional directors with the confirmed result. This procedure is specified in the rule RegionalDirectorCARule4 re 6 7

PAGE 96

96 CDD 8 describes the process where, once the CDD receives the suspected sample, it acknowledges the receipt of the sample to the sender, and informs the sender of the approximate expected date and time to receive the CDD conducts the diagnostic procedure on the sample and makes the confirming diagnosis n instance of the entity Result.* is cr eated by an assignment operation Once CDD gets the confirmed result, it informs the NIS of the result, and a new data item NIS_gets_result CDDCARule 3 NIS Once the NIS gets the confirmed result, it emails the EDP with the result, and a new data item EDP_gets_result with true as its value, is created by the rule shown in Figure 6 9 EDP Once the EDP gets the confirmed result, it forwards the confirmation to the appropriate labs according to wh ether the diagnosis result is new to the US, and whether it is significant or not. New data items RPM_gets_result Regional_Director_in_StateOfOrigin_gets_result SPHD_gets_result and SPRO_gets_result are created. All these new data items will have the va lue true. The above process is described in the rule shown in Figure 6 9 RPM Once the RPM gets the confirmed result, it first contacts the regional director to discuss diagnostic needs and capabilities and then contacts SPHD and SPRO to det ermine who will contact the triage lab about the result. A new data item triagelab_notifier will be produced by the manual operation

PAGE 97

97 RPM_Co n tact_SPRO_SPHD() shown in Figure 6 9 6.1.2 Ev e nt and Met a rules A sample from a sample submitter) is defined at the Triage lab site. The event data include d in this event is an instance of the entity Sample The event is posted when the Tria ge Lab receives a new suspected sample from a sample submitter. M eta rules defined for this event are shown in Table 6 1. The enforcement of NPDN's SOP requires the close communication, coordination and collaboration of many organizations/labs/offices at t he local, state, regional, and national levels. In this section, we have shown that the SOP can be implemented in terms of sharable distributed data, events, rules, processes, manual and automated operations, triggers and meta rules specified by these coll aborating organizations/labs/offices. In the next section, we shall explain how these distributed data, rules, processes and operations can interoperate upon the occurrences of events and how inter organizational processes are dynamically formed and proces sed. 6.2 A Scenario on Dynamic Construction and Processing of Inter organizational Collaboration We use a scenario that exercises a part of the SOP as an example to explain our meta rule enhanced, event triggered, distributed rule processing and process enactment technique The scenario and its steps are shown in Figure 6 10 The rules and meta rules that correspond to these steps are shown in Figures 6 1 6 9 and Table 6 1 The scenario begins with the Triage Lab receiving a new suspected plant sample f rom a sample submitter. Once the Triage Lab receives a new suspected sample, the

PAGE 98

98 a sample submitter). The occurrence of the event causes the event data (denoted by ED1 in Figure 6 10 ) that contains an instance of entity Sample which is sent to the Host rule the NPDN Triage Lab, which serves as the coordinator of this event instance. The coordinator receives applicable sites and applicable rules information, and sends the event data to the ap items will be will also be updated. Let us means that the sample needs further diagnosis by other labs such as NPDN Regional Hub Lab and/or CDD, and the value of the attribute sample.classification Since there have been new data added/updated, the coordinator sends the new version of the event data ED2 to the Host to check whether there are other rules that need to be processed. After the syntactic and semantic matching process and checking of the meta rule TriagelabCARule

PAGE 99

99 presumptive positive sample information and reporting whether it is appropriate to conduct a distant diagnosis no w. In this scenario, let us assume that it is appropriate to conduct a distant diagnosis and that this lab also has distant diagnosis capability. That is, the data item is_distant_diagnosis_appropriate has_distant_diagnosis_capability Similarly, the coordinator sends the new version of the event data, i.e. ED3 in Figure 6 10, to the Host site to start the third round of event notification and rule processing. In the th ird determined to be applicable after the syntactic and semantic matching processes at the Host site be processed sequentially as required by the meta nt data back to the coordinator. In the mean time, the Triage Lab processes its applicable sequentially and send s the updated event data back to the coordinator Let us assume that Hub Lab is the next lab that will conduct a diagnosis on the sample. That is, the

PAGE 100

100 next_sampler_receiver e site, and it updates the value of the attribute sample.status adding/updating an y event data items. Since there are new added/updated event data, the coordinator sends the new version of the event data, i.e. ED5, to the Host to start the fifth round of event notification and rule processing. In this round, the Host determines that and semantic matching processes and applying meta further examin ing the sample with a local expert, and determining whether the sample needs to be diagnosis by the CDD Lab. The rule produces several event data items, including an instance of the entity Shipment is_further_diagnosis_necessary Let us assume that the Hub Lab has come to the confirmed diagnostic result to the sample, which means that the data item is_further_diagnosis_necessary added/updated event data back to the coordinator. Th e coordinator sends the latest version of the event data, i.e. ED6, to the Host again since there are new added event data items. In this round, the Host determines

PAGE 101

101 the ap status entity Result hublab_gets_result tria gelab_gets_result The seventh round of processing will take place because there are new data created in the previous round In this round, the Host constructs a processing graph as shown in Figure 6 rules. The fini site After the coo rdinator receives the returned event data from the Hub Lab site and the Triage Lab site, it sends the new version of event data to the Host again. The Host determines that there are no more applicable rules. The rule processing triggered by the occurrence of the TriageLabE1 10 shows the event data, the executed rules, and the interaction between involving organizations/labs in this scenario. The above scenario and its processing show that, in ETKnet2.0, an event oc curs at one site would trigger the processing of distributed rules defined by collaborating organizations/labs/offices. A CA rule can conditionally or unconditionally enact an

PAGE 102

102 organizational process, which can activate the rules and manual and/or automated operations that define it. The processing of rules and operations may produce data or alter the event data, which in turn trigger more applicable rules. Meta rules are interpreted at runtime to process the applicable rules in a desirable order/structure. Through the multiple rounds of event data transmission, rule processing, and process enactment, the sharable event data, operations, rules and processes defined by different organizations/labs/offices can interoperate to produce the data needed for inter o rganizational collaboration and coordination Thus, an inter organizational process is dynamically constructed and enacted at runtime rather than pre defined at build time by a process designer. This rule processing and process enactment technique would a llow collaborating organizations to change their rules, processes, operations and meta rules at any time as their operating conditions or policies require, and the changes would be reflected instantaneously in the subsequently formed inter organizational p rocesses. In C hapter 7 we will provide another example taken from the business domain to explain and demonstrate the utility of our integrated rule and process specification language and distributed rule processing and process enactment technique. Tab le 6 1. Meta rules related to the global event TriageLabE1 Organization Meta rules SPRO Prerequisite(TriageLabCARule2, SPROCARule1); Prerequisite(EDPCARule1, SPROCARule2); Prerequisite(EDPCARule1, SPROCARule3); Onetime(SPROCARule1, SPROCARule2, SPROCARule 3); SPHD Prerequisite(TriageLabCARule2, SPHDCARule1); Prerequisite(EDPCARule1, SPHDCARule2); Onetime(SPHDCARule1, SPHDCARule2);

PAGE 103

103 Tab le 6 1. Continued Organization Meta rules NPDN Triage Lab Prerequisite(TriageLabCARule1, TriageLabCARule2); Prerequisit e(TriageLabCARule2, TriageLabCARule3); Prerequisite(TriageLabCARule2, TriageLabCARule4); Prerequisite(TriageLabCARule2, TriageLabCARule5); Prerequisite(TriageLabCARule6, TriageLabCARule7); Prerequisite(Or(SPROCARule3, SPHDCARule2, HubLabCARule4), TriageLab CARule8); Prerequisite(And(TriageLabCARule8, TriageLabCARule9), TriageLabCARule10); Prerequisite(Or(TriageLabCARule3, TriageLabCARule4, TriageLabCARule5), TriageLabCARule6) ); Onetime(TriageLabCARule1, TriageLabCARule2, TriageLabCARule3, TriageLabCARule4, TriageLabCARule5, TriageLabCARule6, TriageLabCARule7 TriageLabCARule8, TriageLabCARule9, TriageLabCARule10); NPDN Regional Hub Lab Prerequisite(TriageLabCARule6, HubLabCARule1); Prerequisite(HubLabCARule1, HubLabCARule3); Prerequisite(HubLabCARule1, Hub LabCARule4); Prerequisite(TriageLabCARule8, HubLabCARule2); Onetime(HubLabCARule1, HubLabCARule3, HubLabCARule4, HubLabCARule2); NPDN Regional Director Prerequisite(TriageLabCARule2 ,RegionalDirectorCARule1); Prerequisite(Or(RegionalDirectorCARule2, Regi onalDirectorCARule5), RegionalDirectorCARule3); Prerequisite(EDPCARule1, RegionalDirectorCARule4); If (RegionalDirectorCARule2) then Suppress (RegionalDirectorCARule5); If (RegionalDirectorCARule5) then Suppress (RegionalDirectorCARule2); Onetime(RegionalD irectorCARule1, RegionalDirectorCARule2, RegionalDirectorCARule3, RegionalDirectorCARule4); CDD Prerequisite(CDDCARule1, CDDCARule2); Prerequisite(CDDCARule2, CDDCARule3) Onetime(CDDCARule1, CDDCARule2, CDDCARule3); b NIS Prerequisite(CDDCARule3, NISCARu le1); Onetime(NISCARule1) ; EDP Prerequisite(NISCARule1, EDPCARule1); Onetime(EDPCARule1) ; RPM Prerequisite(EDPCARule1, RPMCARule1); Onetime(RPMCARule1) ;

PAGE 104

104 Figure 6 1. NPDN Triage Lab rules on receiving a new sample (1) Figure 6 2 NPDN Triage Lab rules on receiving a new sample (2)

PAGE 105

105 Figure 6 3 NPDN Triage Lab rules on receiving the confirmed result. Figure 6 4 SPRO rules on being informe d of a presumptive positive sample in the system and the confirmed result. Figure 6 5 SPHD rules on being informed of the confirmed result.

PAGE 106

106 Figure 6 6 NPDN Regional Hub Lab rules on receiving a presumptive positive sample and being informed of the confirmed result.

PAGE 107

107 Figure 6 7 NPDN Regional Director rules on being informed of 1) a presumptive positive sample in the system, 2) the estimation that the confirmation may take more than 7 days and 3) the confirmed result. Figure 6 8 APHIS PPA CDD rules on the receipt of a presumptive positive sample, and the release of the confirmed result

PAGE 108

108 Figure 6 9 NIS, EDP an d RPM rules on receiving the confirmed result. Figure 6 10 Part of event data transmission, rule processing and process enactment in the NPDN Domain (the Host site is not shown here).

PAGE 109

109 Figure 6 11. The processing graph generated by the Host in the seventh round

PAGE 110

110 CHAPTER 7 CASE STUDY 2: AN EXAMPLE SCENAR IO IN THE E BUSINESS DOMAIN In this chapter, we use an e business scenario to demonstrate the utility of the developed technology in achieving inte roperation of sharable business data, operations, rules and processes, and the dynamic construction and processing of inter organizational processes. In the scenario, we assume that retailers and suppliers (i.e., distributors and/or manufacturers) of a cer tain category of products form a collaborative federation in order to achieve their business goals. They all register with our system, ETKnet2.0, as members of the federation. As members, they can publish their products and services and subscribe to events to receive event data when events occur. Any member can join or leave a federation, and can define, delete, and modify events, business rules and processes at any time, thus forming a very dynamic, collaborative business environment, and the partnership m ay change over time. It is a good example for demonstrating that our system can function well in such a dynamic environment. This part of the work is included in the published journal paper (Xiao, DePree and Su, 2011). In this scenario, the retailer receiv es an order online from a customer. The order specifies a certain quantity of a product that the customer wants to purchase. After receiving the order, the retailer first check her inventory to see whether she can fulfill the order. If yes, she then proces ses the order to carry out the usual interaction with the customer to make the sale; otherwise, she will get the product from her partners, i.e. suppliers who have joined the collaborative federation, to fulfill this order. Since retailers and suppliers ca n join or leave the federation at any time, the available suppliers may change over time. The retailer who receives the order can just post a global event to

PAGE 111

111 query all available suppliers for a certain product. The suppliers can respond to the query with their supply. Then the retailer can make a decision as to which supplier will fulfill the order. The order received from a customer specifies a certain quantity of a product that the customer wants to purchase and some information about the customer. Recei ving ReceivingOnlineOrderEvent the retailer site. The event data contain an entity CustomerOrder Request ( ID, productId, quantity ) and an entity CustomerInfo ( ) The retailer define s a trigger to link the event with one of her action oriented rules named OnlineOrderProcessingRule OnlineOrderProcessingRule site to pr ocess this online order. The action part of this rule specifies a process named InventoryCheck ingRule inv entory to get the available quantity of a given product according to her inventory policy. In the following Or Split structure, if the quantity ordered by the customer can be FulfillOnlineOrderByOwnInventory Rule will not be explained in this scenario, is processed to carry out the usual interaction with the FulfillOnlineOrderWithPartners Rule shown in Figure 7 1 is processed to fulfill the order with the help of coll aborating suppliers.

PAGE 112

112 FulfillOnlineOrderWithPartners Process un its of the product should be ordered from suppliers based on the quantity the retailer a Quote Request The event is posted synchronously. The retailer site waits for responses from collaborating business partners within a specified time interval enforced by a timeout mechanism. The event data contain the following entities: QuoteRequest (ID, ProductId, UnitsRequested), RetailerInfo (Name, QuoteResponse (ID, ProductId, UnitsOffered, UnitPrice, PaymentOptions), and Shipping (ShippingOption, Pric e). Here, the first two entities specify what the retailer wants the suppliers to know, and the last three entities specify what responses the retailer expects from the suppliers. Some suppliers may have subscribed to this event by explicitly defining tri ggers that link the event to their business rules. They also can specify the condition when their business rules can be processed through the conditional part of the trigger. For example, they can specify that they only want to process the quotation reques t whose required units are more than or less than a certain amount. These suppliers are most likely the suppliers that do business with the retailer regularly. Other suppliers may not have subscribed to the event but may have rules that can be processed to QuoteRequestEvent" Both types of suppliers should receive the event notification and their rules and processes should be executed. Since

PAGE 113

113 members of a federation can join and leave the federation freely, some retailers and suppliers may not know one another and may not have explicitly defined triggers to link the events defined by other members to their rules. The ability to send event notifications and event data to implicit subscribers (i.e., those that have applicable rules as dete rmined by the system) in addition to explicit subscribers is a key feature of our system. Such a feature is important and useful for achieving dynamic construction and enactment of inter organizational business processes. Continuing our scenario, all the and event data would activate their applicable rules. For example, a rule at one site may activate a structure of operations. The first operation checks her inventory to determine if the units of the pro duct requested by the retailer are available. If not, the retailer is informed of this fact. Otherwise, an inventory policy rule is activated to determine how many units of the product should be offered to the retailer so that her own inventory will not dr op below a certain level. SupplierInfo (SupplierName, Quot eResponse (ProductId, UnitsOffered, UnitPrice, PaymentOptions), and Shipping (ShippingOption, Price). Upon the receipt of the data from the suppliers, the retailer site would merge these data with the original event data to produce a new version of the event data. This merge o processing and process enactment. The retailer has a rule named QuoteRequestEventPostprocessingRule

PAGE 114

1 14 Quot eRequestEvent" to the rule. After merging the event data received from the supplier sites, the Rule Server at the retailer site would automatically QuoteRequestEventPostp rocessingRule data. The invoked rule is an action oriented rule whose action clause invokes a process. The first rule in this process would examine the data returned from the suppliers and select a subset of suppliers who have responded to the positively. This selection may be based on a number of selection criteria such as the timeliness of product delivery, etc. The next rule unconditionally performs a number of operations. Th e first operation would check if the units of the product offered by the selected suppliers meet the needs of the retailer. This is done by reducing the value of the attribute QuoteRequest .UnitsRequested given in the original QuoteRequest instance based on the units provided by the selected suppliers. The next operation checks if the value of said attribute has been reduced to zero. If it has not been, the supplier provided data are removed from the current version of the event data to produce another versi on of the event data, and the new version is sent to new suppliers who may have joined the federation since the last round of event notification and rule processing, and who have either subscribed to the event or defined some applicable rules. It is possib le that some suppliers who have responded to this event instance before would receive the new version of event data because their rules are applicable to this new version. If these suppliers do not want to respond to the same quote request more than once, rules to prevent their rules from being executed more than once for the same event instance, or they can add a

PAGE 115

115 condition to their rules to prevent the processing of those quote requests whose IDs are already in their d atabases. As in the first round, any suppliers who can provide some units of the product can respond positively to the retailer. This procedure may repeat until the retailer gets all the units she needs, or when no new suppliers can be found, or the time s et by the retailer for this request has expired. The automatic operation getQuoteResult() following the event posting operation can further process the received updated event data to create an instance of the entity units responded by suppliers. If the required units of the product have been found (checked by a switched construct followed by the operation getQuoteResult as shown in Figure 7 1), the following sequence of operations is performed: calculate the total pr shipping charges of the selected suppliers, and charge the customer for the product he/she ordered. The next operation, na med CompletePurchaseOrderWithPartners in Figure 7 number of units ordered from the supplier and other pertinent information, and posts a Purchas ing Order RequestEve for each of the selected suppliers Even though all the suppliers might have subscribed to the event, only those selected suppliers will be notified by using the restricted event notification mechanism in the ETKnet2.0 system. The event data transferr ed would contain the following added information: Purchas ing Order (ProductId, SupplierName, UnitsOrdered, ) and

PAGE 116

116 The receipt of the event data at process the received purchase order. Let us consider a possible rule named Purchas ing OrderProcessingRule Figure 7 2), Purchas ing Order ProcessingProcess updates the inventory of the product being ordered based on the units requested by the retailer. The second rule (a derivation rule) checks if the remaining inventory amount drops below 10% of the quota set by Supplier C. If so, a CA rule following it would alert the supplier and ask her to restock the product. Another rule, ing Order Rule which can be processed in parallel with the derivation rule described above, is carried out to fulfill the purchase o rder. This rule has a structure of operations. Two parallel operations are executed first. One would send a message to the person who is in charge of doing the packaging and shipping to carry out the manual operation. The other one is to charge the retaile r. The next operation, the successor of an AND Join construct, would send the information such as the shipping date, shipping company name, tracking number, etc. to the retailer. After receiving the shipping information from the suppliers, the retailer si te would forward all this information to the customer. This ends the example scenario. Figure 7 3 shows the interactions between the retailer and the suppliers to complete an online order. In this scenario, retailers and suppliers define their business ru les and processes independently. By using the event triggered, distributed rule processing and process enactment technique implemented in ETKnet2.0, the retailer is able to complete a purchase order with the help of partners without having to pre specify t he partnership

PAGE 117

117 with these suppliers. The interactions between the retailer and suppliers form an inter organizational process that is dynamically constructed. The scenario demonstrates the key features of our system and its potential application in the e b usiness domain. Figure 7 1. fulfilling an online order with the help of partners.

PAGE 118

118 Figure 7 2.

PAGE 119

119 Figure 7 3. The interactions between the retailer and its suppliers to completing an online order.

PAGE 120

120 CHAPTER 8 CONCLUSION AND FUTUR E WORK W e have po inted out the need and importance for collaborating organizations to share not only data and computing resources, but also their policies, constraints regulations and processes. We also stressed the need for a network infrastructure and a distributed proc essing technique to enable the interoperation of these resources, and the dynamic construction and enactment of inter organizational processes in order to achieve inter organizational collaboration and coordination. To meet these needs, we have developed i n this work an integrated rule and process specification language to enable collaborating organizations to define events of common interest organizational policies, constraints, regulations, and all sorts of human and organizational knowledge in terms of three different kinds of knowledge rules, and organizational and inter organizational processes in terms of structures of operations and knowledge rules. Algorithms have been developed to translate each rule or process into Java code and wrap it as a Web Service All the sharable Web Services are registered with the W eb S ervice Registry for their discovery and sharing. A distributed network system, ETKnet2.0, has been implemented. It uses a meta rule enhanced, event triggered distributed rule processing and process enactment technique to achieve 1) the interoperation of sharable data, rules, manual and automated operations and workflow processes, and 2) the dynamic construction and processing of inter organizational processes. To demonstrate the utility o f the integrated language, the distributed rule processing and process enactment technique and the implemented network system, we have used them to successfully implement and demonstrate the Standard Operating Procedure developed by National Plant Diagnost ics Network of USDA. We have also

PAGE 121

121 applied the R&D results in the area of e business to demonstrate their general application and thus their broad impact. We believe that our R&D results are important for the following reasons: First, unlike the existing w orks that use different specification languages to define different types of rules and workflow processes, this work uses an integrated specification language to define them. The language presented in Chapter 3 provides the facilities for specifying logic derivation rules, action oriented rules and integrity constraint rules, as well as the facility for defining workflow processes in terms of structures of, not only manual and automated operations like in a traditional workflow management system, but also d ifferent types of knowledge rules. The defined rules and processes are automatically translated and deployed as Web services. Since rules and processes can be specified by using the same language and processed uniformly as Web services in our system, dist ributed rules and processes can easily interoperate. Furthermore, there is no need to use multiple rule engines and a workflow management system or a business process execution system to manage and process them. This work provides a new way to combine busi ness process modeling and business rule specification and a new way to achieve the interoperation and uniform processing of distributed rules and processes. Second, h igh level specifications of events, knowledge rules, processes and meta rules are easier f or collaborating organizations to understand, modify and use. O rganizations do not have to write application code to implement them. The automatic translation of three different types of rules and processes into Web services allow s them to be discovered a nd shared in a Web service infrastructure just like other Web services.

PAGE 122

122 This approach makes the business rules and processes independently defined by organizations sharable and reusable. Third, the architecture of ETKnet2.0 presented in Chapter 4 is highl y scalable. As more and more organizations join a collaborative federation, the software components of ETKnet2.0 can be replicated and installed at the new members' network sites. The execution of distributed rules and organizational processes are carried out in parallel. Thus, as the number of organizations, rules and processes grow, the computational power grows. Since different events can occur at different sites, these sites will serve as the coordinators of the corresponding events to manage different sessions of rule processing and process enactment. Thus, no single site will be overburdened. In the present version of ETKnet2.0, there is a single host to, among other tasks, manage the registered events, rules and processes defined by all organizations. If it becomes a bottleneck, it is possible to establish multiple hosts to share the management and processing load (e.g., each manages a subset of events and their corresponding rules, processes and meta rules). The multiple hosts would communicate with o ne another to determine, for example, a set of global rules that are applicable to an event instance. Fourth, unlike most of the traditional workflow or process management systems, in which inter organizational processes are pre defined, this work provi des a new way to achieve the dynamic construction and processing of inter organizational processes. The event triggered, distributed rule processing and process enactment technique presented in Chapter 4 ensures that all applicable business rules and pre d efined organizational and inter organizational processes are executed to produce useful data needed for inter organizational collaboration and coordination. Multiple rounds of distributed

PAGE 123

123 processing of rules and processes constitute an inter organizational process that is dynamically constructed and processed. Fifth, the use of meta rules at runtime (presented in Chapter 6) to suppress the processing of some applicable rules, structure the applicable rules, and/or resolve conflicting rules based on organiz ations' priorities provides a dynamic way to tailor an inter organizational process to meet the changing needs and partnership of collaborating organizations. Sixth, the implemented and demonstrated ETKnet2.0 is a very general system and has many applica tions. As shown in Chapters 6 and 7, it can be applied in both e government and e business domains. We believe that it can be used to facilitate, not only the collaboration among business and government organizations in different environments, but also amo ng people who undertake tasks of common interest such as scientists who collaborate in a research project or experiment, or students who collaborate in a joint project (e.g., DePree, Su and Xiao, 2009) Our R&D results can have a broader impact than what has been presented in this dissertation. There are several R&D issues that are out of the scope of this research and are worthwhile for future investigation. One is security in our network system. During the event triggered rule processing and process en actment we send all the event data to all the subscriber sites and the sites that have applicable rules However, some of the event data should only be seen by some and not all of the sites due to security or privacy reasons. Hence, it is necessary for co llaborating organizations to negotiate and establish some kind of trust and security policies to be enforced during a collaboration and knowledge sharing

PAGE 124

124 session. Also, in our current system, we assume that all global rules and processes defined by collabo rating organizations can be used by all organizations. It is possible in some cases that they can be used only by some but not others. Although we believe that security and trust policies as well as access control to event data, business rules and processe s can all be specified in terms of three types of rules that our system can process and enforce, this issue needs further investigation. The second issue that we have not dealt with is t ransaction management in our c urrent system. In our system, each dis tributed rule processing and process enactment session triggered by an event instance forms a transaction. We have not dealt with the problem of transaction recovery when software or hardware problems occur. The traditional ACID properties of a transaction may not be applicable. For example, a business process that includes manual operations can last a long time. If we treat the multiple rounds of rule processing and process enactment that are triggered by an event instance as a transaction, and apply a loc king mechanism, it will require locking resources for a long period of time. What is more, the conventional transaction rollback mechanism may not be desirable for our system. Consider the following case: if a collaborating site aborts for some reason, it may not be desirable to rollback the data generated in the session because the data generated by a subset of applicable rules may still contain information that is valuable to collaborating organizations. We need to examine and possibly extend the conventi onal ACID enforcement mechanism. The third issue is about the efficiency of rule management at the Host site. In the current version, the specifications of rules defined by different organizations are registered with the Host. These rules are organized by the organizations that define

PAGE 125

125 them. As more and more organizations participate in a collaborative federation, the number of sharable rules will continue to grow. For efficiency reasons, it can be beneficial to organize these rules based on some added seman tic descriptions such as their functionalities, behaviors and/or the categories of organizations in an application domain. For example, rules defined by different organizations but serving a similar function can be grouped together as a rule group. The de termination of the applicability of rules can then take the functionalities of rule groups into consideration, and select the group of rules whose functionality matches with the needs of an event instance, rather than simply include syntactic and semantic matches between their input data items and event data. This will avoid the need to perform the matching on all the registered rules. Furthermore, we can also extend our meta rule specification to include meta rules that specify constraints, not only on the processing of specific rules, but also on the processing of rule groups. For example, we can define a meta rule which constrains processing of a rule group that is useful for completing an order instead of using many meta rules to specify the precedence of individual rules.

PAGE 126

126 APPENDIX A THE XML SCHEMA OF IR PS, META RULES AND EVENT DATA The XML schemas for different types of rules, processes, meta rules and event data are listed here. 1. The xml schema of integrity rules, derivation rules and action oriented rule.

PAGE 127

127


PAGE 128

128


PAGE 129

129


PAGE 130

130


PAGE 131

131 < /xs:element> < xs:sequence>

PAGE 132

132
< xs:complexType>


PAGE 133

133
2. The xml schema of Process Schema for Process specification. 05/29/2010 This is the root element for a proce ss

PAGE 134

134
< /xs:complexType>


PAGE 135

135


PAGE 136

136

PAGE 137

137


PAGE 138

138 unique identifier of the object

PAGE 139

139


PAGE 140

140 3. The xml schema of meta rule Specification of one or more meta rules Specification of one meta rules

PAGE 141

141


PAGE 142

142


PAGE 143

143
4. The schema of EventData

PAGE 144

144
< xsd:element name="Name" type="xsd:string"/> < xsd:extension base="xsd:string">


PAGE 145

145 APPENDIX B THE DEFINITION OF OR GANIZATIONS AND ENTI TIES USED IN NPDN SO P There are several categories of organizations/labs/offices involved in the operation of SOP. Their names and functions are listed below: T riage Lab. The state facility designated to receive and examine suspect samples. This lab is a Land Grant University Lab, State department of Agriculture lab or University Experiment Station Lab. In some states, more than one type of triage lab may exist a nd be a member of the NPDN. NPDN Regional Hub Lab The key coordinating lab for an NPDN region. These labs provide coordination, training, funding, and surge capacity support to the NPDN triage labs within their regions and occasionally to other regions. E xpert Lab A lab which has been approved or provisionally approved by the Animal and Plant Health Inspection Service, Plant Protection and Quarantine (APHIS PPQ) to conduct a specific diagnostic test. The diagnosticians of this type of lab receive addition al training from APHIS PPQ diagnostician and the labs are equipped to handle surge overflow from triage labs. SPRO The State Plant Regulatory Official. The h ighest ranking state plant regulatory official. SPRO is employed by the S tate D epartment of A gricu lture. SPHD. The APHIS PPQ State Plant Health Director. The h ighest ranking federal plant regulatory official in a state. NIS The APHIS PPQ National Identification Service. The USDA authorized lab for diagnosing plant diseases (fungal and viral) This lab also coordinates insect diagnosis with the Systematic Entomology Laboratory, Communication and Taxonomic Services Unit ( USDA ARS SEL CTSU ) for triage and hub labs. CDD. The APHIS PPQ Confirming Diagnosis Designate The person is authorized to make a confi rming diagnosis for a high risk pest. This diagnosis must withstand legal scrutiny if challenged in court. It may be one of the APHIS PPQ labs (NIS or the Center for Plant Health, Science and Technology ( CPHST ) in Beltsville, MD or may be one that has bee n approved or provisionally approved by APHIS PPQ or APHIS CPHST. EDP The APHIS PPQ Emergency and Domestic Programs RPM : The Regional Program Manager There are a few data entities used in the SOP implementation. The entity npdn.Sample (Sample) is used to describe a sample in the system. It contains the

PAGE 146

146 following attributes. As the diagnosis proceeds, these attributes get assigned appropriate values. The tuple ( localLabSampleID, labID, sampleDate ) is the unique identifier of a sample instance localLabSamp leID of type string. It is the sample index in a local lab, which is the triage lab that receives the sample. labId of type string. It is the lab Id of the triage lab. sampleDate of type date. The date when the sample is collected. sampleType of type strin stateOfOrigin of type string. It is the state where the sample is collected. The entity npdn.Result (Result) is used to describe the result of a diagnosis to a unique sample. It contains the following attr ibutes. The ( localLabSampleID, labID, sampleDate ) is used to identify a result record. localLabSampleID of type string. It has the same value as that of the corresponding sample. labId of type string. It has the same value as that of the corresponding sam ple. sampleDate of type date. It has the same value as that of the corresponding sample and stateOfOrigin of type string. It is the state where the sample is collected. The entity npdn.Ship ment ( Ship ment ) contains the following attributes. sender of type string It is the s ender of this shipment

PAGE 147

147 receiver of type string It is the receiver of this shipment. trackingNumber of type string It is the tracking number of this shipment if has. timeOfDelivery of type date The date when the shipment happens. methodOfDelivery of ty pe string It is the method used for this shipment. properlyPackaged of type b oolean It is used to indicate whether the sample included is packaged properly according to the sample type. submissionFormIncluded of type b oolean It is used to indicate whet her the required submission form is included in this package. businessCardIncluded of type b oolean It is used to indicate whether the required business card is included in this package. notification of type string. It is used to indicate who should be notified for this shipment. The entity NPDN.Packing Requirement ( Packing Requirement ) is the packing requirement for a sample that will be shipped to another lab. SOP has different packing requirement to plant samples and insect samples. sealed_in_a_sturdybox of type b oolean It is used to indicate whether the sample should be sealed in a study box. vial of type b oolean It is used to indicate whether the sample should be packed in a vial. in_appropriate_crush_proof of type boolean. It is used to indicate whether the sample should be packed in crush proof. double bag of type boolean. It is used to indicate whether the sample should be packed in a double bag. mark of type string. It is additi onal note for the packing requirement.

PAGE 148

148 The entity NPDN.ResponsePlan (ResponsePlan) is used to describe the response information that SPRO and SPHD should have if the presumptive positive sample in the system is confirmed to be positive It contains the fo llowing attributes. officialsToBeNotified of type string preEmptiveAction of type string. pressReleaseAction of type string. postConfirmationResponseAction of type string. The entity npdn.General includes all variables that are used to save the temp val ue s generated by operations or rules during the ir execution. ok_to_contact_other_directors of type boolean. Whether the NPDN regional director in the state of origin should contact directors in other regions. regionaldirector_knows_presumptive_positive_sam ple of type boolean. Whether the NPDN regional director in the state of origin has been informed of a presumptive positive sample in the system. SPHD_ knows_presumptive_positive_sample of type boolean. Whether SPHD in the state of origin has been informed of a presumptive positive sample in the system. SPRO _knows_presumptive_positive_sample of type boolean. Whether SPRO in the state of origin has been informed of a presumptive positive sample in the system. has_distant_diagnosis_capability of type boolea n. Whether the current triage lab has distant diagnosis capability. is_distant_diagnosis_appropriate of type boolean. Whether it is appropriate to conduct the distant diagnosis to the sample. NIS_gets_result of type boolean. It is used to indicate whethe r NIS gets the confirmed diagnostic result. RPM_gets_result of type boolean. It is used to indicate whether RPM gets the confirmed diagnostic result. SPRO_gets_result of type boolean. It is used to indicate whether SPRO gets the confirmed diagnostic resul t.

PAGE 149

149 SPHD_gets_result of type boolean It is used to indicate whether SPHD gets the confirmed diagnostic result. regionaldirector_in_stateoforigin_gets_result of type boolean It indicates whether the NPDN regional director in the state of origin gets the co nfirmed diagnostic result. triagelab_notifier of type string. It is used to indicate who will contact triage lab with the confirmed diagnostic result. morethan7days of type boolean. Whether the confirmation will tak e more than seven days. is_sample_new_to_USA of type boolean. Whether the sample is new to USA. is_sample_recognized_as_significant of type boolean. Whether the sample is recognized as si g nificant.

PAGE 150

150 LIST OF REFERENCES Alexopoulou N. Nikolaidou, M., Cham odrakas, Y. and Martakos, D. (2008), Enabling o n the fly b usiness p rocess c omposition through an e vent based a pproach HICSS 2008 : Proceedings of the 41 st Hawaii International Conference on System Sciences Waikoloa, HI USA, pp. 379. Alonso, G., Fiedl er, U., Hagen, C., Lazcano, A., Schuldt, H. and Weiler, N. (1999), in RIDE VE 1999: Proceedings of the 9th International Workshop on Research Issues on Data Engineering: Information Technology for Virtual Enterprises Sydney, NSW, Australia pp. 132 139. AOP, Aspect Oriented S oftware Development Available at : http://www.aosd net Accessed on 10 January 2010. Asuncion, C.H., Lacob,M., and van Sinderen, M.J. ervice integration through s eparation of business r ules in EDOC 2010 14th IEEE International Enterprise Distributed Ob ject Computing Conference Vitoria, Brzail, pp. 184 193 control of workflow processes IEEE Transactions on Knowledge and Data Engineering Vol. 16 No.8, pp. 1010 1023. oriented compositional approaches to services based cross Decision Support Systems Vol 40 No.1 pp. 31 50 Bry, F., Eckert, M., Patranjan, P. and Romanenko I. (2006) Realizing b usiness p rocesses with ECA Rules: b enefits, c hallenges, l imits i n PPSWR 2006: Proc eedings of the 4 th International Conference on Pr inc iples and Practice of Sem antic Web Reasoning Budva, Montenegro, pp. 48 62 Buhler, P., and V idal, J.M. (2004) Enacting BPEL4WS specified workflows with multiagent systems Paper Presented at Proceedings of the Workshop on Web Services and Agent based Engineering New York City, NY, USA. Business Rules Group (2000) Defining Business Rules What are They Really? Final Report Available at : http://www.businessrulesgroup.org/first_p aper/br01c0.htm Accessed on 10 October 2010. Charfi, A., and Mezini, M. (2004) Hybrid web service composition: business processes meet business rules in ICSOC 2004: Proc eedings of the 2 nd Int ernational Conf erence on Service Oriented C omputing New York NY, USA, pp. 30 38 Cover, R. ( E d ) (2001) Simple R ule M ark up L anguage Available at : http://xml.coverpages.org/srml.html Accessed 10 January 2011.

PAGE 151

151 David L. (2002) The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems Addison Wesley, Boston, MA, USA Degwekar, S. (2007) ETKnet: A Distributed Event and Rule based System for Knowledge Sharing in a Collaborative Federation Ph.D. Dissertation, Univers ity of F lorida Gainesville, FL, USA Knowledge s haring in a c ollaborative b usiness e nvironment International Journal on Electronic Business Vol. 6, No. 1, pp. 67 92. DePree, J trig gered rule processing in a c ol in ELEARN 2009: Proceedings of World Conference on E Learning in Corporate, Government, Healthcare and Higher Education Vancouver, Canada pp. 1580 1586. DePree, J., Xiao, X. and Su, S. Y. W. (2010) Enhancing team projects using an e vent t riggered k nowledge n etwork International Journal of Knowledge Management & E Learning Vol. 3, No. 2 pp. 222 236. Eijndhoven van, T., Lacob, M.E. and Ponisio, M.L. Achieving b usiness process f l exibi Proc eedings o f the 12th IEEE International Enterprise Distributed Object Computing Conference Mnchen, Germany pp. 95 104 Eshuis, R. and Grefen P. (2009) Composing s ervices into structured p rocesses Internation al Journal Cooperative Information System Vol. 18 No. 2 pp. 309 337 Gandon, F., Sheshagiri, M. and Sadeh, N. (2004) Rule Language in OWL Available at : http://www.mcom.cs.cmu.edu/OWL/ROWL/ROW L.html Accessed on 10 October 2010 Graml, T., Bracht, R. and Spies, M. (2008) Patt ern s of business rules to enable agile busine Enterprise Information System Vol.2 No.4, pp.385 402. Grefen, P., Aberer, K., Hoffner, Y. and Ludwig, H. (200 Int ernational Journal of Computer Systems Science & Engineering Vol. 15 No. 5, pp. 227 290. Grefen, P., Mehandjievb, N., Kouvasc, G., Weich hartd, G. and Eshuisa, R. (2009a ) Computers in Industry Vol.60 No. 2, pp. 86 103. Grefen,P., Eshui s,R., Mehandjiev,N., Kouvas,G. and Weichhart,G. b ased s upport for p rocess o riented i ns tant v irtual e nterprises Internet Computing Vol.13 No. 6, pp. 65 73.

PAGE 152

152 i n WACC 1999: Proceedings of the Internati onal Joint Conference on Work Activities Coordination and Collaboration New York, NY, USA, pp. 79 88. Herbst, H., Knolmayer, G., Myrach, T. and Schlesinger, M. (1994) pecification of business r ules: A comparison of s elected m ethodologies i n Proceedi ngs of the IFIP WG8.1 Working Conference on Methods and Associated Tools for the Information Systems Life Cycle New York, NY, USA, pp. 29 46 Horrocks, I., Patel Schneider, P., Boley, H., Tabet, S., Grosof, B. and Dean, M. (2003) SWRL: A Semantic Web Rul e Language Combining OWL and RuleML Available at : http://www.w3.org/Submission/SWRL/ Accessed on 10 October 2010 Jiang, J., Dignum, V. and Tan, Y. (2011) An a gent b ased i nter organizational c ollaboratio n f ramework: OperA+ in WI IAT 2011: IEEE/WIC/ACM International Conference on Web Intelligence and Intelligent Agent Technology Lyon, France, pp. 21 24. Kappel, G., Rausch Schott, S. and Retschitzegger, W. (2000) A framework for workflow management syste ms based on objects, rules and roles ACM Computing Surveys Vol. 32, No. 1, Article No. 27. Kapuruge, M., Han, J. and Colman, A. (2010) lexibility in service c ompositions : An e valuative s urvey in ASWEC 2010 : 21 st Australia n Software Engineering Conference Auckland, Australian, pp. 97 106 Klingemann, J., Wsch, J. and Abere, K. (1999) ross o rganizational w orkflows in CAiSE 1999: Proceedings of the 11th International Conference on Advanced Informa tion Systems Engineering London, UK, pp.417 421. Knolmayer, G., Endl, R. Modeling processes and workflows by b usiness r ules in Proceeding of Business Process Management, Models, Techniques, and empirical Studies London UK, pp 1 6 29. Krishnamurthy, B. and Rosenblum, D.S. (1995) Yeast: A general purpose Event Action s ystem IEEE Transactions on Software Engineering Vol. 21 No. 10, pp. 845 857. enterprise collaboration ma OTM Confederated International Conferences Agia Napa, Cyprus, pp. 593 611 driven perspective on the rule based in EDOC 2008: Proc eedings o f the 12th IEEE International Enterprise Distributed Object Computing Conference Mnchen, Germany pp. 75 84.

PAGE 153

153 Lamsweerde, A. (200 8 ) Goal models as architectural knowledge SHARK 2008: Proceedings of the 3 rd International Workshop on Sharing and Reusing Arch itectural Knowledge Leipzig, Germany, pp. 1 2. Lazcano, A., Schuldt, H., Alonso, G. and Schek, H. (2001) rocess based E Commerce IEEE Data Engineering Bulletin, Special Issue on Infrastructure for Advanced E Services Vol. 24, No. 1, pp. 46 51. I BM, IBM WebShpere MQ Workflow Available at : http://www 01.ibm.com/software/integration/wmqwf/ Accessed on 10 October 2011 Lee, J. K.and Sohn. M. M. (2003) nowledge m anagement wit h eXtensible r ule m arkup l anguage HICSS 2003 : Proceedings of the 36th Hawaii International Conference on System Sciences Big Island, HI, USA pp. 8 Lee, M., Su, S. Y. W. and Lam,H. (2004) Event and rule s ervices for a chieving a w eb based knowledge n etwork Knowledge Based Systems Vol. 17, Issues 5 6, pp. 179 188. McGuinness, D. and Van Harmelan, F. (eds.) (2004) OWL Web Ontology Language, W3C Recommendation. Available at : http://www.w3.org/TR/owl fea tures/ Accessed on 10 October 2010. Meng, J., Su, S.Y.W., Lam, H., Helal, A., Xian, J., Liu, X. and Yang, S (2005) Int ernational J ournal of Business Process Integration and Management Vol. 1 No.2, pp. 101 115. Microsoft (2009 ) BizTalk, Runtime Architecture. Available at : http://msdn.microsoft.com/en us/library/aa562161.aspx Accessed on 20 May 2010. Milanovic M. and D. (2009) enhanced business process m odeling in EDOC 2009: Proceedings of the 13 th IEEE International Conference on Enterprise Distributed Object Computing Auckland, New Zealand pp. 64 73. D. Modeling s ervice orchestrations with a r ule enhanced b usiness p rocess l anguage in CASCON 2009: Proceedings of the 2009 Conference of the Center for Advanced Studies on Collaborative Research Markham, Ontario, Canada, pp. 70 85 M horeographies with rule in EDOC 20 10 : Proceedings of the 1 4th IEEE International Conference on Enterprise Distributed Object Computing Vitoria, ES, Brazil, pp 194 203

PAGE 154

154 Mller, R., Greiner, U. and Rahm, E. AgentWork : a workflow system supporting rule Data and Knowledge Engineering Vol.51 No.2, pp. 223 256. National Plant Diagnostic Network (2008) The National Plant Diagnosti c Network Standard Operating Procedure for APHIS PPQ Pest of Concern Scenario General SOP Available at : www.npdn.org/webfm_send/1349 Accessed on 20 May 2010. s urvey on the f lexibility r equ irements r elated to b usiness p rocess and m odeling a rtifacts in HICSS 2008: Proceedings of the 41st Annual Hawaii International Conference on System Sciences Big Island, HI, USA pp. 16 30. OASIS (2007) OASIS Web Services Busin ess Process Execution Langua ge. Available at : http://www.oasis open.org/committees/wsbpel/ Accessed on 10 Januar y 2011. OMG (2008) Semantics of Business Vocabulary and Rules (SBVR) v 1.0 Available at : http://www.omg.org/spec/SBVR/ Accessed on 10 January 2011. OMG (2009a) Production Rule Representation (PRR), Specification Available at : http://www.omg.org/spec/PRR/1.0/PDF/ Acces sed on 10 January 2011 OMG (2009b) Business Process Model and Notation, Final Adopted Specification Available at : http://www.omg.org/bpmn/Documents/OMG_Final_A dopted_BPMN_1 0_Spec_06 02 01.pdf Accessed on 10 January 201 2 Orriens, B. and Yang, J. (2006) A r ule d riven a pproach for d eveloping a daptive s ervice o riented b usiness c ollaboration i n SCC 2006: Proc eedings of the IEEE Int ernational Conf erence on Servi ces Computing Chicago, IL, USA, pp.182 189 (2010) Representational a nalysis of business p rocess and business rule languages Paper Presented at 1st International Workshop on Business Models, Business Rules and Ontologies (BuRO 2010) 22 24 September 2010 Brixen, Italy. Recker, J., Indul ska, M., Rosemann, M. and Green, P (2005) Do process modeling Paper Presented at the 16th Australian Conference on Information Systems November 30 Dec ember 2, 2005. Sydney, Australia. n WETICE 2006: the 15th IEEE International Workshops on Enabling Technologies: Infrastructures for Collaborative Enterprises Manchester, UK, pp.271 272. Re d Hat, JBoss Enterprise BRMS Available at : http://www.jboss.com/products/platforms/brms/ Accessed on 10 January 2011.

PAGE 155

155 Rewerse Working Group I1 (2006) R2ML The REWERSE I1 Rule Markup Language. Available at : https://oxygen.informatik.tu cottbus.de/rewerse i1/?q=R2ML Accessed on 10 January 2011. Rosenberg, F. and Dustdar, S. (2005) Business Rules Integration in BPEL A Ser vice Oriented Approach in CEC 2005: Proceedings of the 7th Int ernational Conference on E Comm erce Tech nology 476 479 Rouvellou, I., Degenaro, L., Chan, H., Rasmus, K., Grosof, B.N., Ehnebuske, D. and g different business rules technologies: a Paper Presented at the Proceedings of the OOPSLA 2000 Workshop on Best practices in Business Rule Design and Implementation 15 19 October 2000, Minneapolis, Minnesota, USA. Rule Markup Language Initiative (2011) Schema Specification of RuleML 1.0 Available at : http://www.ruleml.org/1.0 Accessed on 10 January 2011 Russell, N., ter Hofstede, A., van der Aalst, W.M.P. and Mulyar, N. (2006) Workflow control flow patterns: A revised view Technical report BPM 06 22 BPMcenter.org. Available at: http://www.workflowpatterns.com/documentation/documents/BPM 06 22.pdf Accessed on 1 0 Janually 2011. Sirin, E., Parsia, B., Cuenca, B. Grau, Kalyanpur, A. and Katz, Y. (2007) Pellet: a practical OWL DL reasoner J ournal of Web Semantics Vol. 5 No. 2, pp. 51 53. Sowa, J (2000) Knowledge Representation: Logical, Philosophical and Comput ational Foundations Pacific Grove, CA: Brooks Cole. Su, S. Y. W., Beck, H. W., Degwekar, S., DePree, J., Xiao, X., Zhou, C. and Lee, M. (2008) rocessing of e vent d ata and m ulti faceted k nowledge in a collaboration f ederation in IEEE Interna tional Conference on Intelligence and Security Informatics Taipei, Taiwan. pp. 64 69. Su, S.Y.W., Xiao, X., DePree, J., Beck, H.W., Thomas, C. and Coggeshall, A. (2011) Interoperation of o rganizational d ata, r ules, p rocesses and s ervices for a chieving in ter organizational c oordination and c ollaboration in HICSS 2011: Proceedings of the 44th Hawaii International Conference on S ystem Sciences Koloa, H I, USA pp. 1 10 Taveter, K. and Wagner, G. (2001) Agent Oriented e nterprise m odeling b ased on b usiness r ules in ER2001: Proc eedings of the 20th Int ernational Conference on Conceptual Modeling Yokohama, Japan, pp.527 540 Ullman, J. (1982) Principles of Database Systems 2nd ed. Comput er Science Press, Rockville, MD USA Ullman, J. (1988) Principles of D atabase and Knowledge Based Systems Vols. I II, Computer Science Press, Rockville, MD USA

PAGE 156

156 United States Department of Agriculture, Cooperative State Research, Education and Extension Service (USDA, CSREES) (2002) National Plant Diagnostic Network (NPDN) Available at : http://www.npdn.org/ Accessed on 10 January 2012 Widom, J. and Ceri, S. (1996) Active Database Systems, Triggers and Rules for Advanced Database Processing San Mateo, CA: Morgan Kaufmann. WfMC (1998) Wo rkflow Management Coalition Interface 1: Process Definition Interchange Process Model Available at : http://www.wfmc.org/standards/docs/if19807o.pdf Accessed on 10 January 2011 Xiao, X., DePre specification and processing of knowledge and process for achieving knowledge sharing am Paper Presented at Proceedings of the Second International Confer ence on Information Systems, Technology and Management 6 8 March 2008 Dubai, India X iao, X DePree, J and Su, S. Y. W. (2011) Dynamic c onstruction and processing of i nter organizational b usiness p rocesses International Journal of Business and Syste ms Research Vol. 5 No.6 pp. 527 545 Zeng, L., Flaxer, D., Chang, H. and Jeng, J. (2002) PLMflow: D ynamic b usiness process c omposition and e xecution by r ule i nference i n TES 2002: P roceedings of 3rd VLDB Workshop on Technologies for E Services Hong K ong, China pp. 141 150 Zhou C. Xiao, X., DePree, J., Beck, H. W. and Su S. Y. W. (2010) Ontology Management in an Event Triggered K nowledge Network in ESWC 2010 : Proceedings of the 7 th Extended Semantic Web Conference Heraklion, Crete, Greece pp. 4 10 424

PAGE 157

157 BIOGRAPHICAL SKETCH Xuelian Xiao was born in Gu angdong, China. She received her B.S. degree and M.S. degree from Sun Yat sen University, Guangzhou, China, in 2000 and in 2003 correspondingly, both in computer science. She joined the Department of Computer and Information Science and Engineering (CISE) graduate program at the University of Florida in August 2006. Her research areas include kno wledge management and sharing, W eb services e business and inter organizational process and collaboration