Assemblys BizTalk
L'aspect le plus important de Microsoft BizTalk Server et de .NET FRAMEWORK est que tous les artefacts BizTalk Server, à savoir les mappages, schémas, orchestrations et pipelines, sont compilés dans des assemblys .NET. Les deux principales implications d'une telle conception sont que ces assemblys doivent avoir des noms forts. De ce fait, ils suivent également les règles d'établissement de versions .NET. La principale implication de tout ceci est qu'un projet BizTalk, une fois élaboré à partir d'une version donnée d'un autre projet .NET ou assembly (incluant des projets BizTalk), continue à utiliser cette version jusqu'à ce qu'il soit reconstruit à partir d'une version plus récente.
Établissement de versions .NET et assemblys
Un problème d'établissement de versions .NET se produit fréquemment pendant le développement lorsque les numéros de version d'un projet BizTalk ne sont pas modifiés et que l'assembly est redéployé sans arrêter et démarrer l'instance de l'hôte BizTalk dans laquelle les types sont chargés.
Quand le processus est exécuté à nouveau, les modifications ne prennent pas effet. Ceci est dû au mode de chargement en mémoire des assemblys .NET. Dans la mesure où l'hôte possède déjà une copie de l'assembly en mémoire, il ne recharge pas ce dernier lorsqu'une nouvelle copie est placée dans le Global Assembly Cache. Par exemple, si la version 1.0.0.0 d'un assembly avec orchestration est déployée et exécutée, et que des modifications sont apportées à l'orchestration mais que le numéro de version n'est pas modifié, les modifications ne prennent pas effet. Une fois l'instance de l'hôte arrêtée, la copie en mémoire de l'assembly est publiée. Ensuite, lorsque l'instance de l'hôte redémarre, elle recharge la copie nouvelle de l'assembly et reçoit les modifications. Si une nouvelle version, par exemple la version 2.0.0.0, a été déployée et chargée, les modifications prennent alors effet.
Le déploiement d'assemblys sur BizTalk Server est un processus en deux parties. La première étape consiste à déployer l'assembly .NET traditionnel dans lequel l'assembly avec nom fort est déployé sur le GAC de chacun des serveurs sur lesquels l'assembly sera utilisé. La deuxième étape consiste à déployer les métadonnées relatives aux assemblys et à leur type dans la base de données de gestion BizTalk Server. Lorsque des assemblys BizTalk Server sont chargés par BizTalk Server, ils sont en général chargés en utilisant leur nom fort, stocké dans la base de données de gestion.
Déploiement d'assemblys BizTalk Server sur le GAC
Les artefacts BizTalk Server créés par un développeur sont compilés dans des classes qui dérivent de types BizTalk Server intégrés. Par exemple, une orchestration devient une classe qui dérive de la classe Microsoft.BizTalkXLANGs.BTXEngine.BTXService. Ceci s'explique par le fait que ces classes de base sont déployées dans des assemblys sur le GAC, lesquels ont des dépendances avec d'autres assemblys du GAC que leur développeur doit également déployer sur le GAC.
Une autre implication importante des artefacts BizTalk Server déployés dans le Global Assembly Cache et portant par conséquent un nom fort est que les assemblys avec nom fort ne peuvent pas appeler d'autres assemblys qui n'ont pas de nom fort. Cela signifie que tout assembly créé par un développeur et utilisé par ces assemblys BizTalk Server doit également porter un nom fort. De la même manière, les assemblys déployés sur le GAC et qui chargent d'autres assemblys sans utiliser de chemin d'accès spécifique doivent charger ces assemblys à partir du GAC.
Les composants de pipeline sont ajoutés à la boîte à outils d’un développeur dans Visual Studio pour les rendre disponibles pour être déplacés vers le concepteur de pipeline. Lorsqu'un pipeline BizTalk Server est compilé dans un assembly .NET, les informations relatives à tous les composants intervenant aux différentes étapes du pipeline sont compilées dans l'assembly. Lorsque ce pipeline est déployé sur BizTalk Server, les informations sur les composants, y compris leur nom de fichier, sont insérées dans la base de données de gestion BizTalk et l’assembly de pipeline est déployé dans le GAC. Tous les assemblys supplémentaires dont dépendent les composants de pipeline BizTalk doivent également être déployés dans le GAC pour pouvoir être trouvés au moment de l’exécution. Les assemblys de composants de pipeline doivent être copiés dans le répertoire BizTalk Server\Pipeline Components pour être accessibles par un pipeline BizTalk au moment de l’exécution, que l’assembly soit également déployé sur le GAC. Lorsque le pipeline est exécuté, ces composants sont chargés et les interfaces qu'ils implémentent sont appelées selon le besoin. Si un assembly de composant de pipeline est également déployé dans le GAC, l’assembly est chargé à partir du GAC au moment de l’exécution. Cela peut entraîner une confusion si l’on ne prend pas soin de s’assurer que l’assembly du composant de pipeline est le même dans le répertoire BizTalk Server\Pipeline Components et dans le GAC.