INTERPROCS: A Java-based Prototyping Environment for Distributed Electronic Trade Procedures Ronald M. Lee EURIDIS, Erasmus University, P.O. Box 1738, 3000 DR Rotterdam, The Netherlands;
[email protected] Abstract This paper introduces the concept of an electronic trade procedure as a potential solution to "open" electronic commerce -- trade among parities that have no prior trading relationship. The basic idea is that these trade procedures would be stored in a publicly accessible electronic library (perhaps maintained by an independent international organization), and downloaded loaded by trading parties as needed for a particular trade. A representation, called documentary petri nets (DPN) is presented as a possible representation for such trade procedures. The InterProcs system is described as a prototyping environment to support the design and execution of such trading systems using this DPN representation. Given our assumption that the parties are trading at "arm's length", a key concern will be the development of "trustworthy" trade procedures that have sufficient controls and evidentiary documentation. Various directions of further work are described to improve the quality and flexibility of trade procedure designs.
1. Open Electronic Commerce The focus of this project is on "open" electronic commerce: doing business among parties having no prior trading relationship. What we hope to achieve is computerized support for commerce that is "trustworthy" in the sense that trading partners do not know each other, and may even come from different countries and cultures, may conduct business with the assurance that their interests will be protected in the event that "things go wrong", whether by accident, negligence, or intentional fraud. In essence, whereas EDI provides a computational version of the front side of business documents (containing the transaction data), our interest is in computerizing the *back* side of business documents, which contain the rules and procedures for conducting the transaction -- the trading parties' "way of doing business". This has led us to develop formalisms for representing "automated trade procedures" that may be stored in publicly available
libraries, and downloaded by trading parties to perform transactions safely. These automated trade procedures are parameterized according to the risk profiles and available technologies of the trading parties. (Thus, while EDI might be the preferred technology, trade procedures should also be able accommodate parties having e.g. only fax or only paper.) The above representations and techniques have been implemented as a CASE tool prototyping environment called InterProcs, which has been evolving for some six years. In its present form, there are actually two systems1: • •
InterProcs Designer -- for graph-based design and simulation of trade procedures (as Java standalone) InterProcs Executor -- for viewing and simulation (as Java applets, executed from a Web site) and actual execution of trade procedures over the Internet (as Java stand-alone applications, utilizing the POP email protocol).
2. Automated Trade Procedures In order to conduct electronic commerce, parties have to know about each others' "way of doing business" before they can start exchanging data electronically. Extra knowledge about the preferred way of doing business of one trading partner has to be conveyed to the other; in other words, the parties have to agree upon the trade procedure they are going to follow. (These are also called "transaction models" or "trade scenarios" -- see e.g. the ISO/IEC sub-committee on Open-edi, ISO/IEC JTC1/SC30). A trade procedure is the mutually agreed upon set of rules that governs the activities of all parties involved in a set of related business transactions. Thus, a trade procedure controls all interactions between the roles involved. A trade procedure stipulates which actions should be undertaken by which parties, the order in which these actions should be performed and possibly the timing constraints on the performance of these 1 Sample models using the InterProcs Executor may be viewed and executed from the Euridis Web site: http://www.euridis.fbk.eur.nl/Euridis/
1060-3425/98 $10.00 (c) 1998 IEEE
actions. Actions of parties include the sending and/or receiving of goods, documents or funds. The need and usefulness of trade procedures is easy to demonstrate. Consider only a simple post-payment contract for goods. The buyer assumes that an invoice will be sent after delivery to trigger the payment obligation. The seller, on the other hand, abides by the practice that payment becomes due from the time of delivery, and does not send an invoice. Thus, the goods arrive, and the buyer does not pay, waiting for an invoice. Meanwhile the seller becomes irked, and initiates collection proceedings. This is an example of the so-called 'battle of the forms'. Each party utilizes standardized documents such as a purchase order, delivery agreement, etc. which contain (typically on the backside, in small print) the terms and conditions that are their style of doing business. Unfortunately, the small print is often ignored by the receiving party. For trade in a well-established industry area, standardized practice becomes generally accepted, and there usually is not a problem. In some cases, guidelines by international bodies such as the International Chamber of Commerce or the UNCID have been established [6]. However, in more open trading situations, that cross national, cultural or sectorial boundaries, such conflicts are much more likely to arise. Many existing EDI applications of course embed the types of document exchange sequencing of a trade procedure. However, these sequences are normally 'hard coded' into the application programs, as specified in the terms of the 'trading partner agreement', a legal, textual document. A key aspect of the architecture presented here is that trade procedures are 'soft coded', in a declarative, rule-based form. This has the virtue that they may be down-loaded from e.g. a central library to meet the needs of a particular contractual situation.
Figure 1. Contracting Phases
3. Documentary Petri Nets In Figure 1, the contracting process is divided into three main phases: shopping, negotiation and performance. (While we recognize that this oversimplifies somewhat, it is sufficient for present purposes.) Interpreting this in an electronic commerce context, the shopping phase involves navigating among the product offerings of various vendors (e.g. electronic advertisements on the Web). As a result of this phase, the customer identifies a prospective vendor and specifies the product characteristics to be purchased. During the next phase, negotiation, the parties will arbitrate two things: A. the doing tasks of the contract (payment terms, delivery terms) B. control tasks -- including documentary requirements. The output of this negotiation will be the trade procedure that the parties will follow for the execution of the contract. The negotiation process itself also follows a procedure. For many types of trading, this procedure remains more or less the same. The documentary controls for such a negotiation procedure will be such standardized (EDI) documents such as purchase order, PO acknowledgment, etc. However, in certain contract domains, additional controls are required. One example is secured loans, such as home mortgages or documentary credits. In these cases, substantial additional control documentation is needed such as credit worthiness of borrower, inspection of the asset, market value of the asset, etc. In this section we describe the representation called Documentary Petri Nets (DPN's), used to specify a specific instance of a trade procedure. A basic issue for this project is how electronic trade procedures should be represented (a.) from the modeler's perspective, and (b.) from a computation (inferential) perspective. In the course of our prior research, we have examined a wide number of such representations, including statetransition diagrams, marked graphs, event nets, event grammars, the event calculus, process algebras, temporal and dynamic logics. Eventually, we found Petri Nets to be the most appropriate representation for capturing the temporal/dynamic aspects of electronic trade procedures, offering both a graphical representation (for modelers) and a formal basis for the verification of various properties (computational). In addition, Petri nets have become popular in a wide variety of problem domains where sequence, contingency and concurrency of activities need to be modeled. This wide acceptance facilitates the training and understandability for electronic trade procedures. However, Petri nets by themselves offer only a temporal framework for knowledge representation. For that reason, we have
1060-3425/98 $10.00 (c) 1998 IEEE
found it necessary to add various extensions to the Petri net representation, making it more appropriate for the modeling of trade procedures, what we call Documentary Petri Nets (DPN's). Basic petri nets focus on the representation of discrete dynamic systems, including aspects of concurrency and choice. A petri net is a bi-partite, directed graph with two disjunct sets of nodes: places (represented as circles) and transitions (represented as bars). Arcs connect places with transitions or vice versa (it is not allowed to connect two places or two transitions). The dynamic behavior of the modeled system is represented by tokens flowing through the net (represented as blackening of a place). A transition is enabled if all its input places (i.e., arcs exist from those places to the transition) are marked. If this is the case, the transition removes the token from each input place and instantaneously produces one in each output place (i.e., an arc exists from the transition to the place). This is called the 'firing' of a transition. Our extended form of petri nets is called documentary petri nets (DPN's). An important addition we make is the interpretation of transitions as the actions of contracting parties, which are indicated by an associated label of the form: :
Also, whereas basic petri nets represent relative time, we needed to add certain absolute time notations for deadlines, etc. In DPN's, these are included as another kind of transition, namely a timer event, having an associated label of the form: >>
Most commonly, these involve a comparison of the built-in parameter, @current_date, with a another date such as a delivery deadline. Another important extension we have included in DPN's, is a representation of documents (normally of the EDI variety). Syntactically, these are another kind of place node, called a document place, drawn as a rectangle. These have an associated label of the form: to : []
Normally, the document list will be only a single document (type), but this allows also for the sending of bundles of documents as a single documentary communication. Note: The exchange of funds is modeled as a document. Since the concept of money is closely related to documents (a 100 dollar bill is a performative document), we use the document places to denote funds transfer. In the description of these documents, the amount and currency are specified in the structure of these documents.
A variation of document places that is occasionally used is a goods place, indicating the exchange of physical goods. The notation for this is a cube, and it has a similar labeling as for document places: to : []
In addition to the above described labels, any of the control places, document places or good places may have an additional kind of label, known as a state predicate. These use the same predicate notation as in Prolog, and are used to indicate additional properties and relations that become true when the place is marked. These are commonly used to indicate changes in deontic status, for instance, oblig(X,A) which means that party X has an obligation to perform action A. One important aspect of modeling trade procedures is the ability to model the procedures of each role as a separate documentary petri net. This allows the decomposition of an trade procedure into a number of logically separate sub-nets. This modeling style results in a clear 'geographical' separation between the roles. As the role description is a sub-net in the scenario description, designers have some flexibility for experimenting with different role descriptions within the overall scenario constraints. A state transition is enabled by receiving a document, goods or funds, or the expiration of an internal timer (events). Firing a transition can lead to sending documents(s), goods or funds and/or setting an internal timer (actions). Each party (role) to the contract has a separate DPN graph, indicating its actions in the overall transaction. This will be illustrated in the more detailed examples of documentary petri nets appearing in the scenario, below. While the DPN's are used here as the representation for electronic trade procedures, we acknowledge the possibility that better representations may later be found. While the InterProcs prototyping environment is built using this representation in its graphical interface, the underlying computational representation is actually predicate logic (not seen by the modeler), which enables us to support a wide variety of alternative modeling representations.
4. InterProcs In this section we provide an overview of the InterProcs system, which implements the research ideas we have developed for open electronic commerce. The motivation behind the development of InterProcs is to validate our concepts and representations for electronic trade procedures, demonstrating their feasibility though realistic prototype transaction models with actual EDI documents. InterProcs divides into two separate systems, one which executes existing transaction models, called InterProcs Executor and the other, called InterProcs Designer, to aid in the modeling and
1060-3425/98 $10.00 (c) 1998 IEEE
knowledge base development for these transaction models.
4.1. InterProcs Executor In this section, we explain the operation of the InterProcs Executor. With it, one can view and execute existing trade procedure models in two modes: •
•
Viewer Mode: access the trade procedure via a Web site (as an applet), and execute it, simulating all the roles together in a single (browser) window. Documents are transmitted among the roles internally within the executing Java program. Network Mode: download the role(s) of a trade procedure from a Web site, executing them using InterProx Executor as a stand-alone application. Documents are transmitted among the roles via normal Internet email.
4.1.1. Viewer Mode This section illustrates how to load and execute an existing InterProcs model (for instance, from the Euridis Web site). After InterProcs Executor has loaded, an image such as the following will appear:
Figure 2. Display of RFQ (in Italian). User is selecting color. Here, the user sees the electronic document in Italian, and is selecting the choice for red (Rosso) bicycles. As the procedure executes, active places will be marked in black, as shown in the background window of the procedure. The Next button has a dual function. It will first scan the currently showing role, and attempt to execute an action (transition). If no transitions are enabled, it will scan the other roles until it finds a role with an enabled action. Finding this, it will jump to that role and do the action. For instance, in the Simple example, clicking Next (a couple of times) will switch over to the buyer role, shown here in Dutch:
Figure 1. Initial display of Simple example. User is changing language. Note: the appearance will vary slightly depending on the browser and platform. Electronic documents may be viewed at any time by clicking on the document box (rectangle). Also, if the Show Docs On Send option has been selected, they will appear automatically when the document place is marked. For instance:
Figure 3. Display of Seller role (in Dutch). User is about to execute next action.
1060-3425/98 $10.00 (c) 1998 IEEE
4.1.2. Network Mode In Network Mode, the program operation is similar to that in Viewer mode, except that only one role is visible to any single user. Additionally, the sending the document requires that an email account be specified.
4.2. InterProcs Designer In this section, we explain the operation of the InterProcs Designer. With it, one can design new automated trade procedures utilizing: • • • •
graphical drafting using documentary petri nets, by role sharable 'template' sub-procedures design of electronic documents design of detail computations on documents
A principal feature of InterProcs is its modeling environment for designing automated trade procedures. It offers a graphical user interface with which Documentary Petri Nets (DPN's) can be drawn. Furthermore, since InterProcs embeds a Prolog engine, rule-bases can be added to a trade procedure model, allowing further automated 'intelligence'. InterProcs can not only be used to draw trade procedures, it also offers the possibility to simulate and/or animate them. Using InterProcs, each role description is represented as a separate Documentary Petri Net. The trade procedure 'view' of each role of the transaction is shown in a separate window on the screen. A view of the total trade procedure can be achieved by opening all windows containing the role descriptions. The communication between the roles is done by exchanging data as electronic documents. Also, the exchange of goods may be represented (for simulation purposes). The practical contribution of this research is to provide organizations with a method and a tool to define and test automated trade procedures. These trade procedures may be constructed either top-down or bottom-up. In the first case, an overall trade procedure will be distributed over the individual roles. In the second case, the individual role descriptions of the parties have to be combined. In either case, the role descriptions can be distributed over multiple machines, where information parcels may be exchanged over a local or wide area network using an EDI standard. This provides a realistic testing environment in which roles can be played and evaluated by different organizations. Once tested and agreed upon, the trade procedures may be stored in a public repository, e.g. a Web site. Since the trade procedures are defined and stored in a formal language (DPN), they are available for organizations to down-load and execute (using InterProcs Executor). During this execution the overall control of the trade procedure is distributed among the individual role organizations.
5. Modeling Example As an example problem domain we will analyze the formation and execution of an international contract for the sale of commercial goods. Commonly, international sales contracts are executed by a documentary credits procedure, subject to the rules set forth in the Uniform Customs and Practice for Documentary Credits [6]. Documentary credit procedures were introduced by the banking community in order to solve a common problem in business: the lack of trust among trading partners. When partners don't know whether they can trust each other, the risk for both buyer and seller is very high. For example, the buyer might pay for the goods without being sure of receiving them or the seller may ship the goods without being sure of getting paid. These problems arise particularly when the trade is international, as a common legal and banking system exists when trade is conducted within the same country. The solution that the banks offer to international business is that they take over the risk for the buyer and seller. The buyer and seller may rely on a trusted relationship between their banks. Documents play an important role in these transactions in that payment for the goods is made not on the delivery of the goods themselves but on the presentation of stipulated documents. Stipulated documents may include a commercial invoice, an insurance certificate, a certificate of origin, and a transport document (e.g., a bill of lading or an airway bill), among others. The seller receives payment by presenting the stipulated documents to a bank (the advising bank) that the buyer has instructed to make payment. Two attributes make documentary credit procedures in international sales contracts an appropriate problem domain for automated trade procedures. First, these procedures involve numerous agents who often must interact in disparate languages. The agents in an international sale using documentary credits may include two or three banks, a forwarder/broker, a liner-agent, a land transport carrier, a customs official, an insurance agent, a stevedore (to load the goods on the ship), a ship's captain, and several others in addition to the buyer and seller. Also, the goods may have to cross several borders in their transit from seller to buyer; thus, multiple versions of documents in various languages may be required. (The multi-lingual interface and text generation capabilities of InterProcs are thus useful here as well.) Second, these procedures are mired in bureaucratic complexity and are subject to a host of confusing rules depending on the countries of the exporting/importing parties. At one time as many as 100 forms (i.e., performative communications) were required to ship goods from one country to another and to arrange payment. The task of processing these myriad forms was so cumbersome that the goods commonly travelled
1060-3425/98 $10.00 (c) 1998 IEEE
faster than the forms, arriving before the documents did. When the goods being shipped were perishable foodstuff, the buyer was placed in the untenable position of watching his goods go 'bad' as he waited for the documents allowing him to claim the shipment. Using information technology to generate, process (i.e., reason about) and transmit these documents could avoid these problems. In the following example, we present a simple documentary credit procedure, including the buyer (called "consignee"), the seller (called "shipper"), the consignee's bank ("issuing bank") and the shipper's bank ("corresponding bank"). Almost all documentary credit procedures conform to the guidelines issued by the ICC [6]. By including a sentence such as 'this LC has been issued under the rules of ICC/ UCP 500' these guidelines become legally enforceable, independent of differences in national legislation of the involved parties' countries. The principal roles in this procedure are: • • • •
Consignee -- the recipient of the goods (normally the buyer). Shipper -- the party dispatching the goods (normally the seller). Issuing Bank -- the bank issuing the credit (normally in the buyer's country). Corresponding Bank -- a partner bank, which handles paper work at the other side (normally in the seller's country).
Figure 2. Execution Snapshot of DPN for Consignee
Following are snapshots taken from InterProcs of this transaction model. This model may be executed on our Website, ("http://www.euridis.fbk.eur.nl/Euridis/").
Figure 3. Execution Snapshot of DPN for Issuing Bank
Figure 1. Execution Snapshot of DPN for Shipper
1060-3425/98 $10.00 (c) 1998 IEEE
principles, Audit Daemons use these same kinds of principles to provide a "bottom up" approach in providing feedback and advice about procedural controls in documentary petri nets that are designed manually. Originally, these Audit Daemons were used to analyze internal control procedures [5]; a current dissertation [3] generalizes this to the inter-organizational context.
6.2. Procedure Constraint Grammars
Figure 4. Execution Snapshot of DPN for Corresponding Bank
6. Navigation Among Alternatives This paper has introduced the concept of an electronic trade procedure as a potential solution to "open" electronic commerce. The basic idea is that these trade procedures would be stored in a publicly accessible library (perhaps maintained by an independent international organization such as the International Chamber of Commerce), and downloaded loaded by trading parties as needed for a particular trade. The documentary petri net (DPN) representation was presented as a possible representation for such trade procedures. While other representations may later appear, the DPN representation has served us well in a wide variety of transaction modeling applications. The InterProcs system was described as a prototyping environment to support the design and execution of such trading systems using this DPN representation. Metaphorically, the InterProcs Executor is to the DPN representation like Web browsers are to HTML. The InterProcs Designer would correspond to such design aids as Visual HTML for designing Web sites. Beyond this, we also are pursuing several directions to improve the trade procedure designs. One is the development of so-called "audit daemons" that help the designer identify control weaknesses, e.g. fraud potentials, in a designed procedure. Another direction is the automated generation of procedures, using what we call "procedure constraint grammars" (PCG's). A third direction is the navigation of constraints and/or regulations which might be distributed among various national authorities, utilizing a type of intelligent agent we call a "messenger".
6.1. Audit Daemons Whereas the Procedure Constraint Grammar and Messenger are "top down" approaches that produce procedures that are designed to be correct from basic
A limitation of the manual design approach (indeed, more generally of other open edi approaches) is that the scenarios produced are fixed; that is, they cannot be adapted or adjusted to meet additional needs of a given situation. In this part of the project, we address this problem with an expert system approach, by which scenario components are broken down into reusable component parts, which can be flexibly reassembled to meet the needs of a wide variety of situations. The computational formalism employed is called a procedure constraint grammar (PCG). As its name suggests, an objective of the PCG representation is to describe procedures by their temporal ordering constraints, rather than the absolute sequence of steps. This allows for more flexible re-combination of procedural components (doing and control tasks). Using a procedure constraint grammar, the user interacts with the system, specifying constraints and objectives of the contracting situation. Based on these specifications, the system composes a trade procedure, which is presented in graphical form, and which can then be compiled and simulated. Here, the term 'grammar' is used in the linguistic sense of generative grammars, i.e. a set of rules for generating syntactically correct or well-formed sentences in a language. The objective of PCG rules is to generate procedures that are not only well-formed syntactically, but also from a control standpoint. In this aspect, a procedure constraint grammar operates like an expert system shell that may be used to develop knowledge bases about contracting and associated legal and documentary requirements. Unlike language grammars, however, which are typically represented as an integrated hierarchy of rules, PCG's are organized as constraints on a target procedure. It is the job of the PCG constraint solver to identify a (minimal) solution procedure (according to some preference ordering of the user -- e.g. minimal duration vs minimal risk).
6.3. Messenger Model An emerging problem for electronic commerce applications, especially in international trade is "distributed governance" -- e.g. navigating the regulations and trade practices of the various government agencies, trade agents, banks, transporters, insurance and other companies involved. Since these regulations and trade practices and controlled by different authorities, it
1060-3425/98 $10.00 (c) 1998 IEEE
is not practical to assume they are gathered into one central location, or even that they are necessarily consistent. Our approach to this problem is to utilize a special kind of intelligent agent, called messengers, that navigate the regimes (in a computational format, such as PCG) of these agencies and parties and synthesize a trade procedure [12]. This is the most advanced area of our research, but potentially also the most important.
References [1] Ahlsen, M., Pelkonen, H., Walseth, S. "Concepts and Notations for Open-edi Scenarios", Dedicate Project Report No 8, Swedish Institute for Systems Development SISU, February 1994 [2] Bons, R.W.H., Lee, R.M., and Wagenaar, R.W. "Computer-Aided Auditing of Inter-organizational Trade Procedures", submitted to Intelligent Systems i n Accounting, Finance and Management, Special Issue o n Electronic Commerce, ed. Jae Kyu Lee. [3] Bons, R. "Designing Trustworthy Trade Procedures for Open Electronic Commerce", PhD Dissertation, Euridis and Faculty of Business, Erasmus University, to appear, 1997. [4] Chen, Kuo Tay. Schematic Evaluation of Accounting Control Systems, University of Texas at Austin, 1992. [5] Chen, KuoTay and Lee, Ronald. "Schematic Evaluation of Internal Accounting Control Systems", Euridis Research Monograph (RM 92.10.01), October, 1992. [6] ICC, The Uniform Customs and Practices for Documentary Credit Procedures, International Chamber of Commerce publication number 500, Paris, France, January, 1994. [7] ISO, The Open-edi Conceptual Model, ISO/IEC JTC1/SWG-EDI, Document N222, 1991. [8] ISO, The Open-edi Reference Model, IS 14662, ISO/IEC JTC1/SC30, 1996. [9] Kalakota, K., Whinston, A.B., Frontiers of Electronic Commerce, Addison-Wesley Publishing Company Inc., Reading, U.S.A., 1996. [10] Lee, R.M., Dewitz, S.D., Facilitating International Contracting: AI Extensions to EDI, International Information Systems, January, 1992. [11] Lee, R.M., Bons, R.W.H., Soft-Coded Trade Procedures for Open-EDI, International Journal of Electronic Commerce, pp. 27-50, Volume 1 Number 1, 1996. [12] Lee, R.M. "A Messenger Model for Navigating Among Bureaucratic Requirements", Proceedings of the Hawaii International Conference on System Sciences, January, 1997, Vol IV, pp. 468-477.
[13] Wrigley, C.D., EDI transaction
protocols i n international trade, Proceedings Conference o n interorganizational systems in the global environment, Bled, Slovenia, September, 1992.
1060-3425/98 $10.00 (c) 1998 IEEE
