Ce modèle a été développé par Léonard Richardson. Léonard Richardson est, entre autres, co-auteur du livre “Restful Web Service” publié chez O’Reilly.
Martin Fowler a récemment publié un papier à propos du Modèle de Maturité de Richardson intitulé “Richardson Maturity Model: steps toward the glory of REST”. Dans ce papier, Martin Fowler déroule et commente le Richardson Maturity Model au travers d’un cas d’utilisation simple (réserver un rendez-vous chez le médecin).

Dans le billet “REST : Richardson Maturity Model” publié sur le blog de Xebia France, nous présentons le Richardson Maturity Model en nous appuyant en grande partie sur le papier de Martin Fowler. Au programme :

• Le niveau 0 : Le RPC sur HTTP en POX (Plain Old XML).
• Le niveau 1 : L’utilisation de ressources différentiées.
• Le niveau 2 : L’utilisation des verbes et des codes retours HTTP.
• Le niveau 3 : L’utilisation des contrôles hypermédia.

Articles similaires :

• Cas d’utilisation d’un ESB
• Comment les ESB se sont emparés des SOA
• Modèle de référence SOA
• SOA : Du composant au service
• Introduction à Hibernate Search (Googling your Persistent Domain Model)

On pourrait proposer la définition suivante : “Un Service est un composant logiciel distribué, exposant les fonctionnalités à forte valeur ajoutée d’un domaine métier”. Malheureusement, les définitions aussi courtes (bien qu’exactes) sont nécessairement incomplètes et amènent un florilège de questions.

Pour répondre plus précisément à la question, nous vous proposons, dans cette série d’articles parus sur le blog de Xebia, de passer en revue les huit aspects qui caractérisent un service :

• Contrat standardisé : L’ensemble des services d’un même Système Technique sont exposés au travers de contrats respectant les mêmes règles de standardisation.
• Couplage lâche : Le contrat d’un service doit imposer un couplage lâche de ses clients.
• Abstraction : Le contrat d’un service ne doit contenir que les informations essentielles à son invocation. Seules ces informations doivent être publiées.
• Réutilisabilité : Un service exprime une logique agnostique et peut ainsi être positionné comme une ressource réutilisable.
• Autonomie : Un service doit exercer un contrôle fort sur son environnement d’exécution sous-jacent. Plus ce contrôle est fort, plus l’exécution d’un service est prédictible.
• Stateless (sans état) : Un service doit minimiser la consommation de ressources en déléguant la gestion des informations d’état quand cela est nécessaire.
• Découvrabilité : Un service est complété par un ensemble de métas données de communication au travers desquelles il peut être découvert et interprété de façon effective.
• Composabilité : Un service doit être conçu de façon à participer à des compositions de services.

Ces 8 aspects sont issus du livre “SOA Principles of Service Design” de Thomas Erl, également auteur du site SOA Principles.



Articles similaires :

• 10 principes SOA
• Modèle de référence SOA
• Le mythe des repositories de services métiers
• Livre Blanc Comprendre et savoir utiliser un ESB dans une SOA
• Introduction à Hibernate Search (Googling your Persistent Domain Model)

• Introduction à Spring Integration
• Livre Blanc Migration Websphere 6.1
• BEA Aqualogic embarquera Amberpoint SOA Management
• Création du groupe de travail Open CSA à l’OASIS
• Architecte logiciel : un bagage à renouveler en permanence

Tout y est :

• L’équipe.
• Les cérémonies.
• Les artefacts.
• Le fun.

La réalisation très soignée et la BO ne gâchent rien.

A regarder absolument !


Articles similaires :

• L’offshoring Agile : C’est difficile mais ça marche !
• Développement organisationnel via Scrum
• Scrum : Entretien avec Jeff Sutherland à Paris
• Mise en œuvre d’une SOA : Démarrer petit et itérer
• Outsourcing Strategy & Scrum

Dans ce billet, publié sur le blog de Xebia, nous reviendrons rapidement sur la galaxie des standards Web Services, avant de présenter la Web Service Interoperability Organization (WS-I org.) et ses travaux.
Nous nous attarderons ensuite sur les profils proposés par le WS-I puis sur les outils qu’il met à disposition.
Nous terminerons avec quelques recommandations quant à l’implémentation de Web Services conformes aux profils du WS-I.

Articles similaires :

• Modèle de référence SOA
• Ratification de DSS 1.0 par l’OASIS
• Les standards Web Services sont-ils à SOA ce que les EJB furent à J2EE ?
• Spring Web Services 1.0
• Les services critiques ne sont pas nécessairement importants

Antonio Goncalves, David Dewalle et Zouheir Cadi organisent, pour fêter cet anniversaire, une soirée exceptionnelle le mardi 10 février 2009 dans les locaux de la Fiap.

Au programme :

• 19h45 à 20h00 : Accueil.

• 20h00 à 21h00 : 1ère session de quickies :
  • Le Paris JUG, 1 an déjà par Antonio Goncalves, David Dewalle et Zouheir Cadi.
  • Les JUGs en France avec L’équipe du Paris JUG, Christophe Jollivet (Tours JUG), Xavier Hanin (Bordeaux JUG), Nicolas Leroux et Stephane Epardaud (Riviera JUG), Nicolas de Loof (BreizhJug), Sebastien Roul (Nantes JUG), Christophe Meyer, JM Doudoux et Xavier Roy (Lorraine JUG), Gaël Blondelle (Toulouse JUG).
  • Présentation du Framework Wicket par Tarik Filali Ansary.
  • Jazoon’09 - présentation de la conférence et des dernières news par Christian Frei.

• 21h à 21h45 : Buffet.

• 21h45 à 22h45 : 2e session de quickies :
  • Parleys par Stephan Janssen.
  • Présentation de Java SE 7 Dolphin par Thomas Chamas.
  • Comment créer un jeu vidéo en 3D en Java avec OpenGL ? par Julien Gouesse.

• 23h à … : 3ème mi-temps des juggers, cette fois-ci il est préférable (voire nécessaire) pour y participer de s’inscrire.

Venons nombreux et merci encore à Antonio, David, Zouheir, aux speakers, aux sponsors et aux partenaires !

Les inscriptions sont ouvertes : pour assister à la soirée et pour la 3e mi-temps (Châtaignes et Cassis - 34 rue Gassendi - 75014 Paris - à côté de la rue Daguerre).


Articles similaires :

• Exposer un MBean avec Spring dans WebLogic Server 8.1
• Le rôle d’un ESB par Mark Richards
• JavaFX : Java dans le monde des RIA
• Closures en Java : La proposition BGGA
• Service Stateful ou Stateless ?

Anne Thomas Manes, s’est fait son petit plaisir de début d’année en publiant lundi dernier, sur le blog “Application Platform” du Burton Group, un billet intitulé “SOA is Dead; Long Live Services“.
Elle y annonce la couleur d’entrée de jeux : “SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession.”. En substance, alors que les SOAs étaient annoncées comme le paradigme d’architecture qui allait sauver les SI, elles ont en fait, après moult millions investis, empirées les choses (à quelques exceptions).
Les causes de ce fiasco ? D’après Anne Thomas Manes, pas les SOAs en tant que telles, rassurez vous. Si aujourd’hui, le métier ne croit plus aux promesses des SOAs, c’est avant tout un problème d’approche : Ceux qui ont compris que les SOAs n’étaient qu’un des outils du changement (changement organisationnel profond) ont profités d’un ROI énorme. Ouf !

Ce n’est donc pas aux funérailles des Architectures Orientées Services que le Burton Group nous convie en ce début d’années mais à celles de l’acronyme “SOA”, dont nous avons oublié le sens premier.

Bien que cette annonce (savamment provocatrice) n’apporte rien de bien neuf, elle clôture admirablement 2008, l’annus horribilis de la SOA durant laquelle la blogosphère SOAiste est passée de la crise de doute à la désillusion.
Ce qui est sûr, c’est que le billet d’Anne Thomas Manes a rapidement fait le tour de la blogosphère des analystes SOA qui s’en sont donnés à cœur joie. Je vous laisse découvrir le compte rendu des premiers jours proposé par infoQ : “Is SOA Dead?“ qui reprend les réactions de David Linthicum, Joe McKendrick, Miko Matsumura et Steve Jones qui ont étés (comme souvent) les plus prompts à réagir.
Durant toute la semaine les réactions se sont multipliées.
On retiendra tout particulièrement la proposition de Miko Matsumura de suivre l’exemple de Prince et de parler désormais de “the architecture formerly known as SOA“.
A noter également le billet en français d’Olivier Rafal (”SOA mort ? Le terme, oui, pas les principes“) qui rappelle, entre autre, à juste titre que le financement des initiatives SOA a toujours été un gros problème que la crise n’arrangera pas.

Beaucoup de bruit pour rien ? C’est l’avis de Jack Vaughan (”New year - same old SOA tempests?“). Anne Thomas Manes s’en défend et revient sur les réactions que son billet a suscitées.
Cette effervescente semaine aura au moins eu le mérite de rappeler que les SOAs, telles qu’elles ont été abordées dans de nombreux cas, n’ont pas su convaincre (Ces échecs trouvent leurs sources dans de nombreuses causes).
L’année 2009 devra donc, plus que jamais, être l’occasion de rectifier le tir et d’aborder les questions de refonte des SI de façon pragmatique.

Rassurez-vous, ce que nous avions coutume d’appeler SOA est bien vivant !


Articles similaires :

• Les services critiques ne sont pas nécessairement importants
• Sorties d’Apache Synapse 1.0 et de WSO2 ESB 1.0
• Le mythe des repositories de services métiers
• Mise en œuvre d’une SOA : Les clés du succès
• Sortie d’Apache CXF 2.0

Exadel Flamingo fournit un ensemble de scripts, basés sur Maven, visant à simplifier le démarrage de projets RIA. Ces scripts permettent de générer le code initial et redondant d’un projet. La promesse est donc d’offrir la capacité de créer une application CRUD dotée d’une interface riche très rapidement et sans effort de développement.

Les technologies couvertes aujourd’hui sont :

• Flex et JavaFX pour partie cliente,
• AMF et Hessian pour la communication,
• JBoss Seam et Spring pour la partie serveur.

Question de contexte et de goût, j’ai pour ma part porté mon attention sur le triplet Flex / AMF / Spring.

Même si certains aspects méritent des améliorations, la promesse est tenue. Bien que n’ayant jamais pratiqué Flex (ou presque), il ne m’a pas fallu longtemps pour monter mon CRUD Flex / Spring / Hibernate. Le billet Exadel Flamingo - Applications Flex, AMF, Spring, publié sur le blog de Xebia France, présente le déroulé de mes premiers essais.

Articles similaires :

• Jusqu’où Flex peut-il prendre la relève d’Ajax ?
• Spring 2.1 : Interview de Rod Johnson par TSS
• SOA : Du composant au service
• Injection de dépendances par annotations avec Spring 2.1
• Introduction à Spring Integration

L’occasion d’une introduction à Spring Integration, la plate-forme de messaging de SpringSource.

Articles similaires :

• Injection de dépendances par annotations avec Spring 2.1
• Livre Blanc Migration Websphere 6.1
• Introduction à SCA (Service Component Architecture)
• Tibco porte sa plate-forme SOA sur Amazon EC2
• Le rôle d’un ESB par Mark Richards

La liste complète de ces pièges peut être ordonnée en trois catégories :

Les pièges liés à l’implémentation :

• N° 10 - Le syndrome “Not Invented Here”
• N° 09 - Le Versioning
• N° 08 - La sécurité

Les pièges liés à l’architecture et au design :

• N° 07 - Mauvaise granularité des services
• N° 06 - La SOA ne résout pas automatiquement la complexité
• N° 05 - Big Design Up Front (BDUF)
• N° 04 - Mauvaise utilisation des Modèles de Données Canoniques (pivots)
• N° 03 - Le manque de compétences

Les pièges liés à l’organisation :

• N° 02 - Propriété des composants et Financement au projet
• N° 01 - Ignorer les impacts culturels

Comme toujours dans ce genre de “classement”, cette liste n’est ni exhaustive ni définitive.

—

Article original : “Les 10 pièges de la SOA“ sur le le blog de Xebia France.

Articles similaires :

• 10 principes SOA
• Cas d’utilisation d’un ESB
• L’offshoring Agile : C’est difficile mais ça marche !
• Le mythe des repositories de services métiers
• Introduction à SCA (Service Component Architecture)