La JSR 311 JAX-RS [Java^TM API for RESTful Web Services] est le pendant REST de la JSR 224 JAX-WS [Java^TM API for XML-Based Web Service]. Elle marque la volonté de la part de la communauté Java de cadrer, tout comme pour la stack WS-*, le développement des applications JAVA orientées ressources. Bien qu’étant sur le point d’être finalisée (dernier stade : Final Approval Ballot), elle est déjà implémentée par la plupart des frameworks REST du moment (Jersey, RESTeasy, CXF, une extension Restlet…).

La suite de ce billet présente les annotations de la JSR en regard des principes REST qu’elles mettent en œuvre.

(Lire la suite…)

(Lire la suite…)

Lorsqu’une DSI souhaite mettre en oeuvre une Architecture Orientée Services (SOA), il lui est souvent conseillé de suivre une démarche en cascade qui part des processus métier de l’entreprise et qui visent à définir des services ré-utilisables. Même en supposant que ce long processus réussisse, la matérialisation informatique de ces services dans le SI passe généralement par de lourds projets de refonte de l’existant qui est généralement peu aligné sur ces visions théoriques. Qui peut alors réalistement défendre auprès de sa Direction Générale un projet de refonte même partiel de son SI aux seules fins de le rendre SOA ?
(Lire la suite…)

Malgré l’émergence de nouveaux concepts, standards, outils, etc., la complexité de l’intégration demeure toujours la même. Intégrer des applications hétérogènes d’un SI dans une démarche d’urbanisation, de flexibilité et d’évolutivité s’avère un exercice complexe et délicat. Cela nécessite à l’entreprise un effort considérable sur divers volets : économique, technique et organisationnel.

(Lire la suite…)

Le texte suivant est extrait du livre « Une Politique pour le Système d’Information – Descartes – Wittgenstein- (XML) » publié par OCTO Technology :

SOA est l’archétype de la régression collective. Rien de grave, cela arrive dans tous les secteurs. Après DCE, Corba, l’urbanisme des SI et les outils d’EAI, voici le serpent de mer resurgir encore.

Et il y a une bonne raison à sa résurrection : toute réalisation informatique qui implique plus d’une application est un cauchemar : coordination, construction à plusieurs, tests à plusieurs, stress à plusieurs…

Alors les solutions fusent, toujours les mêmes : il faut diminuer le nombre de boîtes et le nombre de fils entre les boîtes.

(Lire la suite…)

Vous concevez une architecture distribuée en utilisant des services Web ?

Bien ! Mais vous êtes-vous posé la question du style architectural, c’est-à-dire du choix entre une approche orientée appel de procédure à distance ou une approche orientée manipulation de ressources ?

Et celle du choix entre une pile de protocoles lourde ou une pile légère pour les échanges avec les services Web ? Vos décisions auront un impact important sur les propriétés de votre système : complexité, facilité d’évolution, obsolescence technique, capacité à monter en charge, stabilité, ouverture.

Nous proposons ici un tour d’horizon des grandes options architecturales… et quelques précieux conseils…

Téléchargez la suite sur www.octo.com

Dans nos missions chez nos clients, il nous arrive régulièrement d’utiliser des ESB (Enterprise Service Bus), pour créer une couche de médiation, gérer des flux, etc.
Mais parfois, on peut oublier ce qu’un tel acronyme de trois lettres signifie (TLA en anglais : Three Letter Acronym).
J’ai demandé à notre ami Google de me dire ce qu’il pensait de cet acronyme et de sa définition :

Google France me propose : Encéphalopathie Spongiforme Bovine
Et Google.com suggère : Empire Strikes Back

Alors, les ESB, est-ce une maladie mortelle ou bien une conspiration des éditeurs hégémoniques ?
Faut-il être un maître Jedi pour s’en sortir dans le monde cruel des ESB ?