Nouvelles fonctionnalités dans JCA 1.6

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 :

			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.

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

			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.

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.

			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.

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.

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.

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é.

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 :

				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.

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 :

				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.

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