<b4p:humanInteractions>? ... </b4p:humanInteractions> ... <bpel:extensionActivity> <b4p:peopleActivity name="NCName" ...> ... </b4p:peopleActivity> </bpel:extensionActivity> ... </bpel:scope>
B.2 Concetti base del linguaggio
Molti concetti che stanno alla base del linguaggio BPEL4People sono ereditati dallo standard WS-HumanTask.
I ruoli umani generici e connessi al processo, definiscono cosa un individuo o un gruppo di persone a cui è stato assegnato un ruolo possono fare con un'istanza del processo stesso. Questi ruoli completano l'insime di generic human roles definiti dallo standard WS-HumanTask. Esistono tre differenti ruoli di questo tipo:
-Process Initiator: è la persona associata al triggering dell'istanza del processo nell'istante della sua
creazione. E' di solito definito automaticamente dall'infrastruttura del processo, ma questa scelta può essere sovrascritta attraverso un esplicita assegnazione. E' necessario garantire che runtime esista almeno una persona associata a questo ruolo.
-Process stakeholders: sono le persone che possono influenzare la progressione dell'istanza del
processo, per esempio aggiungendo nuove task al processo o semplicemente osservando il progresso dello stesso. Gli scopi di questo soggetto sono molto più ampi rispetto alle linee guida
proposte dallo standard BPEl4people. Il process stakeholder è associato ad un istanza del processo. Se non è definito, il process initiator diventa automaticamente il process stakeholder dell'istanza creata. Deve essere garantito nel runtime che almeno una persona sia associata a questo ruolo.
-Business administrators: sono le persone a cui è permesso amministrare azioni del processo,
come per esempio risolvere eventuali deadlines del processo stesso. A differenza di un process stakeholder il business administrator ha un interesse in tutte le istanze dello stesso processo. Se non è definito un business administrator il process stakeholder assume questo ruolo. Durante il runtime è necessario che almeno un soggetto sia associato a questo ruolo.
La sintassi per la definizione dei vari ruoli è presentata di seguito.
<b4p:peopleAssignments>
<htd:genericHumanRole>+
<htd:from>…</htd:from>
</htd:genericHumanRole>
<b4p:peopleAssignments>
L'elemento astratto genericHumanRole introdotto dallo standard WS-HumanTask è esteso con i seguenti ruoli connessi al processo:
<b4p:peopleAssignments> <b4p:processInitiator>? <htd:from ...>...</htd:from> </b4p:processInitiator> <b4p:processStakeholders>? <htd:from ...>...</htd:from> </b4p:processStakeholders> <b4p:businessAdministrators>? <htd:from ...>...</htd:from> </b4p:businessAdministrators> </b4p:peopleAssignments>
All'interno dell'elemento <b4p:peopleAssignments> possono essere utilizzati solo ruoli umani connessi al processo. L'associazione degli individui agli specifici ruoli avviene durante l'inizializzazione del processo. In quanto tale, dunque, l'assegnazione dei ruoli fa parte degli scopi
dell'inizializzazione del processo (che avviene in corrispondenza di un elemento <bpel:process> o <bpel:scope> ) ed influisce sulla riuscita dell'inizializzazione. Di conseguenza se fallisce l'assegnazione fallisce l'intera istanza del processo.
Il responsabile di una task, di una notifica o di un processo è necessario che una persona venga assegnata allo specifico ruolo. Questa assegnazione può avvenire in tre diversi modi:
-attraverso gruppi logici di persone: I gruppi logici di persone definiscono che persone o insiemi
di persone possono interagire con una task umana o una notifica. I dettagli di come vengono utilizzati questi gruppi sono definiti nello standard WS-HumanTask. Questi gruppi sono specificati come parte del processo di definizione del business. Possono essere definiti sia a livello del processo sia al momento della definizione degli scopi dello stesso. Questi gruppi possono essere utilizzati come riferimento per l'assegnazione da molteplici attività. Ogni gruppo logico è legato ad una specifica query di persone durante l'esecuzione. Se viene effettuata la stessa richiesta di assegnazione ciò non comporta necessariamente lo stesso risultato, ma solamente il fatto che venga riutilizzata la stessa query.
L'attività <assign> del linguaggio BPEL permette di manipolare i valori associati ai gruppi logici. Per assegnare una persona ad un gruppo logico o da un gruppo logico viene utilizzata l'attività <copy>.
L'espressione utilizzata da BPEL4People per fare questa assegnazione da un gruppo logico ad un altro è la seguente:
<bpel:from b4p:logicalPeopleGroup="NCName">
<b4p:argument name="NCName" expressionLanguage="anyURI"?>* value
</b4p:argument> </bpel:from>
<to b4p:logicalPeopleGroup="NCName"/>
Delle varianti a questa struttura possono includere ulteriori elementi <b4p:argument>, che permettono di specificare gli argomenti necessari per svolgere la query di persone all'interno del gruppo logico specificato. L'attributo expressionLanguage è facoltativo e specifica il linguaggio utilizzato nell'espressione; se non presente viene fissato di default il valore associato allo stesso
attributo nella sezione racchiusa più vicina.
-attraverso processo automatico associando valori costanti: sono applicabili tutte le versioni di
assegnazione automatica supportate dallo standard BPEL. In aggiunta è possibile anche questa variante:
<htd:genericHumanRole>
<bpel:from variable="NCName" part="NCName"?> …
</bpel:from>
</htd:genericHumanRole>
L'attributo variable è utilizzato per associare persone descritte mediante un valore costante associato al business process.
-attraverso espressioni ad-hoc: E' possibile modificare le espressioni di associazione utilizzando
espressioni create ad-hoc
Quando viene specificata un'assegnazione è utilizzato il metadato htd:tOrganizationalEntity definito nello standard WS-HumanTask. Questo permette di assegnare ai ruoli specificati o una lista specifica di utilizzatori o un gruppo non specificato di persone.
People Activity è l'attività di base utilizzata per integrare le interazioni umane all'interno del processo BPEL. Queste interazioni possono essere integrate in vari modi (figura 7.1).
Nel primo e nel secondo modello proposti le task umane sono definite come parte interna del processo BPEL. Nel primo caso una task inlinea è definita come parte di una People Activity. Alternativamente nel secondo modello una task può essere definita come il costrutto base del processo BPEL. In questo caso la stessa task può essere utilizzata per definire più People Acitvity attraverso composizione ricorsiva di task diverse.
Nel terzo modello viene mostrato l'utilizzo di task a se stanti definite nello stesso ambiente di definizione del processo, senza quindi la specificazione delle interfacce dei WS coinvolti nella task. Di conseguenza l'invocazione di una task avviene attraverso un'implementazione specifica. Questo caso è simile al secondo, tuttavia la definizione della task è totalmente indipendente da qualsiasi processo. Come conseguenza principale la taask non ha diretto accesso al contesto del processo. Nel quarto modello le task son a se stanti e definite in un ambiente differente da quello utilizzato per il processo. La principale differenza con il caso precedente è legata al fatto che la task è associata ad un WS dotato di interfaccia, interpellata mediante gli specifici protocolli del WS. In aggiunta il protocollo di coordinazione dello standard WS-HumanTask è utilizzato per realizzare la comunicazione tra task e processo. In questo modo i cambiamenti di stato si possono propagare tra le task, permettendo così la gestione del life-cycle del processo. Con questo approccio, processi definiti all'interno di sistemi BPEL sono trasferibili all'interno di sistemi BPEL4People. I due sistemi sono resi dunque interoperabili.