Progress Report3

Progress Report

Project Number: INCO-DC 97-2496

Title: A Workflow Management System for the Maritime Industry

Project Acronym: MARIFlow

Report No: 3 Year:2000 Month: March

Reporting Period Under Review: Sept 15, 1999 – Mar 15, 2000

Contract start date: Sept. 15, 1998 Contract termination date: Dec.15, 2000

Names of editors and/or authors and their organisations:

Prof. Dr. Asuman DogacSRDC Dept. of Computer Eng.Middle East Technical University06531, Ankara, Turkey

Report Preparation Date: March 15, 2000

Report Version: V 1.0

Classification: Public

Executive Summary

MARIFlow project has started on the 15th of September 1998. The work accomplished during the first twelve months of the project is presented in Progress Reports No 1 and No 2. As a summary, first six months of the project consisted of the Work Package No 1, which included tasks related to the requirement analysis and the system architecture design. Requirements analysis of the application domain (Deliverable 1.1) and a detailed specification of business process scenario (Deliverable 1.2) are produced during this time as well as a simple prototype has been implemented to get a better understanding of the general design concepts. This prototype provided the base for a detailed system design and for the system development. This prototype did not include all of the functionality of the system, but some basic components such as cooperating agents, guard-based workflow enactment and message passing between different agents in the system were implemented. Within the second reporting period (Progress Report 2), a detailed design of the system has been completed (Deliverable 1.3), and an extended prototype based on a distributed architecture with cooperating agents has been implemented (Deliverable 2.1). Task and worklist managers of the agents have also been implemented. The interfaces necessary to invoke tasks or sub-processes in other companies’ domains (probably on different platforms) have been designed.

During the third reporting period, the following achievements are accomplished on the system: A comprehensive reliable communication mechanism is developed through

persistent queues for reliable message passing and integrated to the system (Deliverable 2.7). All the messages, including MARCA-to-MARCA messages, mails, documents, etc. are transmitted through persistent queues, in a transactional manner.

Security component of the system is developed (Deliverable 2.5) and integrated to the prototype (Deliverable 2.7). Apart from this, configuration files of the system are made secure using encryption methods and the messages are exchanged in communication infrastructure in encrypted form.

An extensive failure mechanism is developed and integrated to the system (Deliverable 2.7). Logging mechanisms are introduced for this purpose so that the execution of the worklfows can be tracked. If some unexpected error occurs, the Compensation Activities defined through the Process Definition Tool for that workflow are executed to undo the effects of the terminated activities of workflow instances. A hierarchical approach to failure handling is implemented for partially rolling back the workflow instance to the nearest point in process history tree where it is possible to restart the execution.

The state recovery of MARCAs, in the case of failures, is added to the system (Deliverable 2.7). Through this option, a MARCA re-constructs itself (if it is dead), including all the task and instance state information, and joins the system as if nothing has happened. The MARCA recovery is optional. That is, the user may create a brand new MARCA, or a MARCA with all previous information ( such as tasks, instances, states of instances ) can be re-initialized.

An exception handling mechanism is designed and implemented and integrated to the system (Deliverable 2.7). The following types of exceptions are handled:

Connection Errors: The destination machine can reject the request because of any site dependent reason, the server may be down, maximum number of users that can be served simultaneously has been reached etc.

Communication Errors: The messages can be lost, or the connection may be too slow for the sender to behave properly. These communication failures can be detected by using time-out mechanism and inserting checksums for the packets that are transferred.Protocol Dependent Errors: Protocol dependent failures occur when the receiver side refuses the continuation of the communication because of an abnormal situation, the username /password combination may be invalid for mail server or database server connection, the destination may not be able to accept the request etc.

When an error of any of the categories defined above occurs, the communication system closes the connection and cleans up any temporary resources, like open files and streams. After a certain amount of time the whole operation is retried again (Note that the retry may not be the issue in some protocol dependent errors i.e. in authentication and authorization errors). If the communication fails in all tries, because of any of the reasons stated above, the user program is informed of the failure. The system constructs an email and sends it to the User-MARCA-Interfacing Application (UMIA) and to the super user in case of a communication problem. The task owning the failed request is aborted, the compensation activity is started and afterwards the workflow is rolled back if there is no contingency activity belonging to that task. Also, an option to re-try to send the document (or mail, message) or to skip it, is included in the prototype (Deliverable 2.7).

Exceptions caused by NON-VITAL Activities are handled: It should be noted that when document flow is a part of a workflow system, more often than not, there will be a need to archive the documents. The transfer and archival of the documents may take considerable amount of time. Therefore a mechanism which allows the other activities in the system (that does not use these documents) to proceed without waiting these archival activities provides for better performance. Yet there should also be mechanisms to guarantee that the workflow instance will not terminate before the successful termination of all such activities. NON-VITAL activities are those that can be assumed to terminate as soon as they start but raise an exception when they fail. In this way a NON-VITAL activity does not delay the execution of other activities unnecessarily; yet their successful termination is guaranteed by the exception handling mechanism (Deliverable 2.7).

A new block type, WHILE block is added to the system, which provides repetitive task invocations. The WHILE block structure is used in implementing the exceptions of NON_VITAL tasks (Deliverable 2.7).

An option for switching to manual mode for document sending is included in the prototype. With this option, the user inside the firewall is free to send the document through a MARCA, or manually. If he sends it manually, a dummy document is constructed at run-time, to inform the receiver that he will receive the document manually. The receiver also has the option to re-join the workflow, after inserting the document to the digital media (Deliverable 2.7).

The user interfaces monitoring tool, process definition tool, and inside firewall applications have been improved.

An Application Server is designed and integrated to the system in order to execute applications in company domains without user intervention. Triggering an application inside the company domain, (which may be an internal workflow) can now be invoked automatically from the system. The Application Server reads the incoming mails and informs the UMIA accordingly. In order to invoke external applications inside the company domain automatically within the MARIFlow System, a mapping should be provided from the activities defined in the workflow

definition to the external applications in the company domain. This mapping is achieved through a graphical user interface which is a part of the UMIA that also allows parameteres of the application to be specified. If the invocation is to be done manually, i.e, no mapping is defined, then the user invokes the task from the UMIA.

MARIFlow system can itself be used to define a workflow inside the company firewall.

The system is currently using a publicly available database namely, Postgres, for all of its data management activities (Making the system independent of a licensed software was a requirement of the industrial partners to reduce the cost). Furthermore different workflow definitions may choose different sites for the installation of the central database. This option is provided to the user through the Graphical Workflow Definition Tool.

After the initialization of the MARCAs at the related sites, messages are sent to the related users informing that the system is ready.

The deliverable 2.4 has been completed and released. This deliverable is the result of joint work between HU and ETHZ and is a comprehensive analysis of the problem of data consistency and execution guarantees in workflow management systems. The deliverable includes an extensive related work section and the results of Task 2.4. These results include a formal model for concurrency control and execution guarantees in process based interactions and a description of the implementation of these ideas as part of the prototype developed at ETHZ.

As part of Task 2.3, the first release of the ETHZ prototype has been completed. Deployment at the industrial partners will follow (May, 2000).

For Task 2.6, the procedure of converting the representation of certificates provided by SZAG in MARIFLOW QALITY subset format into the Extensible Markup Language (XML) representation required by GL are provided.

The design and implementation issues relating to these enhancements and their sub-modules are explained in greater detail in the following subsections and also in the related deliverables.

Deviations from the description in the Technical Annex

The following reflects the reorganization of the work plan according to the new initiatives in the project. To minimize overhead, the new work plan follows the structure of the existing technical annex. The changes mainly involve reallocation of resources to tasks centered around the alternative architecture that ETHZ will start to explore as of January 2000. New version of TASK 2.3 As an extension to this task, ETHZ will explore the use of the WISE engine as a centralized alternative to the system being designed at METU. Doing this is of special interest to the Swiss industry as the WISE engine is a conventional architecture that has already being tried with several companies in Switzerland. By extending the functionality of WISE to cope with the requirements stated in the MariFlow project, both MariFlow and WISE will benefit from the resulting synergy. A prototype system will be developed and, using this prototype, several ideas related to scalability and availability will be explored. For technical details on the ETHZ prototype, see the summary of the 8./9.12.99 meeting in Zurich. New deadlines and deliverables for task 2.3 (replacing current deliverables in technical annex) March, 2000 Prototype made available to partners (software deadline) April, 2000 Description of the prototype and basic functionality (document deliverable) April, 2000 Test installation of the prototype at GL (milestone deadline) September, 2000 New version of the prototype (software deadline) September, 2000 Availability and scalability report (document deliverable) Final project workshop: demo, poster and presentation (milestone deadline) Project end: final version of the prototype (software deadline) New version TASK 2.4 As part of this task, ETHZ will explore, together with HU, different issues related to concurrency control and recovery in the context of workflow systems. This task will conclude in April/May 2000 with a technical report that will be made a deliverable and papers submitted for publication. Resources allocated to this task will be shifted to Task 2.3 (both within ETHZ).

New deadlines and deliverables for task 2.4 (replacing current deliverables in technical annex)

May 2000 = document on consistency (document deliverable)

New version of TASK 2.7

Extension of the current wording as follows:

Study of the interface possibilities among different workflow engines

Removal of TASK 2.2

With the current architectures and technologies the most relevant aspects of this task has been subsumed in other tasks, mainly those related to the development, installation and utilization of the prototypes. Interfacing issues are now studied in task 2.7 (new version).

This task is now obsolete and will not be further pursued as such.

Contacts established with other related projects:

Odensa shipyard is invited to join the project. They expressed willingness to participate to the project workshop. Contacts with other shipyards are continuing.

Project Meetings :

Two project meetings have been organized during this period:

1. 8/12/1999 – 9/12/1999 in Zurich. Attendants: Amaia Lazcano -- ETHZ Andrei Popovici -- ETHZ Eckard Manegold -- Salzgitter AG Gustavo Alonso -- ETHZ Hans–Jorg Schek -- ETHZ Markus Lehne -- Balance Markus Steinbiss -- Balance Matthias Wolf -- Salzgitter AG Uwe Langbecker -- Germanischer Lloyd Uwe Rabien -- Germanischer Lloyd

2. 10/01/2000 – 11/01/2000 in Bremen. Attendants: Asuman Dogac -- ODTU Catriel Beeri -- Hebrew Cengiz Icdem -- ODTU Eckard Manegold -- Salzgitter AG Gustavo Alonso -- ETHZ Markus Lehne -- Balance Matthias Wolf -- Salzgitter AG Murat Ezbiderli -- ODTU Uwe Langbecker -- Germanischer Lloyd Yusuf Tambag -- ODTU

Below the Gannt Chart relating to the tasks executed in this reporting period is presented. Note that the tasks and the Person Months (PMs) shown belong only to this reporting period.

World-wide ‘State-of-the-Art’ Update

I. Introduction

A workflow system is a groupware product and in order to put its place into perspective in this category of products, we will start by describing groupware products. Groupware is any software product or technology that enables groups of people to work together. There are three primary ways in which people work together in groups:

They communicate with each other to send information, requests or instructions. They collaborate with each other by working together on joint projects. They coordinate with each other as participants in structured or semi-structured

sequence of tasks, or business processes.

I.1 Groupware Categories

Groupware products fall into the following categories:

1. Communication Products

These software products enable users to quickly and easily communicate with each other. Examples of communication products include E-mail, fax, computer telephony, video conferencing and chat programs.

2. Communication and Collaboration Products

Collaboration in workgroups involves “knowledge workers” who work together as teams on projects such as producing a report, designing a complex product, or participating in research. Collaborative groupware solutions, therefore, must provide a “document” or repository where the collective work of the team is stored and easily accessible to all participants. The “document” is the key since it is the repository of the work, and the form in which the work is saved and displayed. Examples of collaborative groupware include Lotus Notes, document management systems, graphic design software, CAD software, and other multi-user applications.

3. Coordination Products

In addition to communication and collaboration, individuals also work together by participating in structured or semi-structured processes. The workflow systems fall into this category.

I.2 Two Example Communication and Collaboration Products

Electronic mail provides powerful facilities for distributing information between individuals within an organizations; the use of directory mechanisms not only provide a way of identifying individual participants within an email domain but also potentially recording information about individual user attributes, such as organization roles or other attributes relating to business procedures. Thus electronic mail systems have themselves been progressing towards workflow functionality through the addition of routing commands to define a sequence of recipients for particular types of mail items in response to some form of identified business procedure.

Two representative examples of this type of systems are Lotus Notes and Microsoft Exchange. These platforms provide high level communication support, both inter-personal and inter-application, some degree of document management, and tools to build special purpose application that use the base functionality.

Lotus Notes

Lotus Notes is a client-server application development, integrating a database and a messaging infrastructure. The Notes Application Development Environment enables development of applications that store and route information objects using these database and messaging services.

The document database is comprised of databases of documents. A Notes document is defined as an object containing text, graphics, video, and/or audio objects o any other kind of rich text data. Notes databases are semi-structured records consisting of basic design elements like Forms (for information entry and storage in the document), Subforms (objects in a Form that can be reused across applications), Collapsible sections (sections within a Form that can be expanded or collapsed depending on the need to view that particular piece of information), Views (user-defined ways of looking at information), and Navigators (graphical tables of contents for a database).

In summary Lotus Notes is a powerful document sharing database with messaging but it is not a workflow. It does not provide for: a graphical workflow design tool, ability to specify data and control flow, exception handling, monitoring and it can not inform users of the new tasks.

Microsoft Exchange Server / Microsoft Outlook Client

Microsoft Exchange [Microsoft Exchange] is a powerful messaging and collaboration platform. Microsoft Outlook is a workgroup client combined with Microsoft Exchange Server, which integrates messaging, group scheduling (Calendar), task management (Task), personal information management (Contacts), and a form-design environment. Developers can add custom functionality to Outlook forms using Microsoft Visual Basic Scripting Editing (VBScript) or to add controls using Microsoft ActiveX. However Microsoft Exchange does not provide for: a graphical workflow design tool, ability to specify data and control flow, exception handling, monitoring, database connectivity and it can not inform users of the new tasks.

I.3 Workflow Categories

Popular classification distinguishes three types of workflows:

Ad hoc Workflows: Workflows are controlled by users at run time. Users can react to situations not considered at build-time.

Administrative Workflows: Predictable and repeatable workflows described in simple description languages. Activities are mainly performed by humans.

Production Workflow: Predictable and repeatable complex workflows which are predefined completely and in great detail using complex information structures and involve application programs and automatic activities.

I.4 Basic Functionality of Workflows

There is a large number of applications which can route a document from one person to another. However, these applications are not “automating workflow.” A “workflow automation” product must provide the following basic functionality:

1. Graphical Workflow Design: A means of graphically creating workflow process maps that define the flow of work and the tasks which must be performed from start to finish.

2. Ability to specify data and control flow : The ability to embed complex business logic in the workflow definition without the need for programming or scripting.3. Exception Handling: The ability to handle exceptions which are omnipresent in every organization. 4. Monitoring: The ability to monitor the status of workflow incidents. Ideally, this ability should be available to each workflow participant for incidents they have participated in, and to a centralized workflow administrator for all workflow incidents.5. Measuring: The ability to generate workflow statistical reports so business managers can measure the time and cost of workflow process, and can then modify them based upon their cost-effectiveness and timeliness.6. Pro-Active: The ability to move workflow forward on a pro-active basis. The workflow solution must inform users of new tasks.7. Database Connectivity: Every workflow process either uses information from databases to enable users to make decisions, or feeds information into databases. In many cases, they do both. Thus, a workflow solution must provide seamless database connectivity.8. Document Attachments: Documents are an essential part of business processes. A workflow solution must, therefore, provide an effective means of attaching documents to the workflow, which are then used to support the business process.

II. State-of-the-Art Research and Commercial Products

The literature on Workflow systems can be investigated in two categories: research prototypes and commercial products. There are quite a number of workflow research prototypes, a good selection of which can be found in [Dogac 98 a].

II. 1 Research Prototypes

One of the first workflow research projects is the ConTract project [Reuter 95]. The focus of this project has been to extend transaction-oriented run-time mechanism for fault tolerant workflow execution in a distributed environment.

The ConTract model tries to provide the formal basis for defining and controlling long lived, complex computations, just like transactions control short computations. It is inspired by the mechanisms for managing flow that are provided by some TP-monitors, like queues and context-databases.

The basic idea of the ConTract model is to build large applications from short ACID (Atomicity, Consistency, Isolation and Durability) transactions and to provide an application independent system service, which exercises control over them. As a main contribution, ConTract provides the computation as a whole with reliability and correctness properties. The ConTract Model extends the traditional transaction concept to form a generalized control mechanism for long-lived activities. A large distributed application is being divided into a set of related processing steps that have appropriate consistency and reliability qualities for their execution.

METUFlow [Dogac 98 b] is a fully distributed workflow management system prototype developed at METU-SRDC. The block structured workflow definition language of MARIFlow is borrowed from METUFlow. In METUFlow, the distributed execution is based on CORBA.

Another distributed workflow management system is METEOR (Managing End to End Organization) [Sheth 98]. Its workflow execution model is driven by inter-task dependency rules that are expressed in a specifically designed script language. METEOR allows workflow definition at two levels of abstraction using two different languages: the Workflow Specification Language, and the Task Specification Language.

Language, and the Task Specification Language: Process definitions are saved in an intermediate format that is used for automatic code generation at run

time. The runtime code generators output code for task managers and task invocation, data object access routines and recovery mechanism. The generated code includes all the inter-task dependencies required by the definition of the process, and it is based on CORBA and Web environment for distributed execution.

In [Miller 97], the use of Web technology for workflow is presented with METEOR2 Web-based workflow management system (WebWork). WebWork is said to be web-based rather than web-enabled since both interfaces and communication/distribution infrastructures are built using Web technology. Data flow is realized through exchanging HTML pages and CGI is the main communication mechanism with servers.

In Panta Rhei Workflow System [Eder 98], a user interface is completely integrated in a Web browser. The system supports workflow transactions, exception handling and allows for definition of activities, roles and organization structures. There are sophisticated mechanisms to handle time dependent aspects of workflows.

In [Shan 98], OpenPM Workflow System developed at HP Labs is presented. However it is stated that OpenPM was designed before the advent of the booming usage of Internet, and was therefore based on the traditional client/server architecture and thus will not serve effectively for future Internet based business operations over various heterogeneous computing platforms. The authors then present the initial ideas of a Internet based workflow system called FlowJet.

In Exotica/FMDC Workflow Management System, described in [Alonso 96] disconnected clients are used for workflow management, effectively allowing users distributed over a wide geographic area and working with heterogeneous resources to cooperate. The clients can perform work without being connected to the overall system and the architecture still maintain the correctness and consistency of the process being executed.

In [Muth 98], an approach towards the specification, verification, and distributed execution of workflows based on state and activity charts is presented. The workflow definition extracted from the state and activity charts are used for execution of processes in a distributed manner.

II. 2 Commercial Workflow Systems and Technology

This section describes a commercial workflow product examplifying the underlying technology (1) IBM’s MQSeries for data-centric workflow solutions; (2) Keyflow for Mail-based workflow solution; (3) Ultimus for Web-based workflow solution.

1. IBM MQSeries (Data Centric Based Workflow Solution)

MQSeries [IBM MQSeries, http://www.ibm.com/software/ts/mqseries] enables business applications to exchange information across different operating-system platforms by sending and receiving data as messages. IBM provides an infrastructure of message queuing (MQSeries Messaging) and application integration (MQSeries Integrator) upon which to build production-level workflow applications.

At the heart of MQSeries is the Message Queue Interface (MQI). It has a high level-programming interface that allows applications to communicate transparently across the various platforms that make up enterprise-wide computing environment. With the common MQI, information can pass between mainframe applications, local server-based applications, and PC programs.

The MQSeries provides application-programming services that enable application programs to communicate with each other using messages and queues. This form of communication is referred to as asynchronous messaging. It provides assured, once-only delivery of messages. MQSeries also provides mechanisms for generating acknowledgements of messages received.

http://www.ibm.com/software/ts/mqseries

The programs that comprise an MQSeries application can be running on different computers, on different operating systems, and at different locations. The applications are written using a common programming interface known as the Message Queue Interface (MQI), so that applications developed on one platform can be transferred to another.

IBM offers a basic graphic map-building tool, called MQSeries Workflow Build time, within the product for workflow application and process development. It also has a partnership with Holosofx for enhanced functionality with business modeling and simulation. For example, the Holosofx product (Workflow.BPR) delivers sophisticated process modeling functionality, which includes the ability to capture business metrics (costing, cycle-time, and quality) with powerful analysis and simulation capabilities. Once a process is fully defined in Workflow.BPR, it can be exported as a completely defined process to MQSeries Workflow. In addition, the Holosofx Workflow Monitor (written in Java) has the ability to collect information from a running workflow and display it in an operational or business context.

Figure 2 shows the MQSeries Workflow Buildtime and its basic map building tools. With the process monitor (Figure 3) the status of the activities of the business process can be observed.

Figure 2: The MQSeries Workflow Buildtime

Figure 3: The MQSeries Process Monitor

2. Keyflow (Electronic Mail Based Workflow Solution)

Keyflow [Keyflow, http://www.keyfile.com/products/keyflow/index.htm] is a collaborative workflow authoring solution based upon Microsoft Exchange Server. Microsoft Exchange is a powerful messaging and collaboration platform. It provides infrastructure needed for a workflow, such as user directories, work transport, security, customizable forms and views, and database that can be used to store work items and process templates. Keyflow expands the Exchange features by leveraging the messaging environment and the software is designed for automating core office processes. Keyflow schemas can be opened Microsoft Outlook 97/98 messaging client program as shown in Figure 4.

Keyflow includes drag-and-drop based graphical workflow designer which is shown in Figure 5. Step characteristics are defined by completing dialogue pages that guide the user through the process. Conditional routing is handled in the same dialogue-driven fashion, which allows users to build Boolean expressions between steps. A step execution can be implemented using sophisticated “voting” techniques, in which a particular route is taken, based upon a percentage of participants choosing a particular response. This tool does not support standard Serial or Parallel blocks. These features can be implemented by defining Boolean expressions in step properties. But this process does not represent visual block structure.

Figure 4: Microsoft Outlook Messaging Client

http://www.keyfile.com/products/keyflow/index.htm

3. Ultimus (Web-Based Workflow Solution)

Figure 5: KeyFlow Workflow Designer

The Ultimus Workflow Application [Ultimus, http://www.ultimus1.com] is categorized as an integrated process automation development environment. Ultimus’ architecture is comprised of a set of separate software components. One of them is the Ultimus Workflow Designer.

The Ultimus Workflow Designer (Figure 6) is a graphical development environment for defining process flows. Users can build applications by selecting from either preconfigured tasks, or from a custom-built library.Ultimus supports three different type of steps for defining process steps:

Users steps: These are tasks that are done by people, such as a form filling. Flobot steps: An Ultimus flobot step represents a task that is done by third-party

applications. Ultimus provide predefined flobots for integration with Microsoft Word, Microsoft Excel, ODBC-compliant database, and SMTP (Simple Messaging Transfer Protocol) applications.

Maplet steps: These are tasks performed in other workflow processes. A very valuable capability of the designer is the ability to break down a complex, multi-departmental process into segments, each of which can be defined by the particular segments. Then when the overall process is defined, these segments can be brought into the map as Maplet steps.

Linking Steps Together: Steps are tied together with graphical links. The designer draws a line from on step to another in the direction the work is to flow.

Defining the Properties of the Steps. The details specifying who, what, and when of each step are defined.

Key properties include: Recipients: In Ultimus tasks can be assigned to workflow participants and job

functions, groups, queues, reporting. Business rules can also be defined that indicate who should receive a task based on the specific incident of the workflow.

Completion and Extension Time: Each step has a completion time. This points that how long it takes to accomplish the task. Based on this timeline, the system automatically determines the status of the step as current, overdue, or urgent.

Task Rate: Ultimus allows the user to capture the cost of the person doing the work. This cost is calculated by the amount of time the step actually took to complete; when a task is completed a prompt appears asking the user how much time he or she spent on the step. The system keeps track of lapsed time, the reported task time, and the cost. By knowing the cost of each step, the cost of each incident can be calculated. This data can be used to generate process metrics so the manager can understand the cost of doing business.

Conditions: Ultimus provides forms to define a company’s business logic. The user specifies in an Event Condition Table what should happen when the step is activated, completed, late, rejected, or resubmitted. In addition, users can define specific conditions under which the standard conditions are overridden, such as when the incident is cancelled. The entire conditional rules are defined in the Ultimus Distributed Spreadsheet Model (DSM).

The Ultimus Workflow Designer contains an integrated simulation module. This component allows for validation of routing logic, testing of workloads, and verifying the tasks. The designer also contains an organization chart module. It facilitates the graphical representation of organizational structures, allowing process logic to be defined in terms of roles and relationships. This component can also operate a stand-alone application form managing organizational roles and relationships.

Figure 6: Ultimus Workflow Designer

http://www.ultimus1.com/

III. Comparisons with the MARIFlow System

A chart comparing the features of these products with the MARIFlow system is presented in the Appendix. MARIFlow system provides the basic expected functionality of the workflow systems and is the only one that is based on a truly distributed cooperating agent infrastructure over the Internet. That is all the other systems have client-server architecture (both Keyflow and Ultimus are installed on a single machine) and therefore comes to a complete stop when the server fails and also needs load balancing. MARIFlow is platform independent and is designed and implemented by taking the application requirements of maritime industry. MARIFlow does not depend on any commercial software; the software used (Postgres DBMS and Java) are public domain.

References

[Action Technologies] http://www.actiontech.com/Metro/index.html

[Alonso 96] G. Alonso, R. Gunthor, M. Kamath, D. Agrawal, A. El Abbadi, C. Mohan, "Exotica/FDMC: A Workflow Management System for Mobile and Disconnected Clients", Parallel and Distributed Databases, Vol.4, No.3, 1996.

[Dogac 98 a] A. Dogac, L. Kalinichenko, T. Ozsu, A. Sheth (Edtrs.), Workflow Management Systems and Interoperability, NATO ASI Series, Springer-Verlag, 1998

[Dogac 98 b] A. Dogac, E. Gokkoca, S. Arpinar, P. Koksal, I. Cingil, B.Arpinar, N. Tatbul, P. Karagoz, U. Halici, and M. Altinel, "Design and Implementation of a Distributed Workflow Management System: METUFlow", in [Dogac 98 a], pp. 61-91.

http://www.actiontech.com/Metro/index.html

[Georgakopoulos 95] D. Georgakopoulos, M. Hornick, A. Sheth, "An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure", Distributed and Parallel Databases, Ahmed K. Elmagarmid (Ed-in-chief), Vol. 3, No. 2, 1995, pp. 119-153.

[Eder 98] J. Eder, H. Groiss, W. Liebhart, "The Workflow Management System Panta Rhei", in [Dogac 98 a], pp.129-144. [Hollingsworth 96] D. Hollingsworth, “The Workflow Reference Model", Technical Report TC00-1003, Workflow Management Coalition, December 1996. Accessible via: http://www.wfmc.org.

[IBM MQSeries] http://www.ibm.com/software/ts/mqseries

[Keyflow] http://www.keyfile.com/products/keyflow/index.htm

[Microsoft Exchange] http://www.microsoft.com/exchange/productinfo.htm,http://www.microsoft.com/exchange/Collaboration.htm,http://www.microsoft.com/exchange/DeployAdmin/

DeployAdmin.htm.

[Miller 97] J. Miller, D. Palaniswami, A. Sheth, K. Kochut, H. Singh, (1997), "WebWork: METEOR2's Web-based Workflow Management System", Journal of Intelligent Information Systems, 1997.

[Muth 98] P. Muth, D. Wodtke, J. Weissenfels, G. Weikum, A. Dittrich, "Enterprise-Wide Workflow Management Based on State and Activity Charts", in [Dogac 98 a], pp. 281-303.

[Reuter 95] A. Reuter and F. Schwenkreis, “ConTracts – A Low-level Mechanism for Building General Purpose Workflow Management Systems”, In Bulletin of TC on Data Engineering, March 1995.

[Shan 98] M-C Shan, J. Davis, W. Du, Y. Huang, "HP Workflow Research: Past, Present, and Future", in [Dogac 98 a], pp. 92-106.

[Sheth 98] A. Sheth, K. J. Kochut, "Workflow Applications to Research Agenda: Scalable and Dynamic Work Coordination and Collaboration Systems", in [Dogac 98 a], pp. 35-60.

[Sheth 96] A. Sheth, D. Georgakopoulos, S. Joosten, M. Rusinkiewicz, W. Scacchi, J. Wileden, and A. Wolf, "Report from the NSF Workshop on Workflow and Process Automation in Information Systems", Sigmod Record, Vol. 25, No. 4, pp. 55-67, December 1996.

[Ultimus] http://www.ultimus1.com

http://www.ultimus1.com/

http://www.microsoft.com/exchange/DeployAdmin/DeployAdmin.htm

http://www.microsoft.com/exchange/DeployAdmin/DeployAdmin.htm

http://www.microsoft.com/exchange/Collaboration.htm

http://www.microsoft.com/exchange/productinfo.htm

http://www.keyfile.com/products/keyflow/index.htm

http://www.ibm.com/software/ts/mqseries

http://www.wfmc.org/

Standards for Workflows

The major resource of workflow standards is the Workflow Management Coalition (WfMC) which is a non-profit, international organization of workflow vendors, customers and users whose mission is to promote the use of workflow through the establishment of standards for software terminology, interoperability and connectivity between workflow products. The Coalition has defined a Workflow Reference Model and has published standards for the Workflow Application Client, the Workflow Interoperability interfaces and Audit Data formats. The Workflow Reference ModelThe Workflow Reference Model has been developed from generic workflow application structure by identifying the interfaces within this structure that enable products to interoperate at a variety of levels. All workflow systems contain a number of generic components that interact in a defined set of ways; different products will typically exhibit different levels of capability within each of these generic components. To achieve interoperability between workflow products a standardized set of interfaces and data interchange formats between such components is necessary.

Figure 1 illustrates the major components and interfaces within the workflow architecture.

The purpose of the WfMC Process Definition Interchange interface is to describe a common interface for the exchange of workflow process definitions. This interface is based on a standardised language - the Workflow Process Definition Language, "WPDL" - which can be supported by vendors of workflow management products to allow the exchange and documentation of workflow process definitions.WfMC’s workflow primitives allow to model:· parallel paths· AND / OR routing conditions (SPLIT),· AND / OR rendezvous linkages (JOIN)Activities can have states such as:· in process· suspended· resumeable· completedAnd, of course activities have roles or performers associated with them.

Figure 1: Workflow Reference Model – Components & Interfaces

InterfacesInterfaces

Work Progress Overview

In this section, for each task that was active during this reporting period, first a short description of the objective of the task is presented, followed by the description of the achievements and responsibilities of the partners.

TASK 2.2 Handling Heterogeneity, Interoperability and Adaptability

Objective

With the current architectures and technologies the most relevant aspects of this task has been subsumed in other tasks, mainly those related to the development, installation and utilization of the prototypes. Interfacing issues are now studied in task 2.7 (new version).

This task is now obsolete and will not be further pursued as such.

TASK 2.3 Availability and Scalability

Objective

Implementation of final architectural design for scalability and availability. As an extension to this task, ETHZ will explore the use of the WISE engine as a centralized alternative to the system being designed at METU. A prototype system will be developed and, using this prototype, several ideas related to scalability and availability will be explored.

Achievements

The implementation proceeds according to plan. At the time of writing this document, a meeting with the industrial partners is being scheduled as part of the formal release. The prototype based on WISE has been tested (in ETHZ) for stability and easy installation. Documentation is being written. In the design decisions, ETHZ has followed closely the deployment of the METU prototype in order to avoid the problems encountred, namely choice and configuration of the database, problems with firewalls and interconnectivity, and problems with the installation. These are common hurdles in the development of any system and we are paying close attention to the experience gathered by METU to speed up the deployment process.

The current prototype is a version of the WISE engine that has been tailored to the MariFlow requirements. This tailoring includes the incorporation of a commercial tool for process design and monitoring, which will allow a more sophisticated process design and will set up the basis for iteroperability with other engines (like METU’s). In

addition, we have revisited the source code to make it operating system independent. The final goal, if time and resources allow, is to have a system capable of running both in Solaris and Linux. Similarly, and given the disparity of the database management systems used by the industrial partners, the current prototype has resorted to an ad-hoc, internall developed database that is delivered wih the prototype. That way, in this first stage, there is no need to worry about database configurations and different database systems. In future releases we will more closely look the database problem to ensure it can be used with commercial and freeware systems.

Responsibilities

Following table summarises responsibilities and achievements of partners in this task:

Responsibility Partner Status

Implementation of alternative prototype

ETHZ First release of the system (April, 2000) has been

completed. Deployment at industrial partners in May,

2000.

Task responsible: ETHZ

Involved partners: ETHZ, GL, BAL

Deliverable

Deliverable 2.3: Availability and scalability report (Document deliverable) and software prototype (Prototype deliverable)

Responsible: ETHZ

Due date: Month 24 (September 15, 2000)

TASK 2.4 Data Consistency and Execution Guarantees

Objective

Implementation of the final architectural design that permits execution of multiple, concurrent workflows and workflow instances as well as data consistency. As part of this task, ETHZ will explore, together with HU, different issues related to concurrency control and recovery in the context of workflow systems. Resources allocated to this task is shifted to Task 2.3 (both within ETHZ).

Achievements

Classical transaction management operates under certain basic assumptions about transactions properties. To extend transactional protocols to domains such as process and workflow management, one has to consider whether the basic assumptions hold. If not, then both the theory and the protocols must be carefully considered, and possibly extended or changed. We have examined this issue for processes, following work done at ETH over the last few years on this subject. One of the basic assumptions about transactions is that either all operations of a transaction can be undone, as long as the transaction has not committed, or when this is not the case, the irreversible operations can be deferred to the end, and executed as part of the commit protocol, or even after the commit. This implies that a transaction can be aborted at any time, until it decides to commit, and then it has no more requests actions to be performed. In other words, a transaction enjoys the guaranteed termination property: Its execution can always be terminated, by aborting it or by committing it. This, in turn, has an impact on concurrency control as well, because of the close relationship between atomicity and isolation in the common protocols, in particular in the assumption that cycles in conflict graphs can always be resolved by aborting one or more transactions. But, this basic assumption fails for processes. These are longer than transactions, they are composed of activities that are themselves transactions on some underlying databases, and most importantly, may contain irreversible activities in the middle of their execution, that cannot be deferred to the end. These activities are points of no return for processes. And, they are followed by other activities.

We have explored the implication of this change of basic assumption on the transactional protocols for processes. First, we identified and defined the property of guaranteed termination for processes. This entails assuming a certain structure for process programs, that generalizes the Flex transaction model. This structure guarantees that a process can always terminate, either by aborting, or if it has passed a no-return point, by proceeding to a successful end, along a path that is guaranteed to exist. Other alternatives, that may be tried before this path, also exist, and they have recursively a similar structure. Second, since process aborts cannot always be used to resolve conflict cycles, we have explored the restrictions that are necessary on process scheduling to guarantee that schedules are always serializable, and that irresolvable deadlocks cannot occur. Finally, we have surveyed a number of related process and workflow models and projects.

The work is summarized in Deliverable 2.4

Responsibilities


Correctness guarantees for concurrent workflow

executions

METU, ETHZ, Hebrew, SZAG

Achieved

Data consistency between several databases within

one process

ETHZ, Hebrew, SZAG Achieved

Task responsible: Hebrew

Involved partners: Hebrew, METU, ETHZ, SZAG

Deliverable

Deliverable 2.4: Document on consistency (Document deliverable)

Responsible: Hebrew

Due date: Month 20 (May 15,2000).

TASK 2.5 Implementation of Authentication and Authorisation Module

Objective

Implementation of the authentication and authorisation module, which allows evaluation of electronic signature mechanism, ensures combined distribution of documents and signatures, and allows intra-organisational access.

Achievements

The services that need to be supplied by the security and authentication module can be summarized as follows: It has to ensure: confidentiality of messages, so only the sending and receiving parties can read it; authentication of messages, that is guaranteeing the identity of the perceived sender; and integrity of messages so a receiving party can be sure they have not been tampered with. Similar services are needed for documents, which differ from messages in being long-lived. In terms of operational requirements, all communications in Mariflow need the services above, hence have to be handled by the security manager. This includes communications between two MARCAs, between a UMIA and its associated MARCA, and also intra-company or inter-company communications that utilize the Mariflow services. The services need to apply to each level of communication, so each level should use the security services, independently of the others.

We have considered some publicly available services, such as SSL and PGP, and concluded that they are large, and may prove to be difficult to integrate with the Mariflow software. Instead, we have chosen a Java-based solution. A basic architecture for security services is defined in Java, and some extensions providing a higher level of security are also defined. These were not (at the time) export-able out of the USA, but we found a public domain implementation of the services. We have added to this implementation a software layer that provides the services above, and is compatible with the requirements. It supplies the services through a small set of calls to an interface object. The software has been tested, then handled to the main Mariflow software team, that integrated it into the Mariflow software.

Responsibilities


Evaluation of electronic signature mechanism

Hebrew, BAL, GL, SZAG Achieved

Implementation of a module which ensures the

combined distribution of documents and signatures


Implementation of an intra-organisational access

module


Task responsible: Hebrew

Involved partners: Hebrew, BAL, GL, SZAG

Deliverable

Deliverable 2.5: Implementation of the authorisation module

Responsible: Hebrew

Due date: Month 15 (December 15, 1999).

TASK 2.6 Conforming to Electronic Data Interchange Format

Objective

Implementation of equivalent EDIFACT subset that guarantees that the system conforms to existing standards.

Responsibilities


Guaranteeing that the system conforms to existing

standards

GL, BAL, SZAG In progress

Implementation of equivalent EDIFACT subset


Task responsible: BAL

Involved partners: GL, BAL, SZAG

Deliverable

Deliverable 2.6: Implementation of the equivalent EDIFACT subset

Responsible: BAL


Achievements

The information (certificates) to be exchanged between steelmills, classification societies and their customers (component supplier, shipyards, ship operators, owners) are represented in the EDIFACT message type QALITY. This has been proven by successfully applying the relevant certificate information of SZAG to these EDIFACT data structure. The extension of the capabilities of the data to be exchanged towards future requirements like eCommerce compatibility and easy adaptability to inhouse formats translation of QALITY messages into XML was investigated. As a result of this very promising development as well as the additional features of XML (compared to EDIFACT QALITY message), GL decided to import the QALITY message as a XML file which will be configured according a DTD defined by GL.

By now successful conversion of QALITY messages delivered from SZAG into XML according to the EDIFACT message structure and subsequent mapping to the XML structure required by GL was done by the BALance Data Integration environment.

For more details (messages, mapping tables, DTD's etc. see Del. 2.6).

Responsibilities


Guaranteeing that the system conforms to existing

standards


Implementation of equivalent EDIFACT subset


Task responsible: BAL


Deliverable

Deliverable 2.6: Implementation of the equivalent EDIFACT subset

Responsible: BAL


TASK 2.7 System Integration and Development

Objective

Implementation of the current systems at all partner sites, which include incorporation of different modules into the overall system, release control, code management, implementation of EDI functionality for the application systems, and integration of workflow system and existing application systems.

Achievements

Different modules related with Failure Recovery, Authorisation and Authentication are integrated to the prototype. The prototype has been revised and modified to include the following extensions:

During the initialization of the system a message is sent to the user telling that the workflow has started. After the worklfow has started the user is able to start an instance in the workflow. To enable the execution of workflows that involve iterative tasks a WHILE-BLOCK module was introduced to the system. When called, this module executes the tasks within its scope until the test statement evaluates to false.

Additional modules have been designed and implemented to enable the cooperation between the system and the existing applications. These modules are designed to invoke the existing in-house applications inside the company domain. With the help of these modules a task in a workflow may be assigned one or more applications. There is a User MARCA Interfacing Application (UMIA) and a server inside the firewall, namely the Application Server. The Application Server reads the incoming mails and informs the UMIA accordingly. In order to invoke external applications automatically within the MARIFlow System, a mapping should be provided from the activities defined in the workflow definition to the external applications in the company domain. This mapping is achieved through a graphical user interface which is a part of the UMIA that also allows parameteres of the application to be specified. If the invocation is to be done manually, i.e, no mapping is defined, then the user invokes the task from the UMIA.

The reliability of the system is extended by adding new modules into the prototype. Communication subsystem is made more secure by allowing the kernel to monitor the execution of the subsystem. In order for the communication to be reliable the communication system should recover from any possible failures, retry the operation when possible and inform the user program if the request can not be issued. These failures may be encountered during communication between two agents, or communication with a database system or a mail server. The errors from these failures can be categorized as, Connection Errors, Communication Errors, Protocol Dependent Errors. When an error of these categories occurs, the communication system closes the connection and cleans up any temporary resources. After a certain amount of time the whole operation is tried again. If the communication fails in all tries, because of any of the reasons stated above, the user program is informed of the failure. The task owning the program is informed of the failure. The Task owning

the failed request is aborted, the compensation activity is started and afterwards the workflow is rolled back if there is no contingency activity belonging to that task.

The following enhancements done on the prototype allows the system to recover from failures.

- During our analysis of the execution of the system we have observed that certain activities, like the archival of a document by a MARCA may take long to execute or may fail. This may cause unnecessary delays or even unsuccessful termination of the whole process. To handle such cases we provide the workflow designer with the ability to define activities with a NON_VITAL attribute. The successful termination of these activities becomes the responsibility of the exception handler which handles the failure by possibly attempting it several times before invoking a manual user task. If this failure state persists a manual activity is required for the exception to be handled and an informing mail is sent to the super-user. Non vital activities are assumed to terminate successfully as soon as they start. However if they fail, they raise an exception. For example for a document archival, if this activity is declared as non vital, the workflow can continue assuming that the document is archived as soon as it is invoked. If the activity fails, an exception is raised and the exception handler makes sure that the document is properly archived. As a summary, the functionality provided by the non vital activities is to delegate certain tasks to the exception handler so that it can run in parallel with the workflow process itself. It should be noted that a workflow process instance will terminate only when all the exceptions raised during its flow are properly handled.

- Each MARCA stores all the documents and messages it receives persistently in its database. The information stored also serves the purposes of a log, that is, after a crash, a MARCA can be brought back to a consistent state by using this information. Each MARCA sends a copy of the information it receives to the central database for monitoring purposes. The user is also given the ability to assign databases stored in different places to different workflow instances.

- In order to recover from errors, for each MARCA installed there is a background process at that site, called the “rescue process”. The rescue process is responsible for monitoring the lifetime of the agent and checks the MARCA at specific time intervals through a predetermined socket. A thread of the MARCA listens to this socket and responds to the signals. If the MARCA does not respond to this process for a given period of time, the process starts sending signals more frequently. If the MARCA still does not respond, after sending a bunch of signals the process assumes that the MARCA is not functional. The two possibilities in this case are: the MARCA could be blocked or it could be dead. When the rescue process is unable to find the OS process that belongs to this MARCA (i.e. it is dead), it instantiates a new MARCA by the help of the persistent logs related with the state of the agent. Otherwise if the MARCA is blocked, it is necessary to kill the old instance prior to installation of a new instance of a new instance. Since the logs are persistent it is possible recover the state of the MARCA killed and hence the site does not suffer from any inconsistencies.

- Effects of the terminated activities of failed workflow instances are undone through compensation activities. If there is a compensation activity for the whole block this one is used. Otherwise the compensation activities, which may be defined using the Process Definition Tool, of the involved activities are used to

roll back the block. The logs of every instance kept by the system are used for this purpose.

Authorization and authentication modules were integrated to the system in order to eliminate security holes. These modules ensure that any messages exchanged throughout the execution of the system may not be observed by other people. Authentication module helps the receivers identify the origins of the message.

- The participants, namely the MARCAs and the User-MARCA-Interfacing-Applications (UMIAs for short), and their aliases are known and fixed throughout the MARIFlow scenario. A trusted party exists in the system, whose alias and public key are known to all participants. That trusted party generates a pair of public-private keys for each participant and encrypts each pair using his private key. The steady state of the system is the state when the components have all the information they need to communicate with each other. This information is the following: Each UMIA and each MARCA has a pair of public/private keys. Each component knows its own private key. Each MARCA knows the public keys of all other MARCAs, and of its corresponding UMIA. A UMIA knows both the public and the private keys of itself and of the corresponding MARCA. Each MARCA and UMIA has a name, referred to as an alias, such that a MARCA knows the aliases of all other MARCAs and of its UMIA. The keys are known to each participant in the form of key-alias pairs. In the current architecture, it is the case that a UMIA does not send messages to specific UMIAs - a UMIA does not have the information about the process definition. Hence, there is a need for an alias that represents all UMIAs, and also a pair of keys for this virtual UMIA. Encryption of a message by a UMIA is done using this virtual UMIA as a receiver, and each UMIA can decrypt the message, since all UMIAs know the keys of this virtual UMIA.

- Then the messages sent throughout the scenario are encrypted and decrypted using the Privacy Class supported. The use of the encryption and decryption methods are simple. A message is prepared for a "MARCA - MARCA" or a "UMIA - MARCA" communication. Before the message is sent, it is encrypted using the encryption method. When it is received at the other hand, it is immediately opened using the decryption method. The rest is normal processing, in the MARCA or UMIA.

The integration of the modules into the system are completed.

Responsibilities


Incorporation of the different modules into the overall

system

GL, BAL, SZAG, ISISAN, METU, ETHZ, Hebrew

Achieved

Control of releases and code management

METU, ETHZ, Hebrew In progress

Implementation of EDI functionality for the application systems

BAL In progress

Integration of workflow system and existing application systems

METU,GL, BAL, SZAG, ETHZ, Hebrew

In progress

Task responsible: METU

Involved partners: METU, GL, BAL, SZAG, ISISAN, ETHZ, Hebrew

DeliverableDeliverable 2.7: Implementation of the current systems at all partner sites

Responsible: METU

Due date: Month 18 (March 15,2000).

TASK 3.1 Implementation of the Quality Chain

Objective

First prototype being in use at the end users with dummy data exchange, which includes test data (dummy data) preparation, module and system configuration, bilateral/multilateral scenario and intra-organisational connection implementation, and testing of authentication and authorisation module.

Achievements

Since mid of 1999 several versions of the software have been released and delivered towards the industrial partners. First steps of installation and testing of the software took place and revealed a number of problems, which have been recorded and partly fixed in the new releases. Main problems were related to usage of corporate firewalls, databases (restricted access rights, slow connections, time outs, inflexible JDBC strings), non-availability of specific commercial data bases and database drivers. This led to clarification of system hardware and software requirements, the need for enhanced installation and usage guidelines and a code versioning system.

The development, installation and testing of two complementary workflow tools requires additional effort for installation, adaptation, testing, evaluation and feedback.

Based on the business scenario described in Del. 1.2 a multilateral scenario has been chosen for implementation. These test data have been defined by analysing sample documents of the classification society and the steel supplier. All sample documents provided relate to the same order. Thus it will be easier to track documents over time. In the first phase, the test data are focusing on steel orders. The next step will be the generation of quality data referring to the order data and the configuration of the data exchange modules. Based on the results from task 2.6, various XML data sets have been prepared by transforming existing EDIFACT QALITY messages. Other XML data sets have been created manually in accordance to real certification documents. Graphical representations for inspection reports and inspection certificates have been collected in PDF format. By now, samples for the complete range of data and documents to be supported in the project are available.

Responsibilities


Preparation of test data (dummy data)

GL, BAL, SZAG Achieved

Configuration of the modules


Implementation of a bilateral scenario


Implementation of a multilateral scenario


Implementation of the intra-organisational connections


Test of the authentication and authorisation module


Task responsible: GL


DeliverableDeliverable 3.1: First prototype in use at the end users with dummy data exchange.

Responsible: GL

Due date: Month 20 (May 15, 2000).

TASK 3.3 Providing Continuous Feedback to the System Design and Development

Objective

Formal and informal user test reports and continuous feedback to the system design and development, and practical test of modules and systems in a real environment operated by the users. Use of the prototype in production.

Achievements

The first version of the prototype is received in January 2000. One of the user requirements’ was to use a public domain database in the MARIFlow system and therefore Postgres access is added to the system. Copies of the mails exchanged during test runs are available from the project home pagehttp://www.srdc.metu.edu.tr/mariflow/tests

Responsibilities


Practical test of modules and systems in a real

environment operated by users

GL, BAL, SZAG, ISISAN In progress

Useage of the prototype in a real production

GL, BAL, SZAG, ISISAN Not started yet

Providing continuous feedback to system design

and development

GL, BAL, SZAG, ISISAN In progress

Task responsible: SZAG

Involved partners: SZAG, GL, BAL, ISISAN

Deliverable

Deliverable 3.3: Formal and informal test reports.

Responsible: SZAG

Due date: Month 27 (December 15,2000).

http://www.srdc.metu.edu.tr/mariflow/tests

TASK 3.4 Final Code Release

Objective

Delivery of final system to the users

Achievements

The code release has started with development of the second prototype.The implemented prototype has been revised and modified to include all of the system functionalites and has been installed at industrial partners’ sites. This system is currently being tested and modified according to the bug and maitenance reports from the companies, and final version of the code will be released after realizing the necessary modifications.

Responsibilities


Final system delivery to users

METU, ETHZ, Hebrew In progress


Involved partners: METU, ETHZ, Hebrew

Deliverable

Deliverable 3.4: Final system delivered to the users.

Responsible: METU


TASK 4.1 Administrative Management

Objective

Preparation of financial reports include:

a) Periodic Cost Statements (PCS)

b) Consolidated Cost Statements

Achievements

Administrative project management tasks progressed in accordance to the Technical Annex. A financial report was prepared according to the guidelines based on individual Periodic Cost Statements from each partner. After double checking against the previously submitted Task Level Summary reports, a Cost Statement Summary was compiled and submitted to the Commission. Upon release of the new payment the shares were distributed among the project partners. Not all costs items were approved as submitted, therefore further communication with the Commission was necessary. Additional cost details (person names, exchange rates) were collected and provided to the Commission. For the running period, new data from TLS were collected. Assistance was provided to the technical manager for organisation of technical meetings and workshops. An overview of resources in the project was prepared and made available.

Responsibilities


Periodic Cost Statement Delivery

GL Achieved

Consolidated Cost Statement Delivery

GL Not started

Task responsible: GL

Involved partners: GL

TASK 4.2 Technical Management

Objective

Co-ordination of Requirements and Specifications, Systems Development, Project Milestones and Deliverables, End Users and Developers. This task also includes delivering Periodic Management Reports, 6-monthly.

Achievements

Three Periodic Management Reports have been released within first 18 months of the project. Systems development, project milestones, deliverables and end users and developers have also been co-ordinated within this period.

Responsibilities


Co-ordination of Requirements and

Specifications

METU In progress

Co-ordination of Systems Development

METU In progress

Co-ordination of Project Milestones and Deliverables

METU In progress

Co-ordination of End-Users and Developers

METU In progress

Periodic Progress Report Delivery

METU In progress

Final Report Delivery METU Not started


Involved partners: METU

TASK 4.3 Dissemination of Results

Objective

Dissemination of the project results to a widest audience possible through publications and workshops.

Achievements

The project is presented at the “16th International Conference on Data Engineering” in San Diego, USA on March 1st, 2000

A project web site has been set up by the project leader. http://www.srdc.metu.edu.tr/mariflow/index.html

Individual web pages have been setup by various partners (e.g. http://research.germanlloyd.de/Projects/MARIFLOW/mariflow.html, …)

http://www.balance-bremen.de/balance/mariflow_e.htm

Responsibilities


Deliverables METU, GL, BAL, SZAG In progress


Involved partners: METU, GL, BAL, SZAG

Information dissemination activities

The following publications are realized within this reporting period:

Dogac A., Ezbiderli M., Tambag Y., Icdem C., Tumer A., Tatbul N., Hamali N., Beeri C. “The MARIFlow Workflow Management System”, in “16 th

International Conference on Data Engineering” in San Diego, USA on March 1st, 2000.

Dogac, A., Beeri, C., Ezbiderli, M., Tatbul, M., Icdem, C., Erus, G., Cetinkaya, Dogac, A., Ezbiderli M., Tatbul, N., Icdem, C., Erus, G., Cetinkaya, O., Tumer, A., Beeri, C., "A Workflow System through Cooperating Agents for Document Flow over the Internet", Technical Report.

Cingil, I., Dogac, A., Tatbul, N., Arpinar, S., "An Adaptable Workflow System Architecture on the Internet for Electronic Commerce Applications", In Proc. of Intl. Symposium on Distributed Object Applications, Edinburgh, September 1999.

http://www.srdc.metu.edu.tr/mariflow/marcaarc.ps

http://www.srdc.metu.edu.tr/mariflow/marcaarc.ps

Hagen, C., Alonso, G., “Highly available Process Support Systems implementing backup mechanisms”, 18th IEEE Symp on Reliable Distributed Systems (SRDS'99), Lausanne, Switzerland, October, 1999.

Schuldt, H., Popovici, A., Schek, H.-J., “Give me all I pay for – Execution Guarantees in Electronic Commerce Payment Processes” , In Proc. of the Informatik’99 Workshop “Unternehmensweite und unternehmens-übergreifende Workflows: Konzepte, Systeme, Anwendungen”, Paderborn, Germany, October 1999.

DELIVERABLES TABLE

Project Number: INCO DC 97-2496 Project Acronym: MARIFlow

Title: A Workflow Management System for Maritime Industry

Del. No. RevisionTitle Type Classification Due Date Issue DateDeliverable 2.4 1 Implementation of final architectural

design for data consistencyReport Restricted December 15, 1999 April 11, 2000

Deliverable 2.5 4 Implementation of authorisation module. Prototype Restricted December 15, 1999 December 31, 1999Deliverable 2.6 1 Implementation of equivalent EDIFACT

subset.Prototype Restricted December 15, 1999 June 2000

Deliverable 2.7 4 Implementation of current systems at all partner sites.

Prototype Restricted March 15, 2000 March 23, 2000

DELIVERABLES SUMMARY SHEET

Project Number: INCO DC 97-2496



Deliverable No: 2.4 Due Date: December 15, 1999 Delivery Date: April 11,2000

Short Description: Final Architectural Design for Data Consistency and Execution Guarantees

Partners owning: Hebrew

Partners contributed: ETHZ,METU,SZAGMade available to: All





Deliverable No: 2.5 Due Date: December 15, 1999 Delivery Date: Dec 31, 1999

Short Description: Implementation of authorisation module.

Partners owning: Hebrew

Partners contributed: BAL, GL, SZAGMade available to: All





Deliverable No: 2.6 Due Date: December 15, 1999 Delivery Date: June 2000

Short Description: Implementation of equivalent EDIFACT subset.

Partners owning: BAL

Partners contributed: GL, BAL, SZAGMade available to: All





Deliverable No: 2.7 Due Date: March 15, 2000 Delivery Date: March 23, 2000

Short Description: Implementation of current systems at all partner sites.

Partners owning: METU

Partners contributed: GL, BAL, SZAG, ISISAN, ETHZ, Hebrew Made available to: All

Planned Work for the Next Reporting Period

The following is the list of tasks that will be active for the next reporting period. The due dates of deliverables and the current progress related with the deliverables that will be completed in the next reporting period are already presented in the previous section.

Work Package 2: Prototype and System Development

Leader: METU

Duration: Months 7-24

Task 2.3: Availability and Scalability


Responsible: ETHZ

Task 2.4: Data Consistency and Execution Guarantees


Responsible: HEBREW

Work Package 3: Prototype Demonstrator

Leader: SZAG


Task 3.1: Implementing the Quality Chain


Responsible: GL

Task 3.3: Providing continuous feedback to the system design and development


Responsible: SZAG

Task 3.4: Final Code Release


Responsible: METU

Work Package 4: Management and Dissemination of Results

Leader: METU


Task 4.1: Administrative management


Responsible: GL

Task 4.2: Technical management


Responsible: METU

Task 4.3: Dissemination of Results


Responsible: METU

APPENDIX: A Comparison of Workflow Systems