Archive for July, 2011

Enterprise Java Beans part 5

by on Jul.15, 2011, under Uncategorized

Parliamo adesso di JNDI.

Java Naming Directory Interface è un’interfaccia che offre supporto a vari servizi di nomi, quindi non implementa un singolo servizio, ma l’API, e si serve di plugin di supporto che permettono di collegare i metodi JNDI ai vari metodi specifici del singolo servizio.
Tali plugin di supporto, che contengono le informazioni specifiche per un dato servizio di nomi ( DNS, LDAP, RMIRegistry, etc..), vanno indicati in fase di configurazione nella “initial property” e prendono il nome di Service Providers.

L’altra proprietà da configurare è l’URL del servizio di nomi.
Il Context è l’interfaccia al gruppo di bindings offerti dal servizio di nomi, può esserci un name service organizzato come un Directory gerarchico, in quel caso avrei anche dei Sub-context.

<pre>// Crea contesto iniziale. Environment specifica
// quale JNDI provider utilizzare e a quale URL
   Hashtable hashtableEnvironment = new Hashtable();
   hashtableEnvironment.put(Context.INITIAL_CONTEXT_FACTORY,
                 "com.sun.jndi.rmi.registry.RegistryContextFactory");
   hashtableEnvironment.put(Context.PROVIDER_URL, rgstring[0]);
   Context context = new InitialContext(hashtableEnvironment);
   IntRemota cxt.lookup(“lia.deis.unibo.it:5599/ServerRemoto”);

In questo caso ci interessa un binding relativo al servizio RmiRegistry di RMI, che otteniamo settando la proprietà Context.INITIAL_CONTEXT_FACTORY.
Tutte le proprietà vanno settate su una HashTable, che viene passata all'InitialContext.
InitialContext è un’implementazione di Context e rappresenta contesto di partenza per operazioni di naming

Quando sul contesto invoco il metodo ctx.lookup(Nome); ottengo un riferimento all'oggetto.
Non ho una completa trasparenza: se il servizio di nomi è un Directory ( ho anche attributi associati ad un nome), mi serve un DirContext, che mi permette di effettuare ricerche sul Database del servizio di Directory, anche abbastanza complesse, a partire dagli attributi.

Vantaggi di JNDI: Accedo ad un'unica interfaccia per poter fruire di diversi servizi di nomi, senza dover modificare il codice cliente. Questo si addice particolarmente a contesti aziendali, dove le risorse sono accessibili tramite una moltitudine di servizi di nomi eterogenei.

Quando registro un nome con context.bind("nome",object); object può essere un riferimento all'oggetto remoto, ma la specifica JNDI non mi impedisce di associare un vero e proprio oggetto serializzato: deve essere lo sviluppatore a capire se la semantica del binding è corretta o meno.

Leave a Comment :, , , , , , , , , , more...

Enterprise Java Beans part 4

by on Jul.15, 2011, under Uncategorized

Prima di entrare nello specifico dell’architetture EJB 3.x, analizziamo il funzionamento di una feature che ha determinato il successo di questa stessa architettura: le Java Annotations.

Le Annotazioni aggiungono un livlelo descrittivo al codice, per modificare il comportamento di alcuni strumenti come il generatore di Javadoc, il compilatore, la JVM e il Class Loader ( negli ultimi due casi vi è una modifica sul bytecode che verrà eseguito a runtime).
Vi sono delle annotazioni predefinite, ad esempio @Serializable definisce una classe che è possibile serializzare (alcune classi come Thread non sono serializzabili a causa del fatto che semanticamente è inutile serializzare lo stato di tale classe, infatti il contesto di esecuzione di un Thread è legato alla JVM presso la quale è in esecuzione).
E’ possibile dichiarare delle annotazioni personalizzate col costrutto
@interface nome_annotazione {...}
all’interno del corpo dichiaro dei membri che restituiscono dati di un tipo scelto, la utilizzo decorando una classe o un metodo con la sintassi
@nome( prop1=val1, prop2=val2, ....)
Esistono Meta-annotazioni, cioè annotazioni che decorano annotazioni, la più importante è @Retention, che stabilisce la politica di mantenimento in memoria con cui va gestita una certa annotazione.

  • RetentionPolicy.SOURCE
    Fa si che non rimanga traccia dell’annotazione sul bytecode, ma solo sul codice sorgente
  • RetentionPolicy.CLASS
    Mantiene le annotazioni sul bytecode ma non le rende disponibili a runtime
  • RetentionPolicy.RUNTIME
    E’ la più onerosa, ma grazie ai metodi di refletcion permette allo sviluppatore di accedere all’annotazione e ai suoi campi a runtime.

 

In definitiva:

Vantaggi: Le annotations permettono di gestire il livello descrittivo sullo stesso file dei sorgenti, quindi evitano problemi di incoerenza coi sorgenti al programmatore
Svantaggi: Non mantengo una separazione tra i due livelli concettuali inserendo tutto in un unico file

1 Comment :, , , , , , , , more...

Enterprise Java Beans part 3

by on Jul.14, 2011, under Uncategorized

Continiuamo a parlare di alcune features di EJB, in particolare facciamo riferimento ancora alla versione 2.x.

Il Descrittore di Deployment, è un file contenuto nel modulo EJB ( Ejb-Jar), e contiene informazioni sul tipo di EJB usato (Statefull o Stateless Session Bean ? ) e altri parametri di configurazione.
In generale il Descrittore di Deployment descrive anche le proprietà strutturali dell’applicazione (modalità d’accesso al DB, sicurezza, nomi delle interfacce Object e Home etc..)
L’uso di un descrittore di deployment su un file di configurazione xml, consente di effettuare una configurazione a deployment-time, e quindi separare la logica implementativa (codice sorgente ) da quella di deployment.

Quando il client di un Session Bean è ad esempio un altro Session Bean locale alla macchima, dover gestire una chiamata remota per un’interazione locale tra due componenti risulta dispondioso, è possibile usare delle interfacce locali ( EjbLocalHome ed EjbLocalObject) che di fatto non vengono implementate dal container, ma consentono un’invocazione diretta senza l’utilizzo di proxy, questo comporta una maggiore efficienza a scapito di una minore trasparenza per lo sviluppatore dei Beans.

Vediamo qui una vista dell’architettura EJB2 completa di oggetti proxy RMI (stubs e skeletons) e interfacce.

Il codice che ci permette di inizializzare un client per ottenere un riferimento all’EjbObject è il seguente:


// Ottiene una istanza dell’EJB Interest. Si noti che il codice
// EJB-specific è incluso tutto in questo metodo, cosicché
// la logica nella slide precedente può essere “plain Java”
public static Interest getInterest()
  throws CreateException, RemoteException, NamingException {
// Passo 1: ottenere un’istanza di EJBHome (in realtà un oggetto
// stub per l’oggetto EJBHome) via JNDI
  InitialContext initialContext = new InitialContext();
  Object o = initialContext.lookup ("Interest");
  InterestHome home = (InterestHome)
    PortableRemoteObject.narrow (o, InterestHome.class);
// Passo 2: creare un oggetto EJBObject remoto (in realtà uno
// stub all’oggetto EJBObject remoto
  return home.create();

Il narrowing consente di forzare la conversione tra strutture di ambienti diversi. Poichè J2EE usa solo Java, sarebbe bastato un semplice casting, ma su IIOP gira anche CORBA, che usa il narrowing esteso, quindi uso il metodo narrow().

Il programmatore può far si che il componente business-logic in esecuzione sull’application server implementi sia le interfacce Local che quelle Remote, per Object e Home, il container provvede a generare gli oggetti proxy sia per le chiamate locali che gli oggetti proxy per invocazioni remote, il cliente invece può contenere nel suo Jar classi di supporto esclusivamente  per un solo tipo di invocazione.

Ricordiamo che un’invocazione remota su RMI comporta un passaggio per copia (serializzazione) dei parametri.
Un’invocazione locale comporta un passaggio per riferimento dei parametri, perchè condivido l’Heap e la JVM.

 

Leave a Comment :, , , , , , , , , , , , , , more...

Enterprise Java Beans part 2

by on Jul.13, 2011, under Uncategorized

I componenti EJB generalmente sono categorizzati in tre tipologia in base alle loro funzionalità, vediamole nel dettaglio.

Session Bean

È il tipo di componente che gestisce una sessione col cliente con interazione sincrona (il cliente attende una risposta).
I session Bean non garantiscono la persistenza dei dati, cioè ad esempio lo spegnimento dell’Application Server può determinare la perdita dei dati. Possono essere

  • Stateless

    Lo Stateless Session Bean, gestisce sessioni senza informazioni di stato, quindi senza necessità di assegnamento di ogni istanza ad un unico cliente. (nell’esempio C1 e C2 su S1).

  • Statefull

    Lo Statefull Session Bean adotta l’assegnamento di una diversa instanza del bean ad ogni  cliente al fine di gestire lo stato.

(continue reading…)

Leave a Comment :, , , , , , , , , more...

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!