Using Coloured Petri Nets to aid the Design of Object based Systems

Transcription

1 Using Coloured Petri Nets to aid the Design of Object based Systems A. Tokmakoff, J. Billington University of South Australia, Warrendi Road, The Levels, 5095, Australia E Mail : [A.Tokmakoff, J.Billington]@UniSA.Edu.Au Keywords: Modelling, Simulation, Distributed Processing, Petri Nets ABSTRACT As middleware and networking technologies improve, heterogenous distributed systems are expected to become commonplace. An Object based approach to designing these systems has been adopted by ISO and ITU T in their standardisation of the Reference Model for Open Distributed Processing (RM ODP). An important infrastructure Object within these systems is the recently standardised Trader, which provides Objects with a dynamic resource location service. In order to engineer reliable Open Object based Distributed Systems, it is important to perform modelling and analysis as part of the design process. In this paper, we model the Trader using Coloured Petri Nets and the Design/CPN tool. The model is described, and verification of the model using simulation and Occurrence Graph Analysis is presented. 1. INTRODUCTION Object based systems have been widely accepted as an underlying model for describing Open Distributed Systems, as illustrated by the recent standardisation efforts of ISO and ITU T with the Reference Model for Open Distributed Processing [1] (RM ODP). These distributed systems operate across heterogeneous platforms, where hardware and software systems are provided by multiple vendors. The aim of RM ODP is to define an architecture which allows systems using different hardware and software platforms to share resources and services in a completely transparent manner. As part of this work, a Trading function has been identified which has also been the subject of standardisation [2]. The Trader maintains a database of exported offers and matches import requests with previously exported service offers, returning the most appropriate offer to the importing object (using optional selection criterion provided by the initial request). The Trader provides a mechanism to allow objects in a distributed system to locate each other, thereby allowing sharing of resources and services. Thus, client Objects (Importer) may dynamically locate server Objects (Exporter) which may be located elsewhere in the heterogeneous distributed system using the Trader as a trusted third party. Multiple Traders may interwork [3], thereby increasing the offer space available to client Objects and providing a means for information partitioning. 2. THE ODP OBJECT MODEL The ODP Object model considers an Object to be an entity with internal state and providing methods (services) at an interface which may be used by other Objects. External Objects may only communicate with an Object via the interfaces it presents to the outside world. This allows encapsulation of data and ensures that external Objects are unable to tamper with the internal workings of an Object. Objects are autonomous and it is the interaction between Objects which defines the system s behaviour. Objects may move throughout the system and thus, their location cannot be assumed to be a static property. In addition, new Objects are continually being created and improved in dynamically evolving Open Distributed Systems which indicates a need for a service that dynamically locates Objects at run time. 3. THE TRADING FUNCTION The Trader stores service parameters which describe attributes of exported services/resources. These parameters are used by the Trader to match an import request with a previously exported service. When a set of offers which fulfil the request is obtained, the Trader may then select the best service based upon optional selection criteria provided by the initial client request. The sequence of interactions between the Exporter, Importer and Trader to locate a service are shown in Figure 1 [4]. 1. Service Export Exporter Trader 3. Import Reply 2. Import Request 5. Service Reply 4. Service Invocation Importer Figure 1. Sequence of Interactions between Exporter, Trader, and Importer. 1. Service Export: The Trader receives a service export from the Exporter which is stored in a Database. This request includes

2 a description of the service, a location at which the service may be accessed, and properties of the service. 2. Import Request: The Trader receives a service Import Request from a client. This request includes the type of service required and a list of desired attributes. The Trader checks with an Infrastructure Object called the Type Repository (not shown in Figure 1) to ensure that the requested service and properties are legal. 3. Import Reply: The Trader searches its database of exported services and returns any successful matches after applying selection criteria which is optionally specified by the Importer. 4. Service Invocation: The Importer is now free to utilise the Exporter s service and interact independently of the Trader. 5. Service Reply: The Exporter replies to the Importer s service invocation. Interworking of Traders [5] is where multiple autonomous, possibly heterogeneous Traders cooperate to provide an increased range of matching services. This is facilitated by the creation of Links which describe the knowledge one Trader has of another and with whom it may Interwork. Using these Links, a Trader may act on behalf of one of its clients, as the client of another Trader. 4. COLOURED PETRI NETS CPNs were developed in the early 1980 s by Kurt Jensen at Aarhus University in Denmark [3]. CPN models have a graphical form and a well defined semantics which allows for formal analysis. They have been applied to a variety of applications [6] including Description of Services in Intelligent Networks, Specification and Verification of Protocols and Design and Validation of Hardware at the Register level. When graphical simulations are executed, tokens move throughout the system as transitions fire. Tokens may be arbitrarily complex data values hence simulation allows data flows to be modelled. CPNs are high level Petri Nets which provide for modelling with hierarchical structure and representation of complex data types. there to be an unambiguous statement of the Trader s functionality. We believe that it is important to develop specification prototypes which can be executed to gain insight into the Trader s operation. To do this, we are using Coloured Petri Nets to provide a specification prototype, and the tool Design/CPN for creating and managing the prototype, and for performing simulation experiments. The aims here are to increase our understanding of the dynamics of trader, while at the same time, evaluating the utility of CPNs as a modelling language. 6. THE CPN MODEL The model is of an Open Object based Distributed System, where Objects may be further decomposed into functional entities. It is possible that these entities may be implemented as Objects themselves. The Trader has been modelled in a manner which allows multiple instantiations of Traders and Interfaces to exist within the system. This has been done through the use of a unique instance identifier token, stored within each instantiation and assigned a unique value prior to a Simulation run. A. The Model Hierarchy Design/CPN provides us with the opportunity to create a hierarchy of CPNs which as a whole, model the Trader. These CPNs may represent Objects located in the Trading Environment, or may be used to hide complexity within the model. Figure 2 shows the Hierarchy page of the model (Hierarchy#1001), where pages are represented by a node containing a page name and number. The Trader has ben modelled using Design/CPN [7], a tool supported by Aarhus University in Denmark. The tool allows the creation of hierarchical models. This means that a model may be spread out over a number of pages, where each page models different aspects of the system providing a mechanism for modularity. A page which is used by another is known as a sub page of a super page. The CPN on the sub page is known as a sub net. The main construct for this is a substitution transition. Information on obtaining a free license for Design/CPN may be obtained at: 5. MODELLING TRADER S DYNAMICS An important first step is to increase one s understanding of the Trader by the developing models. A formal specification allows Figure 2. The Hierarchy page of the Trader Model. Relationships between pages are indicated by a directed acyclic graph. This page indicates a uses relationship between pages and is created by Design/CPN upon request (page names are truncated to 8 letters). The function of the pages are as follows:

3 Declarat#2 is a page which contains the Global Declaration Node, where all colour sets and variables are declared, and Standard ML function code is located. Trad_Env#1 is the top most page of the model which defines a topology for communication between Objects in the Trading Environment. It is also the Prime Page which specifies which pages of the CPN should be simulated. Trad_Int#13 represents a Trader operating in the Trading Environment. It has been instantiated twice (Trader_1, Trader_2) allowing interworking Traders to be modelled. TSI#8 represents a Trading Service Interface which is instantiated by the Trader to provide a well defined interface to the Trading Community. SPI#15, LSI_Page#16 and OSI_Page#17 represent Interfaces to the Search Policy, Link Space and Offer Space Objects respectively. They are instantiated by the Trader to provide an interface to the corresponding Object (a binding in ODP terms). Trader#19 models the Trader Object itself. It is the Object which contains functionality to Trade resources/services in an Open Object Based System. It performs management of transaction identifiers whilst servicing concurrent requests. Import_O#3 and Export_O#10 model the operations which the Trader performs when servicing an Import and Export Request respectively. These pages are sub pages of Trader#19. B. Trading Environment Top Level Page The top level page of the model is Trad_Env#1 (Figure 3). It can be seen that are 6 instances of Computational Objects in the distributed system, each of which has been modelled at a lower level on a separate page. An auxiliary box has been used to illustrate the Objects which are part of the Trading Infrastructure. Sub pages are linked to Trad_Env#1 through the use of a shared place which models a Communication Medium used by objects for message passing. It is assumed that there is a Communication Protocol stack in place which provides a service in which: messages are neither lost, nor duplicated, ordering of messages is unimportant (overtaking is allowed), there is no mutilation (corruption) of messages. Each Object in the system is modelled by a substitution transition which encapsulates the object and places it in the context of the environment in which it resides. Substitution transitions are indicated by the presence of a HS within a box located in each transition on the page. The Objects communicate through input/output ports which have a mapping from the high level Trader Environment page to the corresponding sub page representing the object. Thus, the place Comms_Medium has a place in each substitution transition sub page which has exactly the same marking. Importer#5 represents the Importing Object. This page models an importing Object which submits Import requests to the Traders. Search#6 represents the Search Policy Object. This Object is used to determine the Search Scope when an Import Request is being processed. Information held by this Object determines whether a Trader should search the local database, forward the Import Request to linked Traders, or both. Offer_Sp#7 represents the Offer Space Object which is used by the Trader to manage offers which are submitted to the Trader by Exporting Objects. It is a Generic Service Object which may be used by any Trader in the Trading Environment. Link#9 represents the Link Space Object which manages the Trading Links. It maintains a record for each Trader which contains information on the links between Traders (via the TSIs), thereby allowing interworking of Traders. OGA#4 represents a page on which the Occurrence Graph may be drawn and analysed. The Search#6, Offer_Sp#7 and Link#9 pages represent Objects which are yet to be specified by the ODP Standardisation process. In this model, these Objects have been modelled with a limited functionality so as to enable the Trader to perform its service. Figure 3. The Top Level page (Trad_Env#1). Objects in the system have unique identifiers required by the communications sub system to allow inter Object communications. These identifiers are defined by colour Id which is similar to an enumerated type found in most programming languages. Generic Object Identifiers are used in addition to unique Object identifiers. An important colour in the model is Message which defines the structure of messages passed between Objects in the system. It is defined as a tuple of two colours: color Addresses = product Id*Id; color Op_Data = product Op_Elem*Trans_Id; color Data = product Operation*Op_Data; color Message = product Addresses*Data; Addresses is a pair of sender and receiver identifiers for the message, and Data is a pair containing an Operation to be

4 performed and Operation Data, which are parameters for the operation. Operation Data is a tuple consisting of the Operation Element (Op_Elem) and a Transaction Identifier (Trans_Id). This allows the Importing Object to assign a unique identifier to requests, and the Trader to service multiple requests concurrently. The colour Operation defines all valid operations which objects may perform including: color Operation = with get_offers import query_offer_subgraph export get_links unify_policy error respond acknowledge; All Operations have an associated Op_Elem containing Operation parameters. Op_Elem is defined as a Union of different colours representing data required for different Operations. The colours which model Service Offers are based upon the Trader Standard. As before, high level colours are made up of products of lower level colours. A service type is defined by a tuple consisting of an Interface Type (Int_Type), which defines what the service is, and a list of Service Properties (Serv_Prop), which is a list of attributes associated with the service. From this, a Service Offer includes a reference to where the service may be obtained (Serv_Int_Id). An Offer_List is simply a list of Service Offers. It is used in the model for storing the exported offers and for creating a list of retrieved offers which will undergo a selection process to obtain the best. color Serv_Type = product Int_Type*Serv_Prop; color Serv_Off = product Serv_Type*Serv_Int_Id; color Offer_List = list Serv_Off color Imp_Request = product Serv_Type*Link_List; An import request Imp_Req is a product of a Service_Type and a Link_List. This allows a request to maintain information regarding Links which the offer has traversed. This has not been included in the standard, but allows Traders to interwork without entering infinite loops. The shared place Comms_Medium is of colour Message which indicates that only message tokens may exist in the place. Each of the substitution transitions has an associated sub net whose input/output port is connected to a transition with a guard. This guard checks the receiver field of the message and evaluates to true only if the message was addressed to that object. Only transitions with a guard which evaluates to true will be enabled, thus accepting the message when fired. In order to access information which is hidden inside tokens, some Projection Functions have been written. They allow the model to move data around as high order colours, whilst still allowing access to data within the token. Four basic functions (S(mess), R(mess), Op(mess), Op_D(mess)) are defined to access the most commonly used data in a Message token, all of which follow a basic pattern. The input parameter to the functions is a message. For function call S(mess), the variable s is returned as the Id of the sender of the parameter message. fun S(((s,r),dat:Data):Message):Id = s; fun R(((s,r),dat:Data):Message):Id = r; fun Op((addr:Addresses,(opn,op_d)):Message):Operation=opn; fun Op_D((addr:Addresses,(opn,op_d)):Message):Op_Data=op_d; Since there may be multiple instances of Objects, a place is required to hold a unique object identifier. These places are used to identify messages addressed to specific instances of Objects. Design/CPN allows multiple instances of a page and thus, for each instance, the initial marking must be altered to contain a unique identifier. C. Trading Interfaces The Trader uses a number of interfaces in order to communicate with other Objects in the system. These interfaces accept messages from the Comms_Medium place and forward them to the Trader. The standard does not prescribe the use of interfaces, but the RM ODP object model includes interfaces as part of its definition of Objects. As a demonstration of the Trader s application to the provision of advanced information services in an electronic commerce environment, the colour definitions of the Services focus on some typical services which a net hacker might require. (** Service Interface Types **) color Int_Type = pizza software used_car; (** Service Properties **) color Properties = the_lot vegetarian simcity spreadsheet six_cylinder sports; color Serv_Prop = list Properties; (** Service Providers **) color Serv_Int_Id = with pizza_haven pedros_pizza software_supermarket virgin bob_moran champion; A service importer could submit an Imp_Req token to tsi_1: an import request for a used 6 cylinder sports car; t_id=5: 1 ((importer,tsi_1),(import,((imp)((used_car,[six_cylinder,s ports]),[]),5))) Figure 4. The Trading Interfaces (Trad_Int#13). Having multiple interfaces provides the Trader with multiple channels of communication with external Objects, thereby reducing messaging congestion. In RM ODP terms, there is a binding between external objects and the interface which is implicit. The interfaces are shown in Figure 4, where they are positioned between the Comms_Medium and the Trading Object itself which communicates through two shared places.

5 7. ANALYSIS OF THE MODEL There are two methods of analysis which have been applied to the model Simulation, and Occurrence Graph Analysis. 7.1 Simulation Simulation is effective in debugging a model as the modeller has direct graphical feedback from the simulator and can monitor the passage of tokens as they flow throughout the model. It is limited, however, in that it is slow and requires direct human supervision to obtain results. Automatic Simulation Mode disables graphical feedback and terminates the simulation run after a user defined number of steps have occurred. Prior to simulation, Design/CPN performs a syntax check which ensures that arc and transition inscriptions are valid, and that places have an associated colour set. 7.2 Occurrence Graph Analysis Occurrence Graph Analysis can be used to detect deadlocks, livelocks or forbidden states in the model. Its drawback is that it may require large amounts of computational resources for complex systems, and only gives results for a particular initial marking. OGA analysis allows us to place the Trader in a scenario (using an initial marking) and exhaustively determine all paths to a (hopefully) single dead marking corresponding to the final result of the operation being verified. 7.3 Current Status At this point, extensive debugging of the design has been performed through the use of the Design/CPN Simulator. If necessary, the model will be modified to improve OGA performance by removing intermediate places, and reducing of the number of elements in some colour sets (sample data). In general, this results in reduced readability which is the trade off. The Trader has been analysed with the OGA in a scenario in which there are two Traders which are Linked to each other. A single request is submitted to a Trader which services the request and returns a result. This was found to contain 1173 states when there was a single Trans_Id available for the request. This reduced the state space significantly, but does not verify correct operation when servicing multiple concurrent requests. This is part of ongoing analysis work. 8.1 Benefits 8. COMMENTS ON THE MODEL The model allows for true concurrency of operation. This is evident in the structure of the CPN model, where Objects operate autonomously and in parallel. When an Import Request is processed, the local and link searches operate concurrently; that is, two messages are sent to different Objects which process them concurrently. This is particularly attractive as it models the distributed nature of linked traders. The CPN method allows an integration of data and control flow in one model. This is advantageous as it provides a more complete picture of the system being modelled. In addition, the model is executable which provides increased confidence in the model, through simulation runs. Although these runs provide only a limited traversal of the model s state space, use of the OGA tool in Design/CPN allows exhaustive state space verification methods to be applied. The model is both graphical and textual, allowing formalisation of data definitions in addition to a graphical description of the system relationships. The combination of these features improves comprehension of the model which is important when the model is used as a design/implementation tool. 8.2 Limitations The RM ODP object model is not object oriented and has no concept of inheritance. Systems simply consist of Objects which cooperate to perform a given task. In modelling the Trader, there was no need to use inheritance, but it may improve the model by allowing for more re use of components. Design/CPN allows easy use of modularity since it provides for hierarchies of pages. This was used extensively throughout the model and it is through this mechanism that instances were modelled. An important limitation of the tool is that it does not provide an inst() function. This would allow the modeller to identify an instance of a page through the use of a function call. In this model, a hack was used where a token identifies each Object. Using the Petri Nets in Objects methodology [8] with Design/CPN does not allow for dynamic instantiation of objects. In order to verify the Trader s operation in different scenarios, it is necessary to modify the top level CPN to reflect the different Object topology. 9. DESIGNING OBJECT BASED SYSTEMS Object based Systems are becoming increasingly evident in Telecommunications and Open Distributed Systems [10], where resource trading is an essential infrastructure service provided by the Distributed Processing Environment (DPE). There is a need for tools to aid in the design and verification of such complex distributed systems. We believe that Open Object based Systems may be designed and verified using the Design/CPN tool. We have shown how a system may be decomposed into Objects which interact to accomplish a specific service. These Objects may be instantiated multiple times through a combination of hierarchical decomposition and unique Object identifiers. Arbitrarily complex data structures may be created and manipulated using a combination of the CPN structure and Standard ML functions used on arc inscriptions. Having created a model of the Objects and data in a system, the model may be initialised with test data and simulation

6 experiments used to debug the model. This is a very intuitive method which utilises the modeller s understanding of the system in order to detect errors in operation. When the model is considered to be bug free, it is then tested using OGA analysis in an effort to detect errors which remain hidden, even after thorough testing with the simulator. In our model of the Trader, if the Occurrence Graph fails to converge to a single dead node, then there is an error in the model. This is because there is only one correct final result for the scenarios under test. If there are multiple dead nodes, we select a dead node and calculate its predecessors. The marking of the node indicates the state of the system and may be used to detect when a transition fires and takes the Trader to an erroneous state. It is possible to transfer a marking from the Occurrence Graph to the simulator, thereby placing the model into a state which is prior to the error occurring. This is particularly helpful because it indicates which transition is causing the error, and shows the marking which caused the transition to become enabled. Using these two methods, the model may be formally verified and become a basis for implementation. 10. CURRENT WORK The model is being placed in scenarios and analysed using state space analysis with the OGA features of Design/CPN. In particular, the Interworking of Traders is being investigated, where multiple requests requiring Interworking are serviced concurrently by multiple Traders. Using the formally verified model as a basis, a prototype of the Trader is being developed in the Java [9] programming language. Java is object oriented, multi threaded, platform independent and provides convenient networking constructs which make it an ideal language to use for creating a prototype Trader. 11. CONCLUSIONS The ODP Trader has been modelled using the Coloured Petri Net formalism and the Design/CPN tool because CPNs have a graphical representation, are excellent for modelling concurrency, and have a formal semantics which allows us to prove properties of the model. The model includes a number of improvements to RM ODP standard including the ability to service multiple requests concurrently and the ability to interwork with other Traders using a technique which prevents infinite requests being generated. With further analysis of Trading scenarios, the model will be formally proven to function in a manner conforming to the Trading standard, and will act as a design basis for the prototype Java implementation. In this paper, we have described how Design/CPN may be used to model and analyse an Object based system. This is of significant interest since it aids in the design of reliable Open Distributed Systems which are the future of computing. REFERENCES [1] ITU/ISO ODP (1994) Reference Model of Open Distributed Processing Part 1: Overview and Guide to Use, Draft International Standard , Draft ITU T Recommendation X.901, [2] ITU/ISO Trading (1995) Reference Model of Open Distributed Processing Trading Function, ISO/IEC DIS Draft Recommendation. X.950, June Also available at: tandards.html [3] Jensen, K. (1992) Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical Use. Volume 1 : Basic Concepts, EATCS Monographs on Theoretical Computer Science, Springer Verlag. [4] ITU/ISO Trading Tutorial (1995) Reference Model of Open Distributed Processing Trading Function Annex A: Tutorial of the Trading Function. Available at: r_tutorial.html [5] Vogel, A., Bearman, M. and Beitz, A. (1995) Enabling Interworking of Traders. Open Distributed Processing: Experiences with distributed environments, K. Raymond, L. Armstrong (Eds), Chapman and Hall, Also available at: vogel/papers/ icodp95.ps [6] Tokmakoff, A. and Billington, J. (1996) CPN Modelling of An Object Based System: The ODP Trader, 1st International Workshop on Formal Methods for Open Object based Distributed Systems, Paris, France, May [7] CPN Group, University of Aarhus (1996), Online Design/CPN User s Manual. Available at: [8] Bastide, R. (1995) Approaches in unifying Petri nets and the Object oriented Approach, Available at: ract/bastide.html [9] Sun Microsystems, The Java Language: A White Paper, Available from: [10] Tokmakoff, A. and Billington, J. (1996) Service Brokering in Object Based Systems: Advanced Information Services, 3rd IEEE Workshop on Community Networking, Antwerp, Belgium, May 1996.