GAPS++: AN INTERNET-BASED PETRI NET MODELING AND SIMULATION ARCHITECTURE Wolfgang Weitz, Wolffried Stucky Institute AIFB, University of Karlsruhe D-76128 Karlsruhe, Germany E-Mail: fweitz,
[email protected] WWW: http://www.aifb.uni-karlsruhe.de/InfoSys/ KEYWORDS: Computer Software, Discrete Simulation, Interactive Simulation, Internet, Petri nets ABSTRACT GAPS++ is an open, Internet-based software architecture for modeling and simulating dynamic system behavior using high-level Petri nets. It is designed as a collection of collaborating software components and is based on distributed object technology. GAPS++ facilitates a
exible combination of independent modeling, analysis and simulation tools located on di erent computers on the Internet. Every GAPS++ component has a built-in HTTP server. This makes it possible to inspect its current state with a conventional WWW browser at every moment.A directory service helps to locate instances of a required component type and provides the necessary contact information. GAPS++ components may be added or removed without a ecting the operation of the system as a whole. As an example for a complex GAPS++ component, a distributed Petri net editor is presented. 1 INTRODUCTION GAPS++ is an Internet-based architecture for modeling and simulating systems represented by high-level Petri This work was supported in part by the Deutsche Forschungsgemeinschaft (German National Science Foundation) as a part of the research project INCOME/WF (Stu98/9)
nets. It has been developed in the context of the INCOME project series (Oberweis, Scherrer, and Stucky 1994; Oberweis, Schatzle, Stucky, Weitz, and Zimmermann 1997). INCOME employs high-level Petri nets to model information systems. Currently, business process models and work ow management systems are our focus of interest. An early prototype, GAPS (Graphical Animated Petri net Simulator, (Oberweis, Sanger, and Weitz 1994)), allowed to connect external graphical visualization programs to a Petri net simulator via an Internet (TCP) connection by implementing a proprietary client noti cation protocol. In this way, the graphical presentation of a simulation run was technically and logically separated from the core simulation system (Fig. 1). This approach allowed to create new visualization components in a rapid-prototyping manner and to exibly attach the components even to an already running simulation process. 1 0 0 1 0 1 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11
011001
1 0 0 1 0 1 0 1 0 1 0 1 0 1 11 00 0 1
simulator external visualization client
Figure 1: GAPS: simulator-centered architecture
With the technologies available today, large parts of such a system can be implemented with signi cantly less e ort by using a standard Web browsers that can display an HTML document with embedded visualization programs (\applets") written in a language like Java. This does not introduce conceptual improvements of the overall system design but conserves a simulator-centered architecture. To create a more exible and open GAPS system, it was necessary to use a technology extending the platform independence and user-friendliness of current WWW based systems with a more ecient and exible way to combine independent software components over the Internet. This paper is organized as follows: the next section gives a short introduction to Petri nets, the modeling formalism GAPS++ is designed to support. Section 3 discusses some of the technologies GAPS++ was built on. After that, the overall architecture is presented in section 4. A special feature of our system is that the distributed components all contain a minimal HTTP server so that their current state can be inspected with a standard WWW browser. This aspect is described in section 5. A distributed Petri net editor is presented in section 6 as an example of a complex GAPS++ application. Section 7 demonstrates with a little example how to extend the system by adding a new component. Section 8 describes the integration of a Petri net simulator and the use of applets for the visualization of simulation runs. Section 9 concludes the paper with some notes on a prototype implementation of GAPS++. 2 PETRI NETS Petri nets are a well-known formalism to describe the behavior of systems. Work ow modeling is one area of application where Petri nets have proven to be very useful (van der Aalst 1996). A Petri net is a bipartite digraph G. A vertex in G is either a passive element (a so-called place ), or an active element (a transition ). A place is usually interpreted as a data store, while a transition represents a class of operations on its adjacent places. When a transition occurs, one or more tokens are removed from each of its input places and tokens are inserted into each of its output places. In the graphical presentation, places are usually drawn as circles and transitions as rectangles. In the example shown in Fig. 2, the places consultants and clients are input places of transition nd cons for client, and assignments is its only output place. A place is assigned a set of tokens, called its marking. In high-level Petri nets, these tokens have an identity (i.e. they are distinguishable). In the INCOME/WF project, predicate/transition nets (Pr/T nets, (Genrich 1987)) are used for de ning, simulating and analyzing
name skill_level Karen 17 Peter 5 Jöndhard 3
consultants
consultant company Carol Big Company SL >= SLRQ
clients
find_cons_for_client
assignments
company skill_level_required Power Plant Bank
12 4
Figure 2: sta assignment modeled as a Pr/T net work ows. In this type of high-level Petri nets, each place is assigned a relation type and may be marked with a set of tuples of this type. An arc is inscribed with tuples of variables according to the type of the adjacent place, and transitions are inscribed with logical expressions (which may use variables from the inscriptions of the adjacent edges). The dynamic behavior of a Petri net is formally de ned by the occurrence rule. In a Pr/T net, a transition t is enabled (i.e. it can occur) i there is an assignment of values to all variables in the adjacent edges of t, such that under this assignment the inscription of each incoming arc of t is contained in the marking of the respective adjacent input place, the logical expression inscribed in t evaluates to \true", the inscription of each outgoing arc of t is not yet contained in the adjacent output place. When a transition occurs, tuples are removed from its input places and inserted into its output places, according to the inscription of the respective edges under a given variable assignment. The example Pr/T net in Fig. 2 models the process of assigning consultants to projects. The inscription of transition nd cons for client makes sure that only such project assignments are made where the consultant has at least the skill level the client requested for the job. The transition is enabled e.g. for the variable assignment [N=Karen,SL=17,C=PowerPlant,SLRQ=12]. When it occurs, the tuples and are removed from their respective places and a new tuple is inserted into the place assignments. 3 DISTRIBUTED OBJECTS: A FUTURE BASIS OF THE WEB Internet-based distributed object technology increasingly emerges to be the foundation of the next generation
of World-Wide-Web applications. Tim Berners-Lee, the inventor of the WWW, stated in an interview: \A possibly very signi cant step in the development of the web is its use as a space of objects in the sense of ObjectOriented Programming (OOP)." HTML is beginning to be used as a language for creating interactive user interfaces as frameworks for combining and embedding active components. Distributed object architectures like CORBA (Mowbray and Zahavi 1996) provide a basis for building large distributed applications. The industry is starting to recognize this potential: support for distributed objects is announced for the next releases of the most popular Web browsers. These developments go far beyond the currently popular embedding of isolated stand-alone applets with their (for good reasons) restricted functionality. Distributed objects are a key technology to bring together the exibility, platform-independence and ease-of-use of a WWWbased front-end with the power of large, specialized software systems running on remote sites. 4 ARCHITECTURE OF GAPS++ GAPS++ is an extensible collection of components (Fig. 3) which are implemented by one or more objects. These can be classi ed as follows: a Data object encapsulates a data structure, e.g. a Petri net, layout information for a net or a marking of a net. Note that objects may hold references to or be composed of other subordinate objects. For example, a Petri net consists of a set of places, transitions and edges, which are all GAPS++ objects of their own right but cannot exist without their enclosing data object instance. Obviously, it is necessary to be able to create new data objects on demand. This is done by so-called factory objects. Application objects encapsulate certain operations on data objects, such as editing, analysis, simulation, visualization, persistent storage in a database etc. An application object may be implemented and run as a single object, but it can also be dynamically generated by a factory object. In Fig. 3, there is exactly one simulator and database object, while an arbitrary number of EditorSession objects may be created by the EditorSessionFactory at run time. A design goal of the GAPS++ architecture was to make it easy to add and remove components at any time, as well as to combine existing components exibly without much e ort. An arbitrary number of GAPS++ components may run on one computer, but they can also be distributed over a number of sites on the Internet. The open structure of the system should encourage people to make implementations of newly conceived algorithms available for public use. The employment of an Internet-based distributed object system o ers many advantages here:
Grail WWW browser graphical net editor frontend
analysis tool
GapsServ directory service
simulator
database
visualization applet
Internet
EditorSession factory
an EditorSession
Layout factory
a Layout
PetriNet factory
a PetriNet
Figure 3: distributed architecture of GAPS++ There is no need to install a new component on one's own computer. An existing implementation on a remote system may transparently be used over the Internet just like a local object. Components may be implemented in di erent programming languages and run on di erent hardware platforms and operating systems. The Internet is used as a layer of abstraction to integrate those heterogeneous systems. It is not necessary to reveal implementation details of a new (maybe yet unpublished) algorithm to the users in order to let them experiment with it. GapsServ, a directory service, is the only centralized component of GAPS++. It can be queried for the availability and location of any desired service (component type) in the system. GapsServ 's implementation is based on the LDAP protocol, a newly emerging standard for directory services in Internet-based systems (Lewis 1996). Each component registers with GapsServ as a part of its initialization sequence. Conversely, before returning an object reference as a response to a query, GapsServ rst tries to contact each object in order to make sure they are still operational. Each object has a so-called interface de nition which provides the information necessary to use it in textual form (e.g. its name, methods, number and type of parameters). GapsServ serves also as a repository for interface de nition les. An Interface de nition may be uploaded to GapsServ and may then be requested by anyone who wishes to access the described object type in his own programs.
5 DOCUMENTATION: BUILTIN WWW SERVICE From a user's perspective, a complex remote component designed and implemented by another person is a black box. To actually use such a component, good documentation must be available. It is clearly not sucient to obtain the object's name and contact information from GapsServ or to read its interface de nition le. Furthermore, it is often necessary to be able to inspect
a running object's internal state. This is especially true for distributed systems where a user has usually no access to the computer running the implementation of an object in question. In line with our e orts to keep the degree of centralization in our architecture as low as possible, we turned each object in GAPS++ into a minimal WWW server (Fig. 4). A standard WWW browser can be used to obtain an up-to-date description of the object's current state in HTML, the standard format for WWW pages. Since this response is generated on demand by the object itself, it is easy to include HTML hypertext links to other GAPS++ components the object is holding references to. Thus, starting from GapsServ, it is easy to explore the (dynamically changing) net of distributed GAPS++ components without specialized software. Of course, the about obj2
ob
ML
object2
lin
k
about obj3
jec
t re
fer
en
ce
HTML state information generates on demand
about obj1
HT
active object object1
object3
Figure 4: self-documenting components generated HTML response may also include references to WWW pages outside the GAPS++ system, which offers an elegant solution to the documentation problem mentioned above: A developer of a component makes all necessary documents available on his local WWW server and includes a link in the output of his object's self-description. 6 A DISTRIBUTED NET EDITOR: COOPERATIVE PETRI NET MODELING As part of a proof-of-concept study, we have designed a distributed Petri net editor based on the GAPS++ architecture. There was a special requirement from the INCOME/WF work ow modeling project that the editor should allow multiple modelers to work together over the Internet on the same Petri net model. Figure 5 shows the structure of the resulting system. An EditorSession is an application object which was created by a EditorSessionFactory (Fig. 3). It provides a set of editing operations for Petri nets. As already mentioned before, a central concept in GAPS++ is to make the essential data structures like Petri nets, net markings etc. autonomous data objects which are accessible over the Internet just like the application objects themselves, rather than hiding them inside the application objects. Consequently, an EditorSession holds references to a PetriNet, a Layout
EditorView
EditorView
EditorSession
PetriNet places transitions edges
Layout p2: t1: p1: coordinates colors, ...
Marking place p2 place p1 7 "John" 2 "Karen" ... ....
Figure 5: distributed editor and a Marking object which it operates on. These data objects may be newly created for this editing session, but the concept makes it also possible to attach an EditorSession to data objects previously initialized e.g. by automated tools. An EditorView provides a graphical user interface to an EditorSession. The separation between a usercon gurable graphical frontend (EditorView) and the abstraction of the editing session's state (EditorSession ) as a coordinating instance allows multiple users to work on the same Petri net model simultaneously. This is an application of the \Model/View/Controller" paradigm, a well-known design pattern in object-oriented programming (Gamma, Helm, Johnson, and Vlissides 1995). Each participant may choose to work on a di erent part of the model or to con gure his EditorView individually (scaling, optional grid). Fig. 6 shows screenshots of two EditorViews running on di erent computers (a PC under the Linux operating system and a Sun Workstation running SunOS) attached to the same EditorSession. In an
Figure 6: cooperative editing of a Petri net model experiment, participants in two German universities located over 100 kilometers apart cooperatively worked on the same Petri net model. A commercial teleconferencing system was used in parallel to help them coordinate their actions. The result was that even with a highly interactive application such as an editor, the response times were acceptable for practical application. This proved the concept of a toolbox of components spread over distant places and integrated over the Internet feasible.
7 AD-HOC COMBINATION OF DISTRIBUTED GAPS++ COMPONENTS The open, modular structure of GAPS++ together with the high-level programming language Python makes it easy to create new components in a rapid-prototyping fashion. Reuse of existing components allows the developer to concentrate on the task at hand. 1 import XES, ilu, GapsBrowser, Numeric (cls,connectInfo) = GapsBrowser.GapsBrowser().run() 2 session=ilu.ObjectOfSBH(XES.XEditorSession,connectInfo) net edges places transitions
= = = =
session.getNet() net.getEdges() net.getPlaces() net.getTransitions()
vertices nVertices
= places + transitions = len(vertices)
3 4
5
matrix = Numeric.zeros( (nVertices,nVertices) ) 6 for e in edges: fromVertex = e.getFromItem() row = vertices.index(fromVertex) 7 toVertex = e.getToItem() column = vertices.index(toVertex) matrix[row,column] = 1 print matrix
8
Figure 7: extracting the adjacency matrix from a remote Petri net editor session To illustrate this, let us consider the following example: We need to create a new component which computes and prints out the adjacency matrix of a PetriNet object existing somewhere on the Internet. The short program in Fig. 7 (written in Python) shows how easy this can be accomplished: after loading some helper modules (①), the GapsBrowser graphical dialog box queries the GapsServ directory and lets the user choose an arbitrary EditorSession object (②). A reference to the PetriNet object which is currently being edited is obtained by calling the session's getNet() method (③). The net is then asked to return lists of its places, transitions and edges (④). A list of all vertices is computed (⑤) and a new matrix of the appropriate size is created (⑥). The adjacency matrix is computed by considering the adjacent vertices of every edge and marking the corresponding cell with the value `1' (⑦). Finally, the adjacency matrix is printed to the screen (⑧). Note that, since the component can directly work on the remote objects, the overhead to provide the program with a Petri net as its input is minimal. In many traditional systems, additional components like this are often integrated into a single program (usually an editor). This results in large, monolithic applications and makes a recompilation of the whole system necessary after every change of a component, which is especially tedious when experimenting with a new algorithm requires frequent modi cations and tests.
Alternatively, conventional les are often used to exchange data between applications. This allows to use components separately but requires the implementation of code to reconstruct the Petri net from the le data rst before starting work. Furthermore, the integration of multiple components via le exchange is quite inecient, especially if they do not have access to a common le system. If advanced requirements like cooperative access of di erent components to a common data structure and the implementation of a complex control ow between components have to be met, a le-based approach is clearly not the way to go. In contrast to that, our example showed that the use of a distributed object system helps to solve such problems quite elegantly. All components of the system can be easily accessed over the Internet and combined with a few lines of Python code, regardless of their physical location. A remote application object running on another computer somewhere in the Internet can be used transparently like a locally installed one. Note that, in contrast to using WWW applets, not the executable code is transferred to the client and executed locally but the remote server performs a task in response to a local request, which also allows parallel requests to di erent servers, as well as communication between the components. 8 SIMULATION AND VISUALIZATION INCOME/WF uses an evolutionary approach to develop a Petri net based work ow model. An important point here is an early integration of the later user of the work ow system in the design process. Since the average oce worker is not familiar with Petri nets, a way to provide a problem-oriented visualization (rather than just an animation of the token game, the ow of tokens through the Petri net model, which may be the appropriate visualization alternative for work ow developers) without too much extra e ort is needed. In GAPS++, client components may register with the Pr/T net simulator for all or a selection of six event types (simulation starts, transition enabled/occurred, token inserted into/deleted from a place, simulation ends). During a simulation run, the simulator noti es its clients whenever an event they registered for occurred (Fig. 8). Clients may be added and removed even during a simulation run. For example, an EditorView can register with a simulator to visualize the token game of a running simulation in its editing window. As discussed in section 5, all GAPS++ components incorporate an HTTP server which can be used for retrieving the current status of the object as well as a short description and (links to) documentation. In the case of the simulator, this concept is extended to provide easy access to a visualization of a
n
tio
ra ist
g
re
ts
en
ev
EditorView applet
WWW browser Simulator
Figure 8: visualization of simulation runs simulation run: HTML pages including visualization applets can be prepared by the work ow modeler. At the time a Petri net model is loaded into the simulator, an additional list of links to such visualization pages can be transferred. After contacting the simulator object with a Web browser, the user is o ered a list of the available visualization options. A visualization applet needs some contact information to register with the simulator's event service. Since this information changes with every new start of the simulator program, the simulator retrieves the chosen visualization option's HTML page, interpolates its current binding information into the included applet's OBJECT tag and returns the result of this operation to the Web browser. In this way, the user is not required to indicate the location of the desired simulator object to the applet manually. 9 IMPLEMENTATION AND CONCLUSION A prototype of GAPS++ as described in this paper has been fully implemented. To be able to apply our own extensions and changes whereever necessary, we decided to use build our system on the basis of software components which are freely available in source code from other research institutions: GAPS++ is written in the object-oriented, high-level programming language Python (Watters, van Rossum, and Ahlstrom 1996). The Xerox ILU system (Larner 1996) is used as the distributed object framework. It is interoperable with CORBA and includes extensions like support for the WWW's standard protocol HTTP. The WWW browser Grail is completely written in Python and is specially designed for extensibility. Grail can display HTML pages with embedded Python applets and includes distributed object support with ILU. GAPS++ satis ed our requirements for a exible, distributed Petri net simulation and modeling environment as needed in the INCOME/WF project. The use of a distributed object system allowed us to build an open, extensible system whose components can easily be linked together over the Internet. Every component is able to dynamically generate its own state information and documentation in HTML which can be retrieved with a standard Web browser. Using the Grail browser, Python
applets embedded in HTML pages are fully integrated into the distributed object infrastructure. These concepts will be further evaluated in an upcoming joint research project between the universities of Frankfurt and Karlsruhe. REFERENCES Gamma, E., R. Helm, R. Johnson, and J. Vlissides (1995). Design Patterns { Elements of Reusable Object-Oriented Software (1 ed.). Addison-Wesley. Genrich, H. J. (1987). Predicate/transition nets. In W. Brauer, W. Reisig, and G. Rozenberg (Eds.), Petri Nets: Central Models and Their Properties, Advances in Petri Nets 1986, Volume 254 of LNCS,
pp. 207{247. Springer-Verlag. Larner, D. (1996). Migrating the web toward distributed objects. World Wide Web Journal 1 (4). O'Reilly & Assoc., Inc; WWW: http://www.w3.org/Journal/4/s3.larner.html. Lewis, J. (1996). LDAP unites the internet. BYTE 21 (12), 121{126. Mowbray, T. J. and R. Zahavi (1996). The Essential
CORBA { Systems Integration Using Distributed Objects. J. Wiley & Sons, Inc.
Oberweis, A., V. Sanger, and W. Weitz (1994). GAPS { a multiuser tools for graphical simulation of Petri nets. In J. Halin, W. Karplus, and R. Rimane (Eds.), CISS { First Joint Conference of International Simulation Societies Proc., Zurich, Switzerland, August 22{25, 1994, pp. 377{381. The So-
ciety for Computer Simulation, San Diego, CA, USA. Oberweis, A., R. Schatzle, W. Stucky, W. Weitz, and G. Zimmermann (1997). INCOME/WF { a Petri net based approach to work ow management. In H. Krallmann (Ed.), Wirtschaftsinformatik '97, Berlin, Germany, February 26{28, 1997, pp. 557{ 580. Physica-Verlag, Heidelberg, Germany. Oberweis, A., G. Scherrer, and W. Stucky (1994). INCOME/STAR: Methodology and tools for the development of distributed information systems. Information Systems 19 (8), 643{682. van der Aalst, W. M. P. (1996). Three good reasons for using a Petri-net-based work ow management system. In S. Navathe and T. Wakayama (Eds.), Proc. International Working Conference on Information and Process Integration in Enterprises (IPIC'96),
Camebridge, Massachusetts, pp. 179{201. Watters, A., G. van Rossum, and J. Ahlstrom (1996). Internet Programming with Python. MIS Press/Henry Holt publishers, New York.
