Qu'entendons-nous par "contexte fonctionnel" dans les services Web.Que voulons-nous dire par contexte fonctionnel dans les services Web?
Chaque service est attribué son propre contexte fonctionnel distinct et est composé d'un ensemble de fonctionnalités liées à ce contexte
En bref faire une chose et le faire bien, en quelque sorte. Typiquement dans SOA vous auriez beaucoup de différents services chacun traitant de son propre contexte. Par exemple, dans un système de vente, vous pouvez avoir un client, un représentant des ventes et un service de commandes. Dans une architecture bancaire, vous pouvez avoir des clients, des produits, des instruments financiers et des services de transaction (débit, crédit). Une des fonctionnalités intéressantes de SOA est qu'une fois que vous avez beaucoup de petits services différents, vous pouvez commencer à ajouter des fonctionnalités à l'architecture par orchestration d'autres services. Permettez-moi d'utiliser une analogie ici. Commencez à penser aux services comme des blocs lego. Ils sont une pièce, une forme et rien de plus. Vous pouvez créer une maison, une voiture ou toute autre chose avec les blocs. Ainsi, le contexte fonctionnel est l'objet/la cible du service. Par exemple, dans le secteur bancaire, nous aurions un service client. Les capacités du service client signifient que nous avons des opérations relatives à ce service uniquement. Par exemple créer des clients, trouver une liste de clients par région, mettre à jour les détails, etc. Vous ne créez jamais un nouvel instrument financier via le service client. L'idée est de diviser tous vos objets dans le domaine du problème dans leur propre contexte et de développer les capacités de ces objets dans ce contexte. Un problème qui peut survenir si vous ne respectez pas ce modèle de conception est que vous vous retrouvez avec des services qui ont des opérations étranges, comme avoir un client avec une opération de création d'un instrument financier. Ceci est incorrect car le client peut être associé à un instrument financier (son compte d'épargne, sa carte de crédit, etc.) mais il n'est pas le propriétaire de l'instrument. Fondamentalement, tout ce que l'on dit, c'est que si vous créez un service, il ne devrait traiter que d'un seul sujet de préoccupation et ne comporter que des opérations liées à ce problème. Gardez à l'esprit qu'il n'y a rien à vous dire ce que sont ces contextes.
Cela fait partie du processus de conception que vous décidez du contexte.