Partager via

BizTalk Server 2006 ou WF ? Choix de l’outil de flux de travail approprié pour votre projet

  • Article

Kent Brown

twentysix New York (www.26ny.com)

Novembre 2007

Révision de février 2008

S’applique à :

   Microsoft BizTalk Server 2006

   Windows Workflow Foundation

Résumé : Cet article fournit des conseils pour choisir entre Microsoft BizTalk Server 2006 et Windows Workflow Foundation dans divers scénarios de flux de travail Application et Intégration d’entreprise. (16 pages imprimées)

Contenu

Introduction

Processus de choix de l’outil de flux de travail approprié

Scénarios de flux de travail courants

Tout est dans l’hôte

recommandations Workflow-Technology

Future-Proofing

Conclusion

Addendum

Remerciements

Plus d’informations

Introduction

Le flux de travail est omniprésent dans les processus métier quotidiens, de sorte qu’un besoin courant consiste à trouver des outils de programmation qui prennent directement en charge la création de solutions de flux de travail. Microsoft BizTalk Server 2006 et Windows Workflow Foundation (WF) sont les deux principaux outils de Microsoft pour la programmation des solutions de flux de travail. Toutefois, en raison du chevauchement apparent entre eux, de nombreux architectes et développeurs ont des difficultés à décider quelle technologie de flux de travail est logique à leurs fins.

Cela est particulièrement vrai étant donné que WF a été clairement identifié comme la technologie de flux de travail préférée à l’avenir, tandis que BizTalk Server 2006 est toujours le produit de serveur Premium pour l’intégration d’entreprise. Jusqu’à ce que l’orchestration BizTalk Server prenne entièrement en charge WF, les architectes et les développeurs doivent choisir soigneusement dans quelle technologie investir.

L’un des défis liés au choix de la technologie appropriée pour l’implémentation du flux de travail est que le flux de travail peut signifier de nombreuses choses, entre elles :

  • Flux d’écrans d’interface utilisateur avec lesquels un utilisateur interagit pour effectuer une tâche.
  • Flux de logique métier au sein d’une application ou d’un service.
  • Interaction de plusieurs êtres humains pour terminer un processus métier.
  • Coordination de plusieurs échanges de messages entre les systèmes pour traiter une transaction métier.
  • Coordination des étapes pour extraire, transformer et charger des données (ETL) dans une base de données.

Bien que le spectre des scénarios de flux de travail soit large, il est utile de les regrouper en quatre grandes catégories : de flux de travail humain , flux de travail d’application, flux de travail d’intégration d’entrepriseet flux de travail d’intégration des données.

Parmi les quatre principales catégories de flux de travail, le flux de travail d’application et le flux de travail d’intégration d’entreprise sont les deux domaines dans lesquels les personnes trouvent difficile de choisir une technologie. Les scénarios de flux de travail humain et de flux de travail d’intégration des données sont relativement simples, du point de vue de la sélection des outils. Le flux de travail humain nécessite une interface utilisateur et est souvent centré sur les documents, afin que Microsoft Office SharePoint Server 2007 soit la plateforme recommandée pour créer des solutions de flux de travail humain. Microsoft SQL Server Integration Services (SSIS) est l’outil recommandé pour les scénarios d’intégration de données.

Cet article fournit des conseils pour choisir entre BizTalk Server 2006 et WF dans les scénarios de flux de travail d’application et d’intégration d’entreprise.

Moteur d’orchestration BizTalk Server

Le moteur d’orchestration BizTalk Server a toujours été l’une des fonctionnalités attrayantes de BizTalk Server. Lorsqu’il a été introduit, il s’agissait du meilleur outil disponible par Microsoft pour effectuer une programmation centrée sur les flux de travail. L’orchestration BizTalk Server fournit un environnement de programmation visuel permettant de développer des composants pour contrôler les flux de messages complexes et multistep pour effectuer une transaction métier particulière.

Les artefacts de code d’orchestration BizTalk Server ressemblent étroitement aux diagrammes d’activité UML (Unified Modeling Language) qu’un analyste métier peut produire pour documenter un processus métier. Ces artefacts peuvent ensuite être compilés et exécutés dans le runtime du moteur d’orchestration, qui fournit des services tels que les transactions de longue durée et la compensation, la durabilité, la tolérance de panne et la récupération d’urgence, qui sont essentiels pour la création de systèmes qui automatisent les transactions métier critiques.

Une fondation de flux de travail pour l’avenir

Bien qu’il existe des catégories distinctes de scénarios de flux de travail, il existe suffisamment de scénarios communs entre les scénarios, du point de vue de la programmation, pour faire en sorte qu’il vaut la peine d’essayer d’établir un framework commun pour le développement de flux de travail. Le moteur d’orchestration dans BizTalk Server est puissant, mais il n’a jamais été conçu pour être utilisé en dehors de BizTalk Server ; Il n’est donc pas possible de réaffecter efficacement l’orchestration BizTalk Server pour les autres catégories de flux de travail.

WF, qui est publié dans Microsoft .NET Framework 3.0, introduit un modèle de programmation visuel centré sur le flux de travail dans le .NET Framework qui est conçu pour être général et extensible suffisamment pour être utilisé dans tous les scénarios liés au flux de travail sur la plateforme Windows à l’avenir. L’équipe qui a produit WF a pu prendre les meilleurs concepts du moteur d’orchestration BizTalk Server, prendre en compte les exigences du domaine plus large des scénarios de flux de travail et concevoir une infrastructure suffisamment flexible pour les prendre en charge.

Comme preuve de la flexibilité de WF, Microsoft Office SharePoint Server 2007 l’utilise pour implémenter des solutions de flux de travail humain. L’intention est que les fournisseurs de BPM tiers créent également leurs solutions en plus de WF, au lieu de créer leurs propres moteurs de flux de travail propriétaires ; plusieurs fournisseurs l’ont déjà fait. Les développeurs individuels peuvent également utiliser WF pour implémenter un flux de travail d’application personnalisé dans des applications .NET Framework. Le plan est également destiné à une future version de BizTalk Server pour implémenter le moteur d’orchestration sur WF pour implémenter des solutions de flux de travail d’intégration d’entreprise.

Figure 1. Utilisation de l’outil de flux de travail approprié : BizTalk Server 2006 et WF

Processus de choix de l’outil de flux de travail approprié

Notre méthode pour fournir des conseils pour vous aider à déterminer l’outil de flux de travail adapté à votre projet consiste à délimiter les scénarios de flux de travail les plus courants, afin que vous puissiez déterminer le scénario ou la combinaison de scénarios qui conviennent le mieux à votre projet. Ensuite, nous vous fournirons des conseils spécifiques pour chaque scénario sur l’outil qui ( BizTalk Server 2006 ou WF) est le meilleur ajustement et pourquoi. En outre, nous allons utiliser le modèle APIO (Application Platform Infrastructure Optimization), un modèle pour évaluer la maturité des fonctionnalités de développement et de plateforme d’application d’une organisation, afin de fournir des conseils spécifiques à l’organisation dans les scénarios dans lesquels l’un des deux outils peut être utilisé efficacement. Enfin, nous examinerons la feuille de route pour BizTalk Server 2006 et WF, afin que vous puissiez prendre les meilleures décisions pour la vérification future des applications que vous créez aujourd’hui.

Scénarios de flux de travail courants

Même après avoir limité notre étendue aux catégories Application et Intégration d’entreprise de flux de travail, il existe toujours un large éventail de scénarios de flux de travail à prendre en compte. Comme le montre la figure 2, d’un côté du spectre sont des scénarios dans lesquels WF est clairement le bon choix. Par exemple, il s’agit d’une fonctionnalité de flux de travail au sein d’un produit indépendant fournisseur de logiciels (ISV), où les coûts de licence et la complexité du déploiement de BizTalk Server 2006 seraient prohibitifs. Dans ce scénario, en tant qu’éditeur de logiciels indépendants, vous êtes dans l’entreprise de fabrication de logiciels commerciaux, et l’effort de programmation supplémentaire requis pour héberger gratuitement la redevance WF est un investissement raisonnable.

Figure 2. Continuum d’intégration et de flux de travail

De l’autre côté du spectre sont des solutions d’intégration d’entreprise qui sont créées dans un service informatique d’entreprise, où clairement BizTalk Server 2006 est le bon choix. Dans ce scénario, vous souhaitez vous concentrer sur la production de valeur métier, au lieu d’investir dans la construction de la « plomberie » pour rendre votre solution évolutive, fiable et gérable ; Ainsi, le coût de licence de BizTalk Server 2006 vaut bien la peine, en raison de ce qu’il fournit.

La plupart des projets se situent entre ces deux extrémités du spectre. Voici quelques scénarios courants dans lesquels les exigences dictent une solution de flux de travail :

  • contrôleur de page d’interface utilisateur: une exigence courante dans les applications complexes consiste à appliquer la navigation à l’écran de l’interface utilisateur en fonction des règles métier du cas d’usage spécifique en cours d’implémentation. L’exemple le plus simple est un Assistant qui guide l’utilisateur dans un ensemble d’écrans prescrit pour accomplir une tâche. Souvent, il s’agit d’un graphique plus complexe des possibilités de navigation à l’écran basées sur les actions de l’utilisateur et l’état des données.
    Le modèle MVC (Model-view-controller) est la technique classique permettant d’extraire cette logique de navigation des formulaires eux-mêmes, afin qu’elles soient plus simples et plus réutilisables dans différents cas d’usage. Le contrôleur dans le modèle MVC est vraiment un flux de travail ou un ordinateur d’état ; Il est donc naturel de rechercher un outil de flux de travail dans l’implémentation de ces types d’applications.
  • logique métier longue: lorsque de nombreuses étapes sont nécessaires pour effectuer une transaction métier, l’utilisateur peut être amené à s’arrêter au milieu du processus ou à attendre des actions d’autres utilisateurs ou systèmes avant de continuer. La possibilité de suspendre temporairement (ou de « mettre en veille prolongée ») un processus, puis de le redémarrer, en fonction des événements externes, est essentiel à l’idée du flux de travail. Sans moteur de flux de travail, les développeurs sont obligés de concevoir et de coder manuellement les mécanismes permettant de stocker l’état d’un processus incomplet et de rappeler cet état lorsque le processus est poursuivi. Avec un moteur de flux de travail bien conçu, cette fonctionnalité est prise en charge en mode natif sans travail supplémentaire pour les développeurs.
  • flux de processus pouvant être mis à jour dynamiquement: bien qu’il semble possible d’abord de codifier les processus métier en étapes séquentielles bien définies, les humains doivent souvent modifier le flux intermédiaire pour tenir compte des situations réelles. Dans un processus d’approbation des dépenses, le responsable de l’employé qui a soumis le rapport de dépenses peut être l’approbateur par défaut. Toutefois, le responsable peut décider de déléguer la tâche à un secrétaire (par exemple, parce que le responsable est dirigé vers le golf) ou d’élever l’approbation à un supérieur (par exemple, parce que le responsable n’est pas sûr de la politique pour une dépense particulière). Permettre à l’utilisateur de mettre à jour le flux est souvent plus simple que d’essayer d’anticiper chaque permutation possible du flux à l’avance.
  • abstraction des règles de la logique métier: dans ce scénario, votre objectif est de séparer les règles métier d’une autre logique métier. Un bon exemple est les règles de validation de formulaire. Dans un programme d’application hypothécaire, le formulaire demande de prêt peut avoir un ensemble de règles de validation de champ avant que l’utilisateur puisse appuyer sur le bouton Envoyer pour soumettre une demande de prêt. Si le même formulaire est utilisé par l’agent de prêt pour examiner et approuver le prêt, des règles de validation supplémentaires sont requises, car elle se trouve à un stade différent du processus.
    L’implémentation des règles de validation séparément du formulaire facilite la réutilisation du formulaire dans différents scénarios et l’application des règles de validation appropriées simplement en évaluant l’ensemble approprié de règles pour ce scénario.
  • 'aggregator de service web: les applications doivent souvent agréger des données à partir de plusieurs services Web différents. Dans de nombreuses situations, la logique d’agrégation elle-même peut et doit être extraite de l’application et exposée en tant que service à son propre droit qui peut être réutilisée à partir d’autres applications. Ces services sont souvent appelés services web composites, et ils constituent un élément important d’une architecture orientée service mature. Le scénario Aggregator du service web est généralement synchrone et court.en cours d’exécution.
  • processus métier long terme: le scénario Long Running Business Process est utilisé dans cet article pour désigner des processus basés sur le serveur qui intègrent plusieurs applications, tandis que logique métier est utilisée pour la logique au sein d’une seule application. Les exigences de ces processus métier longs basés sur le serveur pour le multithreading, le comportement asynchrone, la persistance de l’état du processus, la corrélation des messages aux instances de processus, la scalabilité, la fiabilité, l’intégrité transactionnelle, etc. sont beaucoup plus élevées que pour la logique métier au sein d’une application.
  • processus métier à entreprise (B2B): le scénario de processus B2B est essentiellement identique au scénario de processus métier à long terme, sauf que l’ancien est entre les organisations en plus des applications internes. Les exigences de sécurité sont donc primordiales. En outre, vous avez encore moins de contrôle sur le format de données et le protocole de transport spécifiques, car ceux-ci peuvent être dictés par votre partenaire commercial ; Vous avez donc besoin de la possibilité de prendre en charge un large éventail de formats et de protocoles et de prendre en charge la configuration des échanges spécifiques pour un grand nombre de partenaires.
  • abstraction des règles du processus métier: de la même façon que l’abstraction des règles à partir du scénario de logique métier, ce scénario s’applique lorsque vous souhaitez séparer les règles métier du code principal dans le scénario processus métier long et le scénario de processus B2B. Ce scénario nécessite un niveau de performances et d’extensibilité plus élevé. En outre, il aura probablement besoin d’outils pour permettre aux non-programmeurs d’afficher et de modifier les règles.
  • référentiel de règles d’entreprise: dans ce scénario, l’objectif est de créer un référentiel de règles partagées centralisée qui peut être appelé à partir de toutes les applications de l’entreprise. Cela fournit une cohérence entre toutes les applications d’une organisation pour appliquer des règles métier importantes. De même que l’abstraction des règles à partir du scénario de processus métier, ce scénario nécessite une scalabilité et des outils élevés pour permettre aux non-programmeurs d’afficher et de modifier les règles. En outre, ce scénario exige que le référentiel de règles soit capable d’être existant en tant qu’entité propre dans l’entreprise, avec son propre mécanisme d’hébergement distinct du moteur de flux de travail et avec des composants ou des API pour l’exécution des règles à partir de différentes applications.
  • Enterprise Service Bus (ESB)/Message Broker: de nombreuses organisations souhaitent une infrastructure de communication standardisée pour tous les services. Les deux topologies les plus courantes pour cette infrastructure sont l’ESB et le répartiteur de messages. La messagerie de publication/abonnement et le routage de base de rubriques sont généralement les fonctionnalités attendues de cette infrastructure.

Modèle d’optimisation de l’infrastructure de plateforme d’applications

Dans certains scénarios de flux de travail, BizTalk Server 2006 et WF répondent de manière satisfaisante aux exigences techniques. Pour ces scénarios, faire le bon choix de technologie de flux de travail nécessite de correspondre à la solution aux besoins de l’organisation spécifique. À des fins d’élaboration de recommandations qui s’appliquent à votre organisation particulière, nous allons utiliser le modèle APIO (Application Platform Infrastructure Optimization), comme illustré dans la figure 3.

Figure 3. Modèle APIO (Application Platform Infrastructure Optimization)

Le modèle APIO est une technique permettant de profiler la maturité d’une organisation en ce qui concerne son infrastructure d’application, son architecture et ses pratiques de développement. L’objectif de ce modèle est de donner aux organisations une feuille de route pour optimiser leur agilité en fournissant des solutions informatiques pour répondre aux besoins de l’entreprise.

Le modèle APIO utilise les quatre profils suivants de maturité d’une organisation :

  • de base : les organisations traitent les logiciels comme un coût. Ils ont en grande partie des applications en silo avec peu d’intégration ou de réutilisation. Les applications dont elles disposent peuvent se trouver sur diverses plateformes. Ils n’ont pas de normes cohérentes pour les techniques d’infrastructure ou de développement ; ils n’ont pas de vision architecturale cohérente.
  • standardisée : les organisations traitent toujours les logiciels comme un coût, mais elles ont pris des mesures pour améliorer l’efficacité. Ils ont une vision architecturale et essaient d’envisager des opportunités de réutilisation. Ils ont commencé à intégrer certaines applications, mais ils sont principalement des intégrations point à point.
  • advanced: les organisations traitent les logiciels comme un outil d’activation métier. Ils ont des architectes dédiés et une vision architecturale claire. Ils ont de nombreux services et obtiennent un niveau élevé de réutilisation. Tous les processus métier de base sont automatisés et surveillés. Ils utilisent une plateforme d’intégration centralisée et empaquetée.
  • dynamique : les organisations traitent les logiciels comme une ressource stratégique. Ils ont un SOA très mature dans la vision et la mise en œuvre. Ils ont des processus clairs pour le contrôle de version dynamique et le redéploiement des services. L’entreprise peut s’adapter rapidement aux changements des besoins de l’entreprise et s’intégrer rapidement aux nouveaux partenaires commerciaux.

Ce n’est pas seulement là où vous êtes, mais où vous allez

Quelque peu implicite dans le modèle APIO est l’idée que chaque organisation aspire à se déplacer vers le profil dynamique. En réalité, cela dépend de la nature de l’entreprise et de la philosophie de la gestion concernant la technologie. Certaines entreprises peuvent être entièrement satisfaites de rester dans le profil de base ou standardisé.

Vous devez considérer le profil actuel, ainsi que les objectifs à court terme et à long terme, avec l’objectif à court terme étant le plus important. Une organisation dans le profil de base, avec un désir d’être dans le profil dynamique éventuellement, peut choisir sagement de se concentrer initialement sur l’entrée dans le profil standardisé ; ainsi, ses décisions technologiques doivent être principalement cohérentes avec le profil standardisé.

En général, BizTalk Server 2006 sera un meilleur ajustement dans les organisations qui sont — ou qui ont un objectif à court terme — dans le profil avancé ou dynamique. Une organisation dans le profil de base relativement satisfaite dans ce profil n’a peut-être ni la motivation stratégique pour adopter BizTalk Server 2006 ni les capacités de tirer parti de celle-ci efficacement ; ainsi, ils ne voudraient probablement pas faire l’investissement. Toutefois, si une organisation du profil De base a pris une décision de passer de manière agressive au profil Avancé, l’adoption de BizTalk Server 2006 peut être une étape stratégique dans cette direction.

Le point d’introduction du modèle APIO dans la discussion est qu’avoir une bonne idée des profils APIO actuels et ciblés de l’organisation aidera à décider entre WF et BizTalk Server 2006, lorsque le scénario technique pourrait être bien pris en charge par l’une ou l’autre technologie. Deux organisations différentes peuvent bien faire des choix différents : chacune faisant le bon choix pour son profil organisationnel.

Tout est dans l’hôte

L’un des aspects les plus importants à prendre en compte lors du choix entre BizTalk Server 2006 et WF est la configuration requise pour l’hébergement de vos flux de travail. Contrairement à BizTalk Server 2006, WF ne fournit pas d’hébergement « prête à l’emploi » ; vous devez implémenter un hôte qui établit le processus Windows et démarre le moteur d’exécution de flux de travail dans lequel vos flux de travail s’exécuteront.

Pour créer une infrastructure qui peut prendre en charge le spectre complet des scénarios de flux de travail de manière réaliste, WF extrait les comportements principaux qu’un environnement tel que BizTalk Server 2006 fournit, afin que différents hôtes puissent fournir le comportement souhaité spécifique pour ces services.

Les principaux services fournis par un hôte de flux de travail WF sont les suivants :

  • service de planification: crée et gère les threads utilisés par le moteur d’exécution pour exécuter des instances de flux de travail.
  • le service Commit Work Batch: gère les transactions utilisées par le moteur d’exécution pour les opérations de base de données.
  • service de persistance: gère la persistance de l’instance de flux de travail lorsqu’elle est dirigée pour le faire par le moteur d’exécution. Ce service est facultatif. S’il n’est pas fourni, les instances de flux de travail ne sont pas conservées et doivent s’exécuter en mémoire pendant toute leur durée de vie.
  • service de suivi: permet d’enregistrer les événements de suivi dans les flux de travail. Ce service est facultatif.

Ce qu’il faut pour générer un hôte de flux de travail

Selon votre scénario de flux de travail et les services que vous devez fournir à vos flux de travail, la création d’un hôte WF peut être triviale ou prohibitive. Pour les scénarios dans lesquels le flux de travail se trouve dans le contexte d’une application, l’hébergement de WF est assez simple. L’application elle-même agit en tant qu’hôte de processus et il existe des implémentations standard des services de base qui peuvent être configurés avec un effort minimal.

Toutefois, la sophistication nécessaire de l’hôte saute considérablement lorsque vous accédez à des scénarios hautement évolutifs basés sur le serveur. Le tableau 1 présente une liste de services hôtes qui peuvent être nécessaires, dont la plupart sont fournis dans BizTalk Server 2006.

Tableau 1. Services hôtes

  • Configuration de scale-out
  • Équilibrage
  • Basculement
  • Strangulation
  • Gestion des threads
  • Gestion de la mémoire
  • Isolation du service
  • Configuration des exceptions
  • Gestion des messages ayant échoué
  • Suivi des messages
  • Archivage et purge
  • Identité et emprunt d’identité
  • Modèle de déploiement multi-environnement
  • Surveillance de l’intégrité
  • Suivi des performances/utilisation
  • Gestion de l’état du processus composite
  • Script
  • Récupération d’urgence
  • Conformité réglementaire
  • Gestion de la configuration

Quelle entreprise êtes-vous dans, quoi qu’il en soit ?

Si vous êtes chargé de créer une application spécifique avec des délais serrés, vous ne souhaitez probablement pas que votre équipe soit distraite en ayant à créer un hôte complexe lorsqu’il doit se concentrer sur l’implémentation de la logique métier nécessaire. Dans ce cas, BizTalk Server 2006 vaut bien la peine d’acheter , au lieu de tenter de créer – un hôte de flux de travail robuste. Si vous faites partie de l’équipe architecturale centrale d’une grande entreprise, vous pouvez choisir d’investir dans la construction d’un hôte qui pourrait être utilisé au sein de l’organisation. Même si, cet effort ne devrait pas être pris légèrement.

recommandations Workflow-Technology

Pour les scénarios au sein d’une application : WF

Pour tous les scénarios contenus dans une application, notamment le contrôleur de page d’interface utilisateur, la logique métier à long terme, le flux de processus pouvant être mis à jour dynamiquement, la composition de service web et l’abstraction des règles de la logique métier, WF est le bon choix de technologie de flux de travail.

Dans la majorité des scénarios centrés sur l’application, le modèle d’utilisation nécessite une interaction synchrone et faible latence entre l’application et le flux de travail, ce qui n’est pas la force de BizTalk Server 2006. BizTalk Server 2006 ne serait pas adapté à ces scénarios, pour des raisons de performances ; Les orchestrations BizTalk Server s’exécutent sur des serveurs BizTalk Server dédiés, et l’appel d’une application cliente nécessite un aller-retour sur le réseau. En outre, la conception de BizTalk Server 2006 de persistance de chaque message à la base de données MessageBox pour la durabilité introduit une latence supplémentaire, ce qui peut ne pas être acceptable dans le contexte d’une interface utilisateur interactive, si le flux de travail doit être appelé de façon synchrone.

WF est un meilleur ajustement pour ces scénarios ; il répond aux exigences de flux de travail, et il est plus simple et moins cher que BizTalk Server 2006. Les fonctionnalités de messagerie de BizTalk Server 2006( par exemple, le mappage et les adaptateurs) ne sont pas nécessaires dans ces scénarios. Les conditions requises pour les services d’hébergement sont modestes, de sorte que l’hébergement du runtime WF à l’intérieur de l’application ne nécessite pas une quantité de travail prohibitive.

Pour la plupart des scénarios Business-Process : BizTalk Server 2006

Pour la plupart des scénarios qui impliquent des processus métier basés sur le serveur, BizTalk Server 2006 est le bon choix. Il s’agit notamment du processus B2B, de l’abstraction des règles à partir du processus métier, du référentiel de règles d’entreprise et d’Enterprise Service Bus (ESB)/Message Broker.

Ces scénarios nécessitent une scalabilité élevée. En outre, ils nécessitent la possibilité d’afficher les processus en cours d’exécution et de les arrêter et de les redémarrer. Enfin, ils nécessitent la prise en charge du scale-out vers plusieurs serveurs. Dans ces scénarios, les fonctionnalités d’hébergement avancées de BizTalk Server 2006 sont nécessaires et valent bien l’investissement.

Basique Normalisé Avancé Dynamique

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

Figure 4. Scénario de processus métier à long terme

BizTalk Server 2006 sera généralement la meilleure plateforme pour le scénario de processus métier long. Ces processus ont tendance à être asynchrones, longs et avec état. Ces processus sont souvent essentiels à l’organisation ; par conséquent, ils nécessitent une haute disponibilité, une visibilité, une sécurité et une facilité de gestion. La topologie groupe ou « batterie » de BizTalk Server 2006 vous permet de gérer un tableau de serveurs pour fournir une scalabilité et une redondance.

Le mécanisme de persistance de BizTalk Server 2006 pour le stockage de l’état du processus a une sécurité robuste intégrée pour protéger la confidentialité de l’état persistant, ce qui peut être important pour des raisons réglementaires. La supervision de l’activité métier (BAM) de BizTalk Server 2006 offre une visibilité appropriée au niveau de l’entreprise sur les processus en cours d’exécution de manière sécurisée. Enfin, ces scénarios nécessitent souvent la prise en charge des formats de messages hétérogènes et des protocoles de transport, y compris les systèmes hérités.

Pour ces raisons, BizTalk Server 2006 sera généralement le meilleur choix pour les organisations qui ciblent les profils standardisés, avancés et dynamiques. Ces organisations considèrent généralement que le scénario de processus métier à long terme est très important pour l’entreprise et très courant au sein de l’entreprise ; ainsi, ils achètent BizTalk Server 2006 spécifiquement pour établir une plateforme standardisée pour eux.

Toutefois, la WF peut être un meilleur choix pour les organisations qui se trouvent dans le profil APIO de base. Ces organisations ne cherchent généralement pas à investir dans la création d’une plateforme d’application standardisée. Au lieu de cela, ils cherchent à réduire les coûts, et les coûts de licence et de matériel de BizTalk Server 2006 peuvent être prohibitifs. L’exception à cette aide est lorsqu’il existe des exigences en matière d’extensibilité, de surveillance et de prise en charge d’un large éventail de formats de messages et de protocoles de transport. Dans ce cas, bien que l’organisation hésite à investir dans sa plateforme d’application, le coût de création des fonctionnalités d’hébergement et de messagerie à partir de zéro dépasserait probablement les coûts de BizTalk Server 2006.

Basique Normalisé Avancé Dynamique

WF

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

Figure 5. Scénario d’aggregator de service web

Les orchestrations BizTalk Server et les flux de travail WF prennent en charge fortement les services Web qui consomment en externe à partir d’un flux de travail et pour exposer le flux de travail en tant que service web. Par conséquent, pour créer des solutions Web Service Aggregator, tout comme pour les solutions de processus métier à long terme, le choix est déterminé par le profil organisationnel et les exigences d’hébergement.

Si le service Web d’agrégation consiste uniquement à agréger d’autres services Web, la capacité de BizTalk Server 2006 à prendre en charge les formats de messages hétérogènes et les protocoles de transport ajoutent peu de valeur. Toutefois, si le service doit également agréger des données à partir d’environnements hérités qui ne sont pas exposés en tant que services Web, BizTalk Server 2006 ajouterait de la valeur.

Étant donné que le modèle d’utilisation est rapide, les appels de requête/réponse synchrones, la durabilité des messages fournie par BizTalk Server 2006 n’est généralement pas importante. En fait, la latence introduite par la persistance dans MessageBox est en fait une responsabilité. La valeur principale que BizTalk Server 2006 fournit pour ce scénario est la possibilité de gérer le déploiement sur de nombreux serveurs et de surveiller les instances en cours d’exécution. La fonctionnalité BAM de BizTalk Server 2006 peut également être utile pour surveiller que les contrats de niveau de service (SLA) sont respectés.

Pour ces raisons, WF est un très bon choix pour l’implémentation de Web Service Aggregators, en particulier dans les organisations dans les profils de base et standardisés. Un exemple dans lequel BizTalk Server 2006 peut être avantageux est celui dans lequel vous devez gérer un grand nombre de points de terminaison pour différentes organisations clientes. La configuration du port de réception et de l’emplacement de réception de BizTalk Server 2006 gère spécifiquement cela. Dans ce cas, les certificats peuvent également être importants et la prise en charge de BizTalk Server 2006 pour la configuration et la gestion des certificats et leur application au chiffrement/déchiffrement peut être utile.

Future-Proofing

Vous souhaitez vous assurer que vos investissements dans les coûts de licences logicielles, dans l’apprentissage d’une technologie de flux de travail et dans la création de composants de flux de travail spécifiques, vous fourniront la valeur la plus possible à l’avenir. Outre le choix du flux de travail approprié pour votre scénario de flux de travail et votre organisation spécifiques, vous devez également prendre en compte les cartes de route des produits pour BizTalk Server 2006 et WF. Il n’y a pas de réponse simple pour cela. Les commentaires qui suivent ne font pas d’argument fort pour choisir l’une ou l’autre technologie ; au lieu de cela, ils sont des points de données pour vous aider dans votre décision.

Ce que BizTalk Server 2006 R2 ajoute

BizTalk Server 2006 R2 ajoute deux fonctionnalités susceptibles d’affecter votre choix de plateforme de flux de travail : les adaptateurs WCF et les intercepteurs BAM pour WCF et WF.

Adaptateurs WCF

Si votre équipe a adopté Windows Communication Foundation (WCF) comme technologie standard pour l’implémentation de services dans la création de votre SOA, le fait que BizTalk Server 2006 n’a pas pris en charge WCF peut avoir été disqualifié comme une plateforme pour la création et l’hébergement de services web composites. Cela vous a peut-être poussé vers WF, même si BizTalk Server 2006 était sinon une correspondance idéale pour vos scénarios et profil APIO.

Heureusement, avec l’introduction d’une grande intégration WCF dans BizTalk Server 2006 R2, cela n’est plus une préoccupation. BizTalk Server 2006 a désormais une forte intégration avec WCF, et il s’agit d’une excellente plateforme pour créer des services composites à partir de services plus granulaires et exposer ces services composites en tant que services WCF.

Intercepteur BAM pour WF

La deuxième fonctionnalité BizTalk Server 2006 R2 pertinente est l’introduction de l’intercepteur BAM pour WF. Si la surveillance de l’activité métier est une fonctionnalité importante de votre solution, vous avez peut-être été poussé vers l’utilisation de BizTalk Server 2006, juste pour tirer parti de BAM, quand WF était autrement mieux adapté à votre scénario. Avec l’intercepteur BAM pour WF, vous pouvez choisir WF s’il s’agit de la technologie de flux de travail appropriée pour votre projet et utiliser BAM comme solution de supervision d’activité métier d’entreprise.

BAM est une fonctionnalité de BizTalk Server 2006 qui fournit une infrastructure permettant de capturer des événements et des données à partir d’orchestrations et de flux de messages BizTalk Server, et de présenter ces données dans un portail pour fournir à l’utilisateur professionnel une visibilité de bout en bout dans le processus métier. Un aspect puissant de la façon dont BAM fonctionne pour les applications BizTalk Server 2006 est que la surveillance BAM peut être configurée (ou « instrumentée ») une fois qu’une application BizTalk Server 2006 a été déployée, sans nécessiter de modifications aux artefacts de code BizTalk Server 2006.

BAM est conçu comme une solution de supervision de l’activité métier à l’échelle de l’entreprise ; Par conséquent, il est possible que les applications non-BizTalk Server 2006 alimentent des événements et des données dans BAM. Toutefois, les API pour cela nécessitent un peu de code à écrire dans les applications externes. L’intercepteur BAM WF dans BizTalk Server 2006 R2 offre la possibilité d’instrumenter les flux de travail WF pour BAM plus simplement et sans nécessiter de modifications de code. En utilisant les intercepteurs BAM, vous pouvez suivre vos processus métier sans recompiler votre solution WF ou WCF ; l’intégration est effectuée via un fichier de configuration.

Extensions BizTalk Server 2006 pour le Kit de développement logiciel (SDK) WF

Les extensions BizTalk Server 2006 pour le Kit de développement logiciel (SDK) WF ont été annoncées et démodées sur TechEd 2007. Ce KIT SDK fournit un mécanisme simple pour l’hébergement de flux de travail WF dans BizTalk Server 2006. Cet outil est destiné à être utilisé par les développeurs .NET qui créent des flux de travail WF aujourd’hui et cherchent un moyen simple d’obtenir un hébergement robuste et évolutif de ces flux de travail.

Le SDK fournit deux activités WF personnalisées ( une activité btsReceive et une activité btsSend) qui peuvent être utilisées dans un flux de travail WF pour recevoir et envoyer des messages via BizTalk Server 2006. En tant que développeur, vous définissez WCF DataContracts pour les messages entrants et sortants, ainsi qu’un ServiceContract pour définir le modèle d’échange de messages. Dans le flux de travail WF, les activités btsReceive et btsSend sont configurées pour utiliser la ServiceContractdéfinie, comme illustré dans la figure 6.

Figure 6. activités btsReceive et btsSend à utiliser dans serviceContract défini

Une fois le flux de travail WF terminé et compilé, cliquez avec le bouton droit sur le projet de flux de travail et sélectionnez Générer l’orchestration pour générer automatiquement une orchestration de wrapper (voir la figure 7) qui lancera le flux de travail WF et acheminera les messages BizTalk Server 2006 à la fois vers et à partir de celui-ci.

L’orchestration du wrapper généré automatiquement contient des schémas pour les messages définis dans le ServiceContract. Il contient également les formes et le code d’orchestration BizTalk Server pour la réception d’un message BizTalk Server 2006, la création et le démarrage de l’instance de flux de travail, la transmission de messages entrants dans l’instance de flux de travail, la réception des messages sortants et leur transfert vers le moteur de messagerie BizTalk Server 2006. Pour terminer l’hébergement de votre flux de travail WF, vous devez simplement compiler et déployer l’orchestration du wrapper et la lier à l’aide du mécanisme BizTalk Server 2006 normal.

Figure 7. Génération automatique d’une orchestration wrapper

En plus de tirer parti du mécanisme d’hébergement robuste et évolutif de BizTalk Server 2006 pour les flux de travail WF, les extensions BizTalk Server 2006 pour le SDK WF vous permettent de tirer parti de l’infrastructure de messagerie BizTalk Server 2006. Par conséquent, vous pouvez tirer parti des nombreux adaptateurs disponibles pour l’obtention de messages dans et hors de BizTalk Server 2006, ainsi que le traitement du pipeline, y compris les fonctionnalités de mappage.

Aussi puissantes qu’elles le sont, les extensions BizTalk Server 2006 pour le SDK WF doivent être utilisées comme outil pour permettre aux développeurs WF de déployer leurs flux de travail sur BizTalk Server 2006, et non pas comme remplacement des orchestrations dans les scénarios dans lesquels nous avons identifié BizTalk Server 2006 comme outil approprié. Certaines formes WF ne fonctionnent pas lorsqu’elles sont encapsulées dans une orchestration. Cela est dû au fait que l’hébergement de vos flux de travail WF à l’intérieur de BizTalk Server 2006 à l’aide des extensions BizTalk Server 2006 pour le SDK WF ne fournit pas le même comportement d’hébergement que les orchestrations natives. Le Kit de développement logiciel (SDK) contient une liste de questions fréquentes (incluse dans le Guide de démarrage rapide) qui présente ces différences.

Conclusion

BizTalk Server 2006 et Windows Workflow Foundation sont les principaux outils de Microsoft pour l’implémentation de solutions de flux de travail dans les catégories Application et Enterprise Integration Workflow. Pour choisir le bon choix pour votre projet, vous devez d’abord identifier les scénarios de flux de travail que vous ciblez.

Ensuite, utilisez le tableau de la figure 8 pour voir la technologie de flux de travail recommandée pour votre scénario. Pour le flux de travail au sein d’une application, nous vous recommandons WF. Pour la plupart des scénarios métier basés sur le serveur et B2B, nous vous recommandons BizTalk Server 2006.

Figure 8. Technologies de flux de travail spécifiques au scénario

Pour les scénarios Long Running Business Process et Web Service Aggregator, les deux technologies peuvent être appliquées de manière affective. Pour ces scénarios, vous devez évaluer le profil APIO cible actuel et à court terme de votre organisation. Les organisations qui se trouvent dans ou se déplacent vers les profils avancés ou dynamiques doivent utiliser BizTalk Server 2006 pour ces scénarios. Les organisations des profils De base et Standard peuvent utiliser efficacement WF pour ces scénarios.

Enfin, vous devez prendre en compte les dates de publication et la durée de vie souhaitée de votre solution, par rapport au plan de route produit pour BizTalk Server 2006 et WF. En utilisant cette infrastructure et les instructions de cet article, vous devez être en mesure de choisir le flux de travail approprié pour votre projet.

Addendum

Dissipez les idées fausses sur BizTalk Server 2006 et WF

Voici quelques idées fausses courantes concernant WF et BizTalk Server 2006 et les arguments de clarification que nous utilisons pour les dissiper :

  • WF est le remplacement de BizTalk Server 2006.Non. Étant donné que WF est la « dernière et la plus grande » offre de Microsoft pour les flux de travail de programmation, beaucoup qui ne connaissent pas BizTalk Server 2006 supposent initialement qu’elle a été rendue obsolète avec la version de WF. La réponse simple pour corriger cette impression est que WF est une infrastructure de développement de bas niveau pour la création de tous les types de flux de travail, tandis que BizTalk Server 2006 est un produit serveur complet avec des fonctionnalités avancées pour une catégorie spécifique de scénarios de flux de travail : Intégration d’entreprise. (Voir la figure 1.)
    WF fournit uniquement un petit sous-ensemble de cette fonctionnalité : flux de travail et règles métier. Bien que la fonctionnalité WF soit plus simple, une solution plus rentable pour les scénarios qui ne nécessitent pas toutes les autres fonctionnalités fournies par BizTalk Server 2006, ne supplante pas BizTalk Server 2006 pour les principaux scénarios d’intégration d’entreprise que BizTalk Server 2006 a été conçu pour prendre en charge.
  • BizTalk Server disparaît.Non. Une idée fausse similaire est l’impression que, étant donné que WF a été publié comme outil de flux de travail à l’avenir, et BizTalk Server n’a pas encore été réécrit pour utiliser WF, Microsoft n’investit plus dans BizTalk Server et le remplacera par un nouveau produit basé sur WF. Ce n’est tout simplement pas le cas ; BizTalk Server a été un produit très réussi, et la zone d’intégration d’entreprise qu’elle cible continue d’être un domaine que Microsoft s’engage à prendre en charge.
  • Vous devez choisir BizTalk Server 2006 sur .NET Framework.Non. Il peut être tentant pour les développeurs .NET qui ne sont pas familiarisés avec BizTalk Server 2006 de choisir WF sur BizTalk Server 2006, juste sur la base qu’ils préfèrent « pure » .NET. Toutefois, ce n’est vraiment pas un critère utile ; BizTalk Server 2006 lui-même est basé sur le .NET Framework.
    En fait, BizTalk Server 2006 représente plus de 2 millions de lignes de code .NET qui peuvent être appliquées à votre solution, ce qui vous permet de gagner du temps, des problèmes et du coût du développement de ses fonctionnalités à partir de zéro. En outre, la programmation BizTalk Server 2006 elle-même est effectuée à l’intérieur de Microsoft Visual Studio .NET, et les composants sont compilés et déployés en tant qu’assemblys .NET. En outre, les projets BizTalk Server 2006 les plus importants combinent des composants BizTalk Server 2006 avec des composants .NET personnalisés ; Par conséquent, le développement BizTalk Server 2006 doit être considéré comme un développement .NET spécialisé, au lieu d’un élément étranger ou différent.
    La vraie question est de savoir si les fonctionnalités bizTalk Server 2006 fournissent suffisamment de valeur pour votre scénario de flux de travail particulier afin de justifier les coûts de licence. Vous ne voulez pas utiliser un sedgehammer pour accrocher des images ; ni ne voulez-vous utiliser le marteau d’un charpentier pour écraser de grandes roches.
  • Le plus de fonctionnalités gagne.Un mauvais choix. Nous pourrions mettre en place une matrice de caractéristiques qui compare les caractéristiques granulaires de WF à celles de BizTalk Server 2006. Toutefois, cette comparaison ne serait pas très utile ; BizTalk Server 2006 a un si grand nombre de fonctionnalités qui sont spécifiquement ciblées sur l’espace d’intégration d’entreprise. Si ce n’est pas votre scénario cible, les comparaisons de fonctionnalités sont sans signification. BizTalk Server 2006 gagnerait probablement, en termes de nombre de cases à cocher de fonctionnalités ; Toutefois, il s’agit d’une comparaison apples-to-oranges, si ces fonctionnalités ne sont pas liées au scénario de flux de travail que vous ciblez.

Remerciements

J’aimerais remercier Paul Andrew et Kris Horrocks, et tout le monde qui a examiné cet article.

Plus d’informations

À propos de l’auteur

Kent Brown est le directeur et l’architecte principal de la pratique d’intégration d’entreprise à vingtsix New York, un partenaire de conseil Microsoft Gold Certified à New York. Il a été excité à propos de BizTalk Server depuis sa création en 2000, et a joué un rôle d’évangéliste autour du produit depuis sept ans. Kent est membre de l’équipe de spécialistes techniques virtuels Microsoft BizTalk, ainsi qu’un MVP de développeur de systèmes connectés Microsoft. Il est le fondateur et leader du nyC Connected Systems Users Group (http://www.NYCCSUG.org).