Cloud, .NET, java, Méthodes agiles, Gouvernance,...
Les frameworks Web pullulent dans le monde Java. Point trop n’en faut.
La majorité d’entre eux sont des frameworks Web à actions tels que Struts, WebWork, Struts 2 (en fait WebWork), et toute une palanquée d’autres … Malgré le chemin parcouru depuis le spartiate Struts, les frameworks à actions atteignent leurs limites : dans leur grande majorité, il ne propose pas de modèle de composant graphique. JSF repose lui sur une approche composant, ce qui en fait tout l’intérêt.
Eclipse est, à n’en point douter, un extraordinaire outil de développement, dont le gros point fort est l’édition du code : refactoring, recherche dans le code, auto-completion … Mais, de base, Eclipse n’offre pas de fonctionnalités de développement Web, Java EE, XML ou de design d’interface graphique. Bien sûr, ces fonctionnalités sont disponibles séparément sous forme de plug-ins, mais leur installation n’est pas toujours simple. Pour être totalement honnête, l’initiative Callisto livre tous les plug-ins compatibles simultanément, et donc simplifie le processus.
MySQL est une base de données open source bien connue, mais qui n’a pas encore tout à fait acquis une complète crédibilité pour les très grosses volumétries de données. MySQL 5.1, en cours de développement, pourrait bien changer la donne. En effet, cette version intégrera le partitionnement, mais aussi la réplication des données dans le cadre d’un cluster.
C’est une forte tendance, les applications d’entreprise opèrent sur des volumétries de données de plus en plus grandes. Qui plus est, une pléthore d’utilisateurs et de clients accèdent à ces données, que ce soit directement, ou, le plus souvent, indirectement. Et ce n’est clairement pas le SOA ou la gestion des données de référence (master data management) qui vont infléchir ces tendances !
Résultat : une pression de plus en plus grande s’exerce sur les systèmes de gestion de bases de données.
On peut lire ça et là, depuis un certain temps, que la base de données n’aurait aucune espèce d’importance. Il suffirait d’utiliser un mapping objet/relationnel et de se reposer sur un mythique cache, sorte de panacée à tous les maux.
Pour le compte de ses clients, nos équipes ont effectué plusieurs dizaines d’audits de performances sur diverses applications en grande difficulté de performance. Et les faits sont sans appel !
Dans une majorité des cas, les causes des mauvaises performances se situent au niveau de la base de données !
L’interface graphique d’une application d’entreprise est par nature très volatile. Elle évolue continuellement pendant tout le cycle de vie de l’application. Et c’est bien naturel : l’interface graphique constitue la partie visible de l’iceberg applicatif. Son ergonomie impacte directement la productivité des utilisateurs, et leur adhésion à l’application.
Dans la mythologie de l‘heroic fantasy, le blob est un monstre gélatineux, de grande taille, dans lequel on ne parvient à distinguer aucune structure particulière. Tel un globule blanc, cette créature phagocyte tout ce qui s’en approche, et grossie à mesure qu’elle se nourrit. Le blob inspire la crainte, et personne ne souhaite vraiment s’en approcher.
Le code-blob, c’est une portion de code de l’application (généralement le corps d’une méthode ou d’une fonction) constituée d’un nombre important de lignes.
La SOA, comme son nom l’indique est une architecture fondée sur les services. Mais, à tant parler de services, n’aurait-on pas perdu de vue les processus.
En première approche, on peut définir un processus comme un enchainement de tâches. Un processus peut être coordonné par un acteur unique, on parle alors d’orchestration, ou par coopération entre des acteurs coordonnant chacun une sous partie du processus, on parle alors de chorégraphie. Au sein d’un système d’information, la plupart des processus sont exécutés par orchestration. Et c’est seulement lorsqu’un processus implique plusieurs systèmes d’information (entre partenaires par exemple) que le mode d’exécution par chorégraphie est généralement intéressant.
