L'orchestration est-elle une responsabilité ESB?

Question

Il s'agit d'un bus de service d'entreprise (outil qui joue le rôle de médiateur, de courtier de messages, de facilitateur de service, d'améliorateur de transformation de schéma, de fournisseur d'emplacement transparent, d'agrégateur de service, d'équilibreur de charge, de moniteur, etc. ce genre de choses) responsable d'orchestrer les services ?

Qu'en est-il de l'intégration d'un processus métier automatisé comportant plus de mille étapes et plusieurs dizaines d'appels de service dans votre bus de service d'entreprise?

Le feriez-vous ou auriez-vous recours à un spécialiste en orchestration tel qu'un moteur BPEL?

S'il vous plaît, donnez-moi votre avis.

Answer 1

Oui et non. La ligne de démarcation entre l'orchestration et l'augmentation de l'agrégation / du service est parfois difficile à distinguer.

En général, si vous avez un processus métier long ou complexe (processus étant le mot clé, même si je ne vais pas le définir), c'est ce qui convient le mieux à BPEL.

Des tâches simples, telles que l’agrégation des résultats de trois appels de service, peuvent et doivent souvent être effectuées dans une couche ESB.

Cela ne vaut pas la peine de perdre trop de sommeil, cependant

Clause de non-responsabilité: je suis un consultant IBM ESB, bien que je n’écrive pas ceci à titre officiel.

Answer 2

Non, la responsabilité d’un ESB n’est pas l’orchestration de services (en soi). ESB fournit une couche d’abstraction au "niveau de l’infrastructure logicielle".

Cela signifie qu’un ESB est un "port d’appel abstrait et logique unique pour la connectivité". avec n'importe quel service publié sur le bus.

ESB étant abstrait, cela signifie que les consommateurs de services dans le bus n'ont pas besoin de savoir. les détails de déploiement du service, et il est possible d'exposer les "services faisant face à l'intérieur" & avec un seul modèle de document. ESB fournit des services de bas niveau (tels que la traduction de protocole et la transformation de messages), de sorte que les services internes puissent communiquer de manière simplifiée.

Cela implique une certaine orchestration: le BSE fournit une orchestration des services de bas niveau susmentionnés (par exemple, lorsque le service X est appelé via IIOP, traduisez-le en SOAP avec pièces jointes. Transformez ensuite la demande de toute donnée sérialisée en charge utile XML).

L’orchestration à éviter dans un ESB est la suivante: pour traiter cette vente (d’assurance), nous devons d’abord valider les informations fournies par l’acheteur, puis nous devons souscrire le risque d’assurance, puis calculer le prime qui doit être payée pour l’assurance, après quoi nous devons & # 8230; etc.

Les étapes décrites ci-dessus constituent clairement un processus commercial (qui pourrait même être interrompu, par exemple, si la souscription automatique n'est pas possible, un souscripteur humain doit alors évaluer le risque davantage).

Les services métier (par exemple, validation, souscription, calcul de la prime) constituant un processus technique (par exemple, la vente d’assurance), généralement appelé orchestration, conviennent mieux à un processus de processus métier (Business Process Engine) et définis à l'aide d'un langage de modélisation de processus métier formalisé (tel que BPEL).

Déterminez également les nombreuses étapes de votre processus: dans l'exemple ci-dessus, la validation est un service (détaillé). Les règles de validation elles-mêmes sont internes à ce service. Pour les règles métier complexes (c’est-à-dire non les processus métier), l’utilisation d’un moteur de règles métier peut être nécessaire.

Answer 3

Ma courte réponse rapide est NON, ce n’est pas sa responsabilité.

Je préférerais laisser cela à BPEL ou à une suite BPM.

Mhh je ne sais pas quoi ajouter :) ... Bonne chance?

Answer 4

Maintenant ma propre vision.

En ce qui concerne tout le travail qu'un ESB doit faire, placer l'orchestration de service dans l'élément principal d'infrastructure de votre SOA n'est pas une bonne idée.

Agrégé, d'accord! Mais garder votre canal de communication occupé avec la logique métier aura certainement un impact terrible sur la capacité à fournir d'autres fonctionnalités.

Après tout, la plupart des ESB , tels que BEA Aqualogic Service, offrent un support limité pour l'orchestration , notamment le manque de capacités avec état et des activités telles que wait (une minuterie) ou pick (attendez que certaines entrées bougent dans le processus), capacités de scission / jointure (déjà ajoutées dans ALSB 3.0), etc.).

Pas question. Utilisez simplement des outils comme un moteur BPEL ou un outil tel que Weblogic Integration.

Merci.

Answer 5

Chaque fois que vous avez deux services ou plus en interaction, utilisez Service Orchestrator, c’est-à-dire pour les services de contrôle de composition et de processus. Si vous avez esb, exposez ce service de composition sur esb. Maintenant, si vous devez composer un nouveau service qui inclut ce service de composition, utilisez orchestrator et exposez-le à nouveau sur esb. Utilisez esb comme mécanisme de prestation de services, ainsi qu’un courtier et un proxy de service Web. Lors de la composition d'un service orchestrator utilisera esb pour accéder aux services en interaction. Si ces services en interaction utilisent des schémas xml incompatibles, esb peut les transformer / les mapper en un schéma commun dans l'exécution et les demandes de service d'acheminement en fonction du contenu, par exemple espace de noms.

Answer 6

Oui, l’orchestration est une responsabilité du BSE dans la plupart des cas. Ou bien, si vous tracez une ligne de démarcation entre infra ESB et infra d'orchestration, vous le faites physiquement pour des raisons de performances et non pour l'attribution logique de responsabilité.

Vous avez le choix entre deux options: lorsqu'un système de RH, par exemple, reçoit un nouvel employé. Où placez-vous la logique applicative indiquant que "le service de la conformité doit d'abord approuver et vérifier, puis si tout va bien? Le service des ressources humaines devra finaliser le recrutement, puis le service de la comptabilité aura besoin d’une nouvelle entrée, puis le système de paye devra être mis à jour, et si cela échoue, nous devrons alors envoyer un courrier électronique aux ressources humaines. Si tous les processus métier sont considérés comme "détenus" par le service / l'application initiateur, le système global de l'entreprise devient complexe, avec des systèmes d'orchestration disparates.

Le deuxième choix est de centraliser l’orchestration, ce qui en fait essentiellement un partenaire logique de la plate-forme de messagerie. Si vous choisissez de les voir comme des artefacts distincts, c'est à vous de décider, mais il est également valable de les décrire en tant que ESB.

Answer 7

Un bus de service d'entreprise ne devrait jamais être responsable de l'orchestration des services.

Orchestration implique un minimum de "intelligences", en particulier la capacité de compenser les transactions ayant échoué. Les outils de bus de service diront souvent qu’ils proposent " try-catch " ou quelque chose comme ça, mais la capacité à exécuter une componsation étendue est la marque d'un outil d'orchestration approprié. De plus, la capacité d'attendre, de connaître son propre état ou de garder les choses en suspens est un autre indicateur du fait que vous avez affaire à un orchestrateur et non à un bus.

En parlant de plus de 1000 étapes et de dizaines de services, considérez que le processus est en cours. Si toutes les instructions if-then de vos 1 000 étapes ne concernent que le routage sans modification des données utiles, vous êtes toujours dans le mode "routage". et donc toujours en ESB. Mais s'il y a même un imbriqué si-alors et je commence à chercher des outils différents. De plus, si cela ressemble à du routage, cela peut très rapidement avoir un impact sur la logique métier. Dès que la logique métier commence à apparaître, un meilleur langage, tel que BPEL ou BPMN, est préférable.

L’exemple d’un chef d’orchestre est souvent donné pour décrire le fonctionnement de l’orchestration, une personne centrale dirigeant les musiciens en fonction d’une partition. Ce qui est souvent négligé, c'est l'idée que le chef d'orchestre non seulement dirige, mais écoute aussi, et que si quelque chose ne va pas, on peut compenser de manière fiable et reproductible.

Par exemple, imaginons que notre premier chef va faire venir le joueur de tuba mais que ce joueur ait décidé d’aller faire autre chose. Un "orchestrateur" de style flipper simple apportera la section tuba, sachant très bien que ce n’est pas là, puis attendra que le public se plaint plus tard. Un chef d'orchestre très avisé verrait le tuba disparu et ferait immédiatement remonter les cornes plus profondes du baryton pour compenser.