De quelle manière sont les services en aval et en amont?


45

Dans le cas d’un système composé de plusieurs services s’appelant (par exemple, Front End -> Backend -> Storage), j’entendais souvent les personnes utiliser une terminologie telle que services "en aval" ou "en amont". Je ne sais pas quelle direction cela signifie. Les données circulent dans les deux sens. Les demandes passent d'un plus grand nombre d'utilisateurs à un plus grand service, mais les réponses vont dans le sens opposé. Il me semble donc que l'une ou l'autre solution peut être discutée.


3
Il est intéressant de noter que la spécification HTTP RFC 7230 inclut les définitions des termes "en amont" et "en aval" de la section 2.3: tools.ietf.org/html/rfc7230#section-2.3
Jack

Réponses:


56

Les services en aval sont ceux qui consomment le service en amont. En particulier, ils dépendent du service en amont. Le front-end est donc en aval du back-end car cela dépend du back-end. Le back-end peut exister de manière significative sans le front-end, mais le front-end n'a pas de sens sans le back-end.

La dépendance ne doit pas nécessairement être aussi forte que ce que je pensais être dans le paragraphe précédent. Plus généralement, les services en amont n'ont pas besoin de savoir ou de se préoccuper de l'existence de services en aval. Les services en aval se soucient de l'existence de services en amont, même s'ils ne les consomment que de manière facultative.


Je pense que cela devrait être "services en aval" au lieu de "services en aval" .
Nawaz

8

Malheureusement, il existe des divergences d’opinion sur la signification de l’amont / aval. Lorsque je parle d’architecture système, je la définit comme suit:

Dans un système préoccupant, les systèmes qui initient l'échange de messages / de données avec le système concerné sont des systèmes en amont, et les systèmes dont dépend le système concerné (c'est-à-dire ceux pour lesquels mon système initie un échange de données) sont des systèmes en aval.

Ce lien ibm décrivant les interactions avec l'un de leurs produits corrobore cette vue: Intégration aux systèmes en amont et en aval https://www.ibm.com/support/knowledgecenter/en/SSWSR9_11.3.0/com.ibm.pim.dev.doc /integration/pim_con_dev_creatingjobsforintegrationcontainer.html

Un système en amont est un système qui envoie des données au système Collaboration Server. Un système en aval est un système qui reçoit des données du système Collaboration Server.

Compte tenu de la terminologie «en amont» et «en aval», il peut être utile de faire une analogie avec une rivière. Si vous déposez un message (données) dans la rivière, il passe de l’amont (initiateur) à l’aval (récepteur).

De manière anecdotique, j'ai constaté que les architectes et les développeurs de middlewares utilisent cette définition et les développeurs Web, l'inverse (peut-être en raison du «téléchargement»).

Avec les chronologies d'événement, un événement est en amont lorsqu'il se produit avant un point de la chronologie (c'est-à-dire qu'il déclenche un autre événement) et en aval lorsqu'il se produit après (c'est-à-dire qu'il a reçu l'événement). Ce qui est en amont et en aval dans une séquence d'événements dépend donc de votre position dans la timeline. Un événement peut être à la fois en aval et en amont, selon que votre point de départ est avant ou après.

Comme le note @Jack, RFC7230 tools.ietf.org/html/rfc7230#section-2.3 a ceci:

Les termes "amont" et "aval" sont utilisés pour décrire les
exigences directionnelles relatives au flux de messages: tous les
messages circulent de l'amont vers l'aval.

Je serais intéressé de voir sur les votes, qui est l'utilisation la plus courante!


1
Ceci est simplement déroutant parce que vous êtes confus sur la question. Il n'y a pas de divergence, juste une différence de point de vue.
Martin Maat le

@MartinMaat Je ne suis pas d'accord avec votre première phrase et suis d'accord avec votre deuxième phrase.
Roj

3

La meilleure façon de penser à cela est de penser à une rivière.

La partie aval de la rivière ne peut avoir d’eau que si elle provient de l’amont, c’est-à-dire que l’aval dépend de l’amont pour son eau.

Si quelqu'un détruisait la partie aval de la rivière, cela n'aurait aucun impact en amont. Si quelqu'un détruisait la partie amont de la rivière, cela aurait un impact en aval, c'est-à-dire qu'il ne recevrait pas d'eau.

Les services en aval dépendent donc des services en amont. Si les services en amont sont supprimés, les services en aval ne fonctionneront pas correctement.


Et pour plus de clarté; Dans une relation client-serveur CRUD standard, les deux extrémités sont à la fois en amont et en aval. Le client ne peut obtenir aucune donnée ou mise à jour si le serveur est arrêté et le serveur n'a aucune instruction à exécuter s'il n'y a pas de client.
Delioth

1
@Delioth n'est pas d'accord. Le backend peut avoir plusieurs clients, mais ne dépend d'aucun d'entre eux. Si vous supprimiez un client, le backend fonctionnerait toujours. Le client peut avoir plusieurs arrière-plans qu'il peut utiliser. Si un client est supprimé à l'insu du client, celui-ci ne peut pas fonctionner correctement. Le client est en aval. Le backend est en amont.
Gaz_Edge

1

Il s’agit peut-être davantage d’un problème linguistique et géographique que technique.

  • La demande d'information va en amont. Cela vient d'un système en aval.

  • La réponse à la demande d'informations (les informations demandées) passe en aval et est envoyée par un système en amont.

Il n'y a aucune différence entre la vue classique d'IBM et l'utilisation des termes par la communauté Web d'aujourd'hui.

  • Un fournisseur de services (serveur) sera situé en amont par rapport à un consommateur de service et enverra des informations en aval au consommateur.

  • Un consommateur de service (client) sera situé en aval par rapport au fournisseur de service et enverra des demandes en amont au fournisseur.

Théoriquement, les rôles des systèmes physiques pourraient changer instantanément, de même que la direction du flux entre ces systèmes. Dans un réseau peer-to-peer, cela peut être le cas.

Les termes téléchargement et téléchargement sont des termes centrés sur le client. Du point de vue du client, une demande est téléchargée et une réponse est téléchargée, ce qui est cohérent avec la métaphore du flux.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.