|
|
Mourad Lafer (EDIS Consulting) |
|
|
|
Ce tutoriel a été réalisé par Mourad Lafer
Mourad Lafer est un ingénieur d'étude senior, architecte en développement Java, J2EE et .Net pour EDIS Consulting.
Après de nombreuses années de développement et fort de son expérience internationale, il nous livre ici la première partie d'une réflexion autour des méthodologies et des approches largement employées dans l'univers du développement. |
|
Le pattern Service Gateway permet de fournir une interface orientée métier d'accès à un système externe simple et stable. Il masque la communication distante donnant l'impression au consommateur que le service est locale. Par l'introduction de cette couche d'abstraction, il réduit considérablement l'impact des évolutions ainsi que l'effort de maintenance des modules accédant aux ressources externes.
Patterns connexes
- Service Interface : Il expose une fonctionnalité via un service et un point d'accès pour les requêtes entrantes. Dans les applications fournisseur, il joue un rôle similaire à celui de Service Gateway dans les applications consommatrices.
- Gateway. Il a été introduit la première fois dans un contexte d'applications d'entreprises par Martin Fowler. Ce pattern est de granularité fine au niveau objet à contrario du service Gateway, dans un contexte d'intégration, est de granularité grossière au niveau plateforme.
- Mapper : assure la conversion entre plusieurs interfaces fixes sans que les objets n'aient à se reconnaître entre eux. Le Service Gateway peut incorporer un Mapper pour effectuer les conversions entre les formats de données de l'application et ceux du service.
- Assembler : similaire à Mapper, ce modèle rassemble plusieurs objets en un seul. La communication entre deux interfaces dans un Mapper est bidirectionnelle, tandis qu'elle est généralement unidirectionnelle dans un Assembler.
- Service Stub : Ce design pattern permet le test d'une application même lorsque l'on n'a pas encore accès à tous les services consommés par l'application. L'idée est de fournir des petits modules qui présentent les mêmes accès et qui simulent les services manquant.
Références
- Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley, 2003.
- Gregor, Hohpe; Bobby, Woolf. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley, 2003.
Par
Bruno Rizzi (Sogeti) : SOA
: l'alignement IT / métier passe aussi par la stratégie de test
De par son alignement sur les enjeux métiers, une architecture orientée services présente sensiblement plus de risques qu'une autre application. Tests permettront de les anticiper.
A
la découverte de WS-Security
Le but de cette spécification XML est de sécuriser une transaction réalisée par
le biais d'un service Web. Pour ce faire, elle fait appel à des mécanismes d'authentification,
de signature et de chiffrement.
