ebXML Messaging Version 3 Core Specification, AS4 Profile, new Advanced Features OASIS ebXML Messaging TC

Overview Part 1: Core Specification OASIS Standard, October 2007 AS4 Profile OASIS Committee Specification, April 2010 Part 2: Advanced Features (2010) OASIS Public Review Draft, August 2010

ebXML Messaging Version 3.0 Part 1: Core Specification

ebXML Messaging 2.0 & 3.0 Message Header with Business Metadata Identifies Business Partners, Transaction Semantics, Context, Agreement, Properties, Payloads Reliable Message Delivery At-Least-Once, At-Most-Once, In-Order delivery Security Digital Signature and Payload Encryption Support for Non-Repudiation of Origin & Receipt Leverages SOAP, MIME envelopes XML, EDI, multimedia payloads Multiple payloads per message Transport Protocol Mappings for HTTP and SMTP Composition with other eBusiness Components

New in ebMS 3.0 Core Further Web Services Convergence SOAP 1.1 or SOAP 1.2 SOAP with Attachments or MTOM WS-Security 1.0 or 1.1 WS-Reliability 1.1 or WS- ReliableMessaging 1.1/1.2 Compatible with WS-I profiles Meets new user requirements SME endpoints, message partitioning

New ebMS 3.0 Concepts & Features Processing Modes Parameters for capturing, expressing, sharing configuration choices, message QoS. Message Pull Feature Message Receiver is Polling the Message Sender Consumer “receives” messages by pulling them from Sender Benefit: Supports Small and Medium Size Enterprises Occasionally connected, no fixed IP address, behind firewalls Message Partition Channels Messages assigned to channels Supports priority handling

Message Pulling Feature Submit Message (for sending) Message queued for future pulling Sender application need not be “pull-aware” PullRequest Signal Generated by requesting MSH (not application) Targets a channel, secured/ authorized for the channel Pulled Message Pulled message sent over HTTP response (if HTTP) Sent Reliably (“Exactly-Once” delivery) “Light” V3 MSH Pull-Capable V3 MSH Submit Message Deliver Message Pull Request Pulled Message

Restricted / Intermittent Connectivity Roaming endpoints (e.g. no static IP address), or intermittently connected MSH 3 Application Pull Signal Pulled Response Pushed Message Deliver Light MSH 1 Submit Response Light MSH 2 Pulled Message

AS4 Profile Message packaging governed by ebMS 3.0 Support for both document push and pull message exchange choreographies Message security governed by WS-Security with added support for payload compression Support for an AS2-like business-level Non- Repudiation Receipt (MDN) Reception Awareness – “just enough” reliable messaging (similar to AS2 and ebMS 2.0)

AS4 compared to AS2 AS4 has comparable features to AS2 including: Document push message exchange patterns Support for Non-Repudiation Receipts Support for “lightweight” reliable messaging Support for common security aspects like digital signatures, encryption, and payload compression AS4 additionally supports the following features not available in AS2: Document pull message exchange pattern including support for secure access to MPCs Native support for Web Services Support for “lightweight” client implementations

ebMS3/AS4 Implementations OASIS successful use statements (2007): Axway, Fujitsu, NEC Vendor implementations Cisco, Data Applications Limited, ENEA, Flame Computing, Fujitsu, NEC Other implementations have expressed interest in interoperability testing, but have not yet been publicly announced Open Source: Holodeck

Industry Endorsement Japan Electronics and Information Technologies Association (JEITA) HL7 Version 3 Standard: Transport Specification - ebXML ebxml.htm ebxml.htm Aerospace industry in Europe protocols/index.htm protocols/index.htm OASIS Energy Interoperability TC open.org/committees/download.php/37925/energyinterop-1%200- spec-wd-12.pdf open.org/committees/download.php/37925/energyinterop-1%200- spec-wd-12.pdf Textile, clothing, footwear industry in Europe eBIZ project

Testing and Certification Drummond Group is planning for the following upcoming testing events: A week-long “virtual” BAKEOFF ideally in early December 2010 to demonstrate AS4/ebMS3 interoperability Followed by a live BAKEOFF event at a TBD conference or expo in early 2011 A full-matrix interoperability Certification Test in 1H2011 Perhaps some of these testing events will be sponsored or co-sponsored by OASIS

ebXML Messaging 3.0 Part 2: Advanced Features OASIS ebXML Messaging TC

New features in Part 2 Multi-hop messaging (not in this presentation) Messaging across ebMS intermediaries Supports SME-to-SME exchanges Message Bundling Messages containing multiple user message units Large Message Handling AS2 restart and AS4 compression New splitting, joining and message compression protocol Variants in MEP Execution Selective pulling, alternate MEPs

Message Bundling

High-end, optional feature Motivated by need to support efficient (very) high volume exchanges of (small) documents Thin, generally useful, layer over core MSH functionality that adds little complexity to an MSH Typical applications: High volume, non real-time transactions involving small documents Event reporting and data synchronization Any legacy batch application

Message Bundling A ebMS “bundle” contains multiple “user messages” Similar to EDIFACT concept of “exchanges” containing “messages” A “bundle” has no identity: Routing and processing configuration is based on a designated user message unit (the primary) Primary unit is first unit in eb3:Messaging container Other units are added as secondary units SOAP with Attachments: MIME envelope MIME part SOAP envelope / header eb3:Messaging Primary unit header Secondary unit(s) header Other SOAP header(s) for security, reliability etc. SOAP Body MIME part(s) Payload(s) related to primary message unit MIME part(s) Payload(s) related to secondary message unit(s)

Requirements and Goals Bundling reduces MSH processing overhead Transport, security, reliable messaging Both push and pull supported (sync not recommended) Units are still submitted and delivered individually Consistent interface for applications Bundling configuration is a partner agreement feature Specify “compatible” units, max delay, size etc. Bundling and SOAP processing Bundling adds limited complexity to an ebMS 3.0 engine Bundling composes with other advanced features

Example Message unit type A Compatible with A only Max delay 60 seconds, max bundle size 5 MB Size ranges from 10 to 40 KB A messages units will never be secondary units, except with other A units Message unit type B and C Compatible with A, B and C Max delay 10 minutes, max bundle size 5 MB Size ranges from to 20 to 60 KB B and C message units will be typically bundled with an A message unit if one is submitted within 9 minutes; otherwise as B/C bundles Message unit type D Compatible with A, B, C and D Max delay 15 minutes, max bundle size 5 MB Size ranges from 1 MB to 8 MB D message units may bundle with other units if they are small, otherwise they will be transmitted as standalone messages

Sample log file fragment from a bundling MSH (Sending MSH) :16:12,006 INFO [bsi.handleTimeouts:2609] Expired: 7518ffa (no outstanding requests) :16:12,006 INFO [app.apply_bundling:35] Checking 4 units as candidate secondary message units for 7518ffa cf-a598- pmode a size :16:12,007 INFO [app.apply_bundling:44] Not bundling unit compatible pmode d time left 48 but size is 5798 so combined size 5816 > maxsize :16:12,007 INFO [app.apply_bundling:47] Bundling secondary unit 1 compatible pmode d time left 493 size now :16:12,009 INFO [app.apply_bundling:47] Bundling secondary unit 2 compatible pmode b time left 503 size now :16:12,009 INFO [app.apply_bundling:47] Bundling secondary unit 3 compatible pmode c time left 599 size now :16:12,009 INFO [app.apply_bundling:55] Formed a bundle containing 4 unit(s):

Message Splitting, Joining and Compression

Background and context Size of B2B messages continues to increase… Operational issues of (very) large messages: Failed transfers cause unnecessary retransmission of data (Network) components impose size limits Temporary storage of MSH Delays in store-and-forward intermediaries become unacceptable Expensive overlap in infrastructures: Web Services / ebXML / SOA-based exchanges EDI / ebXML Managed File Transfer (MFT) and its protocols

Large File Handling in ebMS 3 AS2 Restart feature HTTP feature rather than AS2 feature Limited to “push”, no support for “pull” mode AS4 compression Per payload compression Split, Join, Compress protocol Large message is split by sending MSH and reassembled by (ultimate) receiving MSH MSHs exchange “fragment” SOAP messages, controlled by new MessageFragment SOAP header Optional full message compression feature

SOAP Processing MessageFragment can be used by non-ebMS protocols In ebMS 3 binding, splitting occurs in sending MSH: After ebMS packaging (SOAP, MIME) After bundling (if bundling is used) Prior to security and RM processing Each fragment contains: In ebMS 3 binding, a subset of the eb3:Messaging header A MessageFragment header One payload containing a subrange of the input message Compression option Algorithm agreed among partners Applies to MIME package: payloads, SOAP / MIME headers Fragments can be pushed and pulled

Compose with Bundling GDSN Case Study: 23 sample GDSN 2.7 messages, total 306K ebMS3 eb3:UserMessage header info added: adds 19K (6%) Total after bz2 compression: 13K, i.e. 4% Other case studies eCom 2.6 order (11 docs, 83K), UBL 2.0 (13 docs, 11.8K), bz2/zlib compression: worst case 8% Comparison with payload compression: Best case 14%; worst case 25% Use bundle, split and compress to “optimize” message sizes

Summary

ebMS 3.0 (and AS4) ebMS 3.0 Core Specification WS-* based WS-I profiles compliant Functional superset of ebMS 2.0 Important extensions for Small and Medium-Size businesses AS4 Profile of Core Specification Functional superset of AS2 Adds payload compression, Non-Repudiation of Receipt, Reception Awareness

Part 2: Advanced Features Intermediaries Enable SME-to-SME message exchange Bundling Support efficient high-volume message exchange Split, join, compress Support efficient transfer of very large messages (and message bundles) Variants in MEP Execution Better Pull and Sync replies

ebMS 3.0 Parts 1, 2 and AS4 B2B protocol with the broadest coverage of user deployment scenarios Push, Pull and Synchronous exchanges From light-weight clients to high-end B2B gateways Point-to-point exchange and multi-hop exchanges From occasional exchanges to very high volume exchanges From small message exchanges to very large message exchanges New functionality that today Is not in any other WS-* specification Only exists in (industry) niche B2B protocols Is handled (redundantly) at the application layer

Q & A ……….

More Information ebMS Version 3.0 Part 1: Core Specification msg/ebms/v3.0/core/os/ msg/ebms/v3.0/core/os/ AS4 Profile msg/ebms/v3.0/profiles/200707/ msg/ebms/v3.0/profiles/200707/ ebMS Version 3.0 Part 2: Advanced Features open.org/committees/download.php/38969/ebMS3- Part2-CD01-PR01.zip open.org/committees/download.php/38969/ebMS3- Part2-CD01-PR01.zip

More Information TC public page open.org/committees/ebxml-msg/ open.org/committees/ebxml-msg/ Public Review Announcement msg/201008/msg00010.html msg/201008/msg00010.html