Comment mettre en œuvre couplage lâche avec une architecture SOA

Question

Je fais beaucoup de recherches ces derniers temps sur SOA et ESB de etc.

Je travaille sur la refonte des systèmes existants maintenant au travail et je voudrais construire avec plus d'une architecture SOA que ce qu'il a actuellement. Nous utilisons ces services dans environ 5 de nos sites Web et l'un des plus gros problèmes que nous avons actuellement avec notre système hérité est que presque tout le temps lorsque nous effectuons des corrections de bogues ou des mises à jour, nous devons redéployer nos 5 sites Web. processus assez long.

Mon objectif est de rendre les interfaces entre services faiblement couplées afin que des modifications puissent être apportées sans avoir à redéployer tous les services et sites Web dépendants.

J'ai besoin de pouvoir étendre une interface de service déjà existante sans casser ou mettre à jour aucune de ses dépendances. Est-ce que l'un d'entre vous a déjà rencontré ce problème? Comment l'avez-vous résolu?

Answer 1

Je suggère de regarder un style différent de services que peut-être que vous avez fait jusqu'à présent. Considérez les services qui collaborent les uns avec les autres en utilisant des événements, plutôt que des demandes/réponses. J'utilise cette approche depuis de nombreuses années avec des clients dans différents secteurs avec beaucoup de succès. J'ai beaucoup écrit sur ces sujets au cours des 4 dernières années. Voici un endroit où vous pouvez commencer:

http://www.udidahan.com/2006/08/28/podcast-business-and-autonomous-components-in-soa/

espoir qui aide.

Answer 2

Ce que vous demandez n'est pas un sujet facile. Vous pouvez faire en sorte que votre architecture orientée services soit associée de différentes manières.

Je suggère de vérifier SOA book series de Thomas Erl. Il explique tout assez clairement et en profondeur.

Answer 3

Il existe plusieurs approches possibles. Notre architecture SOA implique des messages XML envoyés vers et à partir des services. Une façon d'atteindre ce que vous décrivez est d'éviter l'utilisation d'une bibliothèque de liaison de données dans notre schéma XML et d'utiliser un analyseur XML générique pour obtenir uniquement les nœuds de données que vous souhaitez ignorer ceux qui ne vous intéressent pas. nouveaux noeuds supplémentaires au message sans casser quiconque qui l'utilise actuellement. Nous ne le faisons généralement que lorsque nous n'avons besoin que d'une ou deux informations provenant d'une structure de schéma plus grande.

Alternativement, l'autre solution (préférée) que nous utilisons est le versionnage. Une version d'un service adhère à un schéma/interface particulier. Lorsque le schéma change (par exemple, l'interface est étendue ou modifiée), nous créons une nouvelle version du service. À tout moment, nous pouvons avoir 2 ou 3 versions en même temps. À la longue, nous désapprouvons puis supprimons les anciennes versions, tout en migrant éventuellement le code dépendant vers des versions plus récentes. De cette façon, les personnes dépendantes du service peuvent continuer à utiliser la version existante du service tandis qu'une dépendance particulière peut être mise à niveau vers la nouvelle version. Les versions d'un service appelées sont définies dans un fichier de configuration pour le code dépendant. Notez que ce n'est pas seulement le schéma qui est versionné, mais aussi tout le code d'implémentation sous-jacent.

Espérons que cela aide.

Answer 4

Il y a quelques pratiques courantes pour obtenir un couplage lâche pour les services.

1. Utiliser un style doc/literal des services web, pensez à des données (le format de fil) au lieu de RPC, éviter que des données à base de schéma de liaison.

2. respecter strictement le contrat lors de l'envoi des données, mais garder quelques hypothèses de traitement des données entrantes, XPath est un bon outil pour cela (en vrac dans, serré sur)

3. utilisation ESB et d'éviter tout point directement point de communication entre les services.

Answer 5

Voici une liste approximative pour évaluer si votre SOA implémente couplage lâche:

• Emplacement du système appelé (son adresse physique): Votre application utiliser URL directe pour accéder à systèmes ou l'application est-elle découplée via une couche d'abstraction qui est responsable pour maintenir les connexions entre les systèmes? Le registre des services et le paradigme de groupe de services utilisé dans SAP NetWeaver CE sont de bons exemples de ce à quoi une telle abstraction pourrait ressembler. L'utilisation d'un bus de service d'entreprise (ESB) est un autre exemple. Le point est que l'application ne devrait pas coder en dur l'adresse physique du système appelé afin d'être vraiment considéré comme couplage lâche.

• Nombre de récepteurs: Est-ce que l'application de spécifier quels systèmes les récepteurs d'un appel de service? Un composite faiblement couplé ne spécifiera pas de systèmes particuliers mais laissera la livraison de ses messages à une couche d'implémentation de contrat de service. Une application couplée étroitement appellera explicitement les systèmes de réception dans l'ordre ; une application faiblement couplée appelle simplement l'interface de service et permet à la couche de mise en œuvre du contrat de service de prendre en charge les détails de distribution des messages aux bons systèmes .

• Disponibilité des systèmes: Votre application exige que tous les systèmes que vous connectez à être opérationnel tout le temps? De toute évidence, il s'agit d'une exigence très difficile, surtout si vous souhaitez vous connecter à des systèmes externes qui ne sont pas sous votre contrôle . Si la réponse est que tous les systèmes doivent fonctionner tout le temps, l'application est étroitement couplée à cet égard.

• Format des données: Est-ce que l'application de réutiliser les formats de données fournis par les systèmes de back-end ou utilisez-vous un système de type de données canonique qui est indépendant des systèmes de type utilisés dans les appelés applications? Si vous réutilisez les types de données des systèmes backend , vous devrez probablement vous battre avec les conversions de type de données dans votre application, et ce n'est pas une approche très faiblement couplée.

• Temps de réponse: L'application requiert des systèmes appelé à répondre dans un certain délai ou est-il acceptable pour l'application de recevoir une réponse de minutes, heures ou même jours plus tard?