L'utilisation de Grails SessionBeans

14 mars 2010 par Alejandro Laisser une réponse »

¿SessionBeans et Grails?

Une des qualités de Grails que personnellement j'aime le plus est son intégration avec JEE. Puisque nous ne pouvons utiliser des balises Grails JSP, Session Beans et EntityBeans comme si elles faisaient partie intégrante du cadre.
Dans ce post nous allons nous concentrer sur la façon dont nous pouvons invoquer SessionBeans qu'ils soient locaux ou distants à partir de notre code de Grails. Cette possibilité, avec la gestion des EntityBeans Grails apporte à l'adaptabilité et l'évolutivité. Un je veux dire par cela, que d'être soignée, nous pouvons développer une application entière de Grails et puis, plus tard aller et modèles de services aux entités et SessionBeans respectivement. De cette façon, nous pouvons commencer à développer rapidement votre application en utilisant les avantages d'être dans un environnement dynamique et puis quand la demande est plus défini et les changements ne sont pas communs alors nous pouvons déplacer la couche d'affaires au JEE. Ce changement n'affecte pas une autre partie de Grails tels que les contrôleurs ou les vues.
Pour atteindre ce dernier on ne fait que remplacer le code d'opérations de services par délégation à la même opération sur le SessionBeans créé.

Puis nous verrons comment Grails est configuré pour utiliser les deux EJB3.0 SessionBeans que EJB2.1

Injection de la SessionBeans
Grails permet l'injection dans les services et dans tous les pilotes SB comme vous le faites avec vos services. Lorsque Grails utilise Spring dans la gestion de ses composantes est possible d'utiliser tous les avantages de ce sein Grails. La meilleure façon de mettre les objets à être injecté dans les pilotes ou des services, et surtout le SB, est d'utiliser le resources.groovy fichier. Ce fichier est équivalent au printemps applicationContext.xml seul fichier au lieu d'être un fichier XML est une classe qui utilise le groovy SpringBuilder que le DSL pour la configuration. Par défaut, le fichier de ressources dans grails-app/conf/spring et a le contenu suivant:

  / / Placez votre code ici Spring DSL
 fèves = {

 } 

Dans la fermeture est l'endroit où vous devez ajouter les définitions des haricots.

JNDI du serveur de configuration
Pour accéder à tout composant dans un serveur d'applications doit le faire en utilisant JNDI. Pour ce printemps fournit une classe utilitaire qui fournit un serveur telles que les opérations de recherche de nom JNDI et il agit également comme un fournisseur de contexte JNDI. Pour cela il faut ajouter la définition suivante dans resources.groovy

	 ejbJndi (org.springframework.jndi.JndiTemplate) {environnement = ["java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory", "java.naming.provider.url", "JNP: / / http : / / localhost: 1099 

Où:

  • ejbJndi
Le nom de la fève qui est de type org.springframework.jndi.JndiTemplate. Ce nom peut être n'importe quoi. C'est ce nom qui sera référencé pour déterminer le nom du serveur qui permet d'accéder à un objet.
  • l'environnement
JndiTempalte est la propriété de ce qui est configuré avec une carte qui a les propriétés JNDI

Dans un fichier peut être autant de définitions que les fournisseurs exigent l'accès JNDI JndiTemplate.

ENVIRONNEMENT JNDI configuration du serveur
Il est très probable et nécessaire, qui exige IP différente de configuration du serveur et le port JNDI comme environnement de développement, de production ou de test. Pour atteindre ce devrait être ajouté à la configuration précédente comme suit:

  • Placer la valeur de l'IP et le port de l'environnement JBoss dans chacune des Config.groovy.
  • Importer le type de fichier resources.groovy ConfigurationHolder
  • Remplacez l'adresse IP et le port de la variable "java.naming.provider.url" facturés par la configuration.

Exemple
Config.groovy

  ...
   environnements {
     {Développement
         ...
         jboss.ip = "10.200.8.173"
         jboss.port = "1099"
         ...
     }
     {la production
         ...
         jboss.ip = "172.16.2.105"
         jboss.port = "1099"
         ...
     } 

Resources.groovy

  l'importation org.codehaus.groovy.grails.commons .*
      ...
	 ejbJndi (org.springframework.jndi.JndiTemplate) {
		 l'environnement = [
			 "Java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory"
			 "Java.naming.provider.url", "JNP ://"+ +":"+ ConfigurationHolder.config.jboss.ip ConfigurationHolder.config.jboss.port]
	 } 

Configuration des composants EJB 3.0
Pour injecter des composants EJB 3.0 ont d'ajouter la configuration suivante:

  xXXServices (org.springframework.jndi.JndiObjectFactoryBean) {
		 jndiName = "XXXServices / remote»
		 jndiTemplate = ref ("ejbJndi")
	 } 

Où:

  • xXXServices
Est-ce le nom que vous donner la référence à distance à la SB et sera utilisé pour injecter ce dans les pilotes et les services. Tout conducteur ou un service qui a une propriété nommée est xXXServices injecter la référence à la distance définie par SB ce nom dans la resources.groovy fichier. Le premier est x minuscules pour indiquer que, par convention, le nom doit commencer en minuscules.
  • jndiName
Nom par lequel de localiser la référence à la SB JNDI du serveur
  • jndiTemplate
Nom de la fève à être utilisé comme un fournisseur d'accès à l'objet JNDI. Est défini dans la section précédente.

Pour utiliser le SB dans un service serait:

  EjemploServices {public class
	 def xXXServices

	 unMetodo void (param1, param2) {
		 xXXServices.invocoMetodoEnEJB (param1, param 2)
	 }
 } 

Configuration des composants EJB 2.1
Afin d'injecter des composants EJB 2.1 ont d'ajouter la configuration suivante est similaire à celle observée pour les EJB 3.0.

  xXXServices (org.springframework.ejb.access.SimpleRemoteStatelessSessionProxyFactoryBean) {
		 jndiName = "EJBXXXServices"
		 businessInterface = "biz.aquait.yyy.ejb.EJBXXXServices"
		 jndiTemplate = ref ("ejbJndi")
		 refreshHomeOnConnectFailure = true
                 lookupHomeOnStartup = false

	 } 

Où:

  • xXXServices
Est-ce le nom que vous donner la référence à distance à la SB et sera utilisé pour injecter ce dans les pilotes et les services. Tout conducteur ou un service qui a une propriété portant ce nom est xXXServices injecter la référence à la distance définie par SB ce nom dans la resources.groovy fichier. Le premier est x minuscules pour indiquer que, par convention, le nom doit commencer en minuscules.
  • jndiName
Nom par lequel de localiser la référence à la SB JNDI du serveur
  • refreshHomeOnConnectFailure
Actualiser la maison quand il détecte un échec de connexion, par exemple lorsque le serveur redémarre
  • lookupHomeOnStartup
Il rend l'application ne fait pas le lookup d'augmenter, mais à utiliser les services de SB.
  • jndiTemplate
Nom de la fève à être utilisé comme un fournisseur d'accès à l'objet JNDI. Est défini dans le premier point.
  • businessInterface
L'interface distante du SB, c'est à dire qui s'étend EDBObject.

Comment utiliser le SB au sein d'un service ou autre composante est de la même manière que les références aux SB en œuvre avec EJB 3.0.

Conclusion

En suivant les étapes présentées ci-dessus nous pouvons dire que SB configurer Grails à utiliser est lourde et que l'utilisation de ces derniers dans le cadre est transparent et utilisé de la même manière qu'un service de Grails.

Blogger message Digg Reddit Google Reader Partager
Publicité

2 commentaires

  1. josem dit:

    SessionBeans Un projet pourrait être déployé dans un conteneur Web comme Tomcat? ou serait-il nécessaire d'utiliser un serveur d'application GlassFish, comme? :)

    Good post

  2. Alejandro dit:

    Le SB statefull ou apatride soit besoin d'un conteneur d'EJB et doivent donc être exécutées dans un serveur d'applications telles que GlassFish ou Jboss. Sur le Tomcat autre part est juste un serveur web et en tant que telle a un conteneur Web dans lequel les composants des pages Web déployeur Pode tels que JSP, JSF et servlets.
    Si pour quelque raison ne voulez pas avoir votre application s'exécute dans un serveur d'applications Grails pourrait avoir une architecture distribuée. Cela aurait une application Web qui utilise Tomcat à distance dans le BS qui sont dans un serveur d'application installé sur une autre machine.

Laisser un commentaire

Protection contre les spams par WP Captcha-Free