CPNaaS – Colored Petri Nets as a Service

I’ve a ton of great ideas for things to do with Petri nets.  Colored nets in particular.  CPN Tools ships with a great simulator, which is both fast and versatile.  Unfortunately, it is extremely cumbersome to use.  Therefore, I am working on a great project I like to cal CPNaaS – Colored Petri Nets as a Service.  It is a RESTful API which is simple to use yet provides much of the same functionality as the regular CPN simulator.

The architecture is as follows (click for larger):

cpnaas

At the left, we have the yellow client, which wishes to do CPNs but easily.  On the right, we have the red simulator which is really good at this.  In the middle, we introduce a stack facilitating simple communication from the client using a intuitive RESTful web-service interface, abstracting away the cumbersome binary BIS/DMO protocol that is the native language of the simulator.

At the heart is the CPNaaS service, which takes care of translating the traffic.  It is more than just a dumb ESB, though.  It also takes care of persistence.  Any net element sent to the API is automatically persisted in a database.  This means that clients do not have to worry about saving models – as soon as it is sent to the API, it is always retrievable until it is deleted.  Persistence is handled using Spring Data and is using its auditing functionality, making it possible to track all changes.

The CPNaaS also changes the paradigm of the CPN Simulator form on-the-fly syntax check to just-in-time syntax check.  This means that clients do not have to bother with triggering syntax checks.  The API can syntax check models in the background or when information is requested that requires a model to be syntax-checked.  The API is even free to completely remove a model from memory if it has not been used for a while, and syntax check it once it is again needed.

The API is specified using WADL and takes a true RESTful hierarchical approach.  Here is an extract of a very early version of the API:

[xml] <resources base=”https://api.brinformatics.eu/api/cpn”>
<param name=”api_key” type=”xsd:string” style=”header” />

<resource path=”/nets”>
<method name=”POST”></method>
<method name=”GET”></method>

<resource path=”/{netId}”>
<param name=”netId” style=”template” />

<method name=”PUT”></method>
<method name=”GET”></method>
<method name=”DELETE”></method>

<resource path=”/errors”>
<method name=”GET”></method>
</resource>

<resource path=”/pages”>
<method name=”POST”></method>
<method name=”GET”></method>

<resource path=”/{pageId}”>
<param name=”pageId” style=”template” />

<method name=”PUT”></method>
<method name=”GET”></method>
<method name=”DELETE”></method>

<resource path=”/errors”>
<method name=”GET”></method>
</resource>

<resource path=”/places”>
<method name=”POST”></method>
<method name=”GET”></method>

<resource path=”/{placeId}”>
<param name=”placeId” style=”template” />

<method name=”PUT”></method>
<method name=”GET”></method>
<method name=”DELETE”></method>

<resource path=”/errors”>
<method name=”GET”></method>
</resource>

<resource path=”/arcs”>
<method name=”POST”></method>
<method name=”GET”></method>

<resource path=”/{arcId}”>
<param name=”arcId” style=”template” />

<method name=”PUT”></method>
<method name=”GET”></method>
<method name=”DELETE”></method>

<resource path=”/errors”>
<method name=”GET”></method>
</resource>
</resource>
</resource>
</resource>
</resource>
</resource>
</resource>
</resource>
</resource>
</resources>
[/xml]

While this looks a mouthful, it is really quote simple. We can even put it into a standard tool like Apache CXF to generate a client for us automatically (which is incidentally also how the server is created). Here’s a couple simplified requests with description to give a feel for the style of the API. Calls include auxiliary optional/required information (like names and inscriptions).

Request Explanation
POST /nets Create a new net
GET /nets/1 Get information about net with id 1
POST /nets/1/pages Create a new page in net 1
GET /nets/1/pages Get all pages of net 1
GET /nets/1/pages/2 Get information about page with id 2 in net 1
POST /nets/1/pages/2/places Create new place on page 2 of net 1
GET /nets/1/pages/3/places/3 Information about place with id 3 on page 2 of net 1
GET /nets/1/pages/3/places/3 Change information about place with id 3 on page 2 of net 1 (e.g., name or initial marking)
GET /nets/1/pages/3/places/3/errors Get errors of place 3 of page 2 of net 1
DELETE /nets/1/pages/3/places/3 Information about place with id 3 on page 2 of net 1
GET /nets/1/errors Get errors of net 1

The API also has entry points for declarations, simulation and getting and setting marking and enabling information. It does not have hooks for syntax check.

Step 1 involves setting up the API for creating and syntax checking nets (the pink bits).  Already this is extremely powerful and will allow third-party user interfaces.

Step 2 is implementing advanced simulation statistics.  Currently, CPN Tools does all statistics itself logging everything to files.  Instead, the CPNaaS ecosystem will come with logging to a time-series database.  Currently, the plan is to use InfluxDB.  Using InfluxDB it is very easy to compute statistics similar to what CPN Tools does already, but the real beauty is that it is possible to make very advanced queries on the obtained data, and to search it, aggregate it, and cross-reference it.  This is all possible because the data is structured and persisted.  As an example, it is possible to use the powerful and beautiful Grafana tool for plotting and analyzing data.  This is done by the Analytics service.  The API manager front-end makes it transparent to users which concrete API they are using, so it is possible to make this a completely separate service.

Step 3 is implementing analysis on top of the existing APIs.  The details are not worked out yet, but it is very likely that this will build on the ASCoVeCo ASAP platform which already lies dormant inside the simulator.  The precise operation is transparent to users.  This is the green box.

Concurrently to steps 2 and 3, it is possible to implement augmentation services.  Thanks to the API manager mediating all access, we can mix the simulation analytics and state space analysis into a single API.  It is also possible to build enhancing APIs on top of the existing CPNaaS.  These enhancers can live inside the API ecosystem or outside it.  Such services could add entirely new constructs (e.g., bounded places or page templates with type parameters) by simply translating the constructs to regular CPN constructs.  This can be done entirely transparent to API users; for example, an extension could add a /channels sub-tree under /nets/pages/transitions (not shown above), or they could add a new nets/templates subtree.  As every node already has a URL (e.g., a place at /nets/1/pages/2/places/3 or a transition at /nets/4/pages/5/transitions/6) with operations, they are themselves web-services which can be invoked, either setting or getting a marking, or invoking a transition.  An extension could build on this to expose a higher-level web-service inputting data, doing execution, and returning values.  By extending the simulator to be able to invoke remote web-services from code segments, we can use real-time data from Yahoo Finance in our models, or have multiple models communicate.

As I am no longer in academia, this will not be developed in the typical academic way (me holding my cards close until I can publish it in one go).  Instead, I am keeping the entire process open.  I really want to hear what your thoughts of the API is and especially your use cases.  The API is not final yet.  I have given it some thought and have some things I want in it, but I am very open to supporting cases I have not thought of.  I am also very interested in thoughts about the entire idea, style of API and so on.  Let me know any thoughts you have in the comments!

5 thoughts on “CPNaaS – Colored Petri Nets as a Service

  1. Dear Michael,

    This idea is incredible. Through the API as an intermediate between a client and the CPN Tools simulator it could be possible to communicate different Internet applications that provide different services to the people.

    Now that I have been involved in this world of CPNs (as I am making a CPN Tools extension in order to reduce a SS into a minimized FSM for protocol verification), I will keep following the evolution of this API.

    Greetings,
    Julio

    1. Dear Julio,

      I’m happy you like it! Your case is actually an interesting one – I’m not sure how well it would fit with the currently planned analysis API. It might not have to fit with the basic API, but it should definitely be possible to make an extension API for something like that.

      I’m planning to base the analysis API heavily around some of the ideas developed around ASAP rather than the old state-space tool. Mostly, my idea was to use the notion of a “verification project,” tying together models, properties and methods, except I’d simplify it to what I call test-suites, which is a collection of properties tied to a single model, abstracting away the method.

      Another point of ASAP was programming everything to interfaces and making it extensible. That aspect hasn’t been thought into the API yet (though extensions are a central part of the simulation API). Maybe some sort of folding-based approach? (Basically, Google’s MapReduce paradigm is a simplified folding operator, so maybe a similar API would work for state-spaces?)

      I would be very interested in some feedback once I’ve gotten around to specifying the first version of the analysis API (hopefully this weekend…)

  2. Dear Michael,

    This is a great idea and enormous contribution to CPN Tools users. It creates countless opportunities to use the simulator. I thought using it as realtime simulator. I use CPN Tools to simulate a power system restoration scheme. Using this tool the simulations can run in realtime considering after a few updates related to data integration.

    Congratulations

    1. Dear Roberto,

      Thanks for your encouraging comment. It’s exactly things like that I was thinking of when designing the API: integrating with – perhaps even providing input for – real systems using web services.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.