On reparle de la MVM, comme Ludovicje pense que cette fonctionnalité est très importante.
En accélérant le démarrage des applications java et en réduisant la consommation mémoire cette fonctionnalité devrait favoriser le déploiement d’application java sur les postes clients.
Mais personnellement j’y vois un intérêt encore plus grand côté serveur!
Il est quasiment impossible de trouver un hébergement gratuit ou peu cher pour des applications java alors qu’il y en a pléthore pour PHP (c’est à mon sens un facteur important du succès de PHP). Avec la MVM il sera possible de mutualiser les ressources ce qui permettra, j’espère, de développer des offres d’hébergement java économique…
Monthly Archives: March 2005
Weblogic 8.1 + Struts
Vous développez avec cette combo?
Marre d’être obligé de redéployer votre webapp à cause d’une ClassCastException à chaque modification dans une action?
1 Tous ce que vous mettez dans la session doit être serializable. Mais ça vous le faites déjà, c’est une bonne pratique.
2 Il y a un bug dans weblogic 8.1 : le problème est décrit ici ainsi que la solution Il existe un patch qui sera intégré dans le futur sp5 à demander au support weblogic.
J’ai été impressionné par la réactivité du support Bea.
ThoughtWorks recrute ?
Je ne cherche pas à tomber dans la critique facile de Martin Fowler qui avec des ouvrages comme Refactoring ou Uml Distilled est un “guru” du développement. Mais son dernier billet ressemble bel et bien à une pub pour sa compagnie.
En même temps je suis entièrement d’accord avec son point vue. J’y vois même un facteur important de l’échec de pas mal de projet. On ne réussit pas un projet informatique avec une équipe peu chère (car ça veut souvent dire débutant ou peu compétent). A vouloir trop réduire les coûts des projets informatiques, ils finissent par durer bien plus longtemps qu’il ne devrait et le produit final est souvent médiocre et donc peu porteur de valeur ajouté.
L’autre facteur majeur d’échec est bien entendu la difficulté qu’ont les clients à définir leurs besoins, et encore plus à les définir dans une forme qui soit exploitatable par l’équipe projet. D’où la nécessité des méthodes agiles et des processus itératifs.
Recette pour un échec avec une SOA
Via Tim Bray
John Crupri nous explique que prendre des composants logiciels déjà existant et rajouter par dessus une couche de web services est une parfaite recette pour un échec dans la mise en place d’une architecture orientée service.
En effets ces composants n’ont certainement pas été conçus dans le cadre d’une SOA. Il y a donc peut de chance qu’ils soient atomiques, indépendents d’autres composants, et conçus avec une granunalirité les rendant réutilisables dans le cadre d’une SOA.
Bien que l’approche bottom-up (partir de l’existant pour construire une SOA) soit la plus naturelle et la plus simple. Il ne semble pas que soit la bonne approche. Il vaut mieux adopter un approche top-bottom: partir du business et aller vers la technique. Bref, l’application d’un principe qui n’est pas prêt de s’user: C’est la technique qui est au service du fonctionnel et non le contraire.
Tout celà nous rappel qu’il est nécessaire d’adopter une démarche d’urbanisation avant de ce lancer dans la mise en place d’une SOA.
Questions pour RESTafarians !
Après les architecture dé-testable voici les RESTafariens, à ne pas confondre avec les SOAPafariens 😉
Et c’est David Megginson qui pose 5 questions intéressantes. Ca commence par une définition simple de REST:
“REST in its now-broadened meaning is easy to explain: pieces of data (likely XML-encoded) sit out there on the web, and you manipulate them using HTTP’s GET, PUT. Try explaining SOAP, much less the essence of the whole WS-* family in one easy sentence like that, and you’ll see the difference.”
A lire, ainsi que les commentaires.