OCTO sera présent à la table ronde organisée par CIO et Le Monde Informatique sur le thème SOA et Agilité mardi 6 Octobre à l’Automobile Club de France (Paris 8e). Le séminaire démarrera à 8:45 avec de nombreux intervenants, la table ronde aura elle lieu à 14h45.
En espérant vous voir nombreux, promis, nous irons au-delà des poncifs d’usage sur ce sujet …
Depuis quelques années, on assiste à l’émergence de nouvelles solutions logicielles, dont le concept à la base est loin d’être nouveau, mais dont l’offre est de plus en plus riche et perfectionnée, à savoir, Complex Event Processing.
Alors de quoi s’agit-il ? (Lire la suite…)
L’architecture SCA (Service Component Architecture) reste une initiative démocratisée relativement récemment même si la version 1.0 a été publiée il y a plus de deux ans maintenant. L’annonce d’Oracle Fusion 11G a récemment rappelé son support par différents grands éditeurs. Il n’en reste pas moins que son périmètre d’utilisation n’est pas forcément évident, d’autant plus qu’il s’agit d’un des nombreux sigles associés à SOA : WS-*, BPEL, JBI, SDO… Nous allons tâcher au sein de cet article de clarifier les potentialités de cette norme et de proposer des contextes qui me semblent propices pour en tirer profit.
par Karim BEN OTHMAN et Sylvain FAGNENT:
Sylvain : Karim, bonjour
Karim : Bonjour.
Sylvain : Ton expérience de l’intégration à Octo te place en référant sur le sujet et moi qui le suis d’un peu plus loin désormais, j’ai des questions autour des MOM, de l’open source et plus récemment des ESB. Tu peux m’aider à y voir plus clair?
Karim : Poses tes questions, on va bien voir ce que je peux faire (Lire la suite…)
La version 6 de la solution ESB de Sun Microsystems, Java CAPS (Composite Application Platform Suite), historiquement connue sous le nom Seebeyond (en référence à la société Seebeyond qui commercialisait cette solution jusqu’en 2005), a fait un bond technologique conséquent par rapport à la version 5.1.3.
(Lire la suite…)
Dans une implémentation SOA, un service n’a de sens que s’il est invoqué par plusieurs applications ou blocs applicatifs. Par conséquent, tout changement survenant sur un service impacte l’ensemble des consommateurs de ce service. Non seulement ces changements peuvent coûter chers, en plus, l’autonomie du service est un fondement de la mise en œuvre d’une architecture orientée services. L’autonomie se traduit par le fait que le service peut être modifié, déployé et maintenu indépendamment des consommateurs qui l’invoquent. (Lire la suite…)
Le versioning de service est un thème à part entière dans les architectures orientée service tant il structure l’évolutivité d’un service. Les architectures REST n’échappent pas à la règle. Posant les principes généraux de l’architecture, Roy Fielding n’en a pas pour autant décrit tous les méandres. Il n’appartient donc qu’à nous, développeurs et architectes, de définir ce qu’est le versioning des services REST en respectant ces principes. Ce billet traitera donc la problématique de versioning des services REST.
12 leçons à retenir
Retour d’expérience sur le projet NéoRetraite de GENERALI, vu par Benamar développeur et Olivier coach. Ce projet stratégique consistait à mettre en production une nouvelle version d’un contrat de retraite. Il s’est déroulé sur 1 an et a nécessité l’effort coordonné de 3 équipes, chacune en charge d’une application participant au projet. Au plus fort de l’activité 50 développeurs travaillaient en même temps sur le projet.
Mr Jourdain fait de la prose ou des vers sans qu’il n’en sût rien. Bon, nous le savons depuis la 5e ! Et comme Molière avait le don d’écrire des universalités humaines et intemporelles, il est certain qu’aujourd’hui autour de nous et dans bien des domaines il y a des Mr Jourdain qui s’ignorent. Projetons donc ce monsieur Jourdain dans l’IT de 2009. Quelle pourrait être la chose qu’il fît depuis pas mal de temps sans qu’il n’en sût rien. Ne serait ce pas de la SOA par hasard ? Reprenons une définition communément rencontrée d’un service. Je cite rapidement et pour l’essentiel :
Cet article est le deuxième d’une série de 3 articles traitant de la stratégie de test d’une architecture REST. Il fait suite au billet sur le test unitaire d’une ressource REST. Pour rappel nous allons, par l’exemple, mettre en pace une stratégie de test sur un code d’exposition de web services REST en Java. L’exemple de code se basera sur le framework REST Jersey, implémentation de référence de Sun de la JSR-311 déjà présentée dans un précédent article . Le but de ces trois articles est de présenter un harnais de tests pouvant couvrir la mise en place de Web services REST. Ce deuxième article s’attardera sur les tests d’intégration tandis qu’un prochain article traitera des tests de recette.
(Lire la suite…)
