IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Nouvelles fonctionnalités dans JCA 1.6

L'édition Java Enterprise Édition 6 inclut une version mise à jour de la spécification Java EE Connector Architecture qui améliore le standard sur de nombreux points.


La spécification Java EE Connector Architecture (JCA) définit une architecture standard pour connecter la plateforme Java EE de manière hétérogène au Système d'information de l'entreprise (SIE). Des exemples de SIE inclut Enterprise Resource Planning (ERP), mainframe transaction processing (TP), base de données et les systèmes de messagerie.


La spécification Java EE Connector Architecture 1.6 a été développée via la Java Community Process (JCP) umbrella du nom de JSR-322 et est inclus dans le profile complet (full profile) de la spécification Java EE 6.


Dans cet article, nous allons faire le tour de la nouvelle spécification Java EE Connector Architecture et voir comment nous pouvons vous préparer à développer vos adapteurs de ressource avec le projet JBoss JCA.


?

Article lu   fois.

L'auteur

Profil ProSite personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Qu'avons-nous de nouveau dans JCA 1.6 ?

La spécification Java EE Connector Architecture 1.6 est compatible avec les anciennes versions de la spécification de la JCA qui ajoutent de nouveaux domaines clés à la spécification.

La spécification a été mise à jour dans les domaines suivants :

  1. Facilité de développement
  2. Générique WorkContext
  3. Sécurité InFlow
  4. Autres évolutions

Dans les sections suivantes, nous allons faire un rapide tour sur les nouveautés et rapidement décrire leurs évolutions.

I-A. Facilité de développement

Un des objectifs majeurs de la spécification Java Enterprise Édition 5 a été d'utiliser les annotations dans le but de faciliter le développement de nombreuses technologies.

Appliquer les mêmes principes d'utilisation de la spécification Java EE Connector Architecture vous aidera au développement plus facile d'un adapteur de ressource, puisqu'il n'est plus nécessaire de spécifier un descripteur de déploiement META-INF/ra.xml.

Les développeurs peuvent maintenant utiliser les annotations suivantes :

  • @Connector
  • @AuthenticationMechanism
  • @SecurityPermission
  • @ConfigProperty
  • @ConnectionDefinitions / @ConnectionDefinition
  • @Activation
  • @AdministeredObject

...dans le but d'aider à minimiser le travail de chargement des metadata.

Un exemple d'une classe de type adapteur de ressource pourrait être :

 
Sélectionnez
			import javax.resource.spi.Connector;
			import javax.resource.spi.ConfigProperty;
			import javax.resource.spi.ResourceAdapter;
			 
			/**
			* My resource adapter
			*/
			@Connector
			public class MyResourceAdapter implements ResourceAdapter
			{
			@ConfigProperty(defaultValue="5")
			private Integer myIntegerProperty;
			 
			....
			}

La spécification autorise les développeurs à utiliser un petit fichier XML si les paramètres de configuration pour l'adaptateur de ressource peuvent être évolués pour la personne en charge du déploiement de l'archive.

I-B. Le générique WorkContext

La fonctionnalité du générique WorkContext est de fournir un chemin pour les adapteurs de ressource afin de propager l'information contextuelle de l'EIS pendant la livraison d'un message ou de la soumission d'un Work.

Cela permet au conteneur JCA de supporter soutenir de nouveaux flux de remise des messages et des programmes de livraison.

L'information contextuelle passe au travers en utilisant l'interface WorkContextProder qui spécifie le contexte supporté. Le standard supporte les trois contextes suivants :

  • TransactionContext
  • SecurityContext
  • HintsContext
 
Sélectionnez
			public interface WorkContextProvider extends Serializable
			{
			/**
			* Gets an instance of <code>WorkContexts</code> that needs to be used
			* by the <code>WorkManager</code> to set up the execution context while
			* executing a <code>Work</code> instance.
			*
			* @return a <code>List</code> of <code>WorkContext</code> instances.
			*/
			List<WorkContext> getWorkContexts();
			}

La TransactionContext négocie le contexte de transaction de l'opération, le SecurityContext (que nous allons voir dans la prochaine section) et le HintsContext qui autorise la propagation des conseils sur l'exécution, QoS ou d'autres propriétés sur le travail que nous aurons besoin de réaliser.

Par exemple, ceci permettra à un développeur de spécifier quelle instance de Work soumise pourra réaliser une tâche sur du long terme, et par conséquent autoriser les conteneurs JCA a exécuté l'instance dans le pool de thread qu'il maintient tel que les tâches.

I-C. La sécurité Inflow

La fonctionnalité SecurityContext a été ajoutée afin d'assurer la sécurité de bout en bout au niveau des applications lors de l'exécution d'une instance de travail ou de livrer un message à un point de terminaison.

Cela permet que le travail peut être exécuté dans le contexte de sécurité dans l'identité établie et pour la propagation d'un EIS au MessageEndPoint.

La fonctionnalité s'appuie sur le travail accompli dans le Java Authentication Service Provider Interface pour les conteneurs (JSR-196) qui utilise des rappels afin d'établir l'identité de l'appelant.

 
Sélectionnez
			package javax.resource.spi.work;
 
			import javax.security.auth.Subject;
			import javax.security.auth.callback.CallbackHandler;
			 
			public abstract class SecurityContext implements WorkContext
			{
			...
			 
			public abstract void setupSecurityContext(CallbackHandler handler,
			Subject executionSubject,
			Subject serviceSubject);

C'est réellement une nouvelle fonctionnalité clé de la spécification JCA car ça permettra une meilleure intégration de la sécurité d'information entre la plateforme Java EE et le SIE.

I-D. Autres évolutions

Il y a d'autres évolutions dans la spécification :

  • Il est possible de spécifier le niveau de support de transaction au temps d'exécution
  • Il y a une définition d'un gestionnaire de travail distribué
  • Les messages createMessageEndpoint() intègrent une valeur de timeout
  • La notion d'exceptions retryable a été introduite
  • Bean Validation (JSR-303) a été intégrée a autorisé la validation des propriétés
  • Classe de chargement sémantique a été clarifié

Et finalement, un container d'environnement standalone a été défini pour spécifier à l'environnement JCA son exécution à l'extérieur d'un serveur d'application. Voire plus dans les temps à venir.

II. Le conteneur JBoss JCA

Le projet JBoss JCA a pour but d'implémenter la spécification Java EE Connector Architecture 1.6 en utilisant une approche d'un Plain Old Java Object (POJO) léger tel qu'un conteneur puisse tourner sur n'importe quel kernel Java.

Le conteneur est une mise en place évoluée de POJOs qui pourront communiquer ensemble par de l'injection et par conséquent, ceci rendra simple la configuration du container qui sera fait au travers de fichiers XML.

Le projet JBoss JCA supporte deux types différents de kernels POJO : Le JBoss Microcontainer et le projet de kernel propriétaire appellent Fungal.

Ceci rend possible l'utilisation de container dans trois cas :

  1. Dans le serveur d'application JBoss
  2. Dans le container complet standlaone
  3. Dans une solution embarquée

Les sections suivantes vont décrire les buts les différents cas

II-A. Dans le serveur d'application JBoss

Le but principal du projet est d'inclure à l'intérieur du serveur d'application JBoss, l'implémentation du container JCA et ainsi de rendre possible les déploiements de la JCA 1.6 qui vont être intégré dans le profile complet de la Java Enterprise Édition 6.

L'intégration va utiliser le profile JBoss Microcontainer du projet comme le serveur d'application JBoss qui utilise ce kernel au sein de son architecture.

II-B. Le profil standalone

Le profile standalone implemente une partie de la spécification du "Standalone Container Environment" qui est définie dans le 3e chapitre section 5.

Cet environnement spécifie une plateforme JCA pour les communications sortantes (et il serait possible pour les communications entrantes ) pour lesquels des aspects de spécification ont été mandatés.

Pour faire simple vous aurez accès au dernier container sortant JCA et tous les services associés de JCA incluant les transactions,la sécurité et bean validation.

Il appartient à chaque vendeur de remplir les "blancs" par exemple le modèle de composant d'application, du noyau de l'environnement et des services complémentaires.

Le projet JBoss JCA utilise des POJOs comme modèle de composant d'application signifiant que vous allez écrire vos services avec des POJOs standard qui utiliseront le cycle de vie fournie par le noyau de l'environnement. Le projet a inclus un serveur web pour le web de base en fonction des capacités de gestion.

L'environnement standalone fournit une excellente base pour l'intégration du serveur d'application JBoss et pourra ainsi être testé à l'extérieur de l'environnement du serveur d'application avant d'être intégré.

II-C. Profil embarqué

Le projet existe aussi dans un profil embarqué qui autorise les développeurs à inclure le conteneur à l'intérieur de leur application.

Le profil est basé sur le profil standalone et permettrait ainsi de partager les mêmes fonctionnalités.

Afin de tester les adapteurs de ressource très facilement, le conteneur embarqué est intégré avec le projet ShringWrap, hébergé sur JBoss.org.

Le projet permet de facilement configurer des cas de test JUnit et d'assembler le programme en une archive d'adapteurs de ressource que vous souhaiteriez tester, comme :

 
Sélectionnez
				package org.jboss.jca.embedded.unit;
				
				import org.jboss.jca.embedded.EmbeddedJCA;
				import org.jboss.jca.embedded.rars.simple.MessageListener;
				import org.jboss.jca.embedded.rars.simple.TestActivationSpec;
				import org.jboss.jca.embedded.rars.simple.TestConnection;
				import org.jboss.jca.embedded.rars.simple.TestConnectionFactory;
				import org.jboss.jca.embedded.rars.simple.TestConnectionInterface;
				import org.jboss.jca.embedded.rars.simple.TestConnectionManager;
				import org.jboss.jca.embedded.rars.simple.TestManagedConnection;
				import org.jboss.jca.embedded.rars.simple.TestManagedConnectionFactory;
				import org.jboss.jca.embedded.rars.simple.TestResourceAdapter;
				
				import java.util.UUID;
				
				import org.jboss.logging.Logger;
				import org.jboss.shrinkwrap.api.Archives;
				import org.jboss.shrinkwrap.api.spec.JavaArchive;
				import org.jboss.shrinkwrap.api.spec.ResourceAdapterArchive;
				
				import org.junit.AfterClass;
				import org.junit.BeforeClass;
				import org.junit.Test;
				import static org.junit.Assert.*;
				
				/**
				 * Test cases for deploying resource adapter archives (.RAR)
				 * using ShrinkWrap
				 *
				 * @author <a href="mailto:jesper.pedersen@jboss.org">Jesper Pedersen</a>
				 * @version $Revision: $
				 */
				public class ShrinkWrapTestCase
				{
				
				   // --------------------------------------------------------------------------------||
				   // Class Members ------------------------------------------------------------------||
				   // --------------------------------------------------------------------------------||
				
				   private static Logger log = Logger.getLogger(ShrinkWrapTestCase.class);
				
				   /*
				    * Embedded
				    */
				   private static EmbeddedJCA embedded;
				
				   // --------------------------------------------------------------------------------||
				   // Tests --------------------------------------------------------------------------||
				   // --------------------------------------------------------------------------------||
				
				   /**
				    * Basic ShrinkWrap ResourceAdapterArchive test case
				    * @exception Throwable Thrown if case of an error
				    */
				   @Test
				   public void testBasic() throws Throwable
				   {
				      ResourceAdapterArchive raa =
				         Archives.create(UUID.randomUUID().toString() + ".rar", ResourceAdapterArchive.class);
				
				      JavaArchive ja = Archives.create(UUID.randomUUID().toString() + ".jar", JavaArchive.class);
				      ja.addClasses(MessageListener.class, TestActivationSpec.class, TestConnection.class,
				                    TestConnectionFactory.class, TestConnectionManager.class,
				                    TestConnectionInterface.class, TestManagedConnection.class,
				                    TestManagedConnectionFactory.class, TestResourceAdapter.class);
				
				      raa.addLibrary(ja);
				      raa.addManifestResource("simple.rar/META-INF/ra.xml", "ra.xml");
				
				      try
				      {
				         embedded.deploy(raa);
				
				         // Lookup ConnectionFactory and start making asserts
				      }
				      catch (Throwable t)
				      {
				         log.error(t.getMessage(), t);
				         fail(t.getMessage());
				      }
				      finally
				      {
				         embedded.undeploy(raa);
				      }
				   }
				
				   // --------------------------------------------------------------------------------||
				   // Lifecycle Methods --------------------------------------------------------------||
				   // --------------------------------------------------------------------------------||
				
				   /**
				    * Lifecycle start, before the suite is executed
				    * @throws Throwable throwable exception
				    */
				   @BeforeClass
				   public static void beforeClass() throws Throwable
				   {
				      // Create and set an embedded JCA instance
				      embedded = new EmbeddedJCA();
				
				      // Startup
				      embedded.startup();
				   }
				
				   /**
				    * Lifecycle stop, after the suite is executed
				    * @throws Throwable throwable exception
				    */
				   @AfterClass
				   public static void afterClass() throws Throwable
				   {
				      // Shutdown embedded
				      embedded.shutdown();
				
				      // Set embedded to null
				      embedded = null;
				   }
				}

...Qui déploie une simple archive d'un adapteur de ressource.

Tester les adaptateurs de ressource n'a jamais été aussi facile.

Dans les futures versions du container embarquées, il y aura aussi une intégration avec le projet Arquillian afin de rendre les tests plus faciles.

II-D. Outils pour l'usabilité

Le projet comprend une composante de validation des adaptateurs de ressources qui vont vérifier l'archive de l'adaptateur de ressources avec les règles de mise en œuvre définies dans la spécification. Le validateur affichera des règles qui ont été déclenchées pendant le démarrage du conteneur et - s'il est configuré - ne pas déploiera pas l'adaptateur.

Un exemple de la sortie console pourrait être :

 
Sélectionnez
				Severity: ERROR
				Section: 19.4.2
				Description: A ResourceAdapter must implement a "public int hashCode()" method.
				Code: com.mycompany.myproject.ResourceAdapterImpl
				
				Severity: ERROR
				Section: 19.4.2
				Description: A ResourceAdapter must implement a "public boolean equals(Object)" method.
				Code: com.mycompany.myproject.ResourceAdapterImpl

... Ce qui empêcherait le déploiement, mais donne au développeur toutes les informations pour savoir où trouver les choses que demande la spécification JCA.

Le validateur peut seulement être utilisé depuis la commande en ligne ou via une tache d'Ant d'Apache.

Le projet comprend également un générateur de code d'adaptateur de ressources qui fournit au développeur un squelette de code basé sur l'entrée déterminée de la ligne de commande ou par l'intermédiaire d'un fichier de configuration.

Le code généré fournira également des conseils sur où chercher dans la spécification des exigences de mise en oeuvre.

Il va de soi que le générateur supporte les diverses spécifications JCA ainsi que les différents types d'adaptateurs de ressources.

Le projet pourra aussi inclure des exemples d'implémentations d'adapteur de ressources qui vont aider les développeurs à démarrer tout autant qu'une partie de la documentation sera intégrée dans la prochaine sortie.

II-E. Les évolutions

Le projet JBoss JCA est toujours en quête de nouveau talent pour faire évoluer le projet. Les contributions peuvent venir de n'importe quelle forme, développement de fonctionnalité jusqu'au rapport de bugs qui aideront à faire évoluer la documentation.

Ainsi, libre a vous de rejoindre nos discussions sur le forum utilisateur développeur ou de venir sur le canal jboss-dev sur FreeNode

III. Qu'avons-nous vu

Dans cet article, nous avons vu succinctement la spécification de la Java EE Connector Architecture 1.6 incluse dans le profil complet de l'édition standard de la Java Entrerprise Édition 6

Nous avons vu comment les nouveaux domaines vont aider les développeurs avec la facilité d'utilisation et l'apport de puissantes nouvelles fonctionnalités pour contrôler le travail d'exécution et obtenir plus de sécurité dans le flux en utilisant les callbackhandlers.

Cet article est un article traduit dont l'article original fut écrit par Jesper Pedersen qui travaille en tant que développeur chez JBoss et avec Red Hat il gère le projet JCA JBoss et d'autres projets.

Aussi, il contribue en tant qu'expert du groupe pour la spécification Java EE Connector Architecture 1.6 (JSR-322).

IV. Remerciements

Je tiens à remercier l'auteur de cet article Jesper Pedersen pour les échanges que nous avons eus et son autorisation à la publication de la traduction française de son article que vous pouvez lire ici.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   



Copyright © 2010 Mike Francois. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.