Study of WFMS Interoperability Based on EnHydra Shark · Study of WFMS Interoperability Based on...
62
1 Politecnico di Milano Polo di Como Scuola di Ingegneria dell’Informazione Study of WFMS Interoperability Based on EnHydra Shark Supervisor Prof. Giuseppe Pozzi Students Min Lin Matr: 816914 Qiong Wang Matr: 780032 2016/2017
Transcript of Study of WFMS Interoperability Based on EnHydra Shark · Study of WFMS Interoperability Based on...
1
Politecnico di Milano
Polo di Como
Scuola di Ingegneria dell’Informazione
Study of WFMS Interoperability Based on EnHydra Shark
Supervisor
Prof. Giuseppe Pozzi Students Min Lin Matr: 816914 Qiong Wang Matr: 780032
2016/2017
2
Table of Contents Abstract ...................................................................................................................................... 4
Sommario ................................................................................................................................... 5
1. Introduction ........................................................................................................................ 6
1.1 History of Workflow Management System .......................................................... 6
1.2 WFMS Architectures and Concepts ..................................................................... 7
1.3 The History of Workflow Management System Interoperability .................... 10
1.4 Thesis Outline ........................................................................................................ 13
2. State of the Art .................................................................................................................. 14
2.1 The Bottleneck and the Problems ........................................................................ 14
2.2 The Four Models ................................................................................................... 15
2.3 The Four Methods to Achieve .............................................................................. 18
2.4 Various Technologies Used in Interoperability .................................................. 18
3. Goals ................................................................................................................................. 23
4. Design Choices ................................................................................................................. 24
4.1 Features of Together Workflow Server .............................................................. 24
4.2 Customizable Deployment of TWS ..................................................................... 26
4.3 The Database Support .......................................................................................... 27
4.4 The Integration with Other Components ............................................................ 27
4.5 The Selection of Web Server ................................................................................. 30
4.6 XPDL ...................................................................................................................... 31
4.7 Together Workflow Editor ................................................................................... 35
4.8 The Features of TWE ............................................................................................ 37
4.9 Wf-XML ................................................................................................................. 40
5. System Description .......................................................................................................... 42
5.1 Model Definition and XPDL creation .................................................................. 42
5.2 The TWS Deployment ........................................................................................... 47
5.3 The Other Components ........................................................................................ 49
5.4 Tomcat Intergration ............................................................................................. 51
6. Results .............................................................................................................................. 54
7. Conclusions ...................................................................................................................... 59
8. References ........................................................................................................................ 61
3
Table of Figures Figure 1 The Workflow Reference Model ......................................................................... 8
Figure 2 Chained Services ................................................................................................ 15
Figure 3 Nested Sub-process ............................................................................................ 16
Figure 4 Peer to Peer ........................................................................................................ 16
Figure 5 Parallel Synchronized ........................................................................................ 17
Figure 6 Interface 4 .......................................................................................................... 18
Figure 7 The ORB general structure ................................................................................ 19
Figure 8 Outlook Integration ............................................................................................ 29
Figure 9The Sequence Pattern in XPDL .......................................................................... 33
Figure 10 Parallel Split and Synchronization in XPDL ................................................... 34
Figure 11 Comparison with other Language .................................................................... 35
Figure 12The Graph View ................................................................................................ 39
Figure 13The XPDL Code View ...................................................................................... 40
Figure 14Wf-XML support by TWE ............................................................................... 41
Figure 15General info of an Activity ............................................................................... 43
Figure 16Extended Attributes of an Activity ................................................................... 44
Figure 17Extended Attribute of an Activity ..................................................................... 45
Figure 18The XPDL header definition............................................................................. 46
Figure 19The Activity Body Definition ........................................................................... 46
Figure 20The id definition ................................................................................................ 47
Figure 21The Customization Style Definition ................................................................. 47
Figure 22 5 Interface Implemented by TWS .................................................................... 49
Figure 23 The id Definition .............................................................................................. 52
Figure 24 The interoperability Configuration .................................................................. 52
Figure 25 Second Interoperability Configuration ............................................................ 53
Figure 26 Upload Package ............................................................................................... 54
Figure 27 XPDL Graph View of the Retailer .................................................................. 55
Figure 28 Create the Process ............................................................................................ 55
Figure 29 The Process Monitor ........................................................................................ 56
Figure 30 The Handle Order for Manufacture ................................................................. 57
4
Abstract
Workflow management is a diverse and rich technology and is now being applied to
an ever increasing number of industries. It has recently found great attention in the
information systems filed, as it allows to capture knowledge about the business processes, to
enact workflows according to their specification. In many organizations different WFMS have
been installed, and even different WFMS are used in different branches. However, enterprises
or departments need to cooperate in the context of at least some business processes, and thus
the various WFMS must be integrated into a federated inter-enterprise or enterprise-wide
WFMS. Nevertheless, currently the interoperability is not yet possible to 100% achieve. The
WFMC has focused on developing a variety of interoperability scenarios and techniques
which can operate at a number of levels from which simple task passing through to full
workflow application interoperability with complete interchange of process definition,
workflow relevant data and a common look and feel. In this progress, Web Service,
Distributed Database, Corba and other technologies are applied to promote the WFMS
interoperability.
In this study we try to implement a few cases demonstrating the WFMS
interoperability. Depending on the WFMC eight levels of interoperability and the four models
of interoperability, we choose to deploy the study in two different machines with the same
type of workflow engine and sharing the same database. Considering the various types of
exchanging format used in communication between WFMS products, we choose the XPDL as
exchanging format because of its well supporting to WFMC specification. About the
workflow engine, we get great help from the open source workflow management server-
Enhydra Shark, which realizes almost all the components of a standard WFMS. Deploying the
two processes at the Tomcat server on two different machines, we use Wf-XML for one of the
process to invoke the other process to run on its engine. In this project, we could see the
difficulty and the whole mechanism of workflow management interoperability. Nowadays,
with the fast growing technology and attention paid in this area, we are confident that in the
future we could get desired workflow management interoperability.
5
Sommario
La gestione elettronica dei processi lavorativi è un differente e ricco
approccio tecnologico che sta trovando applicazione in un numero sempre più grande di
imprese. Essa focalizza l'attenzione sui sistemi informatici, in quanto dà informazioni
riguardo al business process per definire, ottimizzare, monitorare e integrare i processi
aziendali.
I workflow management systems sono dei sistemi software che sanno interpretare una serie di
regole procedurali integrando diverse funzioni: utilizzano strumenti dell’Information
technology per la condivisione dell'informazione e gestiscono la comunicazione e il passaggio
di compiti da un collaboratore all'altro. Essi sono stati installati ed introdotti in diversi campi.
Tuttavia, le imprese e i dipartimenti dovrebbero cooperare tra di loro e questi workflow
management devono essere integrati all'interno del processo aziendale. Anche se la loro
interoperabilità non può raggiungere il 100%. Essi mirano a sviluppare diversi scenari e
tecniche di interoperabilità che operano tramite diversi livelli da task semplici fino ad una
completa interoperabilità. In questo ambito , i servizi web, le basi di dati, Corba ed altre
tecnologie mirano a promuovere l' interoperabilità .
In questa relazione, cerchiamo di fornire alcuni casi per dimostrare l'interoperabilità dei
workflow management systems. Basandosi sui 8 livelli di interoperabilità e sui 4 modelli di
interoperabilità, abbiamo scelto di focalizzare la nostra ricerca su due diverse macchine con
la stessa applicazione software (engine workflow) e stessa base di dati. Considerando diversi
tipi di linguaggi di comunicazione tra i WFMs, abbiamo scelto XPDL. Per quanto riguarda il
programma software (engine workflow), abbiamo fatto riferimento al server Enhydra shark,
che realizza quasi tutte le componenti dei WFMs standard. Installando i due processi sul
Tomcat server su due diverse macchine, usiamo WF-XML per invocare l'altro processo.
In questo progetto, ci siamo accorti della difficoltà e dell'intero meccanismo dell'
interoperabilità della gestione elettronica. Attualmente, grazie allo sviluppo tecnologico e
all'accurata attenzione rivolta a questo ambito, siamo fiduciosi di poter raggiungere in futuro
l'interoperabilità desiderata.
6
1. Introduction
Nowadays, with the fast growing of workflow applications in business market,
workflow management systems have already been the fundamental building block with other
parts of an organization’s structure such as information technology, projects and hierarchies.
But when the organizations share some business interaction and need to exchange work items,
the different workflow application cannot share data or work items properly with different
engines and environment.
In reality life, all the person or organizations need to interact with each other to
promote the business. The process and data connection between different systems has become
crucially important. Considering the workflow applications, to improve the efficiency and
make the workflow applications workable, the workflow system interoperability is vital
important.
To overcome the bottleneck of the interoperability, there come available
methodologies. To ensure interchange business process definitions between different
workflow products, Workflow Management Coalition designed the XML Process Definition
Language format. XPDL is currently the best file format for exchange of business process
model notion diagrams. It could be created and interpreted by different workflow systems that
following the Workflow Management Coalition standard. In the underlying layer, the XPDL
provides the possibility to improve the interoperability.
Currently most efforts are being concentrated on achieving run-time interoperability,
and also some diving the interoperating being achieved during build-time, through the use of
intermediate workflow representation.
1.1 History of Workflow Management System
Workflow management systems are a mature technology for automating and
controlling business process. From the WFMC workflow management coalition, the
workflow management systems are defined as “Workflow is the computerized facilitation
or automation of a business process, in whole or part”. [1] A general task of the workflow
management systems in modern circumstance is the implementation of principles of the
automatic control in business systems.
7
In 1993, the foundation of the workflow management coalition, known as WFMC is
the sign that the workflow management systems are widely used in modern enterprise and
organizations. To enable the interoperability, Workflow Management Coalition created the
standard architecture and general programming interface. One workflow consists of a set
of activities and their sequence relationship, and also including the condition to start and
complete the workflow. Workflow management system is one kind of software that
running on one or more workflow engines to define, deploy and manage the workflow
automation running. It interacts with the operators of the system (human operators) to
promote the execution of the tasks and monitoring the stats of the system. In chart 1 we
give the general architecture of one workflow management systems, from which we could
read the workflow management system is consisted of workflow modeling tools,
workflow engines, tasks manager, users interface and related data.
Workflow management system could describe the process in different time or cover
demission. Base on the process details and the complexity, the workflow management
systems could adapt different methods.
1.2 WFMS Architectures and Concepts
The workflow reference model is a standard that was developed by workflow
management coalition. [2]
8
Figure 1 The Workflow Reference Model
Workflow engine is a software service that provides the runtime execution
environment for a workflow instance. [3]It is a vital important component in workflow
technology and typically makes use of database server. A workflow engine manages and
monitors the state of activities in a workflow, such as the processing and approval of a
loan application form, and determines which new activity to transition to according to
defined processes (workflows). The actions may be anything from saving an application
form in a document management system to sending a reminder e-mail to users or
escalating overdue items to management. A workflow engine facilitates the flow of
information, tasks, and events. Workflow engines may also be referred to as Workflow
Orchestration Engines.
Workflow engines mainly have three functions:
1. Verification of the current status: Check whether the command is valid in
executing a task.
2. Determine the authority of users: Check if the current user is permitted to
execute the task.
3. Executing condition script: After passing the previous two steps, the
9
workflow engine begins to evaluate the condition script in which the two
processes are carried out, if the condition is true, workflow engine execute
the task, and if the execution successfully completes, it returns the success,
if not, it reports the error to trigger and roll back the change.
Workflow enactment service consists of one or more workflow engines and is
responsible for creating, managing and executing workflow instances. The workflow
engines that belong to a workflow enactment service may be deployed in a centralized or
distributed manner. The workflow enactment software interprets the process description
and controls the instantiation of processes and sequencing of activities, adding work items
to the user work lists and invoking application tools as necessary. This is done through
one or more co-operating workflow management engines, which manage(s) the execution
of individual instances of the various processes. The workflow enactment service
maintains internal control data either centralized or distributed across a set of workflow
engines; this workflow control data includes the internal state information associated with
the various process and activity instances under execution and may also include check
pointing and recovery/restart information used by the workflow engines to co-ordinate
and recover from failure conditions. The process definition, in conjunction with any (run-
time) workflow relevant data is used to control the navigation through the various activity
steps within the process, providing information about the entry and exit criteria for
individual activity steps, parallel or sequential execution options for different activities,
user tasks or IT applications associated with each activity, etc. This may require access to
organization / role model data, if the process definition includes constructs relating to
these entity types. The workflow engines also include some form of application tool
invocation capability to activate applications necessary to execute particular activities.
The generality of such mechanisms may vary greatly, with some simple systems only
offering support of a single fixed tool such as a form or document editor, whereas others
may provide methods for the invocation of a wider range of tools, both local and remote
to the Workflow engine.
Process definition tools are able to analyze, model, describe and document a business
process. These tools may support various workflow modelling languages. The final output
of the process definition tools is a process definition which can be interpreted at runtime
by the workflow engines within the enactment service.[4] The Workflow PDT is used to
create workflow process definitions. The PDT also contains a library for the business
10
methods (both Business Process Object (BPO) and entity methods) which are available
for use by the workflow process definitions.
The main function of the PDT is to create workflow process definitions by defining
the activities in a workflow and the transitions between them. There are various activity
types to choose from when creating a process definition, each one of which performs a
different function. What occurs between the activities in a workflow depends on their
transitions, the conditions for these transitions, and the data that is passed between them.
For further details on workflow process definitions see Workflow Process Definitions.
The PDT comes equipped with a visualization tool which allows the workflow
developer to view a version of the workflow process definition.
The PDT will also validate workflow process definitions before the workflow
developer releases them. It will check the process definition against a series of validations
and report any errors for the workflow process on the whole, for activities, or for
transitions. These validations assist a developer in producing a valid and well-formed
workflow.[5]
Workflow client applications are software entities which interact with the end-users
where human interaction is needed.
Administration& monitoring tools are created for management and control beyond the
workflow engines. These tools are used to register the progress of workflow cases and to
detect bottlenecks.
1.3 The History of Workflow Management System Interoperability
Workflow products diverse in nature ranging from those used for more ad-hoc routing
of the tasks or data to those aimed at highly regularized production processes. The work of
the coalition has therefor focused on developing a variety of interoperability scenarios
which can operate at a number of levels from simple task passing through to full
workflow application interoperability with complete interchange of process definition,
workflow relevant data and a common look and feel. In this area it is expected that
relativity simple interoperability scenarios will be supported initially, with the more
complex situations requiring further work on interoperability definitions. Four possible
11
interoperability models has been identified, covering different levels of capability.
The connected discrete(chained) scenario The Connected Discrete (Chained) Scenario
allows a connection point in one process to connect to another point in another process. It
is useful to think to these connection points as being the terminus and starting points of
the processes, but for full generality it is presumed that the connection points can be
anywhere within the processes. This model supports the transfer of a single item of work
(a process instance or activity) between the two workflow environment. The Hierarchical
Scenario allows a process executed in a particular workflow domain to be completely
encapsulated as a single task within a (superior) process executed in a different workflow
domain. A hierarchic relationship exists between the superior process and the encapsulated
process, which in effect forms a sub-process of the superior. The hierarchic relationship
may be continued across several levels, forming a set of nested sub-processes. Recursion
within this scenario may, or may not, be permitted by individual product implementations.
The Connected Indiscrete (Peer-to-Peer) Scenario allows a fully mixed environment;
for example, one process might include activities which may be executed across multiple
workflow services, forming a shared domain. [ 6 ]In this scenario, the process would
progress transparently from task to task, without any specific actions by users or
administrators, with interactions between the individual workflow engines taking place as
necessary.
The Parallel Synchronized Scenario allows two processes to operate essentially
independently, possibly across separate enactment services, but requires that
synchronization points exist between the two processes. Synchronization requires that
once the processes each reach a predefined point within their respective execution
sequences, a common event is generated
This type of mechanism may be used to facilitate functions such as process scheduling
across parallel execution threads, check pointing of recovery data or the transfer of
workflow relevant data between different process instances. There are two major aspects
to the necessary interoperability: the extent to which common interpretation of the process
definition (or a subset) is necessary and can be achieved · runtime support for the
interchange of various types of control information and to transfer workflow relevant
and/or application data between the different enactment services Where both enactment
services can interpret a common process definition, for example generated from a
12
common build tool, this enables both environments to share a single view of the process
definition objects and their attributes. This would include activity, application,
organization and role names, navigation conditions, etc. This potentially enables
individual workflow engines to transfer execution of activities or sub-processes to
heterogeneous workflow engines within the context of a common naming and object
model. This approach is particularly applicable to interoperability scenario 3, where
several systems are co-operating at peer level, although can also be employed in simpler
scenarios
The interoperability models can be achieved through eight levels of interoperability:[7]
Level 1 no interoperability, there are on way of communicating between different
workflow management system products
Level 2 workflow management system products can be implemented as different part
of a bigger process with active participation of human agents to enable the interaction
between workflow management system products
Level 3 unique gateways workflow management systems can work together sharing
same mechanism, which performs routing of operations between workflow engines,
instances, translation and delivery of workflow relevant data and translation and delivery
of workflow application data.
Level 4 limited common API subset， workflow management system products can
work together by sharing a common API. A common API is the one that are defined in
neutral information formats to handle the transport of workflow relevant and workflow
application data that most workflow engines can implement it.
Level 5 complete workflow API workflow management products can work together by
sharing a single standard API that gives access to the full range of possible operations by
any workflow management system. The possible operations can be defined and then
mapped to operations for each workflow products
Level 6 shared definition formats workflow management system products can work
together by having a shared format for process definitions that covers routing decisions;
user access rights and the maintenance of workflow system resources.
Level 7 protocol compatibility. This level assumes that all API client/server
communication including the transmission of definitions, workflow transactions and
13
recovery is standardized
Level 8 common look and feel utilizes. This level assumes that in addition to the
preceding levels, all workflow products present the user with the same standard user
interface and method of operation.[8]
1.4 Thesis Outline
The current thesis is structured as follows: Section 2 introduces the state of the art;
Section 3 describes the main goals; Section 4 illustrates the design choices; Section 5
demonstrates the system description; Section 6,7,8 describe the results, conclusion and
reference.
14
2. State of the Art
From the WFMC, the workflow interoperability has served levels, such like non-
interoperability, gateway, limited public API, full workflow API, sharing definition
format, protocol compatibility and so on. Generally, to achieve the interoperability, the
workflow systems following four main methods: directly communication, message
delivery, bridging and data sharing.
Theoretically it is possible, but in practice the goal can’t be achieved 100% although
the great level of interoperability is reached. However, nowadays it is much easier to
adjust XPDL written for deployment in one workflow system to another one.
2.1 The Bottleneck and the Problems
As a commercial technology, workflow technology has undoubtedly experienced
significant success. This has led to the desire for further research and development in the
area for two directions. First, the requirements placed on some of these applications have
tested the limits of the current workflow technology, highlighting the need for further
research and development. Second, researchers and practitioners have identified new
applications that could conceptually use this technology, but current workflow products,
either do not address these emerging requirements, or do so very selectively.
Some of the apparent weaknesses that need to be addressed from the perspectives of
database and distributed systems community researchers active in the workflow
management area include limited support for heterogeneous and distributed computing
infrastructures, lack of a clear theoretical basis, undefined correctness criteria, limited
support for synchronization of con- current workflows, lack of interoperability, minimal
scalability and availability, and lack of reliability in the presence of failures and
exceptions.
Since workflow management systems unavoidably involve heterogeneous information
resources, one of the major problems they face is interoperability.
15
2.2 The Four Models
Four different interoperability modes were defined, with different features[9]
Chained services, the chained workflow interoperability model enables some
workflow instance trigger another workflow instance to achieve the workflow
interoperability. the work item (process instance or task instance) is moved from one
workflow management system to another both workflow management system run
independently after the move, with no further synchronization. as described below.
From the chart above, we could see that the workflow instance A5 triggered B1, and
then is executed independently in process B. after this, the process A could be terminated
or keep executing. The instance passing among the workflow environment could via
workflow application gateway or via standard API. Need to pay attention is that, the
connection joint point choice should be based on the workflow object model, which
means the passing instance must fulfill the previous object requirement.
Nested sub-process, in this kind of design methodology, it permit one process of
specific workflow environment capsuled as an independent task, and run in another
workflow environment.
Figure 2 Chained Services
16
From the figure above we could see that A3 of process A is run in another process B.
when running in process B, the process A is still active. After the process B completed, it
returned the controlling back to process A. The synchronization between the two
processes is achieved by the instance parameters changing or change the signal. Under
this kind of methodology, the passing is an independent process also could be named sub-
process. This passing could be gateway or other API. Moreover, in this kind of sub-
process, could be more detailed sub-process to form more complicated network
Figure 3 Nested Sub-process
Figure 4 Peer to Peer
17
Peer to peer. This scenario requires that both workflow services support common API
sets for communication and that both can interpret a common process definition, either
imported to both environments from a common build process or exported between
services during the runtime phase. Workflow relevant and application data may also need
to be passed between the various heterogeneous engines.
Whilst simply illustrated as an interworking scenario, there are various complexities
within the peer-peer model which will require further study. As shown each particular
activity is associated with a specific workflow domain, for example predefined within the
process definition. Further complexities arise where a specific activity may be executed
on either of two independent workflow services or where a particular process instance can
be created or terminated independently by either service. Systems administration, security
and recovery across co-operating workflow services will also need to be addressed.
Parallel synchronized, the two processes run independently, but have some
rendezvous points to synchronize each-other.
From the figure above, the synchronization could be the termination of one process or
the check point synchronization. After the synchronization point, the workflow engines
run independently, till one or both reach the synchronization point to wait the new
synchronization event coming.
Figure 5 Parallel Synchronized
18
2.3 The Four Methods to Achieve
Generally, to achieve the interoperability, the workflow systems following four main
methods: directly communication, message delivery, bridging and data sharing. [10]These
four methods have different features and were used in corresponding fields. Base the
workflow system mode, we could use the workflow engines directly communication and
bridging.
The workflow engines directly communication. This is a kind of standard workflow
applications programming interface and the interchange formats, known as WAPI. With
the workflow API and data exchanging, the workflow engines could directly communicate
and achieve the workflow interoperability.[11]
The interface 4 is defined for achievement of workflow management interoperability.
There are two major aspects to the necessary interoperability: the extent to which common
interpretation of the process definition (or a subset) is necessary and can be achieved
runtime support for the interchange of various types of control information and to transfer
workflow relevant and/or application data between the different enactment services.
2.4 Various Technologies Used in Interoperability
Currently, the motivation to promote the interoperability focus on various approach,
such like CORBA, distributed database technology, Web Service etc.[12]
CORBA. The CORBA (Common Object Request Broker Architecture) technology
enables object-oriented computing in distributed heterogeneous environments. The main
Figure 6 Interface 4
19
features of CORBA include the ORB Core, the Interface Definition Language (IDL), the
Interface Repository (IR), the language mappings, the stubs and skeletons, dynamic
invocation and dispatch (DII and DSI), the object adaptors and the interORB protocols.
The general structure of an ORB is illustrated in Figure below
The ORB core delivers requests to objects and returns any responses to the callers.
[13]The key feature is to facilitate transparent client/object communication by hiding object
location, implementation, execution states, and communication mechanisms. To make a
request, the client specifies the target object by using an object reference. These are
created upon CORBA object creation; they are immutable and opaque references that only
ORB cores know how to manipulate.
Before a client can make requests on an object, it must know the types of operations
supported by the object. The Interface Definition Language (IDL) is used to define an
object's interface. IDL is a language independent, declarative language, not a
programming language. It forces interfaces to be defined separately from object
implementations. Objects can be constructed using different programming languages and
yet communicate with one another. Language Mappings determine how IDL features are
mapped to facilities of a given programming language. OMG has standardized language
mappings for C, C++ and Smalltalk. IDL language mappings are where the abstractions
and concepts specified in CORBA meet the "real world" of implementation.
Figure 7 The ORB general structure
20
A CORBA-based application must have a way to know the types of interfaces
supported by the objects being used. The CORBA Interface Repository (IR) allows the
OMG IDL type system to be accessed and written programmatically at runtime. IR is
itself a CORBA object that has a standard interface. Using this interface, an application
can traverse an entire hierarchy of IDL information. IR is usually used together with the
CORBA dynamic invocation interface and as a source for generating static support code
for applications.
OMG IDL language compilers and translators generate client-side stubs and server-
side skeletons.[14] These are interface specific code segments that cooperate to effectively
exchange requests and results. A stub is a mechanism that effectively creates and issues
requests on the client's behalf. A skeleton is a mechanism that delivers requests to the
CORBA object implementation. Communicating through stubs and skeletons is often
called static invocation because the stubs and skeletons are built directly into the client
application and object implementation. For clients, a stub is an adapter that adapts the
function call style of its language mapping to the request invocation mechanism of the
ORB. To object implementation, the skeleton is a proxy that handles translation issues in
passing request in the right format to an object implementation and also passing result
back to the ORB. In addition to the static invocation via stubs and skeletons, CORBA
supports two interfaces for dynamic invocation: Dynamic Invocation Interface (DIl) and
Dynamic Skeleton Interface (DSI). DIl allows clients to invoke requests on object without
stubs. DSI allows servers to be written without skeletons.
The Object Adaptor (OA) is the "glue" between CORBA object implementation and
the ORB itself. OA is an object that adapts the interface of another object to the interface
expected by a caller. It is an object that uses delegation to allow a caller to invoke requests
on an object even though the caller does not know the object's true interface.
Prior to CORBA 2.0, one of the biggest complaints about commercial ORB products
was that they did not interoperate. Lack of interoperability was caused by the fact that
earlier CORBA specification did not mandate any particular data formats or protocols for
ORB communications. CORBA 2.0 specifies an interoperability architecture based on the
General Inter-ORB Protocol (GlOP), which specifies transfer syntax and a standard set of
message formats for ORB interoperation over any connection-oriented transport. CORBA
2.0 also mandates the Internet Inter-ORB Protocol (IlOP), which is an implementation of
21
GlOP over TCP/IP transport. With IlOP, ORBs can interoperate with one another over the
Internet.
Web services uses WSDL to define how to make a request to a SOAP-based method.
WSDL assumes cooperation from companies that define custom data types.[15] Such
cooperation is put to the test by collaborative organizations that are establishing
interoperability test suites. For example, SOAP Builders is an open group of SOAP
developers that define interoperability test suites to check SOAP custom data types for
compatibility. The test suites emerging today begin with the WSDL definition of a SOAP
interface. They test the contents of the request and response documents for valid data.
This has put renewed energy behind WSDL efforts. New technologies such as Cape
Clear Cape Studio and BEA Cajun automatically develop WSDL documents for SOAP-
based web services. Tools such as these eliminate poorly constructed WSDL that appears
when developers hand-code WSDL documents.
The developer likely thought the web service would default to the standard W3 SOAP
name space. While this may work for primitive data types like String, there are known
interoperability problems with Date data types that will appear later in this article.
Without specifying the namespace, the web service will likely fail to handle the data
type correctly.
XPDL is the best way for exchanging process descriptions among different Workflow
Management Systems. The XML Process Definition Language (XPDL) is a format
standardized by the Workflow Management Coalition (WfMC) to interchange business
process definitions between different workflow products, i.e. between different modeling
tools and management suites. XPDL defines an XML schema for specifying the
declarative part of workflow / business process.
XPDL is designed to exchange the process definition, both the graphics and the
semantics of a workflow business process. [16]XPDL is currently the best file format for
exchange of BPMN diagrams; it has been designed specifically to store all aspects of a
BPMN diagram. XPDL contains elements to hold graphical information, such as the X
and Y position of the nodes, as well as executable aspects which would be used to run a
process. This distinguishes XPDL from BPEL which focuses exclusively on the
executable aspects of the process. BPEL does not contain elements to represent the
22
graphical aspects of a process diagram. It is possible to say that XPDL is the XML
Serialization of BPMN.
23
3. Goals
In this report, we want to discuss the possibility and deployment method to enable
workflow interoperability between different runtime environment via WFMC file format
standard. And assess the performance of multiple interoperability realization, such like
nested sub-process and chained service.
After discussing the workflow management system interoperability current state of art
and the constraining, we want to study the possibility and the procedure to enable
workflow interoperability between different runtime environment via WFMC file format
standard. In this process, we try to get better understanding and catch different point of
view of the key component of the workflow management interoperability, such as the
workflow server, engines, instance and so on.
24
4. Design Choices
About the file format describe the workflow process, we choose XPDL. XPDL is the
file format standard specified by Workflow Management Coalition. It is designed to exchange
the process definition and it could be seen as the XML Serialization of BPMN.
Together Workflow Editor as the IDE for creation, update and test environment for the
XPDL part. Also known as Enhydra JaWE, is a graphical Java Workflow Editor implementing
native Workflow Management Coalition XPDL using the BPMN graphical notion.[17]
The communication between two computers we choose the Wf-XML which is a BPM
standard developed by Workflow Management Coalition. It provides a standardized way that
a program can start and monitor a program that might take a long time to complete. Tomcat as
the web server in local network.
The workflow system we choose the Together Workflow System as the Java workflow
server. Firstly, it is free to open source users and licensed under GPL V3. Together server, also
known as Enhydra Shark is an enormously flexible and extendable WFMC XPDL and OMG
workflow management facility compliant, embeddable or standalone Java Workflow Engine.
TWS supports Microsoft Outlook integration, and also the MS Sharepoint server. It supports
multiple type of database, including hyperSQL, MySQL, Oracle and so on.[18]
About the interoperability method, we choose the run-time interoperability and using
directly communication between the workflow engines to realize the “sharing definition
format” interoperability level.
4.1 Features of Together Workflow Server
To study the workflow management system interoperability, we have to choose the
proper tools to simulate and design the whole procedure involved in the workflow
management system. It has to be open source and need to full compliant with the
Workflow Management Coalition open workflow standards. And also we need the design
tool to help us design the XPDL file, which means the open source IDE to manage the
XPDL files.
Together Workflow Server. It is a powerful Java workflow management system that
25
enables high efficient implementation of business process and the corresponding
management. With the Together Workflow Server, we could study how to automating the
real world business process via the help of Together Workflow Editor, XPDL modeling
tool, and deploy the process into Together Workflow Server.
In this report, with the help of the Together Workflow Server, we could speed up the
repeat work and avoid rudimentary error to gain our expected result.
To minimize the time for the process execution
To exactly know what is happening with the particular process instance at any given
time (via process monitoring)
To have various reports about the efficiency of the process execution in order to
improve the model, etc.
Since in the real world the business process is a complicated task to reach the
requirement and then there are many standard points need to take care of and the Together
Workflow Server hold all of the following for us
That all necessary process steps will be completed
That the right people are involved in the execution of the process steps
That there is always enough accurate information available to execute steps
That the right decision will be made at a time it needs to be made
To maximize the application scope in this study, we need considering all the
possibilities that under instruction of Workflow Management Coalition. Hence, Together
Workflow Server’s fulfill compliant with Workflow Management Coalition is vital
important for us.
Analyzing the various runtime environment and the workflow management system
products is the basic task for the study of workflow management interoperability. In this
filed, Together Workflow Server provide multiple method to deploy the system, such like
it could be embedded inside already application or the application can use Together
Workflow Server deployed so powerful and production ready.
As discussed in the “state of art” of the study in workflow management
interoperability, the CORBA, distributed database, web service is popular nowadays. And
the Together Workflow Server provides almost full support to the studying approach.
Considering the scalability problem in the big enterprise and organization, Together
Workflow Server is a scalable system designed to handle thousands of users and millions
of transactions. In this way, all of the discussion and study are surely applicable into the
26
real business environment. Together Workflow Server supports automated, manual and
mixed workflow processes, and has extensible work item allocation algorithms. Activities
are automated through an extensible system of Tool Agents, which enable the invocation
of external logic defined in Java classes, EJBs, native executables, scripts in arbitrary
scripting languages, Web Services, and so on. Human interactions are managed through
work items, which are purely manual. Through the work list API, the Together Workflow
Server clients are able to manage the work items.
In addition to the execution of business processes, TOGETHER WORKFLOW
SERVER offers additional features like tracking of all business processes within the
system. At any time, one can discover who did what and when inside a particular business
process instance.
As we discussed the current study of the workflow management system
interoperability, the XPDL is the best way to do the research and learning. Together
Workflow Server using the Workflow Management Coalition Process Definition
Language as its native workflow definition format. This really helps with the support of
XPDL in every corner of the system and the processes.
4.2 Customizable Deployment of TWS
Even what you are working with is another workflow management system products,
you could integrate the Together Workflow Server on top of your current system. This is
because the Together Workflow Server is a library, it does not open its own threads, but
everything works from the client application thread, which makes it a kind of workflow
state machine- ac thin layer on top of the database. This feature enables Together
Workflow Server could be used in many kinds of environments. Basically, you could use
it directly through its POJO interface by integrating engine within WEB, Swing or pure
console application, or you can use it as CORBA, EJB, RMI or Web Service by making
corresponding wrapper on top of the POJO interface.[19] Then the Together Workflow
Server is really configurable and customizable for the user to handle depending on their
own needs and technical ability.
What’s more besides the support with various wrapper, the Together Workflow Server
currently provides partial CORBA wrappers, full EJB wrappers and WEB service
wrappers based on the stateless EJB interface and AXIS based WEB Service wrappers
deployable on Tomcat. There are also several client applications (including administrative
27
application) in Together Workflow Server project which are able to access Together
Workflow Server through POJO interface, as well as through EJB and WEB Service
wrapper interfaces.[20] Based on the highly configurable and customizable, Together
Workflow Server’s all internal plug-in interface, as well as complete kernel could be
replaced by another implementation. This means not only could you develop your own
service provider but also you could change everything coming with the Together
Workflow Server service to make the whole new workflow management system product
of yourself. Together Workflow Server has implemented Tool Agent concept defined by
Workflow Management Coalition to executes tools of automatic, server side activities of
XPDL definition. Several useful Tool Agents are coming with Together Workflow Server,
and anybody can create its own tool agents based on Tool Agent API, which provides
enormous capabilities for integration with other systems. If you are a Java developer, it
will be great news that the Together Workflow Server supports using custom Java classes
as process variable, and even interfaces or abstract classes
4.3 The Database Support
About the database part, when using Together Relational Objects as implementation of
persistence APIs, Together Workflow Server can work with many databases, in other
words, any DODS supported database could be used. In practice, Together Workflow
Server is known to work with the following databases:
• DB2
• Hypersonic
• MSSQL
• MySQL
• Oracle
• PostgreSQL
The default database coming with Together Workflow Server distribution is
Hypersonic and it is also the database we used in this studying.
4.4 The Integration with Other Components
Theatrically, Together Workflow Server is suitable for any system integrations. There
are many ways to integrate it into your system:
To embed Together Workflow Server as a library. This is the preferred way of
integration into Java Web applications. It is most natural and most efficient way. And also
28
we use this way in the analysis and deployment of the workflow management systems
interoperability.
To have Together Workflow Server deployed as Web Service. This is a way to
integrate it as independent server into your application which is not Java based, or even
some specific Swing based Java application. The drawback of using it this way is
transaction handling. Hence, you can't execute method calls to your application and to
Together Workflow Server in one logical transaction (using JTS).
To have Together Workflow Server deployed as EJB This is another way to integrate
Together Workflow Server into your Java application when you need a central server
independent of the application itself.
Outlook integration. Nowadays, you cannot avoid using email in working
environment, and also most of the staffs in really world have experience using Outlook as
the mail client. And with the development of the Microsoft cloud services, the Outlook
supplies better user experience with Office 365. Since the high frequency using of
Outlook, no doubt, Together Workflow Server supports the Outlook very well.
Together Workflow Server comes with possibility to integrate user's task list with
outlook, so user can see and manage his work items using outlook.
To make a connection to outlook, user should connect to Together Workflow Server's
Web Client application. This application comes with (Sharepoint) web services
implementation that enables user to manage the work list within Outlook. Application is
by default configured to use NTLM authentication, and has a link for Outlook connection.
After connecting Outlook retrieves tasks from Together Workflow Server, and tasks are
displayed in the outlook task list.
The list is a standard Outlook's task list but the information about tasks comes from
Together Workflow Server.
29
Figure 8 Outlook Integration
When user double-clicks the task, a form with task details is shown. This form shows
information about the task such as the name(subject), the time when it has started, the
status, priority, description etc.
There is also a link "Open in browser actions" to open the task form within
administrative application.
It is possible to change the value of task properties and after "Save & Close" button is
pressed, Outlook communicates with Together Workflow Server via Web Services and
changes these parameters for the corresponding activity. If status field is changed to
"Completed" this will also cause activity completion (because of status change), and
process follows to the next activity which will appear in the task list, while the current one
will be marked as completed.
Outlook integration with Together Workflow Server adds another value to the overall
system and enables users that don't need to be in any case "Together Workflow Server
aware" to use workflow and take a part in the execution of the workflow procedures using
well know application they are used to.
30
4.5 The Selection of Web Server
About the web server running the web services, there are several choices like Tomcat,
Nginx, Jboss, at last we choose Tomcat as the local web server to simulate the real world
business interaction.
Developed from the Apache Jakarta Project, Tomcat is an application server designed
to execute Java servlets and render web pages that use Java Server page coding.
Accessible as either a binary or a source could version, Tomcat’s been used to power a
wide range of applications and websites across the internet. There are several reasons for
us to choose Tomcat instead of others.
It’s quite lightweight. Even with JavaEE certification, Tomcat is an incredibly
lightweight application. If offers only the most basic functionality necessary to run a
server, meaning it provides relatively quick load and redeploy times compared to many of
its peers, which are bogged down with far too many bells and whistles. This lightweight
nature also allows it to enjoy a significantly faster development cycle.
It’s open-source. In this case, open-source is always vital important for us. Tomcat’s
free and the source code is readily for us to customize when needed. And it’s quite simple
to change the configuration to support the study in various circumstance.
It’s highly flexible. With the benefits from its lightweight nature and a suite of
extensive, built-in customization options. Tomcat is quite flexible. We can run it in
virtually any fashion we choose. This is quite essential for us to deploy the Together
Workflow Server and its service components.
The server is quite stable. Since in our studying of the workflow management
interoperability, we use not only one web server instance. Tomcat is an extremely stable
platform to build on. Because Tomcat runs independently of our Apache installation-even
one of the server fails, the other would still continuously run the Together Workflow
Server services
It handles the security and other aspects. This save much time for us to concentrate on
the studying field.
31
4.6 XPDL
XPDL is the best way for exchanging process descriptions among different workflow
management systems. XPDL XML Process Definition Language (XPDL) is the language
proposed by the Workflow Management Coalition to interchange process definitions
between different workflow products. The goal of XPDL is to provide a Lingua Franca for
the workflow domain allowing for the import and export process definitions between a
variety of tools ranging from workflow management systems to modeling and simulation
tools. Starting point of XPDL is a minimal set of constructs present in most workflow
products. Unfortunately, this minimal set does not offer direct support to many of the
workflow patterns encountered in practice and present in more mature workflow products.
To address this problem, XPDL offers vendor specific extensions. However, this approach
definitely does not result in a Lingua Franca. Moreover, to date, even the semantics of the
core constructs of XPDL remain undefined. This paper will analyze XPDL using a set of
20 basic workflow patterns and expose some of the semantic problems.
XPDL uses an XML-based syntax, specified by an XML schema. The main elements
of the language are: Package, Application, Workflow Process, Activity, Transition,
Participant, Data Field, and Data Type. The Package element is the container holding the
other elements. The Application element is used to specify the applications/tools invoked
by the workflow processes defined in a package. The element Workflow Process is used
to define workflow processes or parts of workflow processes.
A Workflow Process is composed of elements of type Activity and Transition. The
Activity element is the basic building block of a workflow process definition. [21]Elements
of type Activity are connected through elements of type Transition. There are three types
of activities: Route, Implementation, and Block Activity. Activities of type Route are
dummy activities just used for routing purposes. Activities of type Block Activity are used
to execute sets of smaller activities. Element Activity Set refers to a self-contained set of
activities and transitions. A Block Activity executes such an Activity Set. Activities of
type Implementation are steps in the process which are implemented by manual
procedures (No), implemented by one of more applications (Tool), or implemented by
another workflow process (Sub-flow). The Participant element is used to specify the
participants in the workflow, i.e., the entities that can execute work. There are 6 types of
participants: Resource Set, Resource, Role, Organizational Unit, Human, and System.
Elements of type Data Field and Data Type are used to specify workflow relevant data.
32
[22]Data is used to make decisions or to refer to data outside of the workflow, and is passed
between activities and sub-flows. In this paper, we focus on the control-flow perspective.
Therefore, we will not consider functionality related to the Package, Application, and
Participant elements. Moreover, we will only consider workflow relevant data from the
perspective of routing. Appendix A shows selected parts of the XPDL Schema relevant
for this paper. The listing shows the elements Activity, Transition Restriction, Transition
Restrictions, Join, Split, Transition and Condition. An activity may have one of more
“transition restrictions” to specify the split/join behavior. If there is a transition restriction
of type Join, the restriction is either set to AND or to XOR. The WfMC defines the
semantics of such a restriction as follows: “AND: Join of (all) concurrent threads within
the process instance with incoming transitions to the activity: Synchronization is required.
The number of threads to be synchronized might be dependent on the result of the
conditions of previous AND split(s).” and “XOR: Join for alternative threads: No
synchronization is required.” Similarly, there are transition restrictions of type Split that
are set to either AND or XOR with the following semantics: “AND: Defines a number of
possible concurrent threads represented by the outgoing Transitions of this Activity. If the
Transitions have conditions the actual number of executed parallel threads is dependent
on the conditions associated with each transition, which are evaluated concurrently.” and
“XOR: List of Identifiers of outgoing Transitions of this Activity, representing. [23]
Alternatively, executed transitions. The decision as to which single transition route is
selected is dependent on the condition Patterns and XPDL 5 of each individual transition
as they are evaluated in the sequence specified in the list. If an unconditional Transition is
evaluated or transition with condition OTHERWISE this ends the list evaluation.” .
Appendix A also shows the definition of element Transition. A transition connects two
activities as indicated by the From and To field and may contain a Condition element. The
WfMC acknowledges the fact that workflow languages use different styles and
paradigms. To accommodate this, XPDL allows for vendor specific extensions of the
language. In addition, XPDL distinguishes three conformance classes: non-blocked, loop-
blocked, and full-blocked. These conformance classes refer to the network structure of a
process definition, i.e., the graph of activities (nodes) and transitions (arcs). For
conformance class non-blocked there are no restrictions. For conformance class loop
blocked the network structure has to be acyclic and for conformance class full-blocked
there has to be a one-to-one correspondence between splits and joins of the same type.
These conformance classes correspond to different styles of modeling. Graph based
33
workflow languages like COSA and Staff ware correspond to conformance class non-
blocked. Languages such as MQSeries, WSFL, and BPEL4WS correspond to
conformance class loop-blocked and block-structured languages such as XLANG are full-
blocked. A detailed introduction to XPDL is beyond the scope of this paper. For more
details we refer to.
To represent the performance and the ability to illustrate the workflow pattern, here
we discuss the examples of some workflow patterns in XPDL.
Sequence. This is the simplest pattern in workflow management system. An activity in
a workflow process is enabled after the completion of another activity in the same
process.
Figure 9The Sequence Pattern in XPDL
Parallel Split. And it is quite usual in workflow management system and very basic. A
point in the process where a single thread of control splits into multiple threads of control
which can be executed in parallel, thus allowing activities to be executed simultaneously
or in any order
Synchronization. When more than 1 parallel branches involved into the worklist,
synchronization would be useful regard as controlling. It is an assumption of this pattern
that after an incoming branch has been completed, it cannot be completed again while the
merge is still waiting for other branches to be completed. Also, it is assumed that the
34
threads to be synchronized belong to the same global process instance (i.e., to the same
“case” in workflow terminology).
Figure 10 Parallel Split and Synchronization in XPDL
35
Simple merge. A point in the workflow process where two or more alternative
branches come together without synchronization. It is an assumption of this pattern that
none of the alternative branches is ever executed in parallel with another one (if it is not
the case, then see the patterns Multi Merge and Discriminator).
Here we did not list all the discussion result of all the cases represented in XPDL. But
after we study the XPDL specification broach and test some workflow pattern represented
in XPDL, we get the comparison of XPDL with other standards such as UML Activity
Diagrams, BPEL4WS, BPML, XLANG, WSFL and WSCI.[24]
Figure 11 Comparison with other Language
From the comparison, it is clear that there is no tool supports all of the selected
patterns. Many of these tools only support a relatively small subset of the more advanced
patterns. Specifically, the limited support for the discriminator, the state-based patterns,
the synchronization of multiple instance and the cancellation, is worth nothing.
Considering our needs to learn and study the workflow management system products
interoperability, it’s reasonable and efficient to use XPDL in our study.
4.7 Together Workflow Editor
36
Now we have Together Workflow Server and XPDL as the exchanging format, what
to do next is choosing a powerful open-source XPDL editor which implementing native
Workflow Management Coalition XPDL-Specifications using the BPMN graphical
notation. Here what are we using is the Together Workflow Editor, which is a visual tool
for creating, managing and reviewing process definitions stored in Workflow
Management Coalition XPDL syntax, using BPMN graphical notation.
Together Workflow Editor allows us to quickly create or view XPDL workflow
definition files, check and store them for the further use. Once a definition is proven valid,
it can be referenced by new definitions, thus shortening the time and effort needed to
define workflow processes or imported into workflow engines capable of XPDL for
execution. And it is under GPL V3. Sources are publicly available in the projects CVS
repository hosted at SourceForge.
Workflow management is an evolving technology with lots of vendors claiming their
approach is the best. We have chosen an approach which relies on WfMC and XPDL, thus
supporting efforts to establish the standard.
Together Workflow Editor is based on version 2.1 of the XPDL XML schema
published by WfMC. The editor makes creating and editing XPDL easy. It represents all
XPDL elements graphically through property panels and a graph component using BPMN
graphical notation, to give the user a better understanding and an overview of the process
definitions. Various functions help in finding specific activities, participants, applications,
errors in the model, etc.
The final output of the editor is an XML file (using the standardized WfMC XPDL
schema) which can then be interpreted and executed by all WfMC XPDL compliant
workflow engines. Together Workflow Editor accomplishes three main goals:
Reading of WfMC XPDL files (no matter from which tool they initially come from)
from the filesystem or from the Wf-XML server. Graphical representation and guided
editing/modelling of process definitions. Writing WfMC XPDL process definition XML
files to the filesystem or to the Wf-XML serverreviewing Workflow Management
Coalition XPDL process definition files.
37
Workflow management is an evolving technology with lots of vendors claiming their
approach is the best. We have chosen an approach which relies on WfMC and XPDL, thus
supporting efforts to establish the standard.
The editor makes creating and editing XPDL easy for us. It represents all XPDL
elements graphically through property panels and a graph component using BPMN
graphical notation, to give the us a better understanding and an overview of the process
definitions. Various functions help in finding specific activities, participants, applications,
errors in the model, etc.
The final output of the editor is an XML file (using the standardized WfMC XPDL
schema) which can then be interpreted and executed by all WfMC XPDL compliant
workflow engines.
Together Workflow Editor accomplishes three main goals:
Reading of WfMC XPDL files (no matter from which tool they initially come from)
from the filesystem or from the Wf-XML server. And in this case, to study the workflow
management system products interoperability, we need deploy more than one workflow
management servers in different hosts and we could load the remote repository XPDL file
using the Wf-XML protocol.
Graphical representation and guided editing/modelling of process definitions. Writing
WfMC XPDL process definition XML files to the filesystem or to the Wf-XML server
4.8 The Features of TWE[25]
• Pure Java, useable on almost every operating system, inheriting the cross-platform
property form Java programming language. This makes Together Workflow Editor
could be used various environment, not only perfectly working with Together
Workflow Server but also be used with other systems in different environment.
This is quite important in the research filed of workflow management system
products interoperability.
• Graph actions to select all transactions between the selected activities, which make
it clear for us to understand and analyze the XPDL file.[26]
• Configurable Workflow design patterns copy/paste pool support. This feature
would muchly accelerate the design time of the workflow management system
model. Since in the last chapter, we discussed the XPDL supporting for various
workflow patterns. The good performance of XPDL supporting the workflow
38
patterns cooperates with the copy/paste feature will save much effort in fast
development.
• Customizable activity icons using native XPDL attributes. This would help if you
have special need in your field to get a better graph demonstration of the XPDL
files.
• Dynamic configuration switching at runtime. This enable you not reboot the server
every time when you make a slice changing. Just modify the files and then
dynamically configure it at runtime.
• PDL element view including syntax highlighting
• Problem highlighting and extended navigation tree
• View relations between main XPDL package and its external packages. This would
help a lot when you have many interactions with the external packages. It gives
you much clearer view of the whole hierarchy.
• API documentation for extension programming, which enable the infinite
extension with our digging in.
In combination with Together Workflow Server you get a fully WfMC and OMG
compliant Workflow solution. Together Workflow Server is an enormously flexible and
extendable WfMC XPDL 2.1 / BPMN and "OMG Workflow Management Facility"
compliant Java Workflow Engine for embedded or standalone usage. Process definitions
are based on WfMC-XPDL (XML Process Definition Language) V2.1 / BPMN without
proprietary extensions. For execution of serverside system activities the WfMC Tool
Agents API is supported. Standard toolagents for many common tasks are included. Wf-
XML is supported for communication with design tools and/or other workflow engines
even from different vendors.
39
Figure 12The Graph View
40
Figure 13The XPDL Code View
4.9 Wf-XML
Here in this case, we deploy the interoperability by invoking another process in remote
host by Wf-XML.
Wf-XML is a BPM standard developed by the Workflow Management Coalition.
Wf-XML is designed and implemented as an extension to the OASIS Asynchronous
Service Access Protocol (ASAP). ASAP provides a standardized way that a program can
start and monitor a program that might take a long time to complete. It provides the
capability to monitor the running service, and be informed of changes in its status. Wf-
XML extends this by providing additional standard web service operations that allow
sending and retrieving the “program” or definition of the service which is provided. A
process engine has this behavior of providing a service that lasts a long time, and also
being programmable by being able to install process definitions.[27]
Wf-XML offers a standard way for a BPM engine to invoke a process in another BPM
engine, and to wait for it to complete. Process editing tools and process execution tools
may be produced by different vendors. A standard way to retrieve process definitions and
send definitions will allow a user to match the best process definition tool with the best
process execution engine for their needs. Wf-XML completes the job by giving a standard
way to pass the process definition between the design tool and the execution engine.
41
The roots of the current effort began in 1997 with the Internet Engineering Task Force
(IETF) effort named Simple Workflow Access Protocol (SWAP) led by Netscape, Oracle
Corporation and others. This was followed by the WfMC standard known as Wf-XML 1.0
and Wf-XML 1.1. Wf-XML was implemented by a number of commercial products. Wf-
XML 1.0 and Wf-XML 1.1 predated SOAP and so did not use SOAP message structures.
ASAP and Wf-XML 2.0 uses SOAP messages to provide the same capability.
Wf-XML provides a standard way to retrieve a process definition from a BPM engine,
and to provide an updated one to the BPM engine. A process design tool could used this
standard web services based protocol to browse processes on remote BPM server. It
provides an interface between such a design tool and the BPM engine; this is the
traditional WfMC Interface 1 for getting and setting the process definition. There is no
other effort known to be proposed for standardizing this interaction.
Wf-XML 2.0 is defined using WSDL, thus generally accepted as a standard web
service. It should be known that services built using Wf-XML 2.0 and later are not
backwards compatible with those using Wf-XML 1.1, as the earlier protocol was not
based on SOAP messages.
The Together Workflow Editor gives support to Wf-XML as following figure:
Figure 14Wf-XML support by TWE
At where we could load the remote server files via Wf-XML
42
5. System Description
5.1 Model Definition and XPDL creation
Design different process model for corresponding vendors and consumers. Design
different process models for corresponding venders and consumers. Create the XPDL file
via Enhydra JaWE. Depending the WfXML protocol, define the web URL as the invoking
process ID.
Here we choose the real world the manufacture and the retailer as the basis of our
models here. The manufacture produces the products with name, quantity, tag and so on,
then the retailer will give the order online to the manufacture. The order including the
name, description, product names, quantity, message and so on. Then the manufacture
would be noticed that here comes an order, you need to handle it. The manufacture would
respond to the order from the retailer. After this is done at the manufacture side, the
retailer will receive the receipt from the manufacture, then the simple processes are over.
What are we doing here is that there are two hosts running on different physical machines,
and the two processes (the manufacture and the retailer) running on the different physical
machines independently.
First of all, the retailer creates its own process and initiate it. After the initiation, the
system give the retailer a work list to fulfill the order form. If everything is without error,
then the form will be passed from the retailer server to the manufacture server and then
create the manufacture process. After the process is awaken, the manufacture is noticed
you have a work list to handle. Then the manufacture open the work list item, give his
interaction. In this point, the reply from the manufacture is passed again back to the
retailer server. The retailer process goes continuously from the reply of the manufacture,
he processes the receipt and then then whole procedure is closed.
The models scenario is quite simple, but it involves everything of the sequence
workflow management system products interoperability.
The data involved here are the order information and the reply information.
43
Figure 15General info of an Activity
In the enter order activity, below figure gives the attribute data involved
44
Figure 16Extended Attributes of an Activity
Similar to the enter order, below is the figure of report from the manufacture
45
Figure 17Extended Attribute of an Activity
The XPDL creation of the models designed
Firstly, we create the XPDL file for the retailer part. All of this is done with the
Together Workflow Editor. Following the Workflow Management Coalition and the
Together Workflow Editor tutorials, just declare the header code of the XPDL files, like
the description and the other system information
46
Figure 18The XPDL header definition
And then we define the main part of the activities, first is the contact the manufacture
and then enter the order.
Figure 19The Activity Body Definition
47
Here we define the activity with ID “contact_manufacture” under the
<XPDL:activities>, which define name and the parameters of the activities. Moreover,
here we specified the id
Figure 20The id definition
Here it is defined that it will go to the sub flow of the process with “synchr” execution
mode. What the id defined is the remote host process IP address, the port of the server,
and the process to be invoked, and also the package information.
By this we define the Wf-XML info to be used here to realize the interoperability.
Since we discussed above that the Together Workflow Editor supports customizable
graphical elements such like the icon and the others.
Below is the figure illustrate the customization of the graphical element with the CSS
like code. It defin the border color is black, the fill color in RGB mode and also the
height, width the position info and so on
Figure 21The Customization Style Definition
5.2 The TWS Deployment
Deploy the Enhydra Shark server and run the workflow engine. Based on the 5 level
interface of the Workflow Management Server, Together Workflow Server implements all
the interfaces.[28]
48
Interface 1: XPDL Workflow Metamodel
XPDL (XML Process Definition Language) is an XML dialect used to define portable
workflow processes which conform to the WfMC workflow metamodel. TWS supports all
the core XPDL features and also provides various extensions.
Interface 2 and 3: Worklist Client
WAPI (Workflow API) is an API to a WfMS (Workflow Management System). It also
defines the meta-model for runtime process, activity and work item instances and the
lifecycles associated with each. The WAPI standard is defined in terms of the C language,
and TWS implements this functionality both through WAPI 2/3 specification, and through
its object model representation defined by OMG's Workflow Management Facility
Specification.
Interface 3: Tool Agent
The Tool Agent API is the API which acts on behalf of a WFMS to invoke external
applications. TWS uses this API to invoke external applications through appropriate tool
agent Java class.
Interface 4: Wf-XML
Interface 4 is an extensibility interface that enables communication between a WfMS
and external programs. The interface enables processes and their instances to be created,
managed and queried using an asynchronous request-response protocol. Wf-XML is the
XML binding; there are also bindings to other formats such as MIME. TWS implements
Interface 4, and enables other applications to access TWS through this interface.
Interface 5: Audit Data
Interface 5 defines the format of the audit data which a conformant WfMS must
generate during workflow enactment. The Interface 5 API defines the audit record formats
49
as C language structures – TWS implements a functionality of this interface both through
WfMC and an OMG specification.
Figure 22 5 Interface Implemented by TWS
The deployment is not difficult with the instructions from the Enhydra. One of the
most important part in the Together Workflow Server is the engine.
The Workflow Engine is the core of the workflow management system. It is responsible
for creating and enacting runtime instances of business processes. To achieve this it
creates process, activity and work item instances and drives these through their standard
life cycles (defined by WfMC Interface 2/OMG interface) in order to realize the activity
flows defined in XPDL workflow models. The workflow engine relies upon various
services which are in TWS's case implemented as a separate components based on TWS
internal API.
Typical TWS integration scenario is to embed the core workflow engine part into your
own (WEB) application, and use it through the TWS's public POJO API.
5.3 The Other Components
About the Service Wrappers. TWS provides service wrappers around the core POJO
API of workflow engine. The following wrappers are available:
50
EJB Wrapper - enables usage of the engine through EJB interface, which is a wrapper
around all the core engine's public POJO APIs
Web Service Wrapper - enables usage of the engine through web service interface,
which is a wrapper around all "stateless" public POJO APIs
WfXML Wrapper - enables usage of the core engine through WfMC's Interface 4
CORBA Wrapper - enables usage of the core engine through CORBA API, which is a
wrapper around the core engine's "stateful" public POJO APIs defined by OMG's
Workflow Management Facility Specification
TWS distribution comes with the service wrapper implementations. E.g. EJB wrapper
for JBoss application server is given as the EAR file, Web Service Wrapper as WAR file
to deploy under Tomcat 7.x application server, CORBA Wrapper as the set of batch
scripts and JAR files to install the service, and WfXML wrapper comes both as the set of
batch scripts and JAR files and as the part of TWS's Web Client application
implementation.
About the Administration Tools. The Administration Tools are used to manage
workflow process definitions and the associated runtime process, activity and work item
instances. TWS provides a graphical swing administration application, and similar WEB
based application. Both applications are capable to use TWS through POJO, EJB and Web
Service interfaces.
There is also a console client application (SharkConsoleClient) that enables partial
administration of TWS through the simple console interface.
TWS's Swing Admin and Web Client application will be explained in details in the
following chapters.
About the Worklist Handlers. The Worklist Handler is an application that enables a
human workflow participant to manage the work items which have been assigned to them.
TWS provides graphical Worklist Handlers: graphical swing worklist handler, and similar
51
WEB based application (in fact, these are the part of Administrative tool applications).
Both applications are capable to use TWS through POJO, EJB and Web Service
interfaces. Beside those two, there is also graphical JSP Worklist Handler application
delivered with the project, it uses TWS only through POJO interface.
There is also a console application called "SharkConsoleClient", that enables partial
administration and worklist handling through the simple console interface.
About the XPDL Workflow Editor. TWS project distribution also delivers the fully
configured package of Together Workflow Editor, the advanced graphical XPDL editor
for creating XPDL process definitions to be executed by TWS engine. This editor has
functionality to work in so called "Shark mode", which extends its capabilities and makes
it suitable to define workflow processes for TWS.
There are many executable XPDL samples coming with TWS distribution package.
About the SQL Scripts and ETL Tool. TWS persists the various information about the
process model and process execution into the database. TWS project distribution delivers
SQL scripts, an ETL tool Together Data Transformer and scripts for that tool, together
with the batch scripts using this tool to create TWS data model for all the main database
vendors like DB2, HSQL, MSQL, MySQL, Oracle, PostgreSQL.
Using the batch scripts, it is easy to create TWS data model and thus prepare the
environment for the engine execution.
5.4 Tomcat Intergration
After configuring the Tomcat server running correctly in multiple destination machine,
we need to deploy the Together Workflow Server into Tomcat
Since Together Workflow Server gives us the sharkWebClient.war tvd.war and
root.war, just remove the default root directory in Tomcat and replace the above files.
Here the port we are using is the default 8080 port for web service. Together Workflow
Server distribution package includes JAR files to support the deployment of WfXML as
standalone Service Wrapper. And it is based on the Workflow Management Coalition
interface 4 specification. And the WfXML Web Services are automatically deployed with
52
the Together Workflow Server Web Client application. It allows workflow engines to
interact with each other during an execution of XPDL processes.
As mentioned above, we discussed the id of the activity “enter order”
Figure 23 The id Definition
Here we need configure the WfXML to support the interoperability. The two machine
are in same local network, with Tomcat we could identify them with the local IPV4
address and the port. The IPV4 address for the retailer machine is 192.168.1.12 with port
8080. The IPV4 address for the manufacture machines is 192.168.1.11 with port 8080.
We customize the Together Workflow Server configuration as following
Figure 24 The interoperability Configuration
This is the configuration for the manufacture Shark.conf, it defines its own host and
port. Then comes the interoperability authentication info. With host info, port info and the
name password to communicate. Accordingly, we could easily define the retailer
configuration as following
53
Figure 25 Second Interoperability Configuration
54
6. Results
With same workflow engine and different runtime environment for vendors and
consumers, the study here successfully deploying multiple interoperability type using the
choose method. We studies the various methodology to realize the workflow
interoperability and different design pattern.
Some screenshots
After all the preparation, we start the two independent host server in same local
network.
Firstly we upload the two package into the corresponding server.
Figure 26 Upload Package
Its almost the same to upload the retailer package at another machine. Here we have
the two packages in our two servers.
55
Figure 27 XPDL Graph View of the Retailer
From the XPDL graph view, we could see that we should start from the enter order.
The previous step is “contact the manufacture”.
So we create the process at the “Process Instantiation” tab as following
Figure 28 Create the Process
Then we could see the active process list at the “Process Monitor” tab and the is the
“Work List” tab
56
Figure 29 The Process Monitor
Clicking the work list and we jump into the “handle the order” part, with the
information passing from the retailer.
57
Figure 30 The Handle Order for Manufacture
From here we can see the Activity information, the customer the order number the
Product Quantity, the Product description. And the manufacture need to input the “Order
handled by” and “Availability Date” field.
Then the retailer will receive the reply, similar to this procedure. We will not list all the
following procedure and the figure.
In the retailer part, it is the human who create the process and then all the other
following come. However, with the help of Wf-XML, there are no human who create the
58
manufacture process manually, but by the retailer automatically. In this way, we
implement the interoperability within the two server using same engines successfully.
By this not complicated case, we implemented the whole procedure of the Together
Workflow Server and the Together Workflow Editor. We choose the chained services in
the interface 4 to implement the interoperability between two independent servers running
on two machine with the same type of workflow engines.
59
7. Conclusions
The workflow model could describe the real life workflow structure, but concerning
the design of interoperability, comes the bottleneck for various workflow products. By
enriching the file definition format and underlying protocol, take advantage of four typical
interoperability design pattern, cooperating with CORBA, MQ, WEB technology and
distributed dates, we could significantly improve the interoperability performance. And
with the fast growing web and mobile technology, we should concentrate on the web
service integrate of the workflow interoperability and also the mobile application to make
the workflow system pervasively.
Future research directions
Studying the interoperability among different workflow engines in independent run
time environment.
In this report, we investigated the possibility of two workflow management systems
running on two different machines with the same workflow engines.
The workflow model could describe the real life workflow structure, but concerning the
design of interoperability, comes the bottleneck for various workflow products. By
enriching the file definition format and underlying protocol, take advantage of four typical
interoperability design pattern, cooperating with CORBA, MQ, WEB technology and
distributed dates, we could significantly improve the interoperability performance. And
with the fast growing web and mobile technology, we should concentrate on the web
service integrate of the workflow interoperability and also the mobile application to make
the workflow system pervasively.
Considering the five interface of the workflow management system and for types of
the workflow interoperability, we choose the chained services with the WfXML to get the
implementation of the interoperability we studying.
The case we using to demonstration here is not as complicated as the cases in the real
world business processes. But with the powerful Workflow Management Server and
60
especially the Workflow Management Editor, we could create more complex cases and
solve more complicated reality problems.
With the development of the cloud computing, the distributed database technology,
and the web service technology, we are confident that in the not far future the
interoperability between all kinds of workflow system and environment will be handled
much better.
61
8. References
[1] Giuseppe Pozzi. Architectures for a Temporal Workflow Management System. 2004
[2] Dr Luis Pires. Workflow Management Theories and Techniques including the Data
Perspective. 2012
[3] Gerd Moser. A Practice Guide to Working Within the SAP Business Framework. 2013
[4] The Workflow Management Coalition Specification. 2008
[5] IBM Business Process Knowledge Center. 2011
[6] The Workflow Management Coalition and Fujitsu OSSI. 2008
[7] Andreas Tolk, WeiPing Wang. The Levels of Conceptual Interoperability Model. 2006
[8] D. J. Goodman. Introduction and evaluation of Martlet: a scientific workflow language for
abstracted parallelization. 2007.
[9] The Workflow Management Coalition Specification. 2008
[10] ZhiGuang Qin. The Study of WfMS Interoperability. 2002
[11] T. Hornung, A. Koschmider, and J. Mendling. Integration of heterogeneous BPM
schemas: The case of XPDL and BPEL. 2006.
[12] ZhiGuang Qin. The Study of WfMS Interoperability. 2002
[13] Zahir Tari. Fundamentals of Distributed Object Systems: The CORBA Perspective. 2004
[14] Syed Asad Hussain. Active and Programmable Network for Adaptive Architectures and
Services. 2006
[15] The Workflow Management Coalition Specification.2008
[16] Tomas Skersys. Information and Software Technologies. 2013
[17] Together Workflow Editor Specification. Enhydra. 2007
[18] J. Mendling. Towards an integrated BPM schema. In Proceedings of the 12th CAiSE
Doctoral Consortium (CAiSEDC). 2005.
[19] Together Workflow Server User Manual. Enhydra.2015
[20] Pierantoni, G. and Carley, E. Meta-workflows and Workflow Interoperability for
Heliophysics, in the proceedings of the 6th International workshop on Science Gateways, 2014
[21] Asuman Dogac. Current Trends in Data Management Technology. 1999
62
[22] SHIWA: SHaring Interoperable Workflows for large-scale scientific simulation on
Available DCIs. http://www.shiwaworkflow.eu, 2011.
[23] Asuman Dogac. Patterns and XPDL: A Critical Evaluation of the XML Process
Definition Language. Wil M.P. van der Aalst.2002.
[24] Wil M.P. van der Aalst Patterns and XPDL: A Critical Evaluation of the XML Process
Definition Language. 2002.
[25] The Enhydra Website Documentation. Enhydra.2004
[26] SHIWA: SHaring Interoperable Workflows for large-scale scientific simulation on
Available DCIs. http://www.shiwaworkflow.eu, 2011.
[27] The Workflow Management Coalition Specification.2008
[28] Workflow Management Standards& Interoperability. WfMC& Fujitsu OSSI.2008
