Questo è un problema che mi si è presentato recentemente è ho avuto modo di valutare diverse soluzioni piu o meno realizzabili e in definitiva ho optato per la creazione di un documento PDF per mezzo delle librerie iText di http://www.lowagie.com/iText/ e aprire questo file con l'applicazione predefinita per visualizzare PDF.

Le soluzioni provate sono state diverse anche per il fatto di non sborsare un soldo per eventuali licenze commerciali per librerie o altro.

Trovare un java bean grafico da integrare nel mio programma

Esiste un bean grafico 'Acrobat Viewer '  che puo servire al nostro scopo e una dettagliata pagina di spiegazioni si trova qui (Inglese):

http://today.java.net/pub/a/today/2005/10/20/accessing-pdf-with-acrobat-viewer-javabean.html 

Per utilizzare questa libreria bisogna includere nel nostro progetto di Netbeans le due librerie scaricabili qui 'Acrobat Viewer' che sono:

1.'MRJToolkitStubs.zip'

2.'acrobat.jar'

[Per includere nel progetto queste due librerie e usarle senza errori nel mio codice java:
Aprire la gerarchia del mio 'Application project'  cliccare con il tasto destro del mouse la voce 'Libraries' cliccare la voce 'Add jar/Folder' si possono scegliere file .jar ma anche .zip non dovrebbe dare errori]

Il problema è che l'ultima versione scaricabile fornita è ferma dal 1999 e piu niente è stato aggiornato quindi l'interfaccia resta oltre che un po vecchiotta a rischio di mandarti in crash il tuo programma. 

Un esempio di codice:

import com.adobe.acrobat.*;
import java.awt.*;
import java.io.*;

public class PDFViewer {

    public PDFViewer() throws java.lang.Exception {

    }

    public void viewPDFDocument() {

        try {

            Frame frame = new Frame("PDF Viewer");

            frame.setLayout(new BorderLayout());

            Viewer viewer = new Viewer();

            frame.add(viewer, BorderLayout.CENTER);

            frame.add(new Label("PDF Document in Adobe Acrobat Viewer",

                    Label.CENTER), BorderLayout.NORTH);

            InputStream input = new FileInputStream(new File(

                        "C:/miofile.pdf"));

            viewer.setDocumentInputStream(input);

            viewer.setEnableDebug(true);

            viewer.setProperty("Default_Page_Layout", "SinglePage");

            viewer.setProperty("Default_Zoom_Type", "FitPage");

            viewer.setProperty("Default_Magnification", "100");

            System.out.println("Page Count: " + viewer.getPageCount());

            System.out.println("Current Page: " + viewer.getCurrentPage());

         

            viewer.zoomTo(1.0);

            viewer.activate();

            frame.setSize(400, 500);

            frame.pack();

            frame.show();

           OutputStream output=new FileOutputStream(new File("C:/output.txt"));

            PrintWriter printWriter=new PrintWriter(output);

            printWriter.print(viewer.getTextForPage(1));

            printWriter.flush();

            printWriter.close();

        } catch (java.lang.Exception e) {

        }

    }

    public static void main(String[] argv) {

        try {

            PDFViewer pdfViewer = new PDFViewer();

            pdfViewer.viewPDFDocument();

        } catch (java.lang.Exception e) {

        }

    }

}

Dopo qualche sforzo si riesce a visualizzare l'interfaccia di Acrobat Viewer sul tuo progetto, ma sul mio macbook il drag con la manina funziona correttamente mentre su una macchina windows sfarfalla fastidiosamente. quindi soluzione bocciata.

Altri bean grafici gratuiti che visualizzano PDF attualmente io non ne ho trovato risultano invece facili da trovare quelli a pagamento e in particolare:

1. http://www.icesoft.com/products/demos_icepdf.html 

2. http://www.qoppa.com/demo/vapplet.html 

i quali forniscono delle dimostrazioni on line dei loro viewer.

Un elenco di risorse per gestire, leggere, generare PDF in Java si trova qui:

http://schmidt.devlib.org/java/libraries-pdf.html

Fonte: http://www.pirasters.org/index.php?option=com_content&task=view&id=18&Itemid=30

Licenza Articolo: Attribuzione 2.5 Italia (CC BY 2.5)

Diamo un'occhiata agli EJB

Gli Enterprise JavaBean (EJB) sono i componenti che implementano, lato server, la logica di business all’interno dell’architettura J2EE. Le specifiche per gli EJB definiscono diverse proprietà che questi devono rispettare, tra cui la persistenza, il supporto alle transazioni, la gestione della concorrenza e della sicurezza e l’integrazione con altre tecnologie, come JMS, JNDI, e CORBA.
Gli EJB sono uno strumento molto potente e sono di solito utilizzati in applicazioni distribuite, in cui la necessità di ripartire il carico e le funzionalità, sono di sostanziale importanza.

Un EJB è una classe Java che segue determinate regole imposte dalla specifica che, una volta programmato, viene posto in un application server e da esso verrà gestito secondo le regole definite.

In un contesto Java puro, generalmente, i client di questi oggetti sono le pagine JSP e le servlet, che si poggiano agli EJB per definire il contenuto dinamico da mostrare all’utente (una ricerca, un carrello della spesa, ecc). In realtà, l’idea di questi componenti è nata per permettere a diverse tecnologie di usare lo stesso strato di logica, residente in un contesto distribuito.

Esistono tre tipi di EJB:

• EJB di Entità (Entity EJB): il suo scopo è di inglobare gli oggetti sul lato server che memorizzano i dati. Gli EJB di entità forniscono la caratteristica della persistenza dei dati:
  • Persistenza gestita dal contenitore (CMP): il contenitore si incarica della memorizzazione e del recupero dei dati relativi a un oggetto utilizzando una tabella di una base di dati.
  • Persistenza gestita dal bean (BMP): in questo caso è il bean a occuparsi del salvataggio e recupero dei dati a cui fa riferimento, il salvataggio può avvenire in una base di dati o con qualsiasi altro meccanismo perché è il programmatore che si incarica di realizzare il meccanismo della persistenza dei dati.
• EJB di sessione (Session EJB): gestiscono l’elaborazione delle informazioni sul server. Generalmente sono una interfaccia tra i client e i servizi offerti dai componenti disponibili sul server. Ne esistono di due tipi:
  • con stato (stateful). I bean di sessione con stato sono oggetti distribuiti che posseggono uno stato. Lo stato non è persistente, però l’accesso al bean è limitato ad un unico client.
  • senza stato (stateless). I bean di sessione senza stato sono oggetti distribuiti senza uno stato associato, questa carattestistica permette un accesso concorrente alle funzionalità offerte dal bean. Non è garantito che il contenuto delle variabili di istanza si conservi tra diverse chiamate ai metodi del bean.
• EJB guidati da messaggi (Message driven EJBs): sono gli unici bean con funzionamento asincrono. Tramite il Java Message Service (JMS), si iscrivono a un argomento (topic) o a una coda (queue) e si attivano alla ricezione di un messaggio inviato all’argomento o alla coda a cui sono iscritti. Non richiedono una istanziazione da parte dei client.

Notevoli passi in avanti sono stati fatti dalla versione 2 alla 3.0

La grossa differenza nel passaggio da una versione ad un'altra è stata l'eliminazione delle classi utilizzate come Factory per istanziare concretamente il bean. Ciò significa che nella versione 3 non dovremo più creare una classe Home per ogni bean creato, né dovremo preoccuparci di estendere altre classi o interfacce.

Gli EJB 3.0 hanno in pratica modificato radicalmente l'architettura, lasciando molta più libertà alla costruzione dell'application server che ospiterà i componenti. Sarà infatti il container e la maniera in cui esso è implementato a gestire il ciclo di vita del componente. Non importa come questo avvenga: importante è rispettare la specifica e garantire il corretto ciclo di vita dei componenti. Fondamentalmente nella versione 3 sarà sufficiente scrivere una classe POJO (Plain Old Java Object) che implementa l'interfaccia di business.

Questa cosa potrebbe non essere positiva, in quanto in questo modo perderemmo la possibilità di intervenire in particolari momenti del ciclo di vita dell'oggetto (ad esempio durante le operazioni di passivazione ed attivazione). Ciò viene risolto dalla possibilità di creare delle apposite classi callback oppure di scrivere i metodi per gestire gli eventi ed annotarli con le annotazioni.

A questo punto risulta piuttosto evidente che il descrittore di deploy è inutile. Attraverso le annotazioni, infatti, riusciamo a definire in maniera precisa il componente e le sue diverse funzionalità, il ciclo di vita (anche le transazioni o altre funzioni di middleware da implementare). Di tutti i componenti, probabilmente questo è stato quello meno amato per un semplice motivo: è XML. Difficile da scrivere, da leggere e da capire, attraverso le annotazioni, fortunatamente questo componente viene meno. Inoltre, la sua redazione avviene in una seconda fase rispetto allo sviluppo del componente, quindi, l'insidia può essere rappresentata dalle dimenticanze. La possibilità di definire già all'interno della classe il suo comportamento del componente (transazioni, sicurezza, riferimenti ad altri ejb, ecc) facilita (e non poco) il lavoro.

Come application server per gli EJB consigliamo certamente JBOSS.

Maggiori informazioni su JBoss: www.jboss.com
Comunità degli sviluppatori: www.jboss.org