Si l’intérêt d’utiliser BlazeDS pour faire communiquer une application Flex avec des services distants n’est plus à prouver, il en résulte souvent un manque d’interopérabilité des services.

Dans le cas d’une application qui pourrait avoir des interfaces multiples (web, ajax, swing etc …) il est alors préférable d’utiliser des services de type SOAP ou REST. On peut par exemple imaginer une application Air et une application pour iPhone développée en Cocoa qui accèdent au même applicatif serveur et qui partagent la même session hibernate. Une solution simple serait alors de dupliquer les classes de services, mais cela engendrera par exemple la duplication de la connexion à la base de donnée. L’utilisation de Spring peut alors grandement nous faciliter la tâche, en effet il est possible de partager un contexte entre servlet et donc de n’accéder qu’à une seule instance que ce soit par Axis2 ou BlazeDS.

1) Création du projet

Nous n’utiliserons ici qu’un seul et même projet, pour ceux qui connaissent Spring cette partie ne devrait pas poser de problème :

DaoFactory :

Ici on récupère le context parent avec parentContextRef.getFactory()

public class DaoFactory {

private static ApplicationContext appctx= null;

static {

try {

String locatorFactorySelector = « serviceContext.xml »;

String parentContextKey = « serviceContext »;

BeanFactoryLocator locator = ContextSingletonBeanFactoryLocator.getInstance(locatorFactorySelector);

BeanFactoryReference parentContextRef = locator.useBeanFactory(parentContextKey);

appctx = (ApplicationContext) parentContextRef.getFactory();

} catch (Exception e) {

e.printStackTrace();

}

}

public Object getBean(String name){

return appctx.getBean(name);

}

}

AppFactory :

public class AppFactory {

private static DaoFactory dao;

public static DaoFactory getDao()

{

if (dao == null)

dao = new DaoFactory();

return dao;

}

}

2) Web.xml

Il va maintenant être nécessaire d’ajouter quelques lignes dans les fichiers web.xml de BlazeDS et d’Axis2 :

<listener><listener-class>org.springframework.web.context.ContextLoaderListener</listener-class></listener><context-param><param-name>contextConfigLocation</param-name><param-value> </param-value></context-param><context-param><param-name>locatorFactorySelector</param-name><param-value>classpath:serviceContext.xml</param-value></context-param><context-param><param-name>parentContextKey</param-name><param-value>serviceContext</param-value></context-param>

On assigne la valeur serviceContext à parentContextKey que l’on va définir dans notre fichier serviceContext.xml. C’est ici que Spring va récupérer le context d’exécution en cours. Si le context parent n’existe pas il sera alors automatiquement créé.

3) applicationContext.xml et serviceContext.xml

Pour ceux qui connaissent Spring , déclarez votre applicationContext.xml comme à l’habitude. Pour les autres IDE, de bons tutoriels sont disponibles sur le net.Le fichier serviceContext.xml sera défini de la manière suivante :

<beans>

<bean id= »serviceContext » class= »org.springframework.context.support.ClassPathXmlApplicationContext »>

<constructor-arg>

<list>

<value>applicationContext.xml</value>

</list>

</constructor-arg>

</bean>

</beans>

4) Déploiement

Grâce à Ant nous allons pouvoir déployer tout l’ensemble assez facilement. Les services Axis ne contiendront que les class Axis2Service, DAOFactory, AppFactory et le fichier serviceContext.xml qui se trouvera dans le classpath d’Axis2. Pour BlazeDS nous procédons de la même manière , seul les class de BlazeDSService, DAOFactory, AppFactory et le fichier serviceContext.xml sont déployés dans les répertoires WEB-INF/classes. Les beans seront quand à eux mis dans un .jar qu’on placera dans le répertoire lib de Tomcat. De cette manière BlazeDS et Axis2 y auront accès de la même manière. On pourrait très bien disposer ce .jar ailleurs dans l’arborescence, cela serait surement plus propre mais nécessite un peu plus de configuration et ce n’est pas l’objet de cet article.Un fichier build.xml vaut mieux qu’un long discours ! En voici un que j’ai fait juste pour cet article, il devrait permettre à ceux qui connaissent un peu, de comprendre à quoi va ressembler le tout une fois déployé.

<project name=« BlazeDSAxis2″ basedir=« . » default=« generate.service »>

<property environment=« env »/>

<property name=« TOMCAT_HOME » value=« /Users/home/j2ee/apache-tomcat-6.0.18″/>

<property name=« AXIS2_HOME » value=« /Users/home/j2ee/apache-tomcat-6.0.18/webapps/axis2/WEB-INF »/>

<property name=« BLAZEDS_HOME » value=« /Users/home/j2ee/apache-tomcat-6.0.18/webapps/blazeds/WEB-INF »/>

<property name=« build.dir » value=« build »/>

<path id=« tomcat.classpath »>

<fileset dir=« ${AXIS2_HOME}/lib »>

<include name=« *.jar »/>

</fileset>

<fileset dir=« ${TOMCAT_HOME}/lib »>

<include name=« *.jar »/>

</fileset>

<fileset dir=« ${BLAZEDS_HOME}/lib »>

<include name=« *.jar »/>

</fileset>

</path>

<target name=« compile.service » >

<mkdir dir=« ${build.dir} »/>

<mkdir dir=« ${build.dir}/classes »/>

<!–First let’s compile the classes–>

<javac debug=« on »

fork=« true »

destdir=« ${build.dir}/classes »

srcdir=« ${basedir}/src »

classpathref=« tomcat.classpath »>

</javac>

</target>

<target name=« clean »>

<delete dir=« ${build.dir} »/>

</target>

<!– generate WSDL –>

<target name=« generate.wsdl »>

<taskdef name=« java2wsdl »

classname=« org.apache.ws.java2wsdl.Java2WSDLTask »

classpathref=« tomcat.classpath »/>

<java2wsdl className=« services.Axis2Service »

outputLocation=« ${build.dir} »

targetNamespace=« http://www.matisya.eu »

schemaTargetNamespace=« http://www.matsiya.eu/xsd »>

<classpath>

<pathelement path=« ${tomcat.classpath} »/>

<pathelement location=« ${build.dir}/classes »/>

<pathelement location=« ${basedir}/ressources/META-INF/services.xml »/>

</classpath>

</java2wsdl>

</target>

<target name=« generate.service » depends=« clean, compile.service, generate.wsdl »>

<copy toDir=« ${build.dir}/classes »>

<fileset dir=« ${basedir}/resources/META-INF »/>

</copy>

<!– jar beans –>

<jar destfile=« ${TOMCAT_HOME}/lib/MyApp.jar »>

<fileset dir=« ${build.dir}/classes »>

<exclude name=« services/*.* »/>

<exclude name=« serviceContext.xml »/>

<exclude name=« services.xml »/>

<exclude name=« core/* »/>

</fileset>

</jar>

<!– copy each service –>

<!– BLAZE DS –>

<copy toDir=« ${BLAZEDS_HOME}/classes »>

<fileset dir=« ${build.dir}/classes »>

<!– include your services here –>

<include name=« services/BlazeDSService.class »/>

<include name=« core/*.* »/>

</fileset>

<fileset dir=« ${basedir}/resources/META-INF »>

<include name=« serviceContext.xml »/>

</fileset>

</copy>

<!– AXIS 2 : aar service up –>

<jar destfile=« ${AXIS2_HOME}/services/MysService.aar »>

<fileset dir=« ${build.dir}/classes »>

<!– include you services here –>

<include name=« services/Axis2Service.class »/>

<include name=« core/*.* »/>

</fileset>

<fileset dir=« ${basedir}/resources/ »>

<include name=« **/services.xml »/>

</fileset>

</jar>

<!– copy contextServices to AXIS2/classes –>

<copy toDir=« ${AXIS2_HOME}/classes »>

<fileset dir=« ${basedir}/resources/META-INF »>

<include name=« serviceContext.xml »/>

</fileset>

</copy>

</target>

</project>

Articles sur le même sujet :

1. BlazeDS ………Open source……….Adobe…………. :-)
2. Magento e-commerce : Flash, Flex et AIR
3. Attention au travail collaboratif avec les modules flex

Dans la plupart des tutoriaux présents sur le net Zend AMF est utilisé pour un nombre très restreint de services et de classes. Les performances pour des petits projets restent acceptables cependant pour des projets nécessitant le chargement de beaucoup de VOs et de services les temps de réponse chutent considérablement. Ceci est tout simplement du au fait qu’à chaque requête le framework refait l’introspection des services et réimporte toutes les class.

Pour remédier à ce problème, nous avons modifié Zend AMF afin qu’il soit derrière une socket UNIX, Flex se connecte donc au enpoint qui va envoyer la requête à la class Server de Zend à travers la socket. Le endpoint attend une réponse du Server et affiche le résultat. Il n’y a donc plus d’introspection, une seule et même instance de l’AMF Server est utilisée.
Grâce à cette technique nous avons réussi à obtenir des gains de performance allant de 2000 à 3500 % , les temps de réponse sur des gros projets pouvant être divisés par plus de 30. (17 millisecondes en local pour récupérer 300 enregistrements dans un projet qui compte une trentaine de class). Des temps inférieurs à ceux qu’on enregistre avec BlazeDS et largement inférieurs à ceux enregistrés avec AMFPHP !!

On utilise déjà cette solution sur plusieurs projets et le gain côté utilisateur est assez bluffant. Bien évidemment cette solution ne fonctionne pas sur les serveurs mutualisés mais on trouve aujourd’hui des serveurs virtualisés très bon marché.

Articles sur le même sujet :

1. Réponse GZipée dans Zend AMF
2. Zend Framework 1.7.0 / AMF support (Zend_Amf)
3. Matsiya a la zend amf attitude

Nous vous parlions il y a quelques temps de la mise à disposition en open source de Blaze DS, ce dernier permettant des choses qui n’était alors disponibles que dans LiveCycle ES.

Et bien voici un comparatif entre ces deux serveurs, permettant d’y voir un peu plus clair sur les différences et les points communs qui les composent.

Accéder au comparatif.

Articles sur le même sujet :

1. Zend AMF et socket UNIX