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>

Aucun d'article en relation

Si inclure une animation flash dans magento est relativement simple, la faire communiquer avec les services existants l’est nettement moins. En effet magento fournit une API basée sur le prorocol SOAP peu respectueuse des conventions et Flex/Flash n’aime pas ça …. Nous avons donc du modifier le SDK de flex afin de pouvoir utiliser simplement les services disponibles. Bien qu’il soit possible d’en créer des nouveaux, ces services sont mal adaptés à une interface de type RIA et les taux de transfert sont très faibles.

Nous avons donc décidé de prendre la voie de l’AMF, bien plus rapide et permettant le chargement de plus gros volumes de données. Magento étant basé sur Zend framework , nous avons utilisé Zend AMF présent dans la version 1.7 (possibilité de l’inclure dans des versions antérieures) et après quelques modifications de Zend AMF, nous avons réussi à exposer la totalité des méthodes de l’API existante en AMF. Il reste quelques points à régler (gestion des droits ACL de zend par exemple) pour fournir un framework installable et utilisable en quelques clicks mais il est déjà possible de développer des modules Flash/Flex pour l’administration ou pour le catalogue de vos sites e-commerce Magento.

Aucun d'article en relation

Ruby on Rails permet de construire des webservices SOAP en quelques lignes. Mais ruby étant un langage dynamique, il faudra alors définir les types manuellement pour les entrées et les sorties. Côté flex pas de problème pour récupérer les types simples comme String , interger, datetime etc … Mais comment récupérer un objet plus complexe ?

Dans le post précédent on a introduit SchemaTypeRegistry qui permet de récupérer des objets personnalisés côté Flex; aucun problème pour des services écrits en java ou c#, ces langages n’étant pas dynamiques les objets seront bien définis dans le wsdl et Flex les comprendra sans problème. En revanche imaginons que l’on ait un model User en ruby qui pointe vers la table users. En retournant cet objet dans le SOAP flex sera incapable de le comprendre , aucune de ses proriétées n’étant explicitement définies.

Il existe pourtant une solution à ce problème : ActionWebService::Struct. En définissant un model héritant de cette class on va pouvoir construire un « emballage » de notre model de base et y définir ses propriétés. Exemple pour un model User :

On définit le model UserStruct < ActionWebService::Struct et on y ajoute les propriétés :

class UserStruct


member :name, :string
member :pass, :string

end

et dans notre class d’api on spécifie le retour comme :

:returns => [{:answer => UserStruct}]

Ruby étant totalement dynamique on peut directement renvoyer un objet User dans le controller, celui-ci sera automatiquement transormé en UserStruct. Exemple d’une méthode dans le controller :

def getUser(id)

User.find(id)

end

L’objet reçu sera alors de type userstruct (en minuscules dans le xml) et contiendra toutes les valeurs de User pour peu qu’elles aient été bien définies.
Enfin pour plus de lisibilité rien n’empêche de nommer son objet ‘User’ aussi côté flex et de spécifier le changement de nom dans SchemaTypeRegistry (voir post précédent).

Aucun d'article en relation

Une nouveauté de Flex 3 qui est passé inaperçue c’est la possibilité de recevoir des objets fortement typés depuis un service SOAP comme on pourrait le faire via le protocole AMF. Tout se fait dans la class singleton SchemaTypeRegistry. Il suffit de lui fournir le nom de l’objet reçu , son namespace dans l’enveloppe SOAP et la class de destination. Un petit exemple vaut mieux qu’un long discours : Imaginons que l’on veuille maper un objet user ayant pour namespace « http://www.matsiya.fr/user » vers une class User il suffira d’ajouter dans l’application (le mapping concernera alors tous les services) :

SchemaTypeRegistry.getInstance().registerClass(new QName("http://www.matsiya.fr/user", "user"), User);

Il est aussi tout à fait possible de définir le SchemaTypeRegistry pour une opération donnée en le spécifiant au XMLDecoder :

var sr:SchemaTypeRegistry = new SchemaTypeRegistry(); sr.registerClass(new QName("http://www.mastiya.fr/user", "user"), User);op.decoder.typeRegistry = sr; //op étant notre opérationEtrange qu’adobe ne communique pas plus à ce sujet, la doc est quasi inexistante pour cette fonctionnalité et surtout tout ce qui touche au XMLDecoder. Malheureusement cette technique n’est utilisable que pour les services de type SOAP, à ma connaissance il n’est pas possible de forcer le décodage d’un XML externe ou résultant d’un service REST via le XMLDecoder.

Aucun d'article en relation