Personal Agents

The personal agents work for workflow participants and support the daily operations of the workflow. They may work in the background of user’s desktops, or work as the representative of the users on other servers. The following are some typical personal agents:

1. Notification agent starts automatically to stay in the Microsoft Windows System Tray or the equivalent places in other Unix Window Desktops. It is similar to other popular System Tray applications such as Microsoft MSN or ICQ. The agent responses for user notification and message services. They can also easily display working list status or notify the arrival of new activities automatically.

Therefore, user does not need to check the activity arrival periodically in person.

2. Sign-on agent can simplify the login procedure by assisting the users to sign-on the system via several kinds of security check mechanisms. For example, they handle a single sign-on activity in Microsoft Windows environment. They may also handle the information stored in the security tokens such as iKey (http://www.rainbow.com) or other smart card products.

3. Process instantiation agent can prompt the users to perform scheduled activities such as to initiate a project planning process at the beginning of each season, or to initiate a working summary process bi-weekly. It can also be smart enough to

initiate a business trip report process for the user after the end of the trip by monitoring the user’s business trip calendar.

4. Process tracking agent can monitor and notify the progress of user-assigned process instances by actively monitoring the processes in question. When the monitored processes arrive at the milestones defined, the user is notified through the notification agent.

Figure 31. A typical notification agent that works on the end user’s PC 6.2.2. Portal Agents and Personalization

The portal agents work on the portal and web servers to gather the run-time information of the user community, and provide workflow information to other portal applications. The followings are some typical portal agents:

1. User availability agent monitors the sign-on and sign-off of users and maintains the history. The agent can help other agents to make their decision by providing the name list of the workflow participants.

Figure 32. A calendar portlet displays the daily activities by integrating process-related information.

2. Workflow integration agent interacts with other portal applications on the portal servers. It provides an easier and more simple and efficient integration mechanism.

For example, the to-do list portlet can ask the agent for work items as part of output for to-do list. The calendar portlet can ask for them same information, but to display the work items in terms of calendar view. The agent also performs pre-fetch and cache of workflow information to reduce both the load of workflow server and the response time of end-user’s request.

3. Work list aggregation agent aggregates work items from several workflow engines to compose the final work list for the users. Workflow applications are sometimes divided into several servers for the reason of management or constraints of the network architecture.

Figure 33. Work list view, which can be enhanced by agents

In a portal system the composition and style of a Web page can be personalized. The feature enables the software agents to advice the end-users through portlets. The end-users can compose the final web page by choosing desired portlets, display options, screen locations, and styles. The enterprise process portal system can provide lots of portlets (a few of them handle the advices from the agents) for users to choose.

For example, the administrative staffs can choose portlets that dynamically display summary of business performance. The team leader may want to configure his workspace to oversee his team by placing a portlet that aggregates all work items of his team.

The portal and the backend workflow platform are used together to bring new possibility for the enterprise’s workspace. Users can enjoy the unified workspace for traditional Web applications and workflow applications. Users with various business roles can configure their workspaces to meet the respective duty requirements. They can also get benefits from the advices, based on richer information workflow in their working context.

Figure 34. A sample screen for the enterprise process portal.

6.2.3. Workflow Agents

The workflow agents can work in parallel with the workflow engine to enhance the operation capability of workflow engine. There are several application scenarios that software agents can work more powerful and transparent than traditional workflow products do. For example, they can handle advanced workflow routing issues that can be best resolved by external knowledge. The following are some sample workflow agents:

1. Smart dispatch agent that dynamically finds the proper candidate performers of an activity according to the agent’s knowledge about the skill set of each performer and the required skills for activities.

2. Activity queue coordination agent monitors a set of shareable activities and their potential performers to decide better binding on the performer of each activity.

Traditional approach usually binds the performer to an activity very early under the

amount of activities for each candidate as the dispatch parameter.

A traditional static dispatch mechanism might not be satisfied with time-critical activities, because it often comes out with longer process turn-around time due to improper performer assignments. The agent can improve its mechanism by collecting more dispatching parameters. For example, the agent can communicate with other agents for on-line candidates dynamically. The agent can also collect answers from the on-line candidates through instant and short communication with the notification agent.

3. Substitute or delegation agent temporarily transfers the user’s active activities based on pre-defined rules to his job substitutes. It can handle recursive substitutes and conflict cases well because it has more knowledge about the availability of workflow users than a traditional workflow manager has. In addition, there exist multiple substitute rules to be use to delegate the activities to different people based on the attributes of activities.

4. Ad-hoc routing agent manages dispatched activities that allow ad-hoc routing. It helps collect the opinions or confirmation of dynamically assigned group members.

The collecting sequence can be either parallel or sequential. The agent can resort to traditional workflow user interface (for full-control), notification agent’s instant message (for quicker response), or email (for members not in the workflow organization), for routing information through group members. The agent finishes the ad-hoc routing by summarizing the final result then continues prior activities.

5. Exception handling agent handles system exceptions based on predefined exception-handling procedures. The exceptions in the workflow system are usually cased by (i) system failures that can be recovered by system administrators, and (ii) illegal operations due to unreasonable process definitions or inconsistent changes to

business rules. The agent can react to the exception by notifying administrators, performing rollback, or restarting from the last milestone.

6.3. The Supporting Architecture for the Environment

The features and application scenarios of the software agents in the previous session can be supported by a workflow platform, where the software agents work and which facilitates the portal technology. Software modules shown in Figure 35 work jointly to demonstrate the characteristics that an ‘Intelligent Process Portal’ brings (1) intelligence, provided by the software agents, (2) process power, provided by the workflow server, and (3) personalized application presentation, provided by the portal server.

WF

Figure 35. Architecture of the software agent enabled process portal.

The architecture is derived from traditional workflow architecture by adding the following characters:

1. Software agents are engaged at the workflow server, portal server, and the end-user’s computer. Compared with a rule-based approach of the same purpose, using the software agents can lead to clearer and extendable architecture at the abstraction level. Because software agents are active objects that perform more object functions than passive objects do.

2. Agents communicate and interact with each other through their communication mechanism that is independent with the workflow system. Agents can usually work together for more complicated tasks through their communication. Agents can access workflow related information through APIs exported on the workflow servers. Workflow engine provides APIs in both Java RMI and Web Services for native language integration and cross platform integration respectively. For third-party portlets that need to access workflow information and control the workflow engine, the Web Services can be used as a more general model for cross-platform integration.

3. Traditional Web server is augmented with a portal framework that works well for aggregating several Web application output and personalized workspace.

4. Essential features on workflow user interfaces such as activity list, activity tracking, and process catalog are also provided in form of portlets to integrate seamlessly with the portal.

5. Workflow agents and other agents interact with end users through agent portlets.

As a portlet, an agent portlet can be configured through standard portal features for layout and configuration parameters/rules of the agents.

Figure 36. Third-party portlets can integrate with workflow engine through Web services.

6. At user’s computer, the intelligent process agent is introduced to provide better workflow interaction to the local user. The agent also supports on-line chat, and instant message features. It helps the user to join proper chat channels based on his activities at hand. The agents act for users to establish a common chat channel for those who are in the same process instance. Agents also automatically enroll the users to the virtual workspace represented by the channel. In the virtual workspace, the users can chat with their working peers; attach files to the workspace as they usually do in P2P applications. The agent can record the chat history and important operations as the attachment in the process instance for auditing and tracking purposes. With the support of the audited instant discussion, unnecessary repetitive or compensation procedures on past activities can be significantly eliminated while actions on the process instance can be audited and

tracked. Consequently, the turn-around time of process instances can be largely reduced.

Chapter 7 Conclusion

In this dissertation, we present a cooperative workflow model CA-PLAN and an Agentflow system. The CA-PLAN is a service-oriented workflow model, where an inter-organizational process can be partitioned into several parts (co-processes) with boundary functionalities in different organizations. A co- process is defined as a process which contains a pair of process service and remote process supported by IWC connection between their process services and remote processes. An inter-organizational process is defined as a routing path and it can be assembled by IWCs through connection between their process services and remote processes. This mechanism increases modularity, flexibility and reusability in designing inter-organizational process.

The RCP provides a flexible cooperative mechanism by which the process service and the remote process communicate and pass information back and forth. Through RCP, the cooperative process across organizations becomes simple, faster, and flexible. The newly distributed Agentflow system presents the construction of an internet/inter-organization workflow so that workflow designers, working on different portions of an inter-organizational workflow systems, may work together to accomplish a common mission. It also provides a friendly tool that can be used to model inter-organizational workflow for cooperation. Also, Agentflow system provides a convenient inter-organizational process monitor to track and monitor an inter-organizational process instance.

However, the security discussed in the dissertation is a straight approach. It is necessary to be studied further. The exception handling and distributed transaction mechanism of cooperative processes among multiple WfMSs can support interoperability more transparent, sturdy, and consistent. Hence, applying excepting handling and transaction mechanisms of processes into inter-organizational workflow system are our future topics.

Besides, we present an intelligent and personalized process portal which requires an integration of workflow, portal and software agents. The ability of a workflow system to make external software modules such as software agents and portal portlets to access its process related information through standard APIs and Web services is one of the important success factors behind the integration. The process portal can enhance the intelligence by continuously updating software agent’s business process knowledge. The richness of the process portal can be extended by more portlets. The overall process portal environment can also grow with its underlying information technologies from several open standard organization.

Reference

[1] D. Georgakopoulos, M. Hornick and A. Sheth, “An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure,” Journal on Distributed on Parallel Database, 3(2), 1995 pp. 119–153.

[2] WfMC Workflow Management Coalition. http://www.wfmc.org, 1996.

[3] Jie Meng, Stanley Y. W. Su, Herman Lam and Abdelsalam Helal, “Achieving Dynamic Inter-Organizational Workflow Management by Integrating Business Processes, Events and Rules,” Proceedings of the 35th Hawaii International Conference on System Sciences, 2002.

[4] M. F. Chen, B. S. Liang and F. J. Wang, “A Process-Centered Software Engineering Environment with Network Centric Computing,” Proceedings of the 6th IEEE Workshop on Future Trends of Distributed Computing Systems, 1997.

[5] W. R. Cockayne and M. Zyda. “Mobile Agents.” Manning Publications Co., 1998.

[6] D. B. Lange and M. Oshima. “Seven good reasons for mobile agents”, Communications of the ACM, 42(3):88-89, March 1999.

[7] Workflow Management Coalition, “Workflow Management Coalition Terminology &

Glossary”, the Workflow Management Coalition Specification, Feb 1999.

[8] David Hollingsworth, WfMC, “The Workflow Reference Model,” Technical Report TC-1003, Jan. 1995.

[9] A. Sheth., W. Aalst, and I. Arpinar, “Process Driving the Networked Economy,” IEEE Concurrency, Vol. 7, No. 3; July-September 1999, pp. 18-31.

[10] Dickson K. W. Chiu, S.-C. C., Kamalakar Karlapalem, Qing Li, Sven Till (2002).

Workflow View Driven Cross-Organizational Interoperability in a Web-Service Environment. Web Services, E-Business, and the Semantic Web, CAiSE 2002 International Workshop, WES 2002, Springer.

[11] Fabio Casati, A. D. (2001). "Modeling and Managing Interactions among Business Processes." Journal of System Integration 10(2): 145-168.

[12] Fabio Casati, Angela Discenza, "Supporting workflow cooperation within and across organizations," Proceedings of the ACM symposium on Applied computing, Como, Italy, 2000.

[13] Stanley YW Su, J. M., Raja Krithivasan, Seema Degwekar, Sumi Helal (2003).

"Dynamic Inter-Enterprise Workflow Management in a Constraint-Based E-service Infrastructure." Electronic Commerce Research 3(1): 9-24.

[14] Myungjae Kwak, Dongsoo Han, Jaeyong Shim, "A Framework Supporting Dynamic Workflow Interoperability and Enterprise Application Integration," Proceedings of the 35th IEEE Annual Hawaii International Conference on System Science, 2002.

[15] Mehmet Sayal, Fabio Casati, Umesh Fayal, Ming-Chien Shan, "Integrating Workflow Management Systems with Business-to-Business Interaction Standards," Proceedings of the 18th IEEE International Conference on Data Engineering, 2002.

[16] G. Alonso et al., “WISE: Business to Business E-Commerce,” IEEE 9th International Workshop on Research Issues on Data Engineering, Information Technology For Virtual Enterprises, Sydeny, Australia, March 23-24 1999.

[17] [URL]http://lsdis.cs.uga.edu/proj/meteor/meteor.html

[18] Object Management Group, “CORBA/IIOP 2.2 Specification,” 10 Feb. 1998.

[19] H. Davulcu, S. Dawson, M. Kifer, L. R. Pokorny, C.R. Ramakrishnan, I.V.

Ramakrishnan, "Modeling and Analysis of Interactions in Virtual Enterprises", 9th International Workshop on Research Issues on Data Engineering: Information Technology for Virtual Enterprises, RIDE-VE,Sydney, Australia, 1999.

[20] H. Davulcu, M. Kifer, C.R.Ramakrishnan, and I.V.Ramakrishnan. "Logic based modeling and analysis of workflows", ACM Symposium on Principles of Database Systems (PODS), Seattle, WA, June 1998.

[21] Dickson K. W. Chiu, S. C. Cheung, Sven Till, Kamalakar Karlapalem, Qing Li, Eleanna Kafeza. “Workflow View Driven Cross-Organizational Interoperability in a Web-Service Environment,” Information Technology and Management Volume 5, Issue 3-4 July-October 2004.

[22] WfMC, “Interoperability Wf-XML Binding,” Technical Report TC-1012, May 2000.

[23] Standard ECMA-262 ECMAScript Language Specification, http://www.ecma-international.org/publications/standards/ECMA-262.HTM.

[24] Flowring Technology Corp, Agentflow system, http://www.flowring.com

[25] Yin-Shinn Chen, Feng-Jian Wang: An Editing System for Working Processes.

COMPSAC 2001.

[26] Sun Microsystems,” Java(tm) Remote Method Invocation (RMI)”

[27] Sun Microsystems,” Java Naming and Directory Interface(JNDI)”

[28] “Lightweight Directory Access Protocol(LDAP)”, RFC2551, 1997

[29] Sun Microsystems, “Introduction to JSR 168 - The Portlet Specification”. Via URL http:// developers.sun.com/prodtech /portalserver/reference/techart/jsr168/

[30] Open Symphony, “SiteMesh Overview,” via URL http://www.opensymphony.com/

sitemesh/

Vita

Shung-Bin Yan was born on October 2.1970 in Taipei, Taiwan, Republic of China. He received the BS degree in Computer Science and Information Engineering form National Chiao Tung University, Taiwan in 1994. He works for Flowring Technology as the RD director. He is also a Ph.D candidate in computer science and information engineering at National Chiao Tung University. His research interests include software engineering, workflow system, object-oriented analysis and design and distributed software system.