Un survol des Technologies e-Business / e-Gouvernement Partie 4 Jacques Durand Fujitsu Computer Systems.

Présentation au sujet: "Un survol des Technologies e-Business / e-Gouvernement Partie 4 Jacques Durand Fujitsu Computer Systems."— Transcription de la présentation:

1 Un survol des Technologies e-Business / e-Gouvernement Partie 4 Jacques Durand Fujitsu Computer Systems

2 4. Les Architectures e-Business - Modèles de déploiement des Services Web - Profils WS-I Jacques Durand Fujitsu 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 Publication Web Le modèle Interface d’Application Business Distante (IABD) Le modèle Passerelle-Cliente

8 Le modèle Publication Web
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 SOAP Web Service Scheduling HTTP Proxy (reverse Proxy) Web Service REST CRM REST Web Service Storage WS = Web resource. Stand-alone services, hosted (outsourced) Broad, public access (the more users, the better) Amazon, eBay, Google Protocols: as for any other Web resources – preference to REST SOAP Web Service eCommerce cart Business Process

10 Publication Web Interface App Business distante 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 WS = Interface to a business application. Services are tied to company applications Restricted access to business partners Supply chains, CRM Protocols: SOAP: supportive of QoS, of document transfer. QoS Web Service Pricing Customer Business Process QoS

13 Interface Business Appl. Distante Complete Couteuse Risque eleve’
Mode Déploiement Interface Business Appl. Distante Publication Web Requis XML (+ multi-media) XML (+ EDI, multi-media) Format Document Qualité’ de comm (Sécurité’, Fiabilité’…) Elémentaire (HTTP/S) Complete Gestion de Changement des interfaces Couteuse Risque eleve’ Couteuse Supposé rester modeste Nombre de Services Suppose’ rester modeste Nombre d’utilisateurs ( clients) Conçu pour Grand nombre Supposé rester Limité (partenaires) Invoc. de Fcn (Doc possible) Invocation de Fonction (Transfer Doc possible) Type d’échange B2B Tolérance a des Protocoles autres Non 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 WS = Internal resource, either for (mediated) external access, or for internal appl integration. Services are usually (1) interfaces to business functions (ordering, invoicing…), (2) application components or wrapper to legacy Not externally accessible (WSDL published locally only) Any company ivolved in B2B. E.g. GM Protocols: mostly message-oriented middleware (mom) QoS Business Document Publish / subscribe Business Process DMZ

16 Passerelle-cliente XML et autres Complete Option centralisée Complete
Mode Déploiement Publication Web Interface App Business distante Passerelle-cliente Requis XML (+ multi-media) Format Document XML (+ multi-media) XML et autres Complete Option centralisée Qualité’ de comm (Sécurité’, Fiabilité’…) Elémentaire (HTTP/S) Complete Gestion de Changement des interfaces Couteuse Risque eleve’ Couteuse Facilitee, Peu de risques Suppose’ rester modeste Nombre de Services Suppose’ rester modeste Nombreux possible 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 Non Oui

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 Passerelle: fonctions de routage, d’ autorisation ebMS2 en Interne

19 B2B gateway 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 - The footprint of a single change, affects several parts of your SOA If you do not have an ESB, then the client code needs be synchronized (dynamically or statically). An ESB may shield client from change, but then ESB needs itself be updated (XML transform). No free lunch in face of change, but a more organized environment. 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… Like in software design: iterative design is better than waterfall: but iterations are costly for standards! (new version, disruptive) Profiling is less costly. PROFILE SOAP UDDI HTTP XML STANDARDS

27 + = WS-I Profiles Restrictions, Integration Guidance Best Practices
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 WS-I members have realized that many interop issues come from: LOOSE ENDS, UNNECESSARY OPTIONS: (1) the way underlying WS standards are interpreted by product developers. There are always loose ends – unspecified aspects – that lead to different interpretations by developers. E.g. the order of XML elements (in WSDL, also SOAP message parts) (2) or, some options are redundant and in practice of little use while introducing interop risks (WSDL sollicit-resp, notify ops.) STANDARD COMBINATIONS: BINDINGS, SEMANTICS (3) bindings: the weak link. Use of XML namespace, way to use HTTP status codes (meaning at SOAP level?), (e.g. SOAP encoding style, or the order of elements within WSDL: - type elts and import elts: some expect them to be used always first, some not). (4) or, after the std has been implemented, realize some unforeseen interop issues (SOAPenc Array types, order of message parts in some binding - So, as we stated earlier, a Profile is a set of named specifications, at specific revision levels. The Basic Profile 1.0 is at its essence the following specifications: SOAP1.1, WSDL1.1, UDDI2.0, XML Schema, XML 1.0 Second Edition, HTTP1.1, SSLv3/TLS1.0 and a few supporting RFCs pulled in by refrerence in these base specifications. - Other specs (IETF RFCs) may be referenced in addition: Cookies SHOULD conform to RFC2965 Basic Profile 1.1 = More than 200 interoperability issues resolved

28 WS-I Profiles Reliable Secure Profile 1.0 Basic Security Profile 1.1
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 So, as we stated earlier, a Profile is a set of named specifications, at specific revision levels. The Basic Profile 1.0 is at its essence the following specifications: SOAP1.1, WSDL1.1, UDDI2.0, XML Schema, XML 1.0 Second Edition, HTTP1.1, SSLv3/TLS1.0 and a few supporting RFCs pulled in by refrerence in these base specifications. 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 - Still a techie forum rather than an end-user org: interop issues relate more to WS infrastructure. Even WSDL best practices: do not concern the end-user directly, but rather the dev tools.