Création de systèmes d'informations interopérables avec les technologies du framework .NET 3.0

Mike Walker

S'applique à :
Microsoft Infrastructure .NET 3.0

Résumé : Ce livre blanc utilisera un scénario du secteur de l'assurance pour démontrer les capacités d'interopérabilité de la plate-forme Microsoft. L'utilisation des seules normes de niveau protocole ne suffit pas ; l'acquisition des transactions de messagerie côté entreprise est essentielle à la mise en oeuvre de l'interopérabilité pour votre société. Ceci est vrai dans tous les secteurs, et non pas uniquement celui de l'assurance. (15 pages imprimées)

Build Interoperable Systems with .NET 3.0 Technologies 

Sur cette page

Introduction
Forces du secteur de l'assurance
Terminologie métier utilisée dans ce document
Scénario Police d'assurance-vie
Présentation de l'architecture
Système de police des agents d'assurance
Systèmes pour les compagnies d'assurance
Valeur ajoutée
Conclusion
Ressources

Introduction

Le but de cette série de livres blancs est de fournir des conseils relatifs aux difficultés d'intégration.

Tout le long de ce livre blanc, nous utiliserons un scénario du secteur de l'assurance pour démontrer les capacités d'interopérabilité de la plate-forme Microsoft. En raison de la maturité de nombreuses entreprises, le monde où nous vivons comporte plusieurs piles de technologie. Ces piles de plate-forme vont des applications héritées de type COBOL ou FORTRAN sur macroordinateurs aux solutions plus modernes basées sur .NET, Mobile Systems ou Java, en passant par toutes les solutions intermédiaires. Par conséquent, au fur et à mesure que les entreprises ont évolué à travers les technologies et les tendances technologiques, quelques « rustines » ont été appliquées aux diverses technologies.

Série Interopérabilité dans l'assurance

Ce livre blanc servira de repère pour les architectes qui doivent faire face aux défis d'intégration dans le secteur de l'assurance. Nous vous montrerons comment utiliser les technologies d'intégration Microsoft pour intégrer des systèmes disparates dans votre entreprise. De plus, ce document fournira des conseils de conception pragmatique pour générer de solutions interopérables à l'aide de normes ouvertes telles que WS-*. Cette série contient également les documents supplémentaires suivants :

Aperçu général de l'architecture pour la création de systèmes d'assurance interopérables

Protection des solutions d'assurance

Gestion d'échelle et opérationnelle

Déploiement de solutions d'entreprise

Développement d'applications composites

Les technologies examinées sont notamment :

• BizTalk 2006. Technologie d'intégration pour cette solution. La solution utilise également les règles d'entreprise de BizTalk et l'orchestration du flux de travail.

• Windows Communication Foundation (WCF). Modèle de programmation permettant de développer des messages de services Web et de gérer la communication de niveau protocole à l'aide des protocoles WS-*.

• Windows Workflow Foundation (WF). Pour créer des flux de travail impeccables à l'aide des technologies Smart Client.

• SQL Server 2006. Référentiel de toutes les données application et client.

• Windows Server 2003. Plate-forme du serveur.

Ce scénario nous donnera un aperçu du processus métier. Comme beaucoup d'entreprises, chaque compagnie d'assurance dispose d'un mode de traitement unique. Cependant, il existe quelques similarités que ces entreprises partagent au niveau de la plate-forme. Le but est ici de démontrer qu'il existe un moyen d'exploiter ces services de plate-forme communs afin de créer des architectures orientées service (SOA) tout en donnant à une organisation plus d'agilité dans les processus qui démarquent son activité.

Haut de page

Forces du secteur de l'assurance

Dans le secteur de l'assurance, de nombreuses technologies sont mises en oeuvre, du macroordinateur à UNIX et à Windows. Avec cette grande variété de technologies de plate-forme, il est de plus en plus difficile d'assurer la gestion et le fonctionnement tout en maintenant une agilité dans un marché financier en constante évolution. Pendant des années, les organisations ont créé et acquis des technologies pour répondre à ces besoins. L'interopérabilité est devenue un mal nécessaire une fois la solution créée et/ou mise en oeuvre. Nous nous retrouvons donc avec des intégrations point-à-point qui traitent des problèmes très spécifiques au niveau de l'application ou du système uniquement, mais non au niveau de la fonction commerciale.

Figure 1. Résultat des intégrations point-à-point

Si l'on n'y prend pas garde, les intégrations point-à-point sur plusieurs années ont pour résultat :

• Une gestion impossible du portefeuille informatique, en raison de la duplication de systèmes, des variations multiples d'intégrations, de la gestion de dépendances d'applications, etc.

• L'augmentation considérable du coût des systèmes informatiques, en raison des nombreuses intégrations personnalisées.

• La perte d'agilité, car le développement de systèmes est considérablement ralenti en raison de la complexité croissante du code, d'une réutilisabilité limitée et du manque de normalisation dans l'entreprise.

Aussi, quelles sont les conséquences pour les compagnies d'assurance ? L'interopérabilité est donc d'une importance cruciale, non seulement en matière d'efficacité, mais aussi comme différentiateur compétitif. À notre époque de concurrence moderne, les entreprises doivent augmenter le retour sur l'investissement (ROI) de leurs systèmes informatiques en rationalisant les processus et en renforçant leur agilité pour rester compétitives.

Notre objectif est de relever les défis que rencontre le secteur grâce à une série de technologies d'entreprise prêtes à l'emploi sur la plate-forme Microsoft. Nous utilisons les principes suivants dans les exemples :

• Solution d'entreprise

• Communications standard :

  • utilisation des normes WS-*

  • messages ACORD

• Interopérabilité avec les solutions existantes

Haut de page

Terminologie métier utilisée dans ce document

ACORD : ACORD (www.acord.org) est une association à but non lucratif dont la mission est de faciliter le développement et l'usage de normes pour l'assurance, la réassurance et les secteurs de services financiers apparentés.

Système de commande : crée des requêtes pour les données externes, les transmet au fournisseur de données tiers approprié, gère les réponses reçues et les associe au demandeur original.

Fournisseur de services tiers : système externe répondant aux demandes de souscription (par exemple, un système d'évaluation financière).

Processus de souscription : mise en oeuvre du processus métier pour évaluer et traiter un nouveau client.

Système de courtage : système frontal Smart Client pour la saisie de commandes et le contrôle de la progression utilisé par un courtier d'assurance. D'autres systèmes frontaux sont également possibles, tels qu'un portail Web à destination des courtiers ou une interface utilisateur Web pour la saisie des commandes libre-service par les clients.

Haut de page

Scénario Police d'assurance-vie

Le client, Robert, souhaite souscrire une police d'assurance-vie Platinum d'un million de dollars. Le courtier, Tom, entre la demande de police de Robert à l'aide de son application Smart Client. La police est envoyée au système de commande, où elle est traitée et transmise aux systèmes appropriés pour commencer le processus de souscription. Au même moment, dans le système de commande, les services tiers sont déclenchés. Pour ce scénario, nous utiliserons Paramed, service tiers qui vérifie l'assurance maladie et les dossiers médicaux pour les assureurs.

La logique métier incorporée peut également produire des requêtes aux tiers si une certaine condition est vérifiée. Il peut s'agir du courtier ou d'un autre partenaire de la compagnie d'assurances.

Figure 2. Processus métier utilisé pour notre scénario

Haut de page

Présentation de l'architecture

Cette section vous guidera à travers l'architecture logique de haut niveau utilisée dans le scénario. Les détails autour des aspects spécifiques, tels que la sécurité, les messages, le développement et le déploiement seront fournis dans les autres articles de cette série.

Pour assurer l'adéquation aux défis réels, nous avons déterminé une série d'exigences de haut niveau.

Configuration requise

Les exigences suivantes concernent une solution d'entreprise :

• Doit interagir avec des applications commerciales prêtes à l'emploi. Comme nous l'avons vu précédemment, de nombreuses organisations achètent et personnalisent des logiciels. Il est essentiel de traiter ce problème.

• La technologie d'intégration doit s'appuyer sur des services Web. De nombreuses formes de communication, telles que la communication binaire, sont propriétaires. Jusqu'à l'apparition des services Web, il n'existait aucune norme pour la communication des messages. Les services Web permettent de communiquer à travers des plates-formes hétérogènes.

• Les normes WS-* doivent être utilisées. Les services Web utilisant SOAP et WSDL constituent la norme sectorielle en matière d'intégration depuis des années. Cependant, ces services Web traditionnels ne disposent pas de la robustesse nécessaire à la messagerie. Les normes WS-* offrent ces fonctionnalités nécessaires sans recours à la communication binaire.

• Flux de travail durable. La gestion des orchestrations durables a été difficile, surtout lorsqu'un flux de travail engendre de nombreux flux externes plus petits, ce qui entraîne une gestion de réconciliation et de transaction complexe.

Nous utilisons BizTalk comme concentrateur de messages pour cette solution, en raison de sa richesse fonctionnelle et de la nécessité de relier des systèmes multiples et de gérer plusieurs flux de travail externes.

Figure 3. Utilisation de la technologie bus de messages

La figure 3 montre une vue d'entreprise de BizTalk utilisé comme service d'entreprise (ESB). Gardez à l'esprit que son utilisation comme service d'entreprise n'est pas une exigence. Ce livre blanc ne considère cette couche que comme couche message ; vous pouvez ainsi dans tous les cas l'incorporer à votre solution.

L'utilisation de BizTalk se justifie ici par le fait qu'il fournit une plate-forme centralisée pour les capacités suivantes :

• Gestion des processus métier : la centralisation de processus métier réutilisables se prête non seulement à l'orientation service, mais fournit également un mécanisme permettant aux organisations de développer des applications commerciales existantes ou achetées prêtes à l'emploi sans la complexité nécessaire pour les modifier.

• Orchestration de flux de travail : la gestion de plusieurs flux de travail peut être simplifiée par cette plate-forme. Sans codage ni réconciliation de chaque flux de travail, les solutions peuvent être gérées comme elles le doivent. Aussi, nous créons un flux de travail pour la gestion du processus métier du début à la fin, capable d'orchestrer plusieurs flux de travail système internes.

• Prise en charge élaborée des adaptateurs : le lancement rapide du développement est essentiel pour les organisations. BizTalk est doté d'une grande variété d'adaptateurs pour la prise en charge de vos besoins d'intégration. Dans le domaine de l'assurance, il existe un adaptateur ACORD qui peut démarrer vos intégrations. Conjointement à l'adaptateur ACORD, l'adaptateur de services Web et les adaptateurs basés sur les fichiers sont disponibles pour BizTalk.

• Routage et transformation des messages : le routage de messages peut être très complexe lorsqu'ils doivent être transformés pour permettre à d'autres systèmes de les comprendre. BizTalk peut fournir une plate-forme permettant de réduire la complexité tout en s'alignant avec les normes ouvertes.

Haut de page

Système de police des agents d'assurance

Actuellement, les tendances technologiques du secteur de l'assurance varient des portails, aux clients lourds, aux écrans d'émulation de terminal 3270 et aux solutions Smart Client. Étant donné le nombre important d'applications et de fournisseurs dans ce domaine, nous avons choisi une interface utilisateur Smart Client afin d'offrir à l'agent une expérience optimale pour les raisons suivantes :

• Modes hors ligne et en ligne

• Aucune dépendance à la connectivité réseau

• Une expérience utilisateur riche avec des fonctionnalités plus importantes

L'utilisation d'un modèle déconnecté pour les agents est logique dans de nombreux cas, étant donné que les courtiers peuvent souvent être en déplacement ou disposer d'une connectivité limitée aux ressources réseau. Cependant, comme nous appuierons notre stratégie de messagerie sur les services Web lors de l'élaboration de cette solution, le mode de soumission des polices par le courtier devrait être insignifiant.

Pour l'architecture côté client, nous avons utilisé Windows Forms qui fournit l'interface utilisateur nécessaire aux agents. Plusieurs contrôles seront présents, notamment des grilles de données, des zones de texte et des boutons de commande. Une grille de données sur l'écran Windows servira au courtier d'accès au pipeline des polices. Les services Web permettent d'actualiser cette grille de données afin d'assurer des mises à jour en temps réel.

Étant donné qu'il s'agit d'un client intelligent, les données renvoyées peuvent être mises en cache pour un affichage et une mise à jour hors ligne. Ceci offre des avantages considérables aux courtiers. Outre les données, une petite couche de logique métier résidera sur l'application cliente. La majorité de la logique d'application résidera côté compagnie d'assurance. Le raisonnement ici est que nous disposerons de règles légères pour piloter les fonctionnalités de l'interface utilisateur.

Figure 4. Architecture logique du client

Pour effectuer les appels du client à la couche de messagerie, nous utiliserons Windows Communication Foundation (WCF). WCF enverra les messages de services Web SOAP 1.2 à l'aide des schémas de messagerie ACORD. La couche de WCF fournira un modèle de développement unifié à nos développeurs chargés du codage des communications. Du point de vue du protocole, nous utiliserons une série de normes WS-*. Toutefois, ceci n'est pas suffisant pour assurer l'interopérabilité. L'usage des normes sectorielles ACORD est également essentiel. Nous devons pouvoir interagir de façon continue entre les applications « maison », les applications COTS et les services tiers.

Architecture de messagerie

L'usage de services Web autorise cette large variété de canaux à exploiter un service Web commun qui reçoit les nouvelles demandes de clients au cours du processus de souscription sous la forme d'un message ACORD 103 qui comprend le numéro de police attribué et qui sera utilisé à des fins de suivi/corrélation à travers cette démonstration. Ce message ACORD 103 New Business Submission sera basé sur une pièce jointe Message Transmission Optimization Mechanism (MTOM/XOP) SOAP contenant une représentation binaire de la signature de Robert autorisant la divulgation de son dossier médical, comme l'exige l'organisme HIPAA. Il est absolument essentiel d'intégrer les normes ACORD à notre messagerie. Ceci assurera la portabilité de l'architecture.

Les communications doivent également être sécurisées et fiables. Pour cela, nous utiliserons WS-Secure Conversation (WS-SC) pour les informations personnelles susceptibles de passer par un nombre indéterminé d'intermédiaires. Nous utiliserons également WS SC pour les requêtes fréquentes à grand volume (les vérifications de solvabilité par exemple) nécessaires pour toutes nouvelles demandes de police. Nous utiliserons WS-Security pour les requêtes moins fréquentes, telles que les déclarations du médecin traitant (APS), où les surcharges d'établissement de session ne sont pas justifiées par le volume de demande. Nous utiliserons également TLS/SSL (ou HTTPS) dans les rares situations où un service traite directement les requêtes sans routage intermédiaire.

Pour la messagerie où le suivi des réceptions est important, par exemple pour réclamer une commission après établissement d'une nouvelle police, nous utiliserons WS- Reliable Messaging (WS-RM). Nous utiliserons également WS RM pour les requêtes de données chères à traiter (impliquant généralement un flux de travail humain, comme les demandes d'APS, ou déclaration du médecin traitant). Ceci garantit que les requêtes ne sont livrées qu'une fois, et évite les requêtes en double coûteuses.

Pour les messages longs, nous utiliserons WS-Secure Conversation (WS-SC) (voir Ressources).

Figure 5. Modèles d'échange de messages clients

Tableau 1 : Matrice de décision de conception de messagerie de processus métier

Après une soumission, vous pourriez vous poser les questions suivantes : Pourquoi l'état est-il renvoyé dans une transaction séparée ? Il existe en fait deux raisons. Premièrement, il est important que cette opération soit asynchrone et la norme ACORD n'autorise pas de mise en oeuvre sans séparation de l'état et de la soumission. Deuxièmement, le courtier recevra périodiquement des retours d'état tout le long du processus de demande en interrogeant le service État.

Haut de page

Systèmes pour les compagnies d'assurance

Lors de l'élaboration du côté serveur de la solution, des suppositions et des aspects particuliers ont été pris en compte :

• Cette architecture tient compte des systèmes fragmentés.

• Les zones fonctionnelles sont autonomes et doivent être gérées.

• Les systèmes d'exploitation et les environnements de développement diffèrent.

Par conséquent, il existe un nombre important d'intégrations point-à-point avec des applications très spécifiques, d'où la présence de mises en oeuvre propriétaires. Dans cette solution, la couche de façade sera créée autour de ces applications existantes.

Figure 6. Bus de messages d'assurance

Ici, vous pouvez constater comment nous utilisons le bus de service d'entreprise (ESB) comme bus de messages. Cette couche servira de couche de messagerie centralisée qui assurera la gestion de nos messages internes et externes. La gestion et l'orchestration représentent les avantages principaux de cette architecture.

Une telle infrastructure peut éliminer le chaos causé par les intégrations point-à-point disparates grâce à la mise en place d'orchestrations et de stratégies intelligentes et durables autour des transactions sur une seule couche, et non plusieurs. Il arrive fréquemment qu'une transaction soit effectuée de bout en bout par plusieurs applications COTS distinctes dans plus de cinq ou six systèmes. Nous réduisons le nombre de ces systèmes de manière considérable en consolidant les fonctions redondantes telles que le flux de travail et la messagerie, en laissant les fonctionnalités de niveau infrastructure à l'emplacement approprié et en maintenant la logique métier dans les applications adéquates.

Il est important de garder à l'esprit que ce bus de messages est une représentation logique. La vue de mise en oeuvre peut paraître très différente. Par exemple, le bus de messages pourrait être constitué de plusieurs serveurs BizTalk, ou des serveurs pourraient figurer dans différents environnements de zone DMZ afin de gérer les communications internes et externes.

Figure 7. Concepteur de flux de travail (cliquez sur l'image pour l'agrandir)

La couche inférieure suivante, où les fonctions d'entreprise spécifiques sont exécutées, contient deux systèmes hérités différents groupés en une interface : le système de commande et le système de traitement des commandes. La raison pour laquelle nous gardons ces systèmes séparés au lieu de les consolider est qu'il s'agit, dans la majorité des cas, de deux systèmes COTS distincts.

Un système État a été ajouté pour les raisons suivantes :

• Fournir une méthode centralisée servant à signaler l'état aux agents.

• Réduire le nombre d'interfaces et la quantité de logique de contrôle nécessaires pour interroger plusieurs systèmes.

• Il s'adapte bien aux capacités d'orchestration de notre ESB pour notre flux de travail durable.

Les systèmes de commande et de traitement des commandes ont été transformés en services à gros grains. Nous avons ainsi éliminé les dépendances des mises en oeuvre indépendantes. Toute communication vers ces systèmes passe maintenant par notre concentrateur de messages. Les points finals exposés des services Web gérés depuis le bus de messages peuvent être alors administrés à l'aide des technologies d'orchestration intégrées à BizTalk.

Figure 8. Modèle d'échange de messages de bout en bout

Maintenant que ces applications sont exposées en tant que services Web, toute technologie pouvant accepter du XML de services Web peut être intégrée à ces applications. Ceci supprime le raccord étroit lié aux protocoles d'autres technologies qui limiteraient l'interopérabilité. Par exemple, vous pouvez tout aussi facilement utiliser des systèmes Java existants, si vos systèmes hérités sont de ce type.

SQL Server est utilisé ici pour stocker les données d'application dans la couche de base de données. Étant donné que cet article traite principalement de l'intégration et des applications composites, nous ne nous étendrons pas sur ce sujet.

Les services tiers référencés sont des services externes appelés par le service de traitement des commandes. Les besoins en matière de protocole de ces services varient. Cependant, cet article montrera comment les normes WS-* peuvent fournir des fonctionnalités supplémentaires à vos services. Il est important de noter que de nombreux services tiers d'assurance ne prennent en charge que les communications basées XML, et non les services Web SOAP-BASE plus élaborés. Les sections relatives à l'architecture de messagerie qui suivent contiendront davantage de renseignements sur les services tiers.

Architecture de messagerie des compagnies d'assurance

Cette section décrit une police d'assurance-vie de base traitée par la compagnie d'assurance. En fonction des informations fournies par Robert, les règles d'entreprise ou la logique heuristique définies dans le processus de souscription décident qu'une déclaration du médecin traitant (c'est-à-dire une visite médicale) est également nécessaire.

Étant donné qu'un autre fournisseur doit répondre à cette requête, le système de commande génère une transaction ACORD XML TransType 121 General Requirements Order Request (TXLifeRequest) et la transmet à un système de commande externe secondaire pour le médecin de Robert. Ce message renferme également la pièce jointe MTOM/XOP contenant la signature de Robert, transmise à l'origine via la transaction ACORD 103 New Business Submission, et autorisant son médecin à divulguer son dossier médical à la compagnie d'assurance.

À un moment donné, le médecin de Robert traitera la demande d'APS en vérifiant que la signature de Robert est identique à celle qu'il a dans ses dossiers, en examinant ensuite les antécédents médicaux de Robert, et en indiquant les informations nécessaires devant figurer sur le rapport APS.

Une fois le rapport APS rempli par le médecin, un message 1122 General Requirements Status/Results Transmittal est produit et retransmis à la référence de point final spécifiée à la section WS-Addressing ReplyTo de la demande ACORD 121 précédente. Ce message sera également livré de manière fiable via WS-Reliable Messaging.

Le reste du processus métier s'exécute, décision d'actuaire automatisé comprise. Cependant, dans ce cas, étant donné qu'il existe une déclaration APS et probablement d'autres informations qui ne peuvent pas être automatiquement traitées, le dossier est marqué pour révision et approbation par l'assureur.

Figure 9. Modèle d'échange de messages du processus de souscription

Service de traitement des commandes

Dans le secteur de l'assurance, le système ou service de traitement des commandes est très différent du processus de traitement des commandes :

• Système de traitement des commandes : système ou service qui reçoit une requête et la traite. Vous pouvez considérer qu'il s'agit d'un composant d'intégration pour recueillir des données. Dans ce scénario, le système de traitement des commandes est chargé d'extraire les divers rapports des fournisseurs tiers.

• Processus de traitement des commandes : processus par lequel une police est émise par la compagnie d'assurance.

Vous pourriez vous demander pourquoi nous avons conservé le service de traitement des commandes. Pour ce scénario, nous supposons que des systèmes de ce type ont été achetés comme solutions de boîte noire. Cela ne signifie pas que vous ne pouvez pas supprimer ces couches et les intégrer à un bus de messages.

Le choix d'un modèle de messagerie n'est pas aussi évident que celui d'une série de normes. Lors de la conception de cette partie de la solution, nous avons dû prendre du recul et considérer les aspects commerciaux et héritage de chaque transaction individuelle.

La prise de décisions pour certaines transactions, telles que la réception d'un rapport de solvabilité, était plus facile. En revanche, d'autres transactions, telles que l'extraction d'un rapport APS, ont nécessité la capacité d'inclure des pièces jointes.

Voici quelques aspects à considérer lors de la conception de votre messagerie :

• Comprendre le processus métier. Il est essentiel de comprendre comment l'entreprise utilise ces messages (par exemple, pour la protection des données). Si les données envoyées ne sont pas confidentielles, vous n'avez pas à prendre de précautions de sécurité considérables pour le message.

• Comprendre comment les transactions sont consommées depuis les fournisseurs de service. Il peut s'agir d'une question interne et externe. Souvent, le recours à des fournisseurs de service impose des restrictions techniques. Celles-ci peuvent varier de la prise en charge des normes aux heures d'ouverture.

• Prendre les mesures adéquates en matière de sécurité.Ce point est souvent négligé. La sécurité de niveau protocole, telle que SSL/TLS, est souvent suffisante, mais pas toujours. Veillez à évaluer la confidentialité des données et à revoir l'itinéraire des messages pour déterminer le nombre de points finals avant le consommateur lui-même.

• Faire preuve de réalisme et de pragmatisme. Lors de la conception de ces services, n'en faites pas trop en tentant d'utiliser chaque norme. N'imposez pas une norme dans un message si elle ne convient pas. Ceci ne peut entraîner que des complications supplémentaires.

Figure 10. Modèle d'échange de messages du système de traitement des commandes

Haut de page

Valeur ajoutée

Nous avons abondamment évoqué la plate-forme et les technologies de développement Microsoft au cours de ce scénario. Nous avons souligné également les décisions en matière d'architecture. Nous n'avons pas, en revanche, mis en lumière ces technologies Microsoft.

Les avantages fondamentaux que présentent les technologies Microsoft pour le secteur de l'assurance sont les suivants :

• Automatisation des processus métier : les processus métier sont complexes et spécifiques à chaque compagnie. Avec les outils fournis par BizTalk, les orchestrations peuvent être mises au point par les analystes commerciaux, ce qui élimine le recours au développeur et autonomise l'entreprise.

• Réduction du code d'intégration : grâce aux adaptateurs personnalisés de BizTalk et au modèle de programmation unifié de WCF, le code nécessaire à l'intégration des systèmes est considérablement réduit.

• Alignement avec les normes : WCF et BizTalk sont directement basés sur des normes ouvertes XML. Il n'est plus nécessaire d'effectuer un codage personnalisé pour incorporer les normes de services Web.

• Productivité : avec l'intégration de Visual Studio IDE et des technologies .NET 3.0, les outils et le langage de développement offrent des gains de productivité substantiels par rapport aux autres langages.

Haut de page

Conclusion

Comme l'a démontré cet article, l'utilisation des seules normes de niveau protocole ne suffit pas ; l'acquisition des transactions de messagerie côté entreprise est essentielle à la mise en oeuvre de l'interopérabilité pour votre société. Ceci est vrai dans tous les secteurs, et non pas uniquement celui de l'assurance.

Nous disposons de normes pour les services Web, mais cela ne suffit pas. Une vérification préalable est toujours nécessaire à la prise de décisions optimales en matière de technologie pour votre organisation. Avec cette implémentation de référence spécifique, nous voyons évoluer un scénario réaliste et déterminons la messagerie optimum avec les forces d'entreprise de ce scénario. Ceci peut vous servir de repère pour choisir les modèles d'échange de messages dans votre entreprise. Avec toutes les architectures, des substitutions sont possibles lors de la sélection de normes spécifiques. Il est important de comprendre ces échanges et de se préparer à en accepter les conséquences.

Microsoft s'engage à faciliter les tâches d'élaboration et de développement des solutions orientées service pour ses clients, et nous démontrons ici que Microsoft a supprimé de nombreuses contraintes et complexités sectorielles qui découragent aujourd'hui les clients. Ces mesures vont d'un leadership réfléchi en matière de normes sectorielles à l'automatisation et l'élaboration d'une prise en charge des services Web prêts à l'emploi.

Haut de page

Ressources

Centre Architectes Financial Services Microsoft

BizTalk

.NET 3.0 Framework

Centre de développement Web Service

MTOM 1.0

SOAP 1.2

WS-Addressing

WSS 1.1

Username Token Profile 1.1

X.509 Token Profile 1.1

WS-Secure Conversation

WS-Trust

WS-Reliable Messaging

Haut de page