| french | english |
 |
|
| Créer un compte | |
| 21-02-09 / 17:10 : Web 3.0/MVC client/serveur non J2EE (cjed) |
| Après GWT, Cappuccino ouvre la voie au web 3.0. Les bibliothèques de taglibs JSPs (RIA web 2.0) sont dépassées (JSF RichFaces, ADF, etc.), la version 2.0 de JSF annoncée récemment n'étant qu'une (légère) évolution. Les applications RDA (RWA si le container est un navigateur) accèdent donc directement à la couche services (applicatifs et/ou métiers, selon les besoins de workflow et de gestion transactionnelle) du serveur, la couche présentation (MVC) étant déportée sur le client (MVC de l'AppKit de Next/Cocoa pour Cappuccino). Les appels se font au travers d'un bridge, un objet proxy, qui est soit généré spécifiquement pour un service (cas de GWT), soit générique et dynamique - cas de CP2JavaWS (utilise la méthode forwardInvocation du runtime Objective-J, en l'absence pour le moment d'un équivalent de la classe NSProxy. Ces mécanismes sont bien plus puissants que les dynamic proxies de Java, limités et lourds à mettre en oeuvre). Côté serveur plus aucune servlet n'est nécessaire, l'interception peut se faire au moyen d'un simple filtre de servlet (sur le lequel on peut également préciser le mapping d'url), solution utilisée pour la partie serveur de CP2JavaWS. L'intérêt est qu'on n'impose ainsi plus d'adhérence (critique de Struts pour lequel on devait dériver d'une super-classe, ActionServlet). Ainsi les filtres peuvent être comparés aux interfaces. On peut alors si besoin déclarer des servlets pour des technologies classiques (Struts, Spring MVC), et y associer le filtre de CP2JavaWS par exemple. Ce dernier repère si une requête ne lui est pas destinée, et délègue alors le traitement au reste de la chaîne (filtres suivants, puis servlet MVC classique). On dispose alors d'une application unique pouvant être appelée depuis des clients classiques (interfaces issues du rendu de taglibs côté serveur) et également depuis des applications RDA (basées sur du dom/javascript comme Cappuccino). Cette solution peut aussi faciliter les opérations de migration et/ou de maintenance. Le choix d'un serveur J2EE réside alors beaucoup moins dans son container de servlet/jsp (plus de jsp) que dans ses divers connecteurs (JDBC, JCA, files de messages asynchrones). Reste la gestion des sessions, mais cela aussi pourrait être implémenté dans une autre technologie (partie serveur en Objective-C par exemple, sujet déjà évoqué par les membres de Cappuccino). Quant au format des échanges, JSON semble le mieux placé (répandu et simple), bien qu'il ne propose pas la gestion de namespaces ni des cycles (doivent être gérés par des champs propriétaires/non standards, cas de CP2javaWS). En fait ce format, qui n'est qu'une représentation textuelle d'une grappe d'objets javascript (la conversion est d'ailleurs possible en faisant un eval() d'une chaîne), n'a pas été prévu pour gérer des messages complexes avec contrats (pour cela on préfèrait jusqu'à présent WSDL et SOAP). Dans la documentation de CP2JavaWS j'évoquais quelques recherches/trheads au sujet des limitations et évolutions possibles de JSON. Mais la simplicité de développement permise par l'utilisation de Cappuccino et d'un bridge comme CP2JavaWS compensent largement l'absence d'un format complet et d'un contrat. De plus CP2JavaWS gère déjà les collections de types hétérogènes et imbriquées (et bientôt les cycles), et lorsque la méthode methodSignatureForSelector sera implémentée dans Cappuccino, il sera possible de vérifier les paramètres passés auprès d'un contrat (protocole/interface Objective-J précisé lors de la récupération du proxy). |
| Commentaires |
| Poster un commentaire |