Architettura

Apache Muse definice il concetto di capability in questo modo: ogni resource consiste in una collezione di piccole unità di funzione chiamate capabilities. Il concetto di capability è stato descritto inizialmente in WSDM MUWS 1.0 co-me co-mezzo per informare i client circa i dati,le operazioni e i comportaco-menti che devono aspettarsi da una resource. Il modo in cui sono state definite nella spe-cifica WSDM MUWS ricorda il modo in cui gli sviluppatori Java dividono parti di software in moduli più piccoli ognuno con un proprio task; l’aggregazione di capability come Identity, Configuration e Relationship in singole interfacce Web Service suggerisce un modello simile per l’implementazione server-side. Muse ha

generalizzato il concetto di capability presentato nel WSDM MUWS per rende-re pià semplice ai programmatori l’implementazione di rende-resource come unità di funzioni riutilizzabili piuttosto che come singole classi Java monolitiche.

L’architettura di Apache Muse si basa su quattro concetti base:

Figura 2.16: Architettura Apache Muse

• The Capability Una resource capability è una collezione di dati ed opera-zioni esposti via Web Services. Rappresenta un’unita atomica dell’architet-tura di Muse. Le capabilities sono aggregate per definire i resource types e sono implementate come semplici classi java. Le classi capability sono analizzate at initialization time per determinare il modo in cui si inseriscono nell’interfaccia mostrata dal WSDL della resource.

• The Resource Una resource è una collezione di capabilities esposte at-traverso un’interfaccia Web Services. Rappresenta anche l’interfaccia uti-lizzata dalle capabilities che intendono comunicare con altre capabilities.

• The Implied Resource Pattern Ogni resource ha un unico endpoint re-ference (EPR). Questo data type è definito dallo standard WS Addressing e contiene le basic networking e le runtime-specific data necessari a loca-lizzare e ad invocare le operazioni. L’ implied resource pattern consente agli utenti di aggiungere coppie name-value di un EPR per distinguere tra più istanze di un tipo di risorsa comuni ad un indirizzo(URL).

• The Isolation Layer Le Muse resources possono essere deployate in diffe-renti ambienti J2EE application servers, OSGi, etc. ma è previsto un unico modello di programmazione. E’ possibile implementare una resource type ed effettuare il relativo deploy in ambienti eterogenei con delle semplici modifiche al deployment artifacts senza modificare il codice della resource.

La logica del servizio viene implementata nel capability layer; quello che serve è un modo per combinare insieme le unità prodotte per rispecchiare quanto definito nell’interfaccia WSDL che i client utilizzano per analizzare la resource. La re-source esegue effettivamente l’aggregazione e fornisce ai web services una singola interfaccia per gestire le richieste SOAP in arrivo. Muse utilizza quindi il concetto di capability come strategia d’implementazione di un servizio; il SOAP engine, l’isolation layer e il router non sono a conoscenza di questo concetto di modello di programmazione. Ad esempio un’application server resource implementata con le capability WSN NotificationProducer, WSRL ImmediateResourceTermination e AppServerDeployment nasconde l’aggregazione nel modo mostrato in figura. Il fatto che l’operazione di Subscribe sia gestita dalla capability WSN Notifi-cationProducer e che l’operazione di DeployApplication sia invece gestita dalla

capability AppServerDeployment è irrilevante per il resource router e per tutti gli componenti che gestiscono le richieste. Una volta che la richiesta è stata delega-ta all’appropriadelega-ta resource insdelega-tance, solo la resource sa che l’operazione in corso è implementata da una altro layer: il capability object che definisce il metodo Java equivalente all’operazione richiesta. Il Java object rappresenta la resource instance che eseguirà i task e che delegherà le rishieste alle relative capability sulla base delle informazioni scoperte at initialization time. Quando una resource viene creata, il Muse framework utilizza il WSDL della resource per determina-re cosa la determina-resource ha promesso di sostenedetermina-re e se è in grado effettivamente di farlo; tale verifica viene effettuata analizzando le definizioni delle capability della resource(incluse le implementazioni delle loro classi java) per essere sicuri che le operazioni previste nel WSDL port type presentino equivalenti metodi Java nella collezione di capabilities.

Figura 2.17: Costruire una Resource attraverso le Capability

Infine una shape resource deve garantire che tutte le capabilities ricevano la corretta notifica circa gli eventi del proprio ciclo di vita, per dare loro modo

di prendere le misure adeguate nelle fasi di initialization e di shutdown. Ogni interfaccia Capability definita da Muse è composta da quattro lifecycle events:

• Initialization Capability.initialize() - Quando la capability è in grado di effettuare tutti i self-contained startup tasks, e non richiede l’utilizzo delle altre capabilities presenti nella resource.

• Post-initialization Capability.initializeCompleted() - Quando la capability può effettuare tutti i rimanenti startup tasks; in particolare, può interrogare e manipolare altre capabilities che si trovano in uno stato stabile.

• Pre-shutdown Capability.prepareShutdown() - Quando la capability può effettuare tutti gli shutdown tasks che riguardano l’interrogazione e la ma-nipolazione di altre capabilities. Questa fase è definita come last call pos-sibilità per la capability di ottenere ciò di cui ha bisogno dagli altri compo-nenti prima del loro shutdown e quindi prima che la loro stabilità non sia più garantita.

• Shutdown Capability.Shutdown() - Disponendo dei dati necessari per il pre-shutdown, la capability può ora effettuare il self-contained shutdown tasks, includendo persistence, configuration, o notifications.

Anche in Apache Muse il WSDL è un documento utilizzato per definire l’inter-faccia di un Web Services che client remoti utilizzano per comunicare con le resource. Oltre a fornire l’interfaccia di un servizio al client, il WSDL di una re-source viene utilizzato at initialization time per determinare quali richieste sono

valide, quali Api dovrebbero essere utilizzate e come convertire i dati da elemen-ti XML a oggetelemen-ti Java e viceversa. Il WSDL conferma quanto contenuto nel deployment descriptor muse.xml e fornisce i dettagli necessari per processare le richieste SOAP.