Un sujet a fait débat cette semaine dans la “blogosphère SOA” : La mise en place d’une SOA doit-elle être conduite en démarrant sur un projet à périmètre réduit puis en incrémentant plutôt que de suivre la voix royale de l’approche Top Down ? Le retour d’un déjà vieux débat.
Il a été relancé par les propos d’Edward Cobb (VP architecture and standards chez BEA) à la conférence Arch 2 Arch de Nice : “It’s all about starting small so you can learn how to monitor the benefits and see how your business is becoming more flexible and adaptable.”.
Propos repris par Joe McKendrick sur son blog (“SOA business case: smaller is better“) suscitant alors de nombreuses réactions notamment celles de Steve Craggs sur le blog de Lustratus Research (“OK, start SOA small if you want - but don’t skimp“) et d’Annrai O’Toole sur le blog de Cape Clear’s (“The End of Big SOA“).
En espérant que ces débats (pour l’instant constructifs) ne soient pas les prémices du retour d’une “guerre de religions” autour des approches SOA …
Notons que Manuel Eveno avait abordé le sujet sur le blog de Xebia France : “Quel type de projet pour démarrer une SOA ?“.
Christophe Heubès SOA SOA
Une analogie pleine de bon sens par Charles Stack (BEA) :
“There was a time when dinosaurs ruled the earth, when the environment could accommodate and support gigantic reptiles. That environment changed. The dinosaurs died. Ants didn’t.
A similarly cataclysmic change continues to reshape the global business environment. The extraordinary evolution of the Web has changed how businesses relate to that environment, and to customers, partners, competitors as it redefines the enterprise. That the pace of this change continues to accelerate poses an increasingly significant threat to any company with too much in common with the doomed dinosaur–better to be more like a swarm of tenacious ants. Better to get small.
The widespread interest in and adoption of SOA is an attempt to do just that, to avoid the dinosaurs’ fate by getting small. But it’s not about shrinking or downsizing.”
Christophe Heubès SOA SOA
V.N.Madala publie sur son blog un article assez sibyllin, au sujet des approches de tests dans le cadre d’une SOA. Il a tout de même le mérite de rappeler que :
- L’approche doit être agile (Car la SOA se construit sur un mode itératif).
- La stratégie d’intégration doit être testée (Car c’est le principal point de faiblesse des SOA).
- Les besoins métiers doivent être compris par les équipes de test (Car la mise en place d’une SOA doit servir le métier).
- Les équipes doivent avoir une vision et une compréhension plus large que le périmètre dont elles ont la responsabilité (Car une SOA est un projet transverse).
Christophe Heubès SOA SOA, Tests
Synapse est un médiateur Web Service : routing, load-balancing, transformation et protocol switching (L’annonce sur TSS détaille les fonctionnalités). WSO2 ESB étend Synapse avec un registre de services et une interface graphique permettant de gérer et d’assembler des Services Web.
La stratégie SOA et ESB de la fondation Apache s’obscurcit encore un peu avec ces annonces. Cyrille Le Clerc fait un point sur la situation et nous livre son analyse dans son billet “La bataille des ESB Apache : Synapse vs. Service Mix vs. CXF” publié sur le blog de Xebia France.
Christophe Heubès SOA ESB, SOA
DSS (Digital Signature Services) est une spécification visant à garantir l’intégrité et l’authenticité des données échangées par des Web Services. La version 1.0 de cette spécification a été approuvée par le consortium.
Le communiqué de presse : New Digital Signature Services (DSS) OASIS Standard Assures Authenticity of Data for Web Services.
Christophe Heubès SOA Sécurité, SOA, Web Services
Cette semaine, deux articles assez virulents fustigent les tenants d’une pile de standards (techniques) universelle pour les SOA. Les titres sont sans appels :
La preuve que le débat n’est pas prêt de s’éteindre …
Christophe Heubès SOA SOA, WS-*
Cela fait huit ans maintenant que SOAP et WSDL ont été introduits en tant que standard visant à faciliter la communication entre systèmes hétérogènes. Depuis, moult “extensions” y ont étés ajoutées afin de répondre à des besoins plus complexes et/ou spécifiques, les fameux WS-*. La confusion autour de ces standards est palpable : Quand et pour quel usage doit-on s’intéresser à tel ou tel WS-* ?
C’est la question à laquelle répond Michele Leroux Bustamante dans un article très complet publié sur InfoQ : Making Sense of all these Crazy Web Service Standards.
Après un rapide rappel sur les protocoles de transport (HTTP/S, TCP, SMTP, UDP, …) et sur les standards XML (dont XML Digital Signature et XML Encryption), l’auteur passe en revue les WS-* par catégories :
- Messaging : WS-Addressing, WS-Transfer, WS-Enumeration, WS-EventNotification, MTOM, …
- Sécurité : WS-Security, WS-SecureConversation, WS-Trust, WS-Federation, …
- Fiabilisation : WS-Reliability et WS-ReliableMessaging.
- Transactionnel : WS-Coordination, WS-AtomicTransaction et WS-BusinessActivity.
- MetaData : WS-Policy et WS-MetadataExchange.
Christophe Heubès SOA SOA, Web Services, WS-*
Toute mise en place d’une SOA commence par la réalisation d’un projet pilote pour mettre à l’épreuve les choix effectués dans le cadre de la SOA.
Dans un article publié sur le blog de Xebia France, Manuel Eveno nous éclaire sur les questions à se poser avant de démarrer ce pilote.
Quel type de projet pour démarrer une SOA ?
Christophe Heubès SOA SOA, Xebia
Dans un article publié sur Real World SOA, Dave Linthicum soulève un sujet épineux : Les tests.
En quoi tester un projet sur une architecture orientée services diffère-t-il ? A priori en rien si ce n’est que les SOA sont fortement distribuées ce qui impose de savoir isoler les tests par domaines avant de tester l’ensemble. Dave Linthicum propose les domaines suivants :
- Service Level Testing
- Security Level Testing
- Orchestration Level Testing
- Governance Level Testing
- Integration Level Testing
So, How Do You Test an SOA?
Christophe Heubès SOA SOA, Tests
Dans un article publié sur Arch2Arch, Richard Manning (Bea) revient sur une tâche souvent ardue de la construction d’un socle SOA : La mise en œuvre de la couche d’accès aux données (data services layer). L’idée est de transformer les données en informations. Il nous présente pour cela 8 étapes.
Data in SOA, Part I: Transforming Data into Information
Un fois les données transformées en informations, celles-ci doivent être transformées en connaissance. Ce sujet fera l’objet d’un deuxième article. A suivre …
Christophe Heubès SOA SOA
