Visualizzazione post con etichetta SOA. Mostra tutti i post
Visualizzazione post con etichetta SOA. Mostra tutti i post

mercoledì 16 novembre 2011


La specifica WSRP è stata prodotta dal consorzio OASIS, organizzazione per la promozione di standard tecnici per l’interoperabilità, con l’obiettivo di definire una serie di interfacce per consentire il consumo inter-portale dei frammenti applicativi messi a disposizione da contenitori di portlet e consentire quindi l’interoperabilità fra portali consentendo l’implementazione con tecnologie eventualmente diverse.

Di seguito sono messe a confronto una architettura classica dei portali con una in un cui si fa utilizzo dello standard WSRP, nella prima sono coinvolti un fruitore rappresentato dal browser, una applicazione portale la quale utilizzando una comunicazione basata sullo stesso linguaggio del container recupera e successivamente aggrega i frammenti.

Nel secondo scenario  invece oltre che i meccanismi utilizzati nel precedente intervengono anche i seguenti componenti:
  •  Erogatore WSRP: è un servizio web che offre uno o più portlet e implementa WSRP varie interfacce/operazioni. A seconda dell'implementazione, un produttore può offrire solo un portlet, o può fornire un  contenitore per la distribuzione e la gestione di parecchi portlet.
  •   Fruitore WSRP: è un client del servizio web (in genere implementato come modulo in un portale) che richiama l’erogatore e fornisce un ambiente per gli utenti per interagire con portlet offerti da uno o più produttori


Come accennato in precedenza, WSRP definisce un insieme di interfacce comuni che tutti i produttori WSRP sono tenuti ad implementare e che i consumatori WSRP devono utilizzare per interagire con i portlet in remoto in esecuzione.

La standardizzazione di queste interfacce permette ad un portale di interagire con la portlet da remoto, la specifica WSRP richiede due implementazione obbligatorie e due opzionali:
  •  Service Description Interface (obbligatorio): consente ad un produttore WSRP di pubblicare dati sulle proprie capacità. Un consumatore WSRP può utilizzare questa interfaccia per interrogare un produttore e scoprire cosa offre il contenitore e metadati aggiuntivi su di questo. Questa interfaccia può agire come un meccanismo di rilevamento per determinare l'insieme di portlet offerti, ma soprattutto permette ai consumatori di determinare ulteriori informazioni sulla capacità tecnica del produttore.
  • Mark-up Interface (richiesto): L'interfaccia permette al WSRP consumatore di interagire con un portlet remoto in esecuzione su un produttore WSRP. E’ necessaria per l’interazione con la portlet, la gestione dello stato e l’invio di eventi,
  • Interfaccia di registrazione (opzionale): L'interfaccia di registrazione permette un produttore WSRP di richiedere che i consumatori WSRP eseguino una sorta di registrazione prima di poter interagire con il servizio attraverso la Mark-up interfacce. Attraverso questo meccanismo un produttore può personalizzare il proprio comportamento a un tipo specifico di consumatori.
  • Portlet Management Interface (opzionale): dà l'accesso al ciclo di vita della portlet in esecuzione in remoto. In modo da consentire la personalizzazione del comportamento di una portlet o addirittura distruggere l'istanza di una portlet in esecuzione in remoto.

martedì 15 novembre 2011

WS-Human Task è una specifica dal contesto di WS-*, che ha affrontato la questione di come integrare l'interazione umana nei processi di business, la specifica è stata sviluppata da Adobe, IBM, BEA , Oracle, SAP Active Endpoins e dal giugno 2007 è sottoposta a standardizzazione
WS-Human Task fornisce una sintassi XML in grado di descrivere i compiti (task) e le notifiche con soggetti umani. Inoltre, è possibile utilizzare diversi ruoli e gruppi di utenti (i cui tipi di dati sono inclusi), consentendo una astrazione a livello personale (es.: "impiegato" invece di "John Doe”), include inoltre una semantica per la descrizione di diversi stati ed un API per la facile interazione tra uomo e macchina lato client.
Mentre BPEL4People si occupa di una descrizione astratta delle interazioni umane, l'integrazione concreta è definita con l’utilizzo di WS-HumanTask.
Nelle architetture attuali i task con interazione umana sono generalmente fortemente accoppiati con un sistema di gestione del workflow (WFMS), il quale si occupa di gestire interamente il ciclo di vita dei task, ciò comporta la difficoltà di intervenire nel processo al di fuori del contesto del WFMS e porta quindi ad avere uno sviluppo incentrato su di questo che aumenta fortemente l’accoppiamento dei sistemi e quindi una diminuzione della portabilità.
WS-HumanTask introduce una architettura che supera queste limitazioni definendo un componente il Task Processor, interamente basato su web services, responsabile di creare ed interagire con un task per la transizioni fra stati, tale componente viene portato al di fuori del WFMS.
Una volta introdotto il Task Processor siamo in grado di definire tramite WS-HumanTask l’interfaccia di servizio del task che dovrà essere svolto e di rilasciarlo sul processor in modo che un componente esterno il Task Parent possa istanziare il task tramite un servizio per la creazione delle istanze.
Una volta creata l’istanza il Processor mette a disposizione dei client esterni una serie di operazioni per la gestione del ciclo di vita, ma al termine o al fallimento del compito il Parent deve essere notificato per poter continuare con il flusso di lavoro; rimanendo in ambito SOA viene utilizzato il protocollo di coordinazione WS-Coordinator con la definizione di un protocollo di ordinamento specifico per il contesto.
Lo scambio di messaggi Tra il Parent ed il procesor sarà quindi il seguente:
  • Il Parent crea una istanza del task e passa al Processor le informazioni di contesto, fra cui le informazioni del Register per registrasi alla cooperazione.
  • Il Processor a questo punto si registra passando il proprio indirizzo per la gestione del protocollo di coordinazione, la callback da invocare al termine del task e le informazioni di contesto ricevute precedentemente.
  • Il Register a sua volta comunica al Processor l’indirizzo per la gestione del procollo di coordinazione.
Al termine degli scambi di messaggio avremo quindi l’istanza del task con un collegamento logico al Parent per la notifica dei cambiamenti di stato come illustrato in Figura e per la gestione del protocollo di coordinazione utilizzato, nello scenario più semplice quindi al termine di un task il task processor invoca il coordinator del task parent per segnalare un cambiamento di stato ed il task parent invoca la callback (servizio web) per gli ricevere gli output del task.


Per completare l’architettura è necessario introdurre una interfaccia utente per la gestione delle attività, questo componente è necessario per prospettare agli utenti la lista di task attualmente assegnati e consentire loro di svolgere i compiti assegnati, a questo proposito il linguaggio introduce la possibilità di gestire i rendering, ovvero di definire diversi tipi di GUI con cui l’utilizzatore può inserire o visualizzare dati necessari al corretto svolgimento delle attività.

In questa rapida introduzione sono state riassunte le caretteristiche principali della specifica, nella seconda parte verranno mostrati alcuni esempi di codice per la definizione dei task.

Per ulteriori approfondimenti:
  • Active Endpoints. Architectural Description of WS-HumanTask. s.l. : Active Endpoints, 2010.
  • Ashish Agrawal, Mike Amend, Manoj Das et al. Web Services Human Task (WS-HumanTask), Version 1.0. 2007.
  • OASIS. Web Services – Human Task (WS-HumanTask) Specification Version 1.0. www.oasis-open.org. [Online] 04 11 2009. [Riportato: 15 05 2011.] docs.oasis-open.org/bpel4people/ws-humantask-1.1-spec-cd-06.pdf.
* Le immagini sono prese direttamente dal sito della specifica.

Subscribe to RSS Feed Follow me on Twitter!