2010-10-21 10 views
2

Salut Je veux concevoir et développer une grande application d'entreprise en utilisant seulement GWT côté client. Je veux diviser cette application d'entreprise en parties et j'appelle chaque un module (ou un paquet ou un portlet ou autre!). Ces modules peuvent avoir des relations les uns avec les autres et appeler certains services existant dans d'autres modules (côté client et côté serveur).Comment développer une application d'entreprise modulaire en utilisant seulement GWT

Le problème est, ces modules doivent être Designed, Développé, Compilé et Déployé Indépendamment et Dynamiquement et ils seront placés et Affichée dans un contexte sur le client et la les dépendances entre les modules doivent être gérables (côté client et côté serveur).

Que puis-je faire? Quel type de technologies puis-je utiliser pour créer une application d'entreprise comme celle-ci? Lorsque vous développez une application qui n'est pas divisée en parties (De la manière que j'ai mentionnée), vous pouvez facilement déployer votre application après la construction de votre projet, mais lorsque vous modifiez un seul formulaire dans votre application, vous devez construire l'ensemble application à nouveau, et déployer l'ensemble de l'application.

Dans cette application, je ne peux pas arrêter le serveur pour déployer à nouveau l'application, je veux changer et déployer la partie de l'application qui doit être changée, pas toute l'application !!!

Bien sûr, j'ai cherché sur la façon dont je peux résoudre mon problème !!! J'ai trouvé que je peux utiliser OSGI côté serveur car il offre une modularité au niveau de la construction logicielle et m'aide à gérer le cycle de vie des modules et bien d'autres avantages que vous connaissez! Et j'ai trouvé que je peux utiliser des gadgets sur le côté client.

Qu'en pensez-vous? Sont-ils de bons choix?

Si ce sont de bons choix, comment puis-je commencer? Je sais que nous avons différents types d'implémentations d'OSGi, comme Apache Felix, Eclipse Equinox et Knopflerfish. Lequel est bon pour ce choix?

Comment GWT et OSGi peuvent être intégrés? Comment peuvent-ils interagir les uns avec les autres?

Répondre

2

Je l'ai fait il y a deux ans: OSGi et GWT pour aucun déploiement de modules de projet. Verdict: Ne le faites pas sauf si vous le devez vraiment. En bref, OSGi est une bête et l'adaptation d'une application existante pour elle est loin d'être trivial. Vous ne faites plus de fichiers .war (.ear now) et vous ne pouvez pas utiliser les fichiers jars standard et les référentiels Maven que vous utilisiez auparavant. Maintenant, tout doit être un paquet. Le problème, c'est que beaucoup de choses (GWT, Spring, tonnes de libs) ne sont pas des bundles! Et vous aurez besoin de les trouver dans un référentiel de bundles d'entreprise ou, encore plus amusant, de commencer à les recompiler de sources tierces. Mieux encore, dire aux autres développeurs de réécrire tout ce qui utilise leur lib préférée parce que le regrouper serait trop complexe.

La partie GWT n'a pas pris beaucoup de travail. La façon dont les contextes pour les modules étaient gérés dans gwt-servlet devait être modifiée afin que chaque module puisse trouver son contexte sur le serveur. Nous avons également dû faire en sorte que la plupart des services GWT puissent s'enregistrer/se désinscrire en charge et un service de découverte afin qu'ils puissent savoir qui d'autre était là.

Maintenant l'autre douleur: explosion du projet. Supposons que vous disposiez de 20 modules que vous vouliez déployer indépendamment. Eh bien, pour commencer, ils sont probablement plus couplés que vous le souhaitez, alors mieux vaut passer quelques semaines à les briser dans des projets Maven indépendants et à pousser des parties communes vers un projet lib. Mais maintenant, vous avez des tonnes de dépendances à suivre. Quand quelqu'un modifie votre projet lib, avez-vous besoin de mettre à jour chaque projet ou seulement 7 d'entre eux? Dans le classique arrêter le déploiement du monde, vous avez seulement eu une version de tout votre code. Maintenant, vous devez décider si le formulaire de mot de passe oublié en cours de mise à niveau vous obligera à mettre à jour votre module de page d'index. Vous aurez une tonne de numéros de version à composer et à suivre. Dans notre cas, nous avons rapidement eu 55 projets Maven construisant tout le temps sur notre serveur CI. Cela signifiait que certains checkins pouvaient déclencher 55 builds. Eek.

Enfin, interfaces JSON.

Nous avons utilisé GWT RPC. C'est magique. Ecrire une interface et tout fonctionne.Il est également sérialisé et gzipped sur le fil aussi. Impressionnant. Cependant, les stratégies de sérialisation dépendent des tables de recherche d'objets et de chaînes construites au moment de la compilation par module. Ainsi, le projet A ne peut pas RPC de projeter B. Boo. Nous avons choisi d'utiliser JSON en raison de la dégradation gracieuse, qui n'échoue pas lorsque de nouvelles propriétés non reconnues sont présentes sur les objets. Cela signifie que vous aurez à nouveau besoin d'un moyen de garder tous les appels de service backend cohérents dans les versions du JSON qu'ils attendent et peuvent gérer. Mieux simuler cette mise à niveau en direct à l'avance aussi.

Donc, dernier mot: possible, mais pourquoi? Avez-vous vraiment besoin d'OSGi pour déployer à chaud les modules parce que vous utilisez une application critique à 1000% de disponibilité? Ou votre patron/architecte refuse-t-il simplement d'accepter que 99,999% est suffisant? Vous n'avez probablement pas besoin de cette disponibilité et vous pouvez atteindre une disponibilité de près de 100% avec un bon proxy pour vous permettre de prendre des instances dans/hors du pool d'équilibreurs. Aussi, n'oubliez pas que même si vous pouvez mettre à jour vos projets en direct, j'espère que vous avez un moyen de mettre à jour votre base de données à la volée sans perdre une seule transaction.

4

Malheureusement, ce que vous voulez faire n'est pas entièrement possible avec GWT.

OSGi est une solution modulaire pour Java, ou plus précisément la JVM. Une application client GWT ne s'exécute pas sur la machine virtuelle Java, elle s'exécute sur le navigateur dans un environnement JavaScript. Par conséquent, OSGi ne peut pas être utilisé pour créer des applications GWT modulaires assemblées à l'exécution.

Une application GWT peut être être modulaire au niveau de la source, mais les modules doivent être assemblés dans une application au moment de la construction. L'exécution qui en résulte est monolithique.

Cependant, il est parfaitement possible d'utiliser OSGi pour héberger les servlets GWT, et vous pouvez utiliser toute la puissance de la modularité d'exécution OSGi côté serveur.

Comme alternative, vous pouvez regarder Vaadin.C'est un framework Web qui utilise GWT pour fournir des widgets, mais la logique de l'application s'exécute sur le serveur. Par conséquent, il prend en charge la modularité d'exécution complète via les bundles OSGi. Il y a cependant un coût avec cette approche: votre application web est assez bavarde, avec beaucoup plus de communication entre le navigateur et le serveur que dans GWT ou dans une application web traditionnelle. Il est possible que cette approche ne s'adapte pas à un très grand nombre d'utilisateurs. En ce qui concerne l'utilisation d'Equinox, Felix ou Knopflerfish ... cela n'a pas vraiment d'importance. Stick à la spécification, et vous pouvez facilement basculer entre les implémentations.

+0

Merci pour votre réponse. – Heidarzadeh

+0

Je sais que OSGi est juste applicable du côté serveur! Je pense que mon gros problème sera du côté client, avoir un conteneur comme un conteneur de gadget du côté client sera si difficile pour moi. Maintenant, toutes les parties de cette application sont liées ensemble du côté client et je ne peux pas ouvrir cette cravate !! compiler et déployer différentes parties de cette application séparément !!! – Heidarzadeh

1

Je pense que vous vous préparez pour plus de maux de tête que cela en vaut la peine.
Je voudrais aller déployer le tout à une pop. Sinon, vous vous retrouverez avec des pièces incompatibles de l'application qui ne sont pas synchronisés les uns avec les autres. GWT a des composants client et serveur et ils doivent être déployés ensemble. Si vous avez une politique de temps d'arrêt nul alors vous avez probablement l'équilibrage de charge en place.
J'utiliserais le logiciel d'équilibrage de charge pour déployer la nouvelle version de l'application. Éteignez un côté (en détournant tout le trafic vers l'autre côté), déployez-le, effectuez un test de fumée rapide, changez tout le trafic vers le nouveau côté et répétez avec l'ancien côté.

+0

Merci pour votre réponse. Je pense que l'équilibrage de charge a ses propres préoccupations et que je pourrais avoir d'autres problèmes. De cette façon, compiler le temps, cela prend du temps et je dois reconstruire l'application entière. Il y a beaucoup de clients et je dois copier l'application entière pour tous ces clients et j'aurai des problèmes de bande passante. Quand je compile le projet c'est environ 400MB et pour un petit problème je dois copier tous les fichiers !! – Heidarzadeh

+0

Bien sûr, je peux éviter de recopier les bibliothèques tierces que j'ai utilisées côté serveur, mais encore une fois cela prend du temps. Rappelez-vous, c'est une grande application d'entreprise avec beaucoup de clients !!! Mais si je trouve un moyen de compiler et déployer mon application, partiellement. Je veux dire séparément pour chaque module, ce serait une bonne solution !!! – Heidarzadeh

+0

Vous pouvez toujours séparer votre contenu statique et le mettre sur un serveur Web propre. Cela aide avec le temps de chargement. –

Questions connexes