Introduzione
L'assemblaggio di un modulo
J2EE dà luogo ai seguenti elementi di implementazione:
-
Archivio J2EE (file WAR, EJB-JAR e JAR) e relativi
-
descrittori di distribuzione (file XML) che descrivono i contenuti dell'archivio e indicano come i componenti
contenuti devono funzionare all'interno del contenitore
Per ulteriori informazioni Linea
guida per il prodotto di lavoro: Moduli J2EE.
Definizione dell'archivio
In questa operazione, il provider del componente dell'applicazione identifica i componenti da includere nel modulo.
È possibile creare più archivi per diversi scopi. Ad esempio, archivi separati per la verifica, il debug o la consegna
a diverse configurazioni di distribuzione di "produzione". Gli archivi di verifica possono contenere classi di verifica
e classi costruite con flag di debug, mentre gli archivi di produzione non possono contenere classi di test e non
possono essere costruiti. Il contesto dell'archivio da assemblare influisce sullo spazio di lavoro di assemblaggio
impostato.
Definizione dei descrittori di distribuzione
L'operazione principale nell'assemblaggio del modulo J2EE è la definizione dei descrittori di distribuzione. Molte di
queste informazioni dovrebbero essere state catturate nella progettazione di ogni componente, dunque definire i
descrittori di distribuzione significa principalmente assicurare coerenza al progetto. Se si sta utilizzando roundtrip
engineering, dovrebbe essere disponibile anche il supporto del tool che genera il descrittore di distribuzione.
Ogni archivio contiene un descrittore di distribuzione J2EE standard e oltre a zero o più descrittori specifici di
vendor. I descrittori standard, ejb-jar.xml per EJB-JAR e web.xml per WAR contengono sezioni che devono essere
completate per il testing e altre distribuzioni di "non produzioni", più alcune sezioni che saranno preparate
dall'assemblatore dell'applicazione finale per la distribuzione della produzione.
Ogni descrittore contiene informazioni interessanti per i provider di componenti di applicazione così come gli
assemblatori di applicazioni. Ad esempio, ejb-jar.xml contiene tre sezioni maggiori (relative alla presente
discussione): <enterprise-beans>...</enterprise-beans>, <relationships>...</relationships>, e
<assembly-descriptor>...</assembly-descriptor>. Il provider di componenti di applicazione
definisce le proprietà di EJB, come i campi CMP, nella sezione <enterprise-beans>...</enterprise-beans>. Definisce inoltre le relazioni facoltative tra EJB
nella sezione <relationships>...</relationships> . Nella
sezione <assembly-descriptor>...</assembly-descriptor> sono definite le transazioni, i ruoli di
sicurezza, le autorizzazioni di metodo ecc. Normalmente solo l'assemblatore di applicazioni si occuperà di questa
sezione. L'assemblatore può decidere di modificare i contenuti delle altre due sezioni, ma ciò accade raramente. La
situazione è simile a quella degli archivi WAR. Per ulteriori informazioni sull'assemblaggio di applicazioni, vedere Linea guida: Assemblaggio di applicazioni J2EE.
Se durante la progettazione sono state definite associazioni tra le tabelle di database nel modello dati ed EJB di entità CMP (Container-Managed Persistent),
queste associazioni dovrebbero riflettersi nelle direttive di associazione nei descrittori specifici del vendor (le
direttive di associazione non fanno parte dei descrittori standard EJB). Per ulteriori informazioni su associazioni di
EJB di entità CMP con le tabelle di database, vedere Tecnica: Progettazione di bean di entità.
Se devono essere inclusi più componenti nello stesso archivio (vedere operazione:
Definizione dell'archivio), il provider di componenti di applicazione deve integrare le informazioni sul
descrittore di distribuzione. Ad esempio, quando si combinano EJB in un EJB-JAR, il provider di componenti di
applicazione deve conciliare le informazioni nei descrittori di distribuzione, come ruoli di sicurezza e riferimenti
incrociati.
Convalida dell'archivio
Potrebbe essere una buona idea quella di convalidare i contenuti dell'archivio prima di avviare la distribuzione,
poiché potrebbero esservi degli errori sconosciuti, specialmente sul lato server dell'applicazione, che daranno luogo a
messaggi di errore non esistente o sconosciuto. Ad esempio i nomi JNDI duplicati non possono essere utilizzati dai
componenti inseriti nell'archivio.
|