progress report2.doc

Progress Report

Project Number: INCO- DC 97-2496

Title: A Workflow Management System for the Maritime Industry

Project Acronym: MARIFlow

Report No: 2 Year: 1999 Month: September

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

Names of editors and/or authors and their organisations:

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

Report Preparation Date: September 15, 1999

Report Version: V 1.0

Classification: Public

Executive Summary

MARIFlow project has started on the 15 th of September 1998. The work accomplished during the first six months of the project is presented in Management Report No 1. As a summary, first six months of the project consisted of the work package No 1, which includes tasks related to the requirements 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) is 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 this reporting period (Management Report 2), these concepts have been extended so that a new prototype, containing much of the required functionality the system, has been designed, implemented and tested. Following is a brief description of the work accomplished during months 6-12 of the project:

1. A detailed design of the system has been completed (Deliverable 1.3). This design contains necessary architectural issues related to workflow specification language, workflow enactment service, optimization and availability of the system, performance considerations, concurrency control and authorization and authentication.

2. A prototype of the system has been implemented (Deliverable 2.1). The prototype has been extended from the previous one, and now contains much additional functionality related to system initialization, workflow enactment and monitoring of workflow processes, as well as a fully documented object-oriented design.

3. A completely distributed architecture, based on cooperating agents have been introduced by the new prototype, where each agent in the system has its own workflow engine, and each executing parts of the overall workflow specification. Task managers and worklist managers of the agents are also implemented (Task 2.1, Task 2.7, Task 3.4).

4. The interfaces necessary to invoke tasks or sub-processes in other companies’ domains (probably on different platforms) have been designed (Task 2.2), to handle heterogeneity, interoperability and adaptability issues.

5. A preliminary analysis of the mechanisms that could be used to increase the availability and scalability of the overall system is underway. Current test results prove that the techniques selected are very promising. A paper with test results has been published and more work in this direction is planned (Task 2.3).

6. Concurrent executions of workflows have been investigated and elaborated in great detail. Results have been published in the Parallel and Distributed Systems Journal. Data consistency (correctness of single processes) and correctness with respect to concurrent executions including failure recovery has been achieved by extending the unified

theory of concurrency control and recovery to general configurations and to arbitrary process structures (Task 2.4). Both extensions have been presented at the renowned PODS’99.

7. Implementation of the authentication and authorization module, which provides evaluation of an electronic signature mechanism, ensures combined distribution of documents and signatures, and allows intra – organizational access, is progressing (Task 2.5).

8. Implementation of equivalent EDIFACT subset, which guarantees that the system conforms to existing international standards, is progressing (Task 2.6).

9. Implementation of current systems at all partner sites, which includes incorporation of different modules into the overall system, control of release, code management, EDIFACT functionality implementation and existing application systems integration is progressing (Task 2.7).

10. Implementation of Quality Chain, which includes test data (dummy data) preparation, module and system configuration, implementation of bilateral/multilateral scenario and intra-organizational connections, and testing of authorization and authentication module is progressing (Task 3.1).

11. All partners (Task 3.3) provide continuous feedback to system design and development.

12. Release of final code is progressing (Task 3.4).

Charts enclosed provide the resource utilization information for this reporting period, as well as for the next reporting period. For the two tasks completed within this reporting period (Task 1.3 and Task 2.1), the related deliverables (Deliverable 1.3 and Deliverable 2.1) contain detailed description.

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 1.3 – System Architecture

Objective

Specification of the detailed architecture of the workflow environment.

Achievements

Following has been achieved within the scope of Task 1.3:

1. Requirements of the users have been tested on the initial prototype and appropriate changes have been made on the design.

2. A new communication infrastructure, which consists of three distinct layers, based on persistent queues and 2 Phase Commitment Protocol (2PC) is introduced.

3. All of the system architecture is re-modelled with UML diagrams to better visualise the system modules, packages and their interrelationships.

4. A new prototype has been implemented.

As indicated in Management Report No 1, MARIFlow project helps in automating complex business processes, which include flow of documents between companies over the Internet. The architecture introduced is applicable to any business domain, current application domain being the maritime industry.

The current prototype has mainly the following functionalities:

1. A completely distributed architecture, where there are distinct autonomous nodes at each site, executing parts of the process definition. The collection of all tasks executed on different nodes following the control and data flow defined in the workflow specification leads to an overall workflow process.

2. Agents on different nodes of the network, each having the capability to send/receive messages, documents, informing the user (who might be inside a firewall in a company domain) through e-mails, updating documents and monitoring databases, and processing all information provided by the user. Each agent can also decide on its future actions, by using the event messages retrieved from other agents.

3. A layered communication infrastructure, where each layer has its own set of tasks, providing service primitives to one level up. Encryption/decryption of messages, 2PC implementation and reliable messaging by using persistent queues are also provided by this architecture. These layers are as follows:

a) Reliable delivery layer. This layer guarantees reliable delivery of all messages and documents provided by the second layer. This layer deals with opening a socket to the peer agent, sending and receiving acknowledgements, encryption and decryption of messages, and 2PC implementation.

a) Persistent queue layer. This layer deals with storing messages persistently before transmitting/receiving them, which proves the user that either the message is transferred successfully to the peer, or otherwise it is stored persistently in the queue.

a) User functions layer. This layer provides a generic interface to the agents. By hiding details of internal operations, this layer provides a set of methods and variables to the agent so that the agent does not need to deal with communication details, such as sockets, persistent storage and acknowledgement passing.

4. A comprehensive user-agent interaction module is provided (note that the user or user application may be inside a firewall). The user applications have the capability to view/edit the documents retrieved by the agents, send them to other agents (through their local agents outside the company domain) for further processing, update documents and monitor databases, and to provide process related information to all other agents (such as certificate number, order number, customer name and address, etc.) by special messaging mechanisms and a central database.

5. A process definition language, which clearly specifies the flow of business process. This language is called FlowDL, which is a block structured language specifying flow of control and data among companies and handling the related information provided by the system or the user.

The textual process definition is generated automatically by the use of a graphical process definition tool, which is then parsed by the FlowDL compiler, and the internal representation is sent to other agents in the system, for initialisation.

6. A special kind of agent (called coordinator agent), which has the capability to start a new process instance. This agent also stores the central monitoring information, and all of the block tasks (AND_PARALLEL, OR_PARALLEL, CONTINGENCY...) are executed by this agent.

7. Complete monitoring facilities, which allow authorized users and remote clients to view the ongoing status of workflow processes. The monitoring tool allows graphical visualization of process definition, and access/query all related information such as the status of a certificate, number of certificates issued in a time interval by the classification society, etc. The monitoring tool is designed to be a lightweight applet, so that it can be accessible through the Internet. There is a current plan to also integrate the monitoring tool inside the process definition tool so that process definition, initialisation and monitoring can be performed on the same application.

8. Preliminary design did not consider the issue of application invocation, but only the transfer of documents and messages in a pre-determined order. Currently, the architectural design includes necessary background for invoking any kind of application on the host where an agent resides. Since Java is used as a platform

independent language for prototype implementation, the environment where applications will be invoked is not a problem, provided that the API and parameters of the application are available to the agent. An agent on a host outside the company firewall (if there is any) is capable to invoke two kinds of applications:

a) Existing applications, which are provided by the classification society or the steel mill. These include the document management systems (CENTRA 2000), administrative systems for inspections and surveyors (GLADIS), and technical information systems (TIS).

b) New applications, which are used to regulate the execution of business processes and to provide information to the user from agents outside. An example application is fetching and issuing the certificate numbers. This is a client-server application, where client process (CP) is in the steel mill, and server process(SP) is in the classification society. When a certificate number is needed in the steel mill, CP searches the pool of available numbers and retrieves one number to the requesting process(here, the agent itself). If the pool is empty, CP sends a request to the SP for a new block of certificate numbers. SP generates (or fetches) new certificate numbers to the CP, which then stores them in its local pool, and returns a number to the requesting agent.

All of the above facilities, including reliable messaging using persistent queues are available in the design of the architecture, and many of them are implemented in the prototype. Currently, the prototype lacks reliable messaging using persistent queues and layered network architecture. However, the basic modules such as process definition, system initialisation, process enactment, workflow monitoring, related information processing, multiple workflow and instance handling, user interaction using e-mails and inside firewall applications are implemented and fully tested.

9. After the initial architecture of the system was decided upon, the requirements for authentication and authorization were examined, and their feasibility and location relative to the other parts of the system elucidated. The main requirements were to preserve confidentiality of messages, to guarantee the integrity and authenticity of messages, and to allow messages to be signed. With the given general architecture of the system, such requirements arise in several distinct situations:

1) In communications between the system components that reside outside the firewall, and are responsible for carrying out the application processes. Here, there is a need to prevent eavesdroppers from being able to read either message contents, or process details.

2) In communications between the system components that reside outside the firewall, and those that reside inside. The needs are similar.

3) In communications from one node inside the firewall to another node also inside the firewall. This may be intra-company or inter-company messages. In either case, only the parties should be able to read the message, and authentication and signatures should be available

Given the system architecture, the position of a module that can satisfy such requirements can be decided, namely as a collection of services to the low-level communication layer of the main system. These services will enable to encrypt and sign a message just before it is sent to other parties. The definition of these services and their implementation is now under way.

Responsibilities

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

Responsibility Partner Status

Design of workflow specification language

METU, ETHZ, Hebrew Achieved

Design of workflow enactment service


Optimisation of the design and implementation for

scalability and availability

ETHZ

In progress

Performance factors in workflow execution

METU, SZAG, ETHZ, Hebrew

Achieved

Consistency of concurrently executing workflows

METU,ETHZ, Hebrew In progress

Definition of authentication and authorisation module

Hebrew Achieved

Task responsible: METU

Involved partners: METU, SZAG, ETHZ, Hebrew

Deliverable

Deliverable 1.3: Specification of the detailed architecture of the workflow environment.

Responsible: METU

Due date: Month 8 (May 15, 1999).

TASK 2.1 – Prototype Development

Objective

Implementation of basic modules of the prototype: workflow engine, task managers, worklist manager.

Achievements

After completing the system design and a throwaway prototype implementation, implementation of beta release of the system has started. While doing this, many of the concepts used in first prototype development has been re-used.

The first release of the code consists of a seven-package implementation in three phases:

1. MARCA package. This package consists of all threads and core data structures for a MARCA to execute correctly. All the sub modules responsible of sending/receiving messages, sending/receiving documents, handling message processing, handling multiple workflows and process instances, and deciding on future actions are encapsulated in this package.

2. MARCA Utility package. This package contains necessary utility functions and data structures related with all other packages that cooperate with the MARCA package. The threads checking document availability, sending mails, invoking applications and some vital data structures are encapsulated in this package.

3. Initialisation package. This package contains the applications and the classes, which are used during initialisation of the system. The graphical process definition tool, FlowDL parser and process initialisation server are included in this package.

4. Monitoring package. This package contains the applications used to monitor the status of ongoing processes. The graphical process monitoring tool, monitoring query sub modules, and monitoring database schema integrator classes are included in this package.

5. User applications package. This package contains all the applications that provide a link between the end user and the system. In normal cases, all the

actions are taken automatically, and the user inside the company is informed about the status of ongoing processes, and if necessary, is requested to supply a document or workflow related information. Since the company may have a firewall, message passing between the user and the agent is realised through e-mail. Applications in this package resolve the content of the mail, retrieve the attachment document or any process related information request, and deliver it to user’s screen. The applications also have the capability to view/edit/archive documents, return process related information to local agent outside the company domain, and tell which action the agent should take. This also allows the user to make a selection between automatic and manual document sending of a document (The user may wish to send the certificate by mail instead of giving it to MARCA to send it to the peer agent.) All the applications designed have full compatibility with existing applications currently being used at SZAG and GL.

6. System applications package. This package contains the domain specific applications. The client-server application, which fetches a new certificate number (when the pool of available numbers is empty), the application, which triggers an inter-company workflow from outside of the company (separating workflows inside/outside the company domain) are two of these applications. These applications are in the development stage.

7. Communication subsystem package. This package contains the three layer modules.

Reliable delivery layer (Layer 1)

Persistent queue layer (Layer 2)

User functions layer (Layer 3).

Details of these layers have been presented while explaining the layer concept.

The seven packages presented above are being implemented in three phases, which are carried out in parallel:

1. Kernel coding

Implementation of MARCA package, MARCA Utility package, Initialisation package, Monitoring package.

2. Communication subsystem coding

Implementation of Communication subsystem package.

3. Applications coding

Implementation of User applications package, System applications package.

A detailed description of the architecture is presented in Deliverable 1.3, and basic modules of the prototype are given in Deliverable 2.1. Implementation of the interfaces to invoke existing applications will be presented in Deliverable 2.2.

Responsibilities



Implementation of workflow engine


Implementation of task managers


Implementation of worklist manager



Involved partners: METU, ETHZ, Hebrew

Deliverable

Deliverable 2.1: Basic Modules of the prototype: workflow engine, task managers, worklist manager.

Responsible: METU

Due date: Month 11 (August 15, 1999).

TASK 2.2 Handling Heterogeneity, Interoperability and Adaptability

Objective

Implementation of the interfaces to invoke existing in-house systems for integration between workflow system and existing applications.

Achievements

The modules and interfaces for integrating workflow system with existing applications have been designed and are being implemented within the scope of prototype development. The prototype will be able to co-operate with all kinds of applications inside the company domain by using the advantages of existing enabling technologies such as Internet, Java applications and applets. Basic modules related with integration of workflow system and existing applications have been implemented and tested, which will be extended during this task’s period.

To improve handling and adaptability for the inter-organisational information exchange two standards are under consideration (EDIFACT, XML). The XML standard has to be adapted to the EDIFACT standard to guarantee open communication between large application systems (EDIFACT standard) and browser-oriented applications (XML). The international standardisation activities in this area have been analysed and an implementation strategy has been drafted. Implementation of an EDIFACT-XML converter has started.

At GL two interfaces have been designed and are currently under development, one for importing documents of virtually any electronic format into the central document management system CENTRA, the other one for importing structured data sets in XML format into the database of the GLADIS system.

Responsibilities



Implementation of interfaces to invoke existing

BAL, GL, SZAG, METU, Hebrew

In progress

applications

Task responsible: BAL

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

Deliverable

Deliverable 2.2: Implementation of the interfaces to invoke existing applications

Responsible: BAL

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

TASK 2.3 Availability and Scalability

Objective

Implementation of final architectural design for scalability and availability

Achievements

Availability and scalability are two key factors in industrial strength software. The goal of this task is to ensure that the design and final implementation has sufficient capacity to deal with failures and is capable of sustaining an acceptable performance. The current architectural design includes persistent queues as a way of communication between the different components. This design decision already increases the degree of fault tolerance significantly since it guarantees that messages are not lost in transit and that failures in a component do not result in messages being lost. A number of other mechanisms are also in place to recover from failures. Hence, the current degree of availability in the system is quite acceptable. However, we are currently exploring the possibility of enhancing it even further by using semantic replication of selected information in order to speed up recovery and to allow migration of processes in case of load balancing problems.

In order to do this, and while the MARCA architecture was being designed, we have explored different mechanisms using OPERA, a workflow management system developed at ETH. Until now, we have been able to demonstrate a performance similar to that of commercial database management systems while offering significantly more functionality than what such systems offer. These results have been published in paper that will be presented in the upcoming 18th IEEE Symposium on Reliable Distributed Systems (SRDS'99), to be celebrated in Lausanne, Switzerland (October, 1999).

We are currently analysing the MARCA architecture to identify potential points of failure and bottlenecks. We are also looking for ways to apply the mechanisms developed so far. This work will take place in the next months. In this regard, the task is proceeding according to schedule.

Responsibilities



Implementation of final architectural design for

scalability and availability

ETHZ

In progress

Task responsible: ETHZ

Involved partners: ETHZ

Deliverable

Deliverable 2.3: Implementation of final architectural design for scalability and availability

Responsible: ETHZ


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.

Achievements

With the MARCA architecture (Deliverable 1.3), the problem of guaranteeing local consistency is solved by each MARCA. The prototype that is being developed is designed in such a way that correctness issues are taken into account in the presence of local concurrency. This is sufficient for most aspects of the scenario addressed in MARIFLOW. If global consistency of concurrent executions is required (such as, for instance, when electronic payments are considered), the Coordinating MARCAs can be enhanced with additional components which use the techniques for correct concurrent executions of workflows presented in Dogac et al. (Journal of Parallele and Distributed Databases) in combination with concepts of transactional process management (cf. Schuldt, Alonso, Schek, “Concurrency Control and Recovery in Transactional Process Management”, PODS’99).

Using these concepts, we are able to enforce consistency for concurrent executions and, at the same time, to cope with the added structure found in processes. In particular, and unlike in traditional transactions, processes introduce flow of control as one of the basic semantic elements. Thus, it has to be taken into consideration that processes already impose ordering constraints among their different operations and among their alternative executions. Similarly, processes integrate invocations to applications with different atomicity properties (e.g., activities may or may not be semantically compensatable).

The main components of transactional process management consist of a coordinator the Coordinating MARCA acting as top level scheduler and several transactional coordination agents (cf. Schuldt, Schek, Alonso, “Transactional Coordination agents in Composite Systems”, IDEAS’99) one for each participating subsystem acting as lower level schedulers. Processes encompass activities which are invocations in subsystems scheduled by the coordinator. The coordinator's task is to execute transactional processes correctly with respect to

concurrency control and recovery. Firstly, the execution guarantees to be provided include guaranteed termination, a more general notion of atomicity than the standard all or nothing semantics which is realized by partial compensation and alternative executions. Secondly, the correct parallelization of concurrent processes is required and thirdly, by applying the ideas of the composite systems theory (cf. Alonso, Fessler, Pardon, Schek, “Correctness in General Configurations of Transactional Components”, PODS’99), a high degree of parallelism for concurrent processes is to be provided. The key aspects of transactional process management can be briefly summarized as follows: The coordinator acts as a kind of transaction scheduler that is more general than a traditional database scheduler in that it i.) knows about semantic commutativity of activities, ii.) knows about properties of activities (compensatable, retriable, or pivot), and iii.) knows about alternative executions paths in case of failures. Based on this information, the coordinator ensures global correctness but only under the assumption that the activities within the processes to be scheduled themselves provide transactional functionality (such as, for instance, atomicity, compensatability, order-preservation, etc.). However, many systems do not meet these requirements. Thus, they must be enhanced by transactional coordination agents (TCAs) which, in turn, have to provide the missing functionality so that the subsystem together with its TCA can be seen as a database and treated accordingly.

We have analyzed the MARCA architecture in order to figure out the necessary extensions to cope with problems related to global correctness given the local correctness provided by each component of the system. The architecture is general enough and provides the necessary provisions for such add-ons.

We are also looking for ways to apply the mechanisms developed so far. This work will take place in the next months. In this regard, the task is proceeding according to schedule.

Distributed workflow execution allows for several reasons of failures in data consistency. Each workflow by itself is an (extended) transaction, and the interleaved execution of transactions may produce inconsistent data. A workflow executes by invoking transactional services, and since it comprises many activities, concurrency among those may also contribute to inconsistency. Replication of data is a third cause for inconsistency. Dealing with these cannot be achieved in a general way, but rather the specific goals of a workflow system, and its execution environment need to be analyzed.

MARIFlow deals with a rather specific kind of workflow, in which timely, reliable, and secure document delivery is the main goal. Documents are packaged into messages, and workflow processes define the message flow and guarantee document delivery. From this it follows that data manipulated directly by workflow steps of different workflow processes is distinct; each workflow manipulates its own messages. This minimizes the dependencies between different workflows to system data and structures. For these, normally consistency requirements are weaker. For example, If messages of different processes are entered into a queue, it is not required that they be processed in the same order. Weak preservation of order suffices to guarantee that all messages will eventually be served.

Concurrent execution of two (or more) steps of one workflow may impact data consistency if both steps access common data. Again, this divides into system

data and structures and process data. For the latter, dependencies typically have the form that a data item written by one step is consumed by another. In MARIFlow, such dependencies are explicitly captured by the process definition, as specified in FlowDl. For the processes currently specified in the requirement analysis, this data flow is consistent, as data produced by an activity is consumed by an activity that follows it. The guards produced by the FlowDl compiler guarantee that such data is indeed accessed sequentially, so no violation of consistency may occur.

Transactional properties of individual steps of workflows in MARIFlow, as well as of the MARIFlow system itself are guaranteed by using standard database services. For example, a persistent queue is implemented using database services, which include concurrency control. Thus, these steps cannot compromise consistency.

Finally, in MARIFlow, the system operation is distributed, so there is a potential for data replication, with possibility of loss of consistency. However, in the current design, each node is responsible for the data of the steps it performs. Information about process state is sent to the monitoring database. Since process data is protected from failures by database services, the data in the monitoring database cannot reflect steps for which data is lost.

Another possible source of consistency loss is unreliable communications. If a message is taken out of a send-queue, to be sent to another node, it is possible that it will not arrive safely. In MARIFlow, this problem is solved by applying a 2PC protocol. A message is not deleted by a sender, unless an acknowledgement by the receiver that it is stored durably has been received.

Responsibilities


Correctness guarantees for concurrent workflow

executions

METU, ETHZ, Hebrew, SZAG

In progress

Data consistency between several databases within

one process

ETHZ, Hebrew, SZAG In progress

Task responsible: Hebrew

Involved partners: Hebrew, METU, ETHZ, SZAG

Deliverable

Deliverable 2.4: Implementation of final architectural design for data consistency

Responsible: Hebrew


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

Since communication between inhouse applications and the local Mariflow Agent (MARCA) across the companies firewall will work via email, built-in capabilities of mail clients for encryption and signature have been considered and partly tested. Security requirements for documents and data have been discussed. The main requirement was, that a configurable solution is needed instead of a hardcoded one. Configuration shall be possible at build-time, maybe even at runtime of a workflow. Among other requirements it was clearly identified, that handling of firewalls is a must for real life workflows.

After the initial architecture of the system was decided upon, the requirements for authentication and authorization were examined, and decided upon. Message exchange in the system occurs in the following modes:

1. An agent of a participating organization communicates with another agent of the same organization. For example, a classification society agent communicates with the main branch.

2. Communication between two organizations. E.g. a producer send a report to a classification society.

3. Communications between a node of the system inside the firewall, to the node outside the firewall.

4. Communication between two nodes outside the firewall.

The first two kinds result in documents that are submitted to MARIFlow. The last two are part of the workflow inside the MARIFlow . However, both kinds require similar guarantees:

1) Confidentiality of messages: Only the sender and receiver of a message should be able to read it. In 1) above, this implies that the document contents need to be encrypted before being submitted to MARIFlow, and similarly for the other cases.

2) Integrity and authenticity of messages: A receiver of a message should be convinced that it actually arrived from the purported sender.

3) Signatures on messages: A message can be signed, thereby not only authenticating the sender at the receiver, but also allowing future checking of this signature, at least for the duration of a workflow process, possibly for more.

Given the system architecture, a module to satisfy such requirements can be based on publicly available software, such as PGP or Java SSL. Both were examined and found to be heavy-weight. A design and initial implementation of such a module is now in progress. Its main ideas are:

1) An asymmetric key scheme for authentication and signatures. Given the small number of participants, it is easy to achieve key distribution and management.

2) Using either a symmetric key or an asymmetric key for encryption. The decision which one to use will be based on availability (due to export restrictions in the USA) and efficiency.

Using the above facilities, higher-level services to satisfy the above requirements can be constructed. The definition of these services and their implementation is now under way.

Responsibilities


Evaluation of electronic signature mechanism

Hebrew, BAL, GL, SZAG In progress

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


TASK 2.6 Conforming to Electronic Data Interchange Format

Objective

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

Achievements

An information requirement model has been defined based on the first analysis of the quality chains. Information have been defined which have to be exchanged between the different processes. First EDIFACT messages (ORDERS ORDRSP INVOIC QALITY) have been selected for the pilot implementation. The application of the EDIFACT standard guarantees that the pilot will be compatible with international data exchange standards.

A draft of an EDIFACT-Subset (ORDERS) has been defined. The implementation of the first message (ORDERS) has been started and the mapping table (Inhouse -> EDIFACT) has been generated.

Syntactical and semantical mapping between currently used document types and EDIFACT message types has started. Similar mappings from the EDIMAR projects have been used as input for the analysis. Most essential data elements have been selected for the first implementation.

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


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 Scalability, Availability, Authorisation and Authentication are in progress. These modules will be integrated to the prototype (which is also in progress) after they are completed. EDI functionality will be integrated to the prototype during the scope of this task. Release control, code management and integration of workflow system with existing application systems are also in progress.

Hardware has been purchased and integrated into the existing infrastructure, including precautions for special network components like, e.g. firewalls. The environment has been configured accordingly. The first software release was installed and tested locally.

Responsibilities


Incorporation of the different modules into the

overall system

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

In progress

Control of releases and code management

METU, ETHZ, Hebrew In progress

Implementation of EDI functionality for the

BAL In progress

application systems

Integration of workflow system and existing application systems

METU,GL, BAL, SZAG, ETHZ, Hebrew

In progress


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

Based on the business scenario described in Del. 1.2 a multilateral scenario has been selected for implementation. Test data have been prepared for the scenario. 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. It is planned to generate some test data automatically by conversion from existing EDIFACT messages as long as no real data can be send.

Responsibilities


Preparation of test data (dummy data)


Configuration of the modules


Implementation of a bilateral scenario

GL, BAL, SZAG Started

Implementation of a multilateral scenario

GL, BAL, SZAG Started

Implementation of the intra- GL, BAL, SZAG Not started

organisational connections

Test of the authentication and authorisation module

GL, BAL, SZAG Not started

Task responsible: GL

Involved partners: GL, BAL, SZAG

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

Several additional requirements for the system architecture have been raised by the end users. Importance of security (firewall) issues and configurability were identified. A standard format and a web interface for technical issues by the members of the consortium have been proposed. This is intended to help documentation and tracking of issues.

Responsibilities


Practical test of modules and systems in a real

environment operated by users

GL, BAL, SZAG, ISISAN Not started

Useage of the prototype in a real production

GL, BAL, SZAG, ISISAN Not started

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).

TASK 3.4 Final Code Release

Objective

Delivery of final system to the users

Achievements

Implementation of final release of the code has started with development of the prototype. Final version of the code will be obtained by revising and modifying the prototype, which will include all of the system functionality needed.

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. The financial report is under preparation, therefore Periodic Cost Statements have been requested from the partners for inclusion. Assistance was provided to the technical manager for organisation of technical meetings and workshops.

Responsibilities


Periodic Cost Statement Delivery

GL In progress

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

Two Periodic Management Reports have been released within first 12 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-Uses 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

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

The project scope has been presented to the members of the European Marine STEP Association at their regular meetings.

Responsibilities


Deliverables METU, GL, BAL, SZAG In progress


Involved partners: METU, GL, BAL, SZAG

Information dissemination activities

The project is presented at the “International Maritime forum” in Kavala, Greece on May 21st, 1999.

MARIFlow project is presented at the WONDERMAR workshop on May 20 th, 1999 in Kavala, Greece.

The following publications are also related with the MARIFlow project:

Dogac, A., Beeri, C., Ezbiderli, M., Tatbul, M., Icdem, C., Erus, G., Cetinkaya, O., Hamali, N., “MARIFlow: A Workflow Management System for Maritime Industry” , In Proc. of ‘Application of Information Technologies to the Maritime Industry’, Eds. C.Guedes Soares and J.Brodda, MAREXPO Consortium, 1999, pp. 33-51.

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.

Arpinar, B., Halici, U., Arpinar, S., Dogac, A., "Formalization of Workflows and Correctness Issues in the Presence of Concurrency", Journal of Distributed and Parallel Databases, Vol. 7, No. 2, April 1999, pp. 199-248.

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.

Koksal, P., Cingil, I., Dogac, A., "A Component-Based Workflow System with Dynamic Modifications", In Proc. of Next Generation Information Technologies and Systems (NGITS '99), Springer-Verlag, Lecture Notes in Computer Science, 1649, Israel, July 1999, pp238-255.

Koksal, P., Arpinar, S., Dogac, A., "History Management in Workflow Systems", International Symposium on Computer and Information Sciences, Antalya, Turkey, October 1998.

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.

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

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

Schuldt, H., Alonso, G., Schek, H.-J., "Concurrency Control and Recovery in Transactional Process Management", In Proc. of Intl. ACM Symposium on Principles of Database Systems (PODS’99), Philadelphia, Pennsylvania, USA, June 1999.

Alonso, G., Fessler, A., Pardon, G., Schek, H.-J., "Correctness in General Configurations of Transactional Components", In Proc. of Intl. ACM Symposium on Principles of Database Systems (PODS’99), Philadelphia, Pennsylvania, USA, June 1999.

Schuldt, H., Schek, H.-J., Alonso, G., "Transactional Coordination Agents in Composite Systems", In Proc. of Intl. Database Engineering and Applications Symposium (IDEAS’99), Montreal, Canada, August 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. Revision Title Type Classification Due Date Issue DateDeliverable 1.1 V 1.6 Requirement Analysis of the Application Domain R P March 15, 1999 March 15, 1999Deliverable 1.2 V 1.1 Specification of the Business Scenario R P March 15, 1999 March 15, 1999Deliverable 1.3 V 1.0 Specification of the detailed architecture of the

workflow environmentR P May 15, 1999 May 15, 1999

Deliverable 2.1 V2.0 Prototype development Prototype P August 15, 1999 August 15, 1999

DELIVERABLES SUMMARY SHEET

Project Number: INCO DC 97-2496



Deliverable No: 1.1 Due Date: March 15, 1999 Delivery Date: March 15, 1999

Short Description:

This document describes the application domain of the system to be developed and its requirements. It is prepared as a result of Task 1.1. In this document, requirements of the application domain are analyzed in detail and business rules and procedures are captured. Then using the MARIFlow Workflow Definition Language, FlowDL, the process definition for the MARIFlow application is given. Afterwards, the heterogeneity, interoperability and adaptability; availability and scalability; consistency and execution guarantees; and authentication and authorization requirements of the system to be developed are provided. How to conform to the Electronic Data Interchange Format is also discussed.

Partners owning: SZAG

Partners contributed: GL, SZAG, METU, ETHZ, HU, ISISAN

Made available to: All





Deliverable No: 1.2 Due Date: March 15, 1999 Delivery Date: March 15, 1999

Short Description:

This document describes the business scenario to be realized within the project. It first describes the existing business chains and the exchange of quality data and certificates between the industrial partners. Then, the as-is status of the business processes is compared against the to-be status. Consequently, the requirements to be met to improve the existing business processes are analyzed. Finally, a detailed business scenario is specified which will be realized in the scope of the project.

Partners owning: GL

Partners contributed: METU, ETHZ, BAL, SZAG, HU, ISISAN






Deliverable No: 1.3 Due Date: May 15, 1999 Delivery Date: May 15, 1999

Short Description:

This document contains a detailed description of the system architecture. It first describes the general structure of the system, the workflow specification language primitives, and a general overview of the designed modules. The concepts derived from the throwaway prototype are extended, including the communication layers, reliable messaging, and application invocation. The packages and classes designed for the architecture are then presented, including UML diagrams of overall system. Lastly, the document explains some workflow related scenarios, how execution of concurrent workflows is handled, how the system is optimised for a better performance, scalability – availability and authentication – authorisation modules in detail.

Partners owning: METU

Partners contributed: ETHZ, Hebrew, SZAG






Deliverable No: 2.1 Due Date: August 15, 1999 Delivery Date: August 15, 1999

Short Description: Basic modules of the prototype

Partners owning: METU

Partners contributed: ETHZ, Hebrew


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-18

Task 2.2: Handling Heterogeneity, Interoperability and Adaptability


Responsible: BAL

Task 2.3: Availability and Scalability


Responsible: ETHZ

Task 2.4: Data Consistency and Execution Guarantees


Responsible: Hebrew

Task 2.5: Implementation of Authentication and Authorization Module


Responsible: Hebrew

Task 2.6: Conforming to Electronic Data Interchange Format


Responsible: BAL

Task 2.7: System Integration and Development

Duration: 7-18

Responsible: METU

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