Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

106 aprile
, anno 2006

Cocoon: una piattaforma di pubblicazione di dati XML

I parte: introduzione al framework

Avatar

Angelo Stefani

Angelo Stefani, nato a Vetralla (VT) il 30/03/1978. Dal 1992 al 1997 frequenta l‘ ITIS Leonardo da Vinci di Viterbo dove consegue il Diploma di Perito Industriale Capotecnico spec. Informatica. Attualmente iscritto al corso di laurea in Ingegneria Informatica della facoltà di Ingegneria presso l‘ Università degli studi di Roma "La Sapienza", sta lavorando alla tesi di laurea "Adattamento di contenuti su dispositivi eterogenei" avente come argomento principale Cocoon.
Informazioni più aggiornate sono disponibili su http://angelostefani.blogspot.com/

MokaByte

Cocoon: una piattaforma di pubblicazione di dati XML

I parte: introduzione al framework

Angelo Stefani

Angelo Stefani

  • Questo articolo parla di: Architetture dei sistemi, Frameworks & Tools, Java

Ecco la seconda parte della serie sulla piattaforma di pubblicazione dinamica dei contenuti XML. Analizzeremo la struttura della Web Application e presenteramo alcuni esempi pratici di utilizzo, analizzando anche le “infrastrutture” necessarie al suo funzionamento.

Introduzione

Cocoon è un Java server framework che consente la pubblicazione dinamica di contenuti XML utilizzando trasformazioni XSLT. Basandosi su XML per descrivere i contenuti ed XSLT come mezzo per trasformare i contenuti in differenti formati, Cocoon fornisce una piattaforma ideale per realizzare applicazioni con una forte separazione tra contenuti, logica e presentazione.

Da Cocoon 1 a Cocoon 2

Stefano Mazzocchi fondò il progetto Cocoon nel 1999 come progetto open-source di Apache.
Inizialmente si trattava di una semplice servlet per effettuare trasformazioni on-the-fly di documenti XML utilizzando fogli di stile Extensible Stylesheet Language (XSL) . La prima versione di Cocoon era basata sulla API Document Object Model (DOM). DOM consentiva di caricare integralmente il documento XML in memoria per poi elaborarlo. Questo meccanismo divenne subito un fattore limitante, in quanto richiedeva parecchie risorse di memoria. Per guidare le trasformazioni, il foglio di stile XSL veniva referenziato o inglobato all‘interno del documento XML. Sebbene questo meccanismo fosse inizialmente abbastanza agevole, creò problemi di mantenimento per siti web dinamici.
Per risolvere questi problemi, in Cocoon 2 il framework è stato completamente riscritto.
In Cocoon 2, per il parsing di documenti XML è stato sostituito DOM con Simple API for XML Processing (SAX), il quale richiede meno risorse di memoria e di calcolo. E‘ stato inoltre introdotto il concetto di pipeline per determinare gli stati di elaborazione che un documento può attraversare, e sono state fatte delle modifiche per migliorare le performance ed il caching.
Cocoon è costituito da molti componenti. Alcuni di questi componenti sono stati sviluppati nell‘ambito del progetto Cocoon, mentre altri sono componenti esterni, sviluppati altrove ed integrati poi successivamente. Cocoon può essere utilizzato in vari modi, il modo più diffuso è quello di utilizzarlo come una servlet all‘interno di un servlet engine, il quale può essere collegato con un web server. Cocoon offre un alto grado di portabilità , in quanto può funzionare come una servlet Java.

Il processo di pubblicazione dei contenuti

Cocoon utilizza il concetto di pipeline per descrivere il processo di pubblicazione dei contenuti sul Web. Il processo di elaborazione di un documento XML può essere suddiviso in vari passaggi. La combinazione di questi passi descrive una pipeline. Una pipeline è formata da un input, alcune elaborazioni ed un output.
Una descrizione del ciclo logico di ricezione delle richieste e di restituzione delle risposte può essere il seguente:

  1. Accettare una richiesta da parte di un utente
  1. Determinare la corretta pipeline da utilizzare per gestire adeguatamente la richiesta e fornire una risposta.
  1. Costruire la pipeline con componenti disponibili e preconfigurati.
  1. Incaricare la pipeline di servire la richiesta.
  1. Restituire la risposta generata dalla pipeline all‘utente, possibilmente facendo il caching del risultato per utilizzi futuri.

Il Sitemap

Il sitemap è il punto centrale di gestione di un sito Web realizzato con Cocoon, e fornisce due funzionalità :

  • E‘ il punto dove sono dichiarati i components prima di essere utilizzati nelle pipelines.
  • E‘ il punto dove vengono definite le pipelines.

Il sitemap è un file XML di configurazione avente una struttura ben precisa. Il sitemap è suddiviso in due sezioni di alto livello, map:components e map:pipelines.

Questo è il ciclo base utilizzato da Cocoon per pubblicare dati XML nel Web. Per gestire questo ciclo, Cocoon fornisce un file XML di configurazione chiamato sitemap.

Sitemap Components

I components vengono dichiarati utilizzando le seguenti specifiche:

  • Component-type è il nome di un tipo specifico di component.
  • Ciascun componente deve avere un attributo nome univoco.
  • Ciascun componente deve identificare la sua implementazione.
  • Deve essere definito un componente di default.

Ciascun tipo di componente si trova nel sitemap racchiuso all‘interno del tag .
Ciascun componente ha un nome univoco ed è associato ad una classe Java che implementa il componente.

Pipeline

Il processo di elaborazione di un documento XML può essere suddiviso in vari passaggi. La combinazione di questi passi descrive una pipeline. Una pipeline è formata da un input, alcune elaborazioni ed un output.
Una pipeline è una sequenza di procedure che consentono a Cocoon di sapere cosa fare quando un documento viene richiesto.
Cocoon fornisce un numero abbastanza ampio di componenti che possono essere connessi tra di loro per realizzare una pipeline. Questi componenti possono essere raggruppati in tipologie abbastanza distinte, in base al ruolo svolto all‘interno della pipeline:

  • Pipeline inputs – generators e readers
  • Processing steps ? transformers e actions
  • Pipeline outputs ? serializers
  • Conditional processing ? matchers e selectors

Generator

I generators leggono da una sorgente dati ed immettono all‘interno della pipeline i dati letti sotto forma di una serie di eventi SAX. Ci sono molti generators disponibili in Cocoon. I più utili sono:

  • FileGenerator: legge files XML dal file system o dal Web
  • HTMLGenerator: legge files HTML dal file system o dal Web
  • DirectoryGenerator: legge dal file system per fornire il contenuto delle directory

Le informazioni prelevate da un generator non devono essere necessariamente in formato XML.

Readers

I readers sono un caso particolare nel modello della pipeline di Cocoon, in quanto non sono componenti XML-aware. I readers accedono ad una risorsa esterna e la passano inalterata come risposta. Vengono generalmente utilizzati per gestire files statici, come ad esempio immagini o fogli di stile CSS.

Transformer

I transformers prendono eventi SAX come ingresso, effettuano alcune elaborazioni e poi inoltrano il risultato nella pipeline come eventi SAX. Un modo molto utile di vedere un transformer è quello di considerarlo come un componente che modifica il flusso di eventi SAX che lo attraversano. Il transformer più utilizzato è sicuramente l‘XSLT Transformer. Questo transformer passa il suo input ad un XSLT processor che effettua trasformazioni XSLT. Il risultato della trasformazione viene poi inoltrato nella pipeline come eventi SAX.

Serializer

Ogni pipeline deve terminare con un serializer. Il serializer prendere un flusso di eventi SAX e li “serializza” per renderizzali nel formato previsto per la risposta. Il formato specifico dipende dal tipo di serializer utilizzato. Il serializer più semplice è l‘XML serializer, il quale semplicemente trasforma gli eventi SAX in un documento XML. Altri serializers sono:

  • HTML Serializer: trasforma XHTML in HTML
  • SVG Serializer: trasforma SVG in immagini JPEG o PNG
  • PDF Serializer: trasforma XSL-FO in un documento PDF

Actions

Le actions sono eseguite durante il setup della pipeline. Il loro scopo è quello di eseguire il codice necessario per eseguire la pipeline. Per esempio, una action può prelevare informazioni da un database per riempire il documento consumato dal generator. La loro esecuzione può avere successo o fallire. Se una action fallisce, la porzione di pipeline definita all‘interno della action non viene eseguita.

Matcher

La funzione principale del matcher è quella di consentire ai documenti richiesti di essere gestiti all‘interno di una pipeline. Il matcher funziona come una clausola switch/case o come una sequenza di clausole if di un linguaggio di programmazione. Se un matcher intercetta una richiesta, Cocoon passa la richiesta da gestire alla rispettiva pipeline. Se un matcher non intercetta la richiesta, Cocoon prova con il prossimo matcher della pipeline, finchè non viene raggiunta la fine. Se nessun matcher è in grado di intercettare la richiesta, Cocoon genera un errore. Il matcher più utilizzato è il wildcard matcher, il quale controlla se l‘URI o il nome del documento richiesto soddisfa un pattern ben preciso. Sostanzialmente un matcher rappresenta l‘ingresso di una pipeline.

Selector

I selectors sono simili allo statement if-then-else. I selectors vengono utilizzati quando sono disponibili una o più opzioni. I selectors sono utilizzati di solito per creare sezioni di selezione all‘interno di una pipeline, mentre i matchers vengono utilizzati per gestire l‘accesso alle pipelines.

Conclusione

Abbiamo visto le caratteristiche principali di Cocoon. Nel prossimo articolo andremo più in dettaglio vedendo alcuni esempi di utilizzo.

Riferimenti bibliografici
[1] Massimo Canducci “XML” Apogeo, 2005
[2] Aaron Skonnard, Martin Gudgin “Essential XML Quick Reference” Addison-Wesley, 2002
[3] Doug Tidwell “Mastering XML Transformations”, O‘Reilly, 2003
[4] http://www.w3.org/Style/XSL/
[5] http://cocoon.apache.org/
[6] Matthew Langham, Carsten Ziegeler “Cocoon: Building XML Applications”, New Riders, 2002

Facebook
Twitter
LinkedIn
Avatar

Angelo Stefani

Angelo Stefani, nato a Vetralla (VT) il 30/03/1978. Dal 1992 al 1997 frequenta l‘ ITIS Leonardo da Vinci di Viterbo dove consegue il Diploma di Perito Industriale Capotecnico spec. Informatica. Attualmente iscritto al corso di laurea in Ingegneria Informatica della facoltà di Ingegneria presso l‘ Università degli studi di Roma "La Sapienza", sta lavorando alla tesi di laurea "Adattamento di contenuti su dispositivi eterogenei" avente come argomento principale Cocoon.
Informazioni più aggiornate sono disponibili su http://angelostefani.blogspot.com/

Angelo Stefani

Angelo Stefani

Angelo Stefani, nato a Vetralla (VT) il 30/03/1978. Dal 1992 al 1997 frequenta l‘ ITIS Leonardo da Vinci di Viterbo dove consegue il Diploma di Perito Industriale Capotecnico spec. Informatica. Attualmente iscritto al corso di laurea in Ingegneria Informatica della facoltà di Ingegneria presso l‘ Università degli studi di Roma "La Sapienza", sta lavorando alla tesi di laurea "Adattamento di contenuti su dispositivi eterogenei" avente come argomento principale Cocoon. Informazioni più aggiornate sono disponibili su http://angelostefani.blogspot.com/
Tutti gli articoli
Nello stesso numero
Loading...

JFreeChart: una libreria Open Source per la generazione dinamica di grafici

I parte: introduzione al framework

New to Java: la strada per diventare guru

I parte: primi passi nel mondo della programmazione

Service Oriented Architecture

VII parte: Enterprise Service Bus (II)

L‘Oracolo e l‘Open Source

Oracle si interessa a MySQL e JBoss?

Architetture d‘Integrazione

II parte: le architetture EAI

Nella stessa serie
Loading...

Device Independence

Approccio server side mediante Cocoon e DELI

Cocoon: una piattaforma di pubblicazione di dati XML

II parte: esempi di utilizzo

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte