Modèles de Déploiement des Services Web

1. Un survol des Technologies e-Business / e-GouvernementPartie 4Jacques DurandFujitsu Computer Systems

2. 4. Les Architectures e-Business - Modèles de déploiement des Services Web- Profils WS-IJacques DurandFujitsu Computer Systems

3. Aspects Importants du Déploiement Web Services [pour e-Bus / e-Gov]- Interopérabilité: Web Services Interoperability (WS-I) Profils- Gestion du déploiement: Adaptée au mode de déploiement des Services

4. Modèles de Déploiement des Services Web • Plusieurs façons de déployer / publier un service Web (WS) • Affecte la gestion du WS • Gestion des changements (interface du WS, location du WS) • Ajout d’utilisateurs, intégration coté’ applications… • Quelques paramètres d’ un déploiement: • Exposition de l’interface du Service (fichier WSDL): interne? Externe? • Protocole Web utilisé (SOAP? REST?) • A quel profil WS-I se conformer?

5. Questions préliminaires (1): • Qu’ y a-t-il derrière mon Service? • Un “vrai” service? (exécute une fonction précise, “délocalisée”) • conversion de monnaie • évaluation de police d’ assurance • gestion de panier eCommerce • Une adresse où poster un document métier? • Bons de Commandes, Factures… • Un interface Web a une application conventionnelle? • visibilité de stock / inventaire • modules de gestion, ERP ? Web Service

6. Questions préliminaires (2): • Qui / quel est l’utilisateur du WS (“Clients”)? Un processus métier interne ? ? WS Un navigateur Web ? ? Une passerelle Un “Enterprise Service Bus” (ESB)

7. 3 Modèles de Déploiement de WS • Le modèle PublicationWeb • Le modèle Interface d’Application Business Distante (IABD) • Le modèle Passerelle-Cliente

8. Le modèle PublicationWeb • Service Web = resource Web • comme les pages Web et documents accessibles par tous. • Les services ne sont pas liés a des processus métier spécifiques d’ une filière • Plutôt “hosted” (outsourced) et gères comme des entités individuelles • Large accès public • Cherche a maximiser le nombre d’utilisateurs, facilite l’ acces • E.g. WS publies par Amazon, eBay, Google • Protocoles: comme pour les autres resources Web, préférence pour REST • L’interface du service: sa définition est diffusée publiquement – connue des utilisateurs • cependant, l’ingterface joue un role surtout documentaire si REST est utilise’ (WSDL doc non processe’)

9. Modèle Publication Web Utilisateurs publics (nombreux) Services hotes, SaaS Client Application Business Application Scheduling Web Service SOAP Web Service HTTP Proxy (reverse Proxy) REST CRM REST Web Service Storage SOAP Web Service eCommerce cart Business Process

10. Interface App Business distante Publication Web Mode Déploiement Passerelle-cliente Requis Format Document XML (+ multi-media) Qualité’ de comm (Sécurité’, Fiabilité’…) Elémentaire / comm (HTTP/S) Gestion de Changement des interfaces Couteuse Suppose’ rester modeste Nombre de Services Nombre d’utilisateurs ( clients) Conçus pour grand nombre Invocation de Fonction (Transfer Doc possible) Type d’échange B2B Tolérance a des Protocoles autres Non (SOAP ou REST)

11. Modèle Interface d’Application Business Distante • Service Web = Interface d’ une application métier. • Rend possible l’ accès distant. • Le service est lié a un processus métier spécifique. • Liens avec les processus d’ entreprise ou de l’ administration: accès contrôle’, mise en opération délicate. • Accès restreint • Uniquement partenaires business (sécurité’, autorisation, authentification) • E.g. WS qui servent d’ interface a des gestionnaires d’ inventaire, des modules ERP. • Protocoles:, préférence pour SOAP, et les modules de qualité’ de service de la communication associes • sécurité’, fiabilité du message • L’interface du service: sa définition est diffusée de facon restreinte – connue des partenaires seulement • Interface est nécessaire coté client – e.g. utilise’ pour générer du code source coté client.

12. Modèle Interface pour Application Business Distante Manufacturing Company Applications from Trusted Business Partners Qual. Of Svce Security Authorization Reliability Client Application Inventory Visibility Client Application Web Service Small Supplier SOAP HTTP Proxy (reverse Proxy) Web Service Enterprise Business Applications SCM SOAP QoS Web Service Pricing Customer Business Process QoS

13. Mode Déploiement Interface Business Appl. Distante Publication Web Requis XML(+ EDI, multi-media) XML(+ multi-media) Format Document Qualité’ de comm (Sécurité’, Fiabilité’…) Complete Elémentaire (HTTP/S) Couteuse Risque eleve’ Gestion de Changement des interfaces Couteuse Supposé rester modeste Nombre de Services Suppose’ rester modeste Supposé rester Limité (partenaires) Nombre d’utilisateurs ( clients) Conçu pour Grand nombre Invoc. de Fcn (Doc possible) Invocation de Fonction (Transfer Doc possible) Type d’échange B2B Non Tolérance a des Protocoles autres Non

14. Modèle Passerelle-Cliente • Service Web = Une ressource interne quelconque. • Souvent Interface de module Applicatif business, mais interne. • Le service est lié a un processus métier spécifique. • Ou bien une fonction utilisée par un processus métier, en interne, ou interface a des fins d’ intégration internes avec des systèmes existant (ERP, CRM, PLM…) . • Accès externe par médiation uniquement • Service déployé en interne, accès externe direct impossible. Accès indirect par un “médiateur” ou passerelle de messagerie. • Protocoles: Le découplage entre communication externe et interne par passerelle B2B, autorise variete’ cote’ B2B: • AS2, ebMS2,3. SOAP-based (ebMS3) facilite la conversion du message sous forme d’ invocation WS. • sécurité’, fiabilité du message • L’interface du service: sa définition n’est PAS diffusée aux partenaires • La passerelle est le client réel des WS internes.

15. Modèle Passerelle-Cliente Internally Deployed Services Business Users Client Application The actual WS client Client Application eB/eG Gateway Client Application Web Service eB/eG Gateway WS SOAP ebXML AS2 RNIF … HTTP Proxy (reverse Proxy) WS WS QoS Business Document Publish / subscribe Business Process DMZ

16. Mode Déploiement Publication Web Interface App Business distante Passerelle-cliente Requis XML(+ multi-media) XML(+ multi-media) Format Document XML et autres Complete Option centralisée Qualité’ de comm (Sécurité’, Fiabilité’…) Complete Elémentaire (HTTP/S) Couteuse Risque eleve’ Gestion de Changement des interfaces Facilitee, Peu de risques Couteuse Suppose’ rester modeste Nombreux possible Nombre de Services Suppose’ rester modeste Conçu pour Petit nombre Nombre d’utilisateurs ( clients) Conçu pour Grand nombre Grand nombre Invoc. de Fcn (Doc possible) Invoc de Fcn (Doc possible) Doc. metiers: +++ Invoc. de Fcn: + Type d’échange B2B Tolérance a des Protocoles autres Non Oui Non

17. Les Passerelles e-Business • Tendance: multi-standard • Rôle: découplage messagerie / intégration avec applications, sécurité’/ autorisation, validation de docs, etc. • SeeBeyond eXchange Integrator (Java CAPS) • supporte AS2, ebMS2, RosettaNet (RNIF) • Hermes/CECID (Open Source), • supporte AS2 et ebMS2 • BusinessConnect/TIBCO: • AS2, ebMS2 et + • SonicCollaborationServer/SonicSoftware: • ebMS2 et +

18. 2 Exemples d’ Architectures Passerelles • General Motors • ebMS2 cote’ B2B • Conversion ebMS2  invocation de services Internes. • Passerelle: traite la securite’ generale • Health Care Dental, Canada • ebMS2 cote’ B2B • Passerelle: fonctions de routage, d’ autorisation • ebMS2 en Interne

19. Architecture Orientées-Service • (Service-Oriented Architectures, SOA) • “Agile” : changements facile a gerer • conversion de messages en un format normalise’ sur le BUS (assume une partie des fonctions de la passerelle “cliente”) Web Service ERP B2B gateway Web Service SCM ESB Registry Repository Web Service J2EE application Business Process (e.g. BPEL) Web Service .NET application

20. Les échanges orientés-document • Service ou pas Service ? • A supposer “Service”, autre question cruciale: Service externe ou Service interne? WS internes WS externes WS clients = User apps WS client = Gateway Web Service Web Service Web Service Web Service Web Service Documents Over ebMS, AS2 JMS MQ

21. Echanges orientés document • Grand nombre potentiel de types de documents, e.g schemas XML. Même pour un seul Document Métier: • Evolution de ces documents (versions successives, e.g. Bon de Commande V1, V1.1, V1.2. • Personnalisation: chaque entreprise a sa variante de Bon de Commande. •  Difficulté à maitriser dans les interfaces Service Web (fichiers WSDL). • Types de doc: associes étroitement à l’ interface WS. • A Eviter absolument: faire face aux deux a la fois: • l’ instabilité / l’ évolution de l’ interface WSDL • la diffusion du WSDL a un nombre important de partenaires

22. Risques d’ une exposition externe des Service Web orientés-document • 1- Impact d’ une évolution des documents. • problèmes logistiques de transition des partenaires eB/eG. (tous ne peuvent migrer en même temps sur le nouveau Service.) • 1 opération du WS = 1 seul document au plus en input (pas plusieurs variantes). • Donc, difficulté d’associer les deux variantes d’ un document type, à la même opération  impact sérieux sur la définition d’interface. Operation A Web Service Operation B Operation C

23. Risques d’ une exposition externe des Service Web orientés-document • 2- Gestion des erreurs. • Le document XML est validé automatiquement par la pile Web services • vérification automatique de “types”: une bonne chose dans les langages de programmation ou dans Remote procedure Calls, mais inappropriée pour les documents business ! • Non conformité au schéma XML  message rejeté par la couche basse du protocole. Or, de telles erreurs: • (1) souvent ne sont pas fatales au niveau business, (e.g. différente version d’ un même document, avec conversion possible). • (2) en majorité’ devraient être traitées a un niveau “business” comme les erreurs “sémantiques” de contenu business. (et non comme un problème de couche communication)

24. Risques d’une exposition externe des Service Web orientés-document • 3- Pré-traitement souvent nécessaire • Sécurité commune aux Services: éviter de la gérer au niveau de chaque service ! • La centraliser au niveau passerelle (pas HTTP proxy ) • Laisser la partie spécifique a chaque WS (e.g. autorisation d’ accès) • Coté Réception: Routage interne souvent nécessaire • doit être flexible: La destination finale du document demande une visibilité préalable. • Passerelle: Un Web service intermédiaire? Mais le document XML doit souvent être transmis tel-quel, avec son contexte message (non-transforme’) • Contrôler la validation (éviter validation aveugle par la pile Web services) • Le concept de passerelle, ou d’ intermédiaire s’impose pur les prétraitements – et ce ne doit pas être un Service.

25. En Conclusion • Gestion des systèmes en production: doit faire partie d’un cahier des charges COMPLET qui va au delà des aspects fonctionnels et infrastructure (interface définition & Protocol): • Identifier le type de Service, perspectives d’ évolution de leur nombre, de leurs définitions, • Gestion des changements? Transition a un nouveau service? A une nouvelle version? Impact sur utilisateurs? • L’existant doit être pris en compte: intégration avec back-office , problèmes de transition.

26. The WS-I Approach • WS technology involves several standards (from OASIS, W3C, IETF…) • Many Interoperability issues in WS arise from • Different Interpretations of these Standards by Product Vendors • Different Integration Approaches • Need for… PROFILE SOAP UDDI HTTP XML STANDARDS

27. SOAP 1.1 • WSDL 1.1 • UDDI 2.0 • XML Schema • XML 1.0 (Second Edition) • HTTP 1.1 • SSL 3.0 • Restrictions, • Integration Guidance • Best Practices + Basic Profile 1.1 = More than 200 interoperability issues resolved WS-I Profiles

28. WS-I Profiles • WS-ReliableMessaging1.1 • WS-SecureConv • WS-S 1.1 • SAML • WS-Addressing • SOAP 1.1 • WSDL 1.1 • UDDI 2.0 • XML Schema • XML 1.0 • HTTP 1.1 • SSL 3.0 Reliable Secure Profile 1.0 Basic Security Profile 1.1 Basic Profile 1.1, 1.2

29. WS-I Organization www.ws-i.org • An open industry effort • advance Web services interoperability across platforms, applications and programming languages • Broad participation • 150+ users, software vendors, consultants, industry orgs, etc. • Establish best practices for achieving interoperability • Based on existing and broadly supported standards • Cooperate with SDOs (standards development orgs) • On the Consumer side of standards