�ݺ�ߣ

Java Petri Net DEvelopment
Framework (JPNDE) @ JADE
Antonio Furone

Obiettivi
Sviluppare un framework che consenta la simulazione (e/o
l’esecuzione) e lo sviluppo di applicazioni distribuite
modellate attraverso Reti di Petri (PN).
Sviluppare un framework che consenta la simulazione (e/o
l’esecuzione) e lo sviluppo di applicazioni distribuite
modellate attraverso Reti di Petri (PN).
In particolare, tale framework deve:
• mettere a disposizione un ambiente di runtime per l’esecuzione di un
modello definito attraverso PN e un insieme API per l’estensione del
modello stesso attraverso un linguaggio di programmazione di alto livello;
• consentire la distribuzione “trasparente” (per lo sviluppatore) delle attività
computazionali di un PN sui nodi di rete che compongono l’architettura
esecutiva dell’applicazione;
• permettere l’interazione tra differenti PN (o tra attività computazionali di
una stessa PN) attraverso lo scambio di token contenenti tipi di dati
complessi.

Premesse [1/2]
Tipologie di PN:
• Reti Posti/Transizioni (P/T) standard a token interi ed archi pesati: l’attivazione
di un transizione provoca la rimozione da ogni posto a monte (preset) e l’aggiunta
ad ogni posto a valle (postset) di un numero di token pari al peso degli archi che la
collegano a tali posti;
• Reti di Petri Colorate (CPN) : estendono quelle standard (P/T) introducendo
alcune primitive di programmazione per la definizione di tipi di dati complessi
trasportati dai token e la manipolazione dei valori in essi contenuti.
JPNDE supporta entrambe le tipologie di reti. Le primitive di
programmazione introdotte all’interno delle CPN si basano su
scriptlets JAVA.
JPNDE supporta entrambe le tipologie di reti. Le primitive di
programmazione introdotte all’interno delle CPN si basano su
scriptlets JAVA.

Premesse [2/2]
Paradigma di sviluppo:
• JPNDE è stato sviluppato attraverso il paradigma dell’ Agent-Oriented
ed è basato su JADE (Java Agent DEvelopment Framework );
• La maggior parte dei componenti dell’architettura di JPNDE sono degli
Agenti in JADE;
• Il concetto di piattaforma di runtime di JPNDE è equivalente al
concetto di platform in JADE.

Definizione del modello: PNML [1/6]
Le PN sono fornite al framework attraverso documenti XML basati su
PNML (Petri Net Markup Language).
•E’ un formato la cui
grammatica è definita
mediante lo schema
language RELAX NG;
•Consente l’interscambio di
modelli tra tool che
supportano tale standard;
•Non esiste al momento una
estensione del PNML per il
supporto delle CPN;
•Le estensioni previste nei
modelli JPNDE (scriptlets
Java, distribuzione nella rete
di task computazionali,
interazione tra modelli, ecc.)
sono state introdotte
attraverso tag specifici
all’interno del tag ToolInfo.

Definizione del modello: PNML [2/6]
<pnml xmlns="http://www.pnml.org/version-2009/grammar/pnml">
<pnml xmlns="http://www.pnml.org/version-2009/grammar/pnml">
<net id="macchina" type="http://www.pnml.org/version-2009/grammar/ptnet">
<name>
<text>macchina - jpn example</text>
</name>
<place id="p1">
<name>
<text>p1</text>
</name>
<toolspecific tool="JPNDE" version="1.0">
<jpnEventIn delay='5000' auto='Y'/>
</toolspecific>
</place>
…
<transition id="t1">
<name>
<text>t1</text>
</name>
<jpnContainer/>
<jpnImplClass/>
</toolspecific>
</transition>
….
<arc id="p1t1" source="p1" target="t1">
<inscription>
<text>1</text>
</inscription>
</arc>
…
</net>
</pnml>
<name>
<text>macchina - jpn example</text>
</name>
<place id="p1">
<name>
<text>p1</text>
</name>
</toolspecific>
</place>
…
<name>
<text>t1</text>
</name>
<jpnContainer/>
<jpnImplClass/>
</toolspecific>
</transition>
….
<arc id="p1t1" source="p1" target="t1">
<inscription>
<text>1</text>
</inscription>
</arc>
…
</net>
</pnml>

Definizione del modello: Estensioni [3/6]
 Condizioni sugli archi del preset per l’abilitazione di una transizione
<arc id="arc_SendPacket_i_1" source="Send" target="SendPacket">
<inscription>
<text>1</text>
</inscription>
<jpncondition priority="0">
<arc id="arc_SendPacket_i_1" source="Send" target="SendPacket">
<inscription>
<text>1</text>
</inscription>
<<jpncondition jpnexpression priority="numToken="0">
<jpnexpression numToken="0">
0">
<body>
token.get("numPack").equals(NextSend_token.get("count"))
<body>
</body>
</jpnexpression>
</jpncondition>
</toolspecific>
</arc>
token.get("numPack").equals(NextSend_token.get("count"))
</body>
</jpnexpression>
</jpncondition>
</toolspecific>
</arc>
•La condizione può essere
composta da n espressioni;
•L’ordine con cui la
condizione è verificata,
rispetto a quelle degli altri
archi del preset di una
transizione, può essere
definita attraverso la
property ‘priority’ (=0;
verificata per ultima);
•L’espressione può riferirsi
ad uno specifico token
(property numToken).
Send NextSend
SendPacket
arc_SendPacket_i_1
L’espressione è verificata se esiste un token nel posto ‘Send’, la cui property ‘numPak’ è
uguale al valore della property ‘count’ del token selezionato dal posto ‘NextSend”.

 Inizializzazione dei Token
<place id="Send">
<initialMarking>
<place id="Send">
<initialMarking>
<text>7</text>
</initialMarking>
<jpnscript>
<jpnfunction onEvent="initialMarking">
<body>
tokens[0].put("numPack",1);
tokens[0].put("contPack","Modellin");
….
tokens[6].put("contPack","i Nets##");
</body>
</jpnfunction>
</jpnscript>
</toolspecific>
</place>
<text>7</text>
</initialMarking>
<jpnscript>
<jpnfunction onEvent="initialMarking">
<body>
tokens[0].put("contPack","Modellin");
….
tokens[6].put("contPack","i Nets##");
</body>
</jpnfunction>
</jpnscript>
</toolspecific>
</place>
In corrispondenza del
marking iniziale di un
posto, è possibile
definire una funzione
che viene eseguita
prima dello start-up del
modello
(onEvent=“Initial
Marking”) e nella quale
è possibile inizializzare i
token.
 Modifica dei token prima dell’inserimento in un posto
<place id="b">
<jpnscript>
<place id="b">
<jpnscript>
<jpnfunction onEvent="add">
<body>
<jpnfunction onEvent="add">
<body>
if (!token.get("ok")){
token.put("contPack","");
token.put("numPack",-1);
}
</body>
</jpnfunction>
</jpnscript>
</toolspecific>
</place>
if (!token.get("ok")){
token.put("contPack","");
token.put("numPack",-1);
}
</body>
</jpnfunction>
</jpnscript>
</toolspecific>
</place>
E’ possibile definire una
funzione che viene eseguita
prima dell’inserimento di un
token in un posto
(onEvent=“add”) e nella
quale è possibile modificare
i dati trasportati dal token.
Tali funzioni possono
essere associate sia ad un
Posto che ad arco che
termina in un Posto.

 Esecuzione task in corrispondenza dell’attivazione di un transizione
Esistono due modi per implementare un task:
• script all’interno del file PNML
<transition id="TrasmitPacket">
<jpnscript>
<transition id="TrasmitPacket">
<jpnscript>
<jpnimport package="java.util.Random"/>
<jpnfunction onevent="activation">
<body>
tokenOut=((Token)context.getTokensByPlace("a")[0]).clone();
if ((new Random()).nextInt(9)>5)
<jpnimport package="java.util.Random"/>
<jpnfunction onevent="activation">
<body>
tokenOut.put("ok",false);
else
tokenOut.put("ok",true);
</body>
</jpnfunction>
</jpnscript>
</toolspecific>
</transition>
else
</body>
</jpnfunction>
</jpnscript>
</toolspecific>
</transition>
•L’oggetto tokenOut rappresenta il
Token
(it.uniba.di.mas.jpnde.core.Token) che
sarà aggiunto nei posti target degli archi
del postset della transizione;
•I token di input possono essere
prelevati dall’oggetto context
(it.uniba.di.mas.jpnde.core.PNContext).
• classe Java referenziata attraverso il tag <implClass/>
<jpnImplClass name="myappl.transition.T1"/>
</toolspecific>
</transition>
<jpnImplClass name="myappl.transition.T1"/>
</toolspecific>
</transition>
La classe referenziata dovrà implementare un
interfaccia di tipo
it.uniba.di.mas.jpnde.core.ITransitionTask o
estendere una classe di tipo
it.uniba.di.mas.jpnde.impl.
AbstractTransitionTask.
public class T1 extends AbstractTransitionTask{
@Override
public Token exec(PNContext ctx) throws Throwable {
…..
return new Token(transition.getId());
}
Entrambe le modalità consentono lo sviluppo di task di un certa compessità (accesso a DB, richiamo di web services,
ecc.).

 Eventi per prelevare e aggiungere token da/a posti di una rete
<place id="p1">
<place id="p1">
</toolspecific>
</place>
</toolspecific>
</place>
EventIn: consente di aggiungere token in un posto della rete.
Le properties ‘delay’ e ‘auto’, se specificate, consentono
rispettivamente di definire un intervallo di tempo minimo che
deve passare tra la generazione di un token e l’altro e di
indicare se la creazione del token deve essere effettuata
dall’evento stesso (non inoltrato da un EventOut).
<place id="p4">
<place id="p4">
<jpnEventOut route="p1.macchina1@devplat"/>
</toolspecific>
</place>
</toolspecific>
</place>
EventOut: consente di prelevare token da un posto della rete
ed eventualmente (property ‘route’) di inoltrarli ad un EventIn
della medesima rete o di un’ altra rete in esecuzione sulla
stessa piattaforma.
 Termine dell’esecuzione
<place id="p4">
<jpnEndPlace threshold="10"/>
</toolspecific>
</place>
<place id="p4">
</toolspecific>
</place>
E’ possibile definire un posto tale per cui la
presenza di un certo numero di token in tale posto
(property threshold) determina la fine
dell’esecuzione della rete.
 Distribuzione in rete del modello
E’ possibile definire i nodi dell’architettura
esecutiva (containers Jade) nei quali
verrà eseguito l’intero modello o i singoli
task attivati con l’abilitazione di una
transizione.
<jpnContainer id=“Container-1”/>
</toolspecific>
…..
…..
</toolspecific>
</transition>
</toolspecific>
…..
…..
</toolspecific>
</transition>

Architettura
Back-end
Console
Back-end
Console
UUI IC Coonnssoolele
Modelli
(PNML files)
PPNN M Maannaaggeerr
PPNN T Trarannssitiitoionn 1 1
…………...
PPNN T Trarannssitiitoionn n n
Impl Class 1
…………...
Impl Class m
Place
Events
Place
Events
Script Engine (Bean Shell)
PN 1..N
Tasks
Platform

Descrizione dei Componenti [1/4]
UI Console:
E’ il componente di interfaccia
tra l’ambiente di runtime del
framework e l’utente. Viene
attivata dall’ agente “Back-end
Console” e consente di gestire
le PN all’interno della
piattaforma (Load, Start, Stop).

Back-end Console:
Implementa i servizi richiesti dall’utente attraverso la UI Console ed effettua il
monitoring delle reti eventualmente in esecuzione. In particolare:
• Load: parsing dei files PNML e rappresentazione dei modelli attraverso un una
gerarchia di classi: PN, Transition, Place, Arc,etc.;
• Start: creazione dell’agente di coordinamento per l’esecuzione della rete (PN
Manager) e invio a tale agente della gerarchia di oggetti che rappresentano il
modello da eseguire. Il PN Manager è creato nel container JADE eventualmente
specificato nel file PNML o, di default, in è quello dove è in esecuzione l’agente
“Back-end Console”;
• Stop: invio richiesta di stop dell’esecuzione della rete al PN Manager.

PN Manager:
Gestisce la rete attivando gli agenti necessari per la sua esecuzione e
coordinando l’attivazione delle transizioni e degli eventi secondo le regole
definite nel modello.
Gli agenti per la gestione delle transizioni (PN Transition) sono distribuiti nei container eventualmente
specificati nel file PNML o, di default, nel container del PN Manager. Gli agenti per la gestione degli
eventi (in/out) definiti sui posti della rete sono creati nello stesso container del PN Manager.
Una volta creati gli agenti necessari per l’esecuzione della rete, il PN Manager invia agli stessi la
configurazione delle entità (transizioni e eventi) che dovranno gestire. Durante l’esecuzione della rete, gli
agenti comunicano attraverso messaggi asincroni. In particolare, il PN manager:
• invia messaggi per attivare transizioni e per inviare token (eventi di prelievo dei token dai posti della
rete);
• riceve messaggi per notifiche di fine esecuzione transizioni e per ricevere token (eventi di inserimento
dei token nei posti della rete).
Tale agente si occupa anche dell’esecuzione degli script associati ai posti (eventi "initialMarking“ e “add”)
e della valutazione delle condizioni definite sugli archi per l’estrazione dei token dai posti della rete. Gli
script e le espressioni associate alle condizioni sono eseguiti/valutate attraverso uno script engine basato
sul prodotto open source BeanShell (http://www.beanshell.org/ ).

PN Transition:
Si occupa di eseguire l’attività computazionale associata all’attivazione della
transizione che gestisce. A seconda della modalità utilizzata per implementare il
task, viene eseguito uno script o attivata una classe Java. Al termine
dell’esecuzione, il token restituito dal task viene inviato al PM Manager che
provvederà a distribuirlo sui posti della rete che sono target di archi del postset
della transizione.
PN Event:
Gestisce gli eventi di prelievo/inserimento dei token dai/nei posti della rete. A
seconda della tipologia di evento, comunica con il PN Manager e/o altri agenti
dello stesso tipo, inviando e ricevendo messaggi contenenti token.

PNs vs Container JADE
UUI IC Coonnssoollelle
Container 1 Main Container Container 2
Back-end
Consolle
PN
Manager
# 1
PN
Transition
# 1.1
PN
Transition
# 1.2
PN
Manager
# 2
PN
Transition
# 2.1
PN
Transition
# 2.2
PN
Transition
# 2.3
EventOut EventIn

Esempio #1: Rete P/T con eventi [1/2]
<jpnEventIn
delay='5000' auto='Y'/> p1 p2
p3
p4
t1
t2
machine <jpnEventOut/>

Esempio #1: Esecuzione [2/2]
Ciclo di
esecuzione
Messaggi scambiati dagli agenti durante l’evoluzione della rete

Esempio #2: Reti P/T che si scambiano token [1/2]
<jpnEventIn delay='3000' />
p1 p2
p3
p4
t1
t2
<jpnEventIn/>
p1 p2
p3
p4
t1
[Main-Container]
t2
macchina1 macchina2 [Container-1]

Esempio #2 : Esecuzione [2/2]
Ciclo di
esecuzione
Messaggi scambiati dagli agenti durante l’evoluzione della rete

Esempio #3: CPN [1/2] Protocollo di comunicazione “pessimistico” - da
onEvent=“initialMarking”
tokens[0].put("numPack",1);tokens[0].put("contPack","Modellin");
tokens[1].put("numPack",2);tokens[1].put("contPack","g and An");
tokens[2].put("numPack",3);tokens[2].put("contPack","alysis b");
tokens[3].put("numPack",4);tokens[3].put("contPack","y Means ");
tokens[4].put("numPack",5);tokens[4].put("contPack","of Colou");
tokens[5].put("numPack",6);tokens[5].put("contPack","red Petr");
tokens[6].put("numPack",7);tokens[6].put("contPack","i Nets##");
Send
token.get("numPack").equals(
NextSend_token.get("count"))
NextSend
SendPacket
else
a
tokenOut=(context.getTokens
ByPlace("Send")[0]).clone();
Simulo una
transizione non
deterministica
onEvent=“add”
if (!token.get("ok")){ token.put("contPack","");
token.put("numPack",-1); } Received
b
TrasmitPacket
tokens[0].put("message","");
tokens[0].put("count",1);
c
tokenOut.put("count",context.g
etTokensByPlace("d")
[0].get("count"));
d
onEvent=“add”
if (!token.get("ok")){token.put("count",-1);}
NextRec
tokens[0].put("count",1);
ReceivePacket
tokenOut=((Token)context.getTokensByPlace("Received")[0]).clone();
Token next=(Token)context.getTokensByPlace("NextRec")[0];
Token pack=(Token)context.getTokensByPlace("b")[0];
if (pack.get("ok")){
if (pack.get("numPack").equals(next.get("count")))
tokenOut.put("message",tokenOut.get("message")+
pack.get("contPack"));}
tokenOut.put("count",
(pack.get("numPack").equals(next.get("count"))?next.get("count")+1:
next.get("count")));
TrasmitAck
tokenOut.put("count",context.getTokensByPlace("c")[0].get("count"));
if ((new Random()).nextInt(99)>97){
tokenOut.put("count",-1);
System.out.println(">>> TrasmitAck failed !");}
else
ReceiveAck
“A Brief Introduction to CPNs” – K.Jensen

Esempio #3: Esecuzione [2/2]
In caso di fallimento
il Packet perso
viene re-inviato

Caso di Studio [1/5]
• Tipico processo aziendale nel quale è necessario coordinare le attività di più
sistemi: processo di generazione dei dati consuntivazione di una primaria azienda
telefonica che opera in un contesto internazione, fornendo il servizio di
International Wholesale per il traffico voce;
• Sistema di Rating: produce le viste dati di traffico valorizzato (detto anche
‘SITAX’) per le componenti economiche di credito e debito, applicando gli accordi
commerciali stipulati con le carrier clienti / fornitori. Tale modulo, ha come output
anche la componente di traffico scartato (‘NOTAX’), per il quale non è stato
trovato in anagrafica un accordo valido;
• Sistema Gestionale: utilizzando l’output del sistema di Rating (‘SITAX’ e
‘NOTAX’), produce le viste dati per la verifica dell’effettivo andamento del
business attraverso l’applicazione di regole ed algoritmi di valorizzazione
gestionale: applicazione ipotesi di sconto, recupero NOTAX, previsione
andamento SCONTI. Inoltre, mette a disposizione una serie di utilities per l’analisi
delle marginalità sui dati prodotti, un ampia reportistica per la business
intelligence e alcune funzionalità per la certificazione delle regole di valorizzazione
applicate.

 Rating
Macro-step Descrizione Pre-requisiti
GeneraDB Viene creato uno snapshot del DB degli accordi (aggiornato tramite interfaccia WEB e/o da altri
processi esterni al Rating) che sarà utilizzato dai successivi step di classificazione e
valorizzazione
Classificazione Ad ogni CDR viene associato, attraverso un algoritmo di classificazione di tipo best-match,
l’accordo attraverso il quale sarà valorizzato. In questa fase, il traffico non classificato viene
scartato (NOTAX)
GeneraDB sull’istanza
(credito/debito) relativa
Valorizzazione Valorizzazione del traffico attraverso gli accordi associati nello step precedente. Oltre alla
valorizzazione per singolo CDR, viene prodotta anche una vista aggregata che rappresenterà
l’input (SITAX) per i processi del sistema Gestionale
Classificazione
dell’istanza relativa
 Gestionale
Macro-step Descrizione Pre-requisiti
Migrazione
Anagrafica
•Migrazione anagrafica accordi chiusi (periodo di validità) nei sei mesi precedenti e riaperti per
l’applicazione dell’algoritmo di recupero no-tax ALGO1;
•Migrazione anagrafica sconti
•Genera DB Gestionale
Algo1 Processi di Classificazione e Valorizzazione applicati sui NOTAX generati dal sistema di
Rating, utilizzando l’anagrafica degli accordi migrata nello step precedente
Migrazione anagrafica
sull’istanza relativa +
Classificazione
Consuntivazione Applicazione algoritmi di valorizzazione gestionale: ALGO2, Sconti, Ipotesi di Accordo,ecc. Algo1 relativa istanza +
Fine processo di Rating
(Valorizzazione
Credito/Debito)

Rating Gestionale
<jpnEventOut
route="Cre2.gestionale@devplat"/>
<jpnEventIn/>
Classificazione
Credito
<jpnEventIn/>
Classificazione
Debito
<jpnEventOut
route="Deb2.gestionale@devplat"/>
<jpnEventOut
route="RatingEnd.gestionale@devplat"/> <jpnEventIn/>
Fine Rating =
Valorizzazione
Credito e Debito

Start
Cre1
Deb1
onEvent=“add”
token.put("istanza","CRE");
Activation
onEvent=“add”
token.put("istanza",“DEB");
GenDBCRE
GenDBDEB
Cre2
<jpnImplClass
name="rating.process.Classificazione"/>
<jpnImplClass
name="rating.process.Classificazione"/>
Deb2
ClassifCRE
ClassifDEB
ClassCreEnd
Cre3
Deb3
ValorizCRE
ValorizDEB
ClassDebEnd
Join
<jpnEventOut
route="RatingEnd.consuntivazione@devplat"/>
Notify
End
<jpnEventOut
route="Cre2.consuntivazione@devplat"/>
<jpnEventOut
route="Deb2.consuntivazione@devplat"/>
<jpnImplClass
name="rating.process.GeneraDB"/>
<jpnImplClass
name="rating.process.GeneraDB"/>
<jpnImplClass
name="rating.process.Valorizzazione"/>
<jpnImplClass
name="rating.process.Valorizzazione"/>
Rating
2

Start
Cre1
Deb1
Activation
onEvent=“add”
token.put("istanza","CRE");
token.put("datacons","201008");
onEvent=“add”
token.put("istanza",“DEB");
token.put("datacons","201008");
MigrazioneCRE
2
<jpnImplClass
name="cons.process.Algo1"/>
MigrazioneDEB
Cre2
Deb2
Algo1CRE
Algo1DEB
Cre3
Deb3
ConsCRE
ConsDEB
<jpnImplClass
name="cons.process.Migrazione"/>
<jpnImplClass
name="cons.process.Algo1"/>
Gestionale
<jpnImplClass
name="cons.process.Consuntivazione"/>
<jpnImplClass
name="cons.process.Migrazione"/>
<jpnEventIn/>
<jpnEventIn/>
RatingEnd
<jpnImplClass
name="cons.process.Consuntivazione"/>
<jpnEventIn/>
End
RatingEnd2
2
2

�ݺ�ߣ

Jpnde

More Related Content

Jpnde