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



OASIS Standard, October 2007


OASIS Committee Specification, April 2010


OASIS Public Review Draft, August 2010







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



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


SME endpoints, message partitioning




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

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

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








Axway, Fujitsu, NEC



Cisco, Data Applications Limited, ENEA,
Flame Computing, Fujitsu
(Some others not yet public – to be confirmed by Timothy)
Open Source: Holodeck
 http://holodeck-b2b.sourceforge.net/




Japan, Electronic Commerce ALliance for
Global Business Activity (ECALGA)


Japan Electronics and Information Technologies
Association (JEITA) http://ec.jeita.or.jp/eng/modules/contents01/index.ph
p?id=3
HL7 Version 3 Standard: Transport
Specification - ebXML
 http://www.hl7.org/v3ballot/html/infrastructure/transp ort/transport-ebxml.htm
Textile, clothing, footwear industry in Europe
 http://www.ebiz-tcf.eu/

OASIS ebXML Messaging TC





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



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



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)





Reduce MSH processing overhead (transport, security, reliable messaging)


Bundled units are sent, forwarded and received as a whole
Both push and pull supported (sync not recommended)
Units are submitted and delivered individually

Consistent interface for applications
Bundling configuration is a partner agreement feature

Specify “compatible” units, max delay, size etc.

Error to report inconsistent bundles
Error and receipt signals reference individual units

Delivery policies define dependencies among units




SOAP processing requirements:


Bundling feature should impose limited changes to an existing
Core v3 engine and its security and reliability modules
Bundling should compose with multi-hop and split, join, message compression features
Security



Single XML Signature covers payloads and the eb3:Messaging (including all units) and other SOAP headers
WS-Security signing and encryption keys are specified by primary unit Pmode
Receipt signals are generated for each unit separately
Reliable Messaging


Bundling precedes RM processing: a bundle is a single RM unit
Compatible with In-Order contract




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 transmit as standalone messages

2010-08-02 22:16:12,006 INFO [bsi.handleTimeouts:2609] Expired: 7518ffa5-7366-
42cf-a598-c14878af81b2@example.com (no outstanding requests)
2010-08-02 22:16:12,006 INFO [app.apply_bundling:35] Checking 4 units as candidate secondary message units for 7518ffa5-7366-42cf-a598c14878af81b2@example.com pmode a size 18
2010-08-02 22:16:12,007 INFO [app.apply_bundling:44] 1280780220 Not bundling unit e611ae8c-5454-457d-96df-01550be752ec@example.com compatible pmode d time left 48 but size is 5798 so combined size 5816 > maxsize 5000
2010-08-02 22:16:12,007 INFO [app.apply_bundling:47] 1280780665 Bundling secondary unit 1 2d96b46f-3e63-4466-ad8b-5b8a0d752239@example.com compatible pmode d time left 493 size now 3413
2010-08-02 22:16:12,009 INFO [app.apply_bundling:47] 1280780675 Bundling secondary unit 2 3b767852-957d-4cb7-83e1-5e56ed7b1db1@example.com compatible pmode b time left 503 size now 3455
2010-08-02 22:16:12,009 INFO [app.apply_bundling:47] 1280780771 Bundling secondary unit 3 cc874b4f-0851-4249-8694-80aa5bb8fdb6@example.com compatible pmode c time left 599 size now 3477
2010-08-02 22:16:12,009 INFO [app.apply_bundling:55] Formed a bundle containing
4 unit(s):
7518ffa5-7366-42cf-a598-c14878af81b2@example.com
2d96b46f-3e63-4466-ad8b-5b8a0d752239@example.com
3b767852-957d-4cb7-83e1-5e56ed7b1db1@example.com
cc874b4f-0851-4249-8694-80aa5bb8fdb6@example.com




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




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






MessageFragment can be used by non-ebMS protocols
In ebMS 3 binding, splitting occurs:



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 to support routing across intermediaries
A MessageFragment header

One payload containing a subrange of the input message
Compression option


Algorithm agreed among partners
Applies to complete MIME package (all payloads and headers)
Supports push and pull





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%
Bundle and split to “optimize” message sizes

E.g. rearrange 1000 messages, sizes ranging from
5K to 800MB, into 10MB fragments



Selective Pulling

New mechanism to “pull” a specific message

E.g., the response message to a request (using its eb3:RefToMessageId ),

E.g. a subsequent related message (based on eb3:ConversationId )
Alternate MEPs

New fallback mechanism for synchronous exchanges

Mechanism to pull a response, if the MSH is aware it is unable to produce a timely synchronous response







Intermediaries

SME-to-SME message exchange
Bundling

Efficient high-volume message exchange
Split, join, compress and AS2 restart

Transfer very large messages and bundles efficiently
Important functionality that today:

Only exists in (industry-specific) niche protocols


Is not in any WS-* based spec
Is now typically handled (and duplicate) at the application layer



 ebMS Version 3.0 Part 1: Core Specification
 http://docs.oasis-open.org/ebxmlmsg/ebms/v3.0/core/os/
AS4 Profile
 http://docs.oasis-open.org/ebxmlmsg/ebms/v3.0/profiles/200707/ ebMS Version 3.0 Part 2: Advanced Features
 http://www.oasisopen.org/committees/download.php/38969/ebMS3-
Part2-CD01-PR01.zip

MSH 1
Gateway
Or ESB
MSH 3
Request Web
Service A
Response
One-Way
Async
Response
Web
Service B
Light
MSH 2
Web
Service C
JMS, MQ..

Pull signal
Low-priority ServiceRequest
MSH
Customer
Service
High priority ServiceRequest
Channels used for
•
Selective Transfer
• DataType Channels
• QoS Channels ?
•
Yes, but not 1-1 with QoS
MSH
Support
Center
ProcessingMode
Channel QoS

1.
How does ebMS(V3) relate to other ebXML specifications?
2.
if ebMS 3 is so heavily based on WS standards, what value does it add to using just plain WS?
3.
How does ebMS V3 relate to WS-I Profiles?
4.
What does ebMS V2/V3 do that AS2 doesn’t?
5.
Isn't pulling replicating what POP3 servers do?

How does ebMS(V3) relate to other ebXML specifications?


Compose with each other, but can be deployed separately (no dependencies on each other)
Integration points:



V3 Message Exchange Patterns map to ebBP Business Transactions
V3 Processing Modes map to CPPA
CPAs used to configure MSH may be stored in, and retrieved from, Registry

If ebMS 3 is so heavily based on WS standards, what value does it add to using just plain WS?





Business Headers
Channels, Pulling, Non-repudiation of Receipt
Different message consumption styles (WSDL not always appropriate)
Allows for a gateway architecture to decouple external
B2B and internally deployed WS
Future features (Part 2: routing, bundling…)

How does ebMS V3 relate to WS-I Profiles?

V3 reuses SOAP, WS-Security, WS-ReliableMessaging, and is subject to compliance with WS-I profiles
(BP1.0/1.2, BSP1.0/1.1)

V3 Conformance Profiles , defined in an adjunct document, will state compliance with above profiles
(some yet to be finalized in WS-I: BP2.0, RSP1.0)

What does ebMS V2/V3 do that AS2 doesn ’t?





Some QoS like reliability.
Message pulling, channels (e.g. selective pulling)
Message Exchange Patterns, and their bindings to business transactions
Ability to process WS invocations (SOAP intermediary model)
Will use SOAP model for routing (part 2)

Isn't pulling replicating what POP3 servers do?




There have been issues with SPAM on SMTP-based solutions.
Pull feature is desirable, regardless of protocol used.
May not want to rely on 3 rd -party (ISP) infrastructure.
Pull allows a better understanding and control of message location and status at all times.

2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010 ebMS1 ebMS2
BIP
ISO 15000
SOAP 1.1
ebMS3 Core
SWA
SOAP 1.2
BP 1.0
WS-A
BP 1.1 SSBP
SOAP 1.2
2nd
AP
MTOM ebMS3 Part 2
BP 1.2
BP 2.0

2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
S/MIME
XML DSIG
XML ENCR
SWA ebMS1 ebMS2
BIP
ISO 15000
WSS 1.0
WSS 1.1
BP 1.0
ebMS3 Core ebMS3 Part 2
WSSC 1.4
BSP 1.1
RSP 1.0
BP 1.1 SSBP AP
BSP 1.0

2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010 ebMS1 ebMS2
BIP
ISO 15000
WS-Reliability 1.1
ebMS3 Core
WS-RM 1.1
WS-RM 1.2
ebMS3 Part 2 RSP 1.0