Figure 1: Mediators as a skin on top of a network (transport)
Managing processes in and objects flowing through chains by linking information systems of different actors is studied. The concepts of interorganizational WorkFlow management are discussed. They are based on managing business transactions that behave according to business transaction protocols. The components of an interorganizational WorkFlow management system are briefly discussed. Changes in business and changes in the underlying protocols can easily be accommodated by entering new parameter values in the system. An architecture of an interorganisational WorkFlow management system is presented, including the appropriate tools to parameterize such a system. The use of such a system to interconnect legacy systems is presented. A prototype of the interorganizational WorkFlow management system is discussed by Aerts, Hofman, and Somers in [2]. We take a business perspective by illustrating the concepts by means of a transport chain. An example of a chain in the agri- and the food-business can be found in [?]. The relation with existing standards and their developments is given.
Several standardisation bodies are developing their solution to the interoperability between information systems in different organizations. Each of these bodies has its own perspective of the problem, e.g. ISO/TC 184 focusses on industrial automation and integration and ISO/IEC JTC1 SC21 on the communication between information systems in general. There are also relations between standardisation bodies, e.g. ISO/IEC JTC1 SC 14 and UN/ECE WP4 have developed a set of data elements for admistrative data interchange (TDED: Trade Data Element Directory). The ISO is developing a Basic Semantic Repository to store Basic Semantic Units and link them to elements of the TDED (see for instance [??]). With respect to administrative data interchange, ISO/IEC JTC1 has a special working group on the development of an Open EDI Reference Model (see [6]), UN/ECE has raised a group investigating Business and Information Modelling for EDI (EBES/T.5, [+]), the European Workshop on Open Systems (EWOS) is looking into Electronic Commerce, and UN/ECE is developing a special standard for interactive EDI ([11]). The use of IDEF is adopted to model product (STEP) and administrative data (EDI).
All these bodies investigate the same problem from a different perspective: interoperability of information systems. In the database world, similar achievements and opportunities in database research have been identified by an NSF Workshop on the Future of Database Systems Research ([++]). They have amongst others concluded that interoperability of legacy systems is to be provided through the use of so-called mediators. These mediators can perform customized integration and additional filtering or processing. The participants of the NSF workshop have identified the question: what tools are necessary to make use of arbitrary information sources in integrated systems as easy as using stand-alone databases.
On behalf of the European Commission/DGXIII (1993) we have performed with respect to tools for EDI tools. One of the findings is: those tools that have not been developed specially for EDI modelling, maintenance, and implementation are not usefull to EDI Standardisation Bodies. Most CASE tools, and system developers, see EDI as a special feature of information systems. Tool developers have made extension to their tools supporting an EDI syntax. Thus, these tools are not able to model mediators and to link mediators to legacy systems.
We will discuss the issues at stake in more detail by looking into one aspect of interorganisational communication: the exchange of structured (administrative and logistical) data. By means of this example, we present an architecture for interorganisational WorkFlow management and its underlying concepts. We present the relation with existing standards and try to derive more general rules for an architecture of interorganisational WorkFlow covering all aspects of business operation.
In their day-to-day operations, commercial companies as well as non-profit organizations provide their products to their clients. These products are goods, services, money, or information. The clients are other companies and organizations, departments of organizations, or private persons. Within logistics, goods are distributed and transported by using several modes of transport like rail, road, air, and sea. Information regarding the location of the goods is relevant to both the shipper and the consignee of the goods. These goods represent an economic value and are part of their stock. In some cases, the seller gets paid only after the assembly of his products in the final product of the buyer. To initiate and to control the product provision process, information exchange is required between all parties involved in international multimodal transport chains.
The information can be exchanged by paper documents, telefax, telephone, electronic messages, or other media. Advantages of using electronic information exchange, also called EDI (Electronic Data Interchange), can be found in literature (see Hofman [4] and Sokol [10]). They are for instance in the reduction of stock, improvement of market share, and visibility of the product flow across boundaries of companies and non-profit organizations. For instance, an automotive manufacturer having more information regarding the components of a car is able to re-use these components after the car breaks down. Thus, the polution and waste problem can be diminished and the manufacturer can differentiate from its competitors. Other strategies mentioned by Porter [9], e.g. cost reduction, can also be achieved by exchanging information electronically.
For instance, we envisage a transport service operated by a forwarder on behalf of this particular shipper. The forwarder can arrange the transport for all types of packages offered by the shipper for transport. The transport service consists of two stages: the first stage is the transport by road to a port, and the second stage is the transport between two ports. The transport from the port of discharge to the place of delivery in either the United States or in Asia is arranged by another forwarder. Additionally, the forwarder is requested to arrange the transport from the port of New Orleans in the United States to a destination in the state Louisiana. The ports in Europe in this example could be Antwerp and Rotterdam. Packages from the Netherlands, Germany, and Belgium can be transported to the United States and Asia via both ports. The packages that are going to be transported via Rotterdam have to be stuffed in containers by a container stuffing centre. Those containers that are transported to the United States are transported back to Rotterdam (either full or empty). Containers that are transported to Asia are re-used in Asia.
Figure 1 shows the business system of the shipper (the stuffing centre is part of the port of Rotterdam).
Figure 1: Mediators as a skin on top of a network (transport)
Sea transport is arranged by an agent of the carrier (a liner-agent). A liner-agent can arrange the loading of the packages onto and the discharging of the packages from the vessel. The actual loading and the actual discharging is executed by a stevedore. Depending on, amongst others, the sailing schedule of vessels, the forwarder selects a liner-agent.
The information exchange between all actors involved in the transport chain can be visualized by so-called time sequence diagrams or scenario's (see for example the model on Open-EDI [6], the document on Interactive EDI [11], and the Open Systems Interconnection Basic Reference Model [x]). In a time sequence diagram, each actor is represented by a vertical line. The arrows between these vertical lines represent information transferred from one actor to another. Figures 2 and 3 show a time sequence diagrams for the transport chain of export of goods.
The shipper and the forwarder exchange information in order to co-ordinate their business operation. For example, the shipper exchanges a transport order with the forwarder, referring to the contract they have. As a result of processing the transport order, the forwarder submits his transport planning to the shipper. By means of the transport planning, the shipper can carry out his planning for the shipment of the packages. Once the shipment has taken place and the packages are delivered, the forwarder reports on the execution of his service to the shipper (figure 2).
Figure 2: Exchange of messages to execute a contractually agreed transport service
The time sequence shown in figure 2 can be refined. A shipper can send updates to an earlier exchanged instruction and the forwarder can give updates of the planning and is capable of reporting by several messages. Sea transport is part of the service agreed by contract between the shipper and the forwarder. We call these three related messages a transaction: if the shipper requires transport of packages, he initiates a transaction with the forwarder that contains information to enable the execution of a service. The forwarder selects the proper service and initiates the execution of the tasks of the service by sending a shipping instruction to a liner-agent for the transport of the cargo with a certain vessel. The planning of the liner-agent tells him that he is able to arrange the transport of the cargo using the particular vessel. He receives a report from the liner-agent after the execution.
A possible time sequence of the messages that are exchanged between all actors involved in sea transport is shown in figure 3.
Figure 3: A time sequence diagram of the messages of the example
Figure 3 shows one possible time sequence of the messages that are exchanged between the actors involved. The sequence depends on the behaviour of the actors involved. Another sequence is for instance the exchange of the report of the carrier before the agent of the forwarder sends his planning. The forwarder can also offer a service to the shipper by which every report received by the forwarder is passed to the shipper. Another service of the forwarder is to exchange the report of the carrier that performs the road transport, which is the report of the first action of the service, and the final report of his agent, which is the report of the final action of the service. Another option is that the forwarder wants to confirm the transactions with the carrier, the stevedore, and the liner-agent, before he has received the report of his agent.
Figure 3 shows that in time, first of all, the instruction and, secondly, the planning messages are exchanged between the actors involved. Thirdly, all report messages are exchanged. The sequence of the instruction and the planning messages can be called the 'initiation of a transaction' ('init'). The exchange of report messages can be called the 'confirmation' ('cffr').
In this particular example, the forwarder arranges first of all the sea transport. It is also possible that he starts by arranging transport to the premises of a stevedore and waits on the reports of the road carrier and the stevedore before he arranges sea transport. Therefore, the initiation of the execution of tasks can be interleaved with the confirmation of the execution of those tasks.
One way of representing the possible contents of the messages in a time sequence diagram is by a data model (see Aerts [1]). Other ways are by means of EDIFACT (EDI for Administration Commerce and Transport, [7]) message structures. We will apply the data modelling approach.
A data model of the transport of containers represents two basic object types: containers and transport means (figure 4). Furthermore, the status of a container is represented by place and time. The status represents the availability of containers for the next transport stage. A process is owned and can be executed by a certain actor, e.g. the transport to a port is owned (executed) by a carrier.
Figure 4: A data model for transporting containers
The data model of figure 4 can be extended by introducing entities that specify goods that can be stuffed in containers and/or transported by a means of transport.
The solution for efficiently dealing with the increase in the number of messages and message scenario's is sought in the form of a general utility for controlling the message flows. This utility has to satisfy a number of requirements following from the fact that it has to be able to recognize the state of a particular transaction and from the fact that one transaction may spawn of a number of secondary transactions. This is discussed in the following section. In the section after that we will show how the requirements lead to a general architecture for a Business Transaction Management System (BTMS). The solution proposed here is quite general and does not depend on the example chosen for the purpose of illustration: the control of transactions in a pork chain.
The usefulness of a BTMS derives from the fact that it is able to keep track of the progress that has been made with a given business transaction, and of the relations between various business transactions. In order to understand the architecture, it is necessary to have some appreciation of the complications arising in a business transaction and the difficulties a transaction protocol has to deal with. It is not our aim to discuss the design of protocols here.
Business transactions. A business transaction, in the context of this paper, is regarded as the information exchange between two actors, needed to control a single physical process, such as the transport of containers. The information is exchanged between two actors (parties): a superior who initiates the transaction by requesting the activity and a subordinate, who is asked to carry out the activity.
A business transaction is to satisfy a number of conditions. An important aspect here is that a transaction controls a physical activity:
Regarding the execution of business processes, first of all, actors are autonomous. Business transaction protocols therefore are agreements that may be fixed between two business partners but may vary with different partners. Communication therefore is always between two actors. A transaction may involve more than one subordinate, but subordinates do not communicate with each other within the context of the transactions.
Local autonomy, that is autonomy of each actor, implies that in general no atomicity can be guaranteed (Mullen, [8]). There is no global transaction or chain manager and only bilateral agreements can be used.
The information exchange is split up into an exchange of (standardized) messages. In order to preserve the properties mentioned above, a transaction is characterized by a special attribute: its state. In each state, only certain messages can be meaningfully sent and received. What states are and which messages may be exchanged is specified in a protocol and can be represented by a state transition diagram, such a shown in figure 5. The labels used in this figure will be explained below. Figure 5 shows a simplified example of a business transaction protocol. A more complex example requires the transformation of the state transition diagram to a more formally specified model and the extension of that model. A formal technique that can be used, is for instance timed, coloured, hierarchical Petri nets (see [3]). The transformation of state transition diagrams to Petri nets and a complete model of the business transaction protocol are shown in [5].
Figure 5: State transition diagram of a transaction protocol
The exchange of a message may change the state of the transaction as decisions with regard to certain aspects of the requested activity are communicated. In figure 5, an example of the various states of a transaction is given. The arrows indicate the transition of one state to another (possibly the same) state, and are labeled by the type of message exchanged in making the transition. We will illustrate the diagram for the case of the pork chain, but it is applicable to other situations as well (e.g. flowers and bulbs). Similarly, alternate state transition diagrams, involving more or different transitions and messages may be devised to reflect more properly the protocol needed.
The state transition diagram summarizes the protocol by specifying in which state which type of messages may be sent or received. The information exchange passes through two phases. In advance to these phases a contract has been concluded between two actors, either for one or for more transactions. The initiation phase begins as soon as the superior sends a request (req. message). The subordinate keeps the superior informed of the schedule of the required activity by sending responses (res. message). Information about the actual progress of the activity is transmitted in the confirmation phase by means of a confirm (cf. message). When the activity is completed a final confirm (cf. message) is sent by the superior and the transaction ends. When the superior decides in the initiation phase to call of the activity, he can start a rollback transaction.
Procedures: relationship between transactions. The role of superior and subordinate is only fixed within the context of a single transaction. The dual role of an actor with respect to transactions in general is illustrated in figure 6.
Figure 6: Incoming and outgoing transactions
When dealing with a chain of activities an actor may act both as a superior and a subordinate (for different transactions). For instance, an actor, say Forwarder, who is asked by another actor - Shipper, acting as a superior - to provide a transport service, acts as a subordinate. In case Forwarder has outsourced part of the transport service, he will initiate an outgoing transaction to ask a third actor, say Carrier, to provide the transport to a port (as a subcontractor) and then acts as a superior to Carrier. Note that the incoming transaction is dependent of the result of the secondary, outgoing transaction: Forwareder can't confirm the requirements of Shipper before Carrier gives information regarding the availability of capacity for transport. Such an outgoing transaction is called an inserted transaction (see figure 7). It satisfies the following two conditions:
For instance, a request message of an inserted transaction can only be sent after a request message of the corresponding incoming transaction has been received. Every phase has to be initiated by Shipper, the superior of the initial transaction.
Figure 7: Inserted transactions
In case an incoming transaction causes an outgoing transaction but doesn't depend on the result of it, the outgoing transaction is called a decoupled transaction (figure 8). E.g. an importing forwarder may be able to arrange transport to a consignee and will never report to the exporting forwarder. Clearly, the completion of the first transaction doesn't have to wait for the progress of the second one. Another example is a warehouse that acts as a physical decoupling point between incoming and outgoing goods, or a bank account that acts as a financial decoupling point between credit and debit payments.
Figure 8: Decoupled transactions
In principle, one incoming transaction may initiate zero, one or more outgoing transactions, e.g. transport arranged on behalf of a shipper can be decomposed in three transport stages. The relationship between the phases of a single transaction are specified within a procedure. In case of inserted transactions, the planning phase of all outgoing transactions for a given incoming transaction is handled before the execution phase. The planning phases of the outgoing transactions can be in parallel, e.g. a forwarder requests transport to a port with a carrier and transport between two ports with a liner-agent at the same. The planning phases can also be in sequence, e.g. a forwarder arranges transport between two ports before transport from the place of a shipper to a port. An example of a procedure of a forwarder is shown in figure 9.
Figure 9: An example of a procedure of a forwarder
Figure 9 shows six building elements for constructing procedures. A case in sea transport has identified in total sixteen building elements. These building elements include the control of the physical chain and elements to exchange information in messages like Manifests. Development of new business transaction protocols will give additional building elements.
The requirements of the preceding section may be summarized as follows:
Figure 10: System architecture
These requirements have lead to the architecture shown in figure 10 (subsystems, i.e. processes, represented by squares, and flows by arrows). Procedures based on transaction protocols are parameters to the process 'transaction management'. It implies that if a protocol between two actors changes, it may not affect the protocol with other actors with whom outgoing transactions can be initiated within the same procedure. It also implies that if the business of an actor changes or is extended, the changed business can easily be supported by information systems and electronic communication by adding new procedures.
**The text of this section needs revision
Business Transaction Management represents the process modelling aspect of interorganisational communication. The process approach we have taken, is currently not available in legacy systems. Therefore, a BTMS can serve as a 'front-end' to and is to interface with legacy systems. Part of a procedure is modelling the communication with legacy systems. Possibly, new building elements have to be specified.
Before specifying the process aspects of interorganisational communication, one often starts to specify the data aspects. Message structures (EDI) and physical file formats (PDI) are specified using a particular syntax (e.g. EDIFACT: EDI for administration commerce and transport). We have used a functional data model (see van Hee [3]) to specify these data aspects for our example in section 2. As illustrated by Hofman in [5], (functional) data models can be mapped to data interchange standards.
The data models can not only be used for specifying the external communication; they also specify the structure of the transaction database of a BTMS and can be mapped to data structures of legacy systems. Two BTMS installation can exchange database tables; a BTMS can interface with legacy systems by converting between transaction database and data interchange standards (external conversion) or between transaction database and database structure of a legacy system (internal conversion). Thus, a mediator consists of the following functionality (figure 11):
Additionally, an application supporting humans can run on a mediator.
Figure 11: Architecture of a mediator
Each element of a mediator requires particular parameter settings for its interconnection with different legacy systems, using different standards, and being applied in different business areas like transport and health care. Each of these settings requires specific tools, e.g. a modelling tool for specifying a BTMS and its procedures and a mapping tool for mapping a transaction database to data interchange standards and database structures of legacy systems to configure external and internal conversion respectively.
In an ideal situation, every legacy system interfaces with a mediator. Thus we create extra functionality on top of a communication network (figure 12).
Figure 12: Mediators as a skin on top of a network (transport)
Figure 12 shows mediators interfacing with legacy systems in transport. We have specified a similar environment within healthcare in Holland. In some cases, these business environments have to communicate, e.g. one aspect of healthcare is ordering and logistics. Therefore, it is required that the tools have to be able to exchange data structures or Basic Semantic Units. It requires a Data Definition Language and possibly standard directory access protocols (X.500) to access information in these tools.
**The text of this section needs revision. It contains some preliminary thoughts.
We have identified new areas for standardisation in specifying business transaction protocols and building elements for procedures. These business transaction protocols are based on two-phase commit protocols (see for instance [xx]) and are used to control business processes. The basic principle is to bind resources for the execution of a business process, instead of locking records in distributed database environments. Resources are for instance people, machines, trucks, and slots in vessel. Similarly, ISO transaction protocols use a two-phase commit approach ([xxx]).
We have given a layered model of a mediator, thus indicating the relation with the OSI Basic Reference Model. External communication may be the interconnection to an X.400 network and will therefore consist of seven layers. Functionality of internal and external conversion is similar to the functionality of the presentation layer, both for connectionless and connection oriented communication. In the EDI documents, connectionless communication is often similar to batch-EDI, whereas interactive-EDI is often used as a synonym for connection oriented communication.
Syntaxes for data interchange can be SQL, EDIFACT, STEP or any other, although one syntax seems to be better equipped for a certain application area. A data modelling technique is to be selected to support the development of data structures of transaction databases. However, selecting a data modelling technique is not sufficient to achieve a common data structure of transaction databases. Certain rules have to be obeyed, e.g. a data model has to specify information elements of (physical) objects and business processes. These rules have been specified in [5].
Although we have only presented an approach for EDI, we are of the opinion that the same concepts can be applied in other application areas. For instance, product or process engineering requires a clear basic design consisting for instance of drawings and construction rules as part of an request to a supplier. The supplier is to give a detailed specification by means of a response and will confirm after or during production as agreed with his principal (see for instance [+++]).
Besides standardisation issues, we are of the opinion that clear guidelines have to be created on the implementation of these standards. The requirements as we have tried to describe them in this contribution, have to be described. These requirements can be used to specify the relationship of several standards.
**The reference list will be completed.
[1] Aerts A.T.M., Alblas G., Hee K.M. van, Conceptual modelling of systems, Academic Press, 1991 (in Dutch). [2] Aerts A.T.M., Hofman W.J., and Somers L.J., Message Flow Control, in Information Systems Development for Decentralized Organizations, Chapman & Hall, 1995. [3] Hee K.M. van, Information Systems Engineering: a formal approach, Cambridge University Press, 1994. [4] Hofman, W.J., EDI Handboek, Uitgeverij Tutein Nolthenius, 's Hertogenbosch, 1989. [5] Hofman, W.J., A Conceptual Model of a Business Transaction Management System, Ph.D. Thesis, Uitgeverij Tutein Nolthenius, 's Hertogenbosch, 1994. [?] Hofman, W.J, Engelbart, F, Chain or object management: is there a difference, to appear in Proceedings Second International Conference on Chain Management in Agri- and Food Business, the Netherlands, 1996. [6] ISO/IEC JTC 1/WG 3 N255, Open-EDI Reference Model Standard - Working Draft 1993. [7] ISO 9735, Electronic Data Interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules, ISO, 1988. [xxx] ISO/DP 10026-1,2,3, Information Processing Systems - Open Systems Interconnection - Distributed Transaction Processing (part 1: model, part 2: service definition, part 3: protocol specification), 1989. [8] Mullen J.G., Elmagarmid A.K., Kim W., Sharif-Askary J., On the impossibility of Atomic Commitment in Multidatabase Systems, in Proceedings first International Workshop on Interoperability in Multidatabase Systems, pp. 625-634, 1991. [xx] Ozsu M.T., Valduriex P., Principles of distributed database systems, Prentice-Hall International Editions, 1991. [++] Report of an NSF Workshop on the future of Database Systems Research, May 26-27, 1995. [9] Porter M.E., Competitive advantage, Creating and sustaining superior performance, The Free Press, 1985. [10] Sokol P.K., EDI, the competitive edge, Intertext Publications, McGraw-Hill Book Company New York, N.Y., 1989. [??] TEDIS II B1 Consortium, Feasibility Studyfo a Basic Semantic Repository, september 1992. [+] UN/ECE WP.4, Business and Information Modelling, 1996. [11] UN/ECE WP.4 GE.1, Recommendation on Interactive EDI, version 3.1, October 1992. [12] Venkatraman N., IT-enabled business transformation: from automation to business scope redefinition, Sloan Management Review, Winter 1994, pp. 73-87. [+++] Vries B. de, Communication in the building industry, a strategy for implementing electronic information exchange, Technical University of Eindhoven, 1996.
Return to: JSW Home Page.