Programme TICPME2010 Minefe - DGCIS Standards de Messagerie eBusiness Nouveaux développements  ebXML Messaging V3  Web Services (WS-I)  AS4 Présentation faite par : Jacques Durand : Fujitsu Computer Systems JDurand@us.fujitsu.com 19 Mars 2009

Programme TICPME2010 Minefe - DGCIS 1. ebMS V3 Version 3.0: Part 1, Core Features Committee Specification 02, 12 July 2007 DGCIS - Programme TICPME - Groupe thématique Architecture technique 19 Mars 2009

Messagerie ebXML: rappels Programme TICPME2010 Minefe - DGCIS Messagerie ebXML: rappels Basé sur extension SOAP (avec attachements) ebXML Messaging SOAP avec Attachements (MIME) SOAP HTTP SMTP … TCP / IP DGCIS - Programme TICPME - Groupe thématique Architecture technique 19 Mars 2009

ebMS 2.0 & 3.0: Principes de Base Programme TICPME2010 Minefe - DGCIS ebMS 2.0 & 3.0: Principes de Base Standard de messagerie ouvert, pour protocoles Internet, avec les fonctions avancées des messageries commerciales Indépendent du niveau bas Transport (HTTP, SMTP, FTP…) Ne définit pas d’ interface application (JMS ou autre…) Une entête genérique “Business” Identifie les partenaires, définit la sémantique Transaction et son Contexte, les attributs du Contrat eB Fiabilité du message (Reliable Message Delivery) Livraison garantie, élimination des doublons, livraison dans l’ordre Securité Signature digitale et Encryptage Support pour Non-répudiation d’Origine & de Réception Principles & fundamental features of ebMS (applies to both v2.0 & 3.0): Business Headers: Partner Identities: From (Sender), To (Recipient) Business Transaction Semantics: Service, Action, Roles Business Context: ConversationId applicable “Contract” properties: CPAId (reference to technical agreement) Reliable Delivery typically includes “At Least Once” or “At Most Once” (or both) quality of service, i.e. message is guaranteed to be delivered (or one or more party is notified of a problem), and if delivered more than once, duplicates are discarded. Security: Message content can be digitally signed, and data can be encrypted. One difference here is that 2.0 did not support encryption of the message headers, But 3.0 remedies that deficiency. Message envelope and packaging is based on SOAP and the MIME multipart message format. Because they are MIME-based, are easily carried over HTTP (web) & SMTP (email). These standards-based formats lead to Affordable Messaging solutions Composition with other functional pieces of the eB/eG stack (registry, agreement, bus transactions): whether ebXML or other 19 Mars 2009 DGCIS - Programme TICPME - Groupe thématique Architecture technique

Ce qui est nouveau dans ebMS 3.0 Programme TICPME2010 Minefe - DGCIS Ce qui est nouveau dans ebMS 3.0 Reutilisation des standards Web Services au niveau Protocole WS-RM (Fiabilite), WSS1.1 (Securite), profils WS-I, SOAP 1.1 + 1.2 Transfer de message en mode “ tiré “ (pull) Le Receveur interroge l’ Envoyeur (Polling style POP3) Adapté aux petits utilisateurs (PME), connectivité restreinte “Conduits” (channels) de Messages Permet les priorités de transfer, et les flux tendus Modes de Traitement du Message (P-mode) Ensemble de parametres qui controlent le traitement du message (codifiable dans le CPA). Multi-hop (en cours de standadisation) Aussi dans ebMS3: notion d’ accuse’ de reception (niveau business) En cas de connectivite limitee: Occasionellement connecte’, pas d’addresse Internet fixe, restrictions d’acces dues aux murs de feu Processing Modes: Explain relationship w/ CPA. Client-Only Partners  Message Pulling Selective Transfer  Message Channels (message pulling, channels, MECs, headers, message authorization, non-repudiation support, compliance with SOAP/WS/WS-I). DGCIS - Programme TICPME - Groupe thématique Architecture technique 19 Mars 2009

Compatibilite ebMS3 - WebServices et profils WS-I Programme TICPME2010 Minefe - DGCIS Compatibilite ebMS3 - WebServices et profils WS-I Profils WS-I ebMS V3 WSDL WS-RM UDDI WS-Sec + + HTTP ebMS + SOAP SMTP SMTP SMTP DGCIS - Programme TICPME - Groupe thématique Architecture technique 19 Mars 2009

Programme TICPME2010 Minefe - DGCIS Intranet Passerelle B2B Partenaire distant Gateway Or ESB Requête- réponse ebMS3 ebMS3 Web Service A Internet Web Service B “One-Way” ebMS3 Messages tirés The Gateway is where the message QoS (security, reliability, non-repudiation) will be enforced by MSH V3. It offers a single entry point (URL) to the company systems on the right. (This is NOT the HTTP proxy / reverse-proxy: it has higher-level functions.) The Gateway may act as an intermediary to Web services deployed internally. Based on the processing mode, and message header content (Service/Action) it will forward to the right WS. It could be a request-response, or a One-way operation. In doing so, it may act as the proxy WS client, and remove the need to publish WSDL files to every external business partner. Remote business partners only need to know which business document to send out. These may be transformed by the Gateway to suit the internal WS invocation. Gateway will mediate B2B traffic to other hosts internally, possibly for various message consumption modes – e.g. queuing. A light MSH will access the Gateway and pull asynchronous responses over its channel. The Web service (B) does not need to adjust to either type of partner (e.g. publish a different type of operation): the Gateway does. Applic. ERP Terminal Leger (pas d’ adresse IP) JMS, MQ.. DGCIS - Programme TICPME - Groupe thématique Architecture technique 19 Mars 2009

2. Web Services Programme TICPME2010 Minefe - DGCIS DGCIS - Programme TICPME - Groupe thématique Architecture technique 19 Mars 2009

Programme TICPME2010 Minefe - DGCIS Situation Actuelle des Standards de Services Web  Interface:  WSDL 1.1 plutot que WSDL 2.0.  déploiements en interne surtout  Messagerie:  SOAP 1.1 et 1.2 bien supportés dans les plateformes Web mais REST aussi…  SOAP mieux supporté par les outils de devpt  Repertoire:  UDDI adoption: en-dessous des prévisions  Pas adapté au cahier des charges SOA? Servcies Web: Trois espaces de standard bien distincts (interface service, messagerie, repertoire) IBM spokespeople are saying that the UDDI standard for registries isn't cutting it, and the "time is now" for a new registry standard more focused on today's SOA realities. In the meantime, IBM will be offering a proprietary solution. In a new report in ITWeek, IBM managers state that SOAs have stretched the Universal Description, Discovery and Integration (UDDI) web services standard to the limit, and that it's time for a new standard. "Our clients are telling us that they have an integration pain point," Andrew Hately, a manager at IBM's Software Group, said. "We need to [create a new standard] and the time is now." A few days ago, I posted news that Burton Group's Anne Thomas Manes had just issued a report that IBM's WebSphere Service Registry and Repository (WSRR) 6.0.1 doesn't fully support UDDI, the commonly accepted standard behind SOA registries. Manes pointed to the irony that IBM was one of the DGCIS - Programme TICPME - Groupe thématique Architecture technique 19 Mars 2009

Programme TICPME2010 Minefe - DGCIS Parmi les WS-*, quelle combinaison gagnante?  WS-Security  WS-ReliableMessaging  WS-Addressing  WS-Policy  WS-SecureConversation  WS-Trust  WS-Transactions  WS-ResourceAccess  WS-Eventing  WS-Notification  WS-Transfer - … IBM spokespeople are saying that the UDDI standard for registries isn't cutting it, and the "time is now" for a new registry standard more focused on today's SOA realities. In the meantime, IBM will be offering a proprietary solution. In a new report in ITWeek, IBM managers state that SOAs have stretched the Universal Description, Discovery and Integration (UDDI) web services standard to the limit, and that it's time for a new standard. "Our clients are telling us that they have an integration pain point," Andrew Hately, a manager at IBM's Software Group, said. "We need to [create a new standard] and the time is now." A few days ago, I posted news that Burton Group's Anne Thomas Manes had just issued a report that IBM's WebSphere Service Registry and Repository (WSRR) 6.0.1 doesn't fully support UDDI, the commonly accepted standard behind SOA registries. Manes pointed to the irony that IBM was one of the designers of UDDI. En mai 2001, IBM et Sun ont signé un document intitulé "Using UDDI to find ebXML Registry/Repository". DGCIS - Programme TICPME - Groupe thématique Architecture technique 19 Mars 2009

Programme TICPME2010 Minefe - DGCIS The WS-I Approach Les Profils WS-I Définissent des normes d’ Intégration de standards WS existants (d’ OASIS, W3C, IETF…) Ces normes réduisent les problèmes d’ interopérabilité PROFIL WS-I Like in software design: iterative design is better than waterfall: but iterations are costly for standards! (new version, disruptive) Profiling is less costly. SOAP UDDI HTTP XML … STANDARDS WS-* et autres 19 Mars 2009

Programme TICPME2010 Minefe - DGCIS WS-I Profiles Les Profils WS-I Destinés à être automatiquement imposés par l’infrastructure WS :  La pile Web Service (e.g. Axis2, WebSphere…) met en application le coté MESSAGE  L’ environnement de développement met en application le coté INTERFACE (WSDL) SOAP 1.1 WSDL 1.1 UDDI 2.0 XML Schema XML 1.0 (Second Edition) HTTP 1.1 SOAP 1.2 WS-Addressing WSDL 1.1 UDDI 2.0 XML Schema XML 1.0 HTTP 1.1 Basic Profile 1.1 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 2.0 19 Mars 2009

Programme TICPME2010 Minefe - DGCIS Coté Logiciel: les piles Web de 3 ème génération élargissent la notion de “Service Web”  Plus flexibles – moins “orthodoxes”:  Services avec ou sans WSDL  SOAP 1.1 + SOAP1.2 + REST, et aussi HTTP / SMTP / JMS  Meilleur traitement des documents:  gros formats: streaming, XML parsing.  Logiciel libre et commercial:  Logiciel Libre: Apache Axis2, JBossWS, GlassFish (Sun), SpringWS…  Commercial: IBM (WebSphre), Microsoft (.NET)… The MSH is an Apache Axis2 “service” . Taille message: 2-3Mb trop gros pour gen 2. DGCIS - Programme TICPME - Groupe thématique Architecture technique 19 Mars 2009

3. AS4 Programme TICPME2010 Minefe - DGCIS DGCIS - Programme TICPME - Groupe thématique Architecture technique 19 Mars 2009

Programme TICPME2010 Minefe - DGCIS AS1 AS2 AS3  “Internet Draft” IETF (2003)  AS1,2,3: fournissent une alternative aux VAN/EDI (“EDI-INT” ou “Web EDI”)  utilisent S/MIME, et toutes les facettes de la sécurité (confidentialité, non-répudiation, authentification, autorisation…)  AS 1, 2, 3 ne sont pas basés sur SOAP  …et diffèrent par le protocole utilisé DGCIS - Programme TICPME - Groupe thématique Architecture technique 19 Mars 2009

Programme TICPME2010 Minefe - DGCIS AS2 MIME Sur SMTP MIME Sur HTTP MIME Sur FTP AS1 AS3 AS2 AS1 AS3 HTTP SMTP FTP TCP / IP 19 Mars 2009

Programme TICPME2010 Minefe - DGCIS AS2  Tous types de messages:EDIFACT, X12, ebXML…)  Definition élaborée d’accusé de réception: MDN (message disposition notification), synchrone (i.e. sur réponse HTTP) ou asynchrone  Non-répudiation de réception (NRR): évênement légal = vérification du reçu signé renvoyé par Receveur. 19 Mars 2009

Programme TICPME2010 Minefe - DGCIS AS4: Echanges Securisés de Documents B2B basés sur les protocoles Web Services Les societés originatrices: - Drummond Group - TIBCO - AxWay - CISCO - Fujitsu 19 Mars 2009

Programme TICPME2010 Minefe - DGCIS AS4: Convergence d’ AS2, ebMS et Web services:  Un protocole facile à déployer sur les infrastructures Service Web: basé sur les standards WS de sécurité, de fiabilité mais un protocole B2B simple et orienté document, pour connecter les architectures services (SOA) deployées en interne  Tire parti de fonctionnalités avancées de ebMS V3 sans les réinventer.  en-tête “business” élaborée, notion de conversation, etc  tirage de messages (“pulling”), canaux… Par rapport aux WS: AS4 limite les risques d’ absence d’ interoperabilite (pas de dependance d’ interface WSDL: ceux-ci peuvent etre deployes en interne). Highlights: Support for both document push and pull message exchange choreographies Support for an AS2-like business Non-Repudiation Receipt Message security governed by WS-Security specification along with support for payload compression Reception Awareness – Just enough reliable messaging 19 Mars 2009

Programme TICPME2010 Minefe - DGCIS La “ligne simple” du B2B  Le succès d’AS2 réside dans une approche minimaliste du B2B sécurisé  AS4 continue cette tendance en éliminant la complexité des interfaces WSDL et en évitant les risques inhérents au mapping de document types et business processus métiers aux operations SOAP  Support immédiat pour les types de transactions les plus courants.  Tous types de documents.  Juste assez de “fiabilité” (notification de réception) Web services landscape lacks a B2B messaging specification that has the simplicity and elegance of AS2 Simplification of Web services for B2B breeds an environment whereby the likelihood for interoperability become achievable As SOA and Web services deployments becomes more pervasive, the opportunity for B2B communication on these platforms will increase New markets that are Web services centric can benefit from the AS2 success story 19 Mars 2009

Pourquoi AS4? (d’ après Drummond) Programme TICPME2010 Minefe - DGCIS Pourquoi AS4? (d’ après Drummond)  AS4 est basé sur protocoles Web services (pas AS2)  “La complexité des Web services n’ a pas été bien traitée et une véritable interopérabilité n’ a pas été accomplie. AS4 apporte la simplicité d’ AS2 aux services Web. ”(Drummond)  Permet aux installations d’architectures orientées services (SOA) de différentes Entreprises de s’ interconnecter  AS4 aide ceux qui ont investi dans les services Web mais ont besoin de simplicité and d’interoperabilité  Les entreprises et consortiums qui ont déjà investi lourdement dans AS2 continueront avec AS2, mais pourront évoluer plus facilement (conversions AS2 <> AS4) AS4 aide ceux qui ont investi dans les services Web mais ont besoin de simplicité and d’ interoperabilité: En particulier dans les environnements multi-proprietaires. Maps the AS2 functional requirements onto the WS-* stack using ebMS 3.0 as a leverage point An open standard for the secure and payload-agnostic exchange of B2B documents using Web services Constrains the ebMS v3.0 specification (and its underlying specifications) for message packaging, transport, security, exchange patterns, and business non-repudiation 19 Mars 2009

AS4: Convergence d’ ebMS, des Web services et d’AS2 Programme TICPME2010 Minefe - DGCIS AS4: Convergence d’ ebMS, des Web services et d’AS2 AS4 = (fonctions d’AS2 augmentées, sur protocole ebMS3) ebMS V3 + HTTP AS4 AS2 Un sur-ensemble fonctionnel de Un profil de ebMS V3 AS4 ajoute le tirage de message (pulling) à AS2  Conforme aux profils WS-I (coté message), étant lui-même un profil d’ ebMS3  Interface plus aisé avec les Web services internes SOA 19 Mars 2009

Programme TICPME2010 Minefe - DGCIS Compléments d’informations disponibles auprès de l’AFNET :  Les standards d’architecture technique  des avis d’experts  Des cas d’utilisation (Rosettanet, Center for Disease control, GS1 etc. (les projets TICPME invités à les publier) Les propositions d’amélioration de ces informations sont bienvenues. Le soutien technique fera son possible pour vous apporter conseils et contacts utiles :  Remy Marchand :  Erick Jonquière :  AFNET : 01 53 43 82 70 remy.marchand@afnet.fr jonquiere@afnet.fr 19 Mars 2009