OASIS ebXML Messaging Services TC

Pim,
 
Excellent ideas.  So quick check here for my understanding - does re-start equate to chaining - so that I can send a large message in multiple pieces and the receiver then be able to recreate the original file when complete?  Sorta like the filesharing swarm delivery of bittorrent clients... but with discreet channels - not just anyone!


Thanks, DW
 
 

-------- Original Message --------
Subject: [ebxml-msg] Large file transmission using AS2 restart
From: "Pim van der Eijk" <pvde@sonnenglanz.net>
Date: Wed, March 24, 2010 10:52 am
To: <ebxml-msg@lists.oasis-open.org>


Hello,

There is a requirement of some potential users of ebMS 3.0
to be able to exchange large files (Gigabytes and larger).
There is a specification for AS2 that offers a "restart"
feature:
http://www.ietf.org/id/draft-harding-as2-restart-00.txt

We can borrow this feature for ebMS, and add a mini-section
to chapter 4 that references the AS2 feature. Since we just
reference the IETF RFC, this feature adds just a few lines
of text to the spec. Many multi-protocol B2B products
support this for AS2 already. It would be minimal effort
for them to enable this for ebMS. For ebMS users, it adds a
useful capability.

As we did for pipelining, we could add a Pmode parameter to
indicate whether the ebMS MSH supports it or not. If
"True", clients in HTTP client mode can add the HTTP ETAG
with ebMS messages sent and can use the HTTP HEAD command to
obtain the status of the transfer, as described in the RFC.
If "False", they should not do this. We've added Pipelining
to MEPBinding, and could do the same with "Restart":

PMode.MEPbinding.Restart {True/False}

Or we could make it a parameter in PMode.Protocol

What do people think?

Pim




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Restart has a sender do a HTTP HEAD
request to find the status of how many bytes (0 to all) made it to the receiver.
An identifier (from the original POST request) allows the receiver to know what
interaction is being queried. The sender then transmits the remainder. 



So it is not similar to bittorrent. (Mostly
the files exchanged in business are created by one party for some other one
party—there just aren’t other nodes out there that have a copy of
the specific file so that data exchange can spread file-part transmissions over
many TPC connections.)



Read the Internet-Draft for more details.
Terry Harding is the editor.















From: David RR Webber
(XML) [mailto:david@drrw.info]

Sent: Wednesday, March 24, 2010
8:24 AM

To: Pim van der Eijk

Cc: ebxml-msg@lists.oasis-open.org

Subject: RE: [ebxml-msg] Large
file transmission using AS2 restart







Pim,





 





Excellent ideas. 
So quick check here for my understanding - does re-start equate to chaining -
so that I can send a large message in multiple pieces and the receiver then be
able to recreate the original file when complete?  Sorta like the
filesharing swarm delivery of bittorrent clients... but with discreet channels
- not just anyone!











Thanks, DW





 





 







--------
Original Message --------

Subject: [ebxml-msg] Large file transmission using AS2 restart

From: "Pim van der Eijk" <pvde@sonnenglanz.net>

Date: Wed, March 24, 2010 10:52 am

To: <ebxml-msg@lists.oasis-open.org>



Hello,


There is a requirement of some potential users of ebMS 3.0

to be able to exchange large files (Gigabytes and larger).

There is a specification for AS2 that offers a "restart"

feature:

http://www.ietf.org/id/draft-harding-as2-restart-00.txt


We can borrow this feature for ebMS, and add a mini-section

to chapter 4 that references the AS2 feature. Since we just

reference the IETF RFC, this feature adds just a few lines

of text to the spec. Many multi-protocol B2B products

support this for AS2 already. It would be minimal effort

for them to enable this for ebMS. For ebMS users, it adds a

useful capability.


As we did for pipelining, we could add a Pmode parameter to

indicate whether the ebMS MSH supports it or not. If

"True", clients in HTTP client mode can add the HTTP ETAG

with ebMS messages sent and can use the HTTP HEAD command to

obtain the status of the transfer, as described in the RFC.

If "False", they should not do this. We've added Pipelining

to MEPBinding, and could do the same with "Restart":


PMode.MEPbinding.Restart {True/False}


Or we could make it a parameter in PMode.Protocol


What do people think?


Pim





---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail. Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php











---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php