OASIS ebXML Messaging Services TC

Back to discussions
Expand all | Collapse all

Groups - ebMS v3.0: Part 2, Advanced Features (v55) (ebMS3-part2-V55.odt) uploaded

  • 1.  Groups - ebMS v3.0: Part 2, Advanced Features (v55) (ebMS3-part2-V55.odt) uploaded

    Posted 03-17-2010 19:12 
    Updates on:

(1) Bundling: see changes (in red) in 3.2.1, for WS-I compliance (one
payload as Body child)
(2) conformance clause: fixed the CC based on comments March 17th. (see
result in red from rev53). Based on last week discussion, a compromise is
to draft here a minimal conf clause (requiring only the push-and-push
forwarding model). Still WS-A required for routing ebMS signals.

 -- Mr Jacques Durand

The document revision named ebMS v3.0: Part 2, Advanced Features (v55)
(ebMS3-part2-V55.odt) has been submitted by Mr Jacques Durand to the OASIS
ebXML Messaging Services TC document repository.  This document is revision
#25 of ebMS3-part2-V32-JD.odt.

Document Description:
Updates on:

(1) Bundling: see changes (in red) in 3.2.1, for WS-I compliance (one
payload as Body child)
(2) conformance clause: fixed the CC based on comments March 17th. (see
result in red from rev53). Based on last week discussion, a compromise is
to draft here a minimal conf clause (requiring only the push-and-push
forwarding model). Still WS-A required for routing ebMS signals.

View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=36915

Download Document:  
http://www.oasis-open.org/committees/download.php/36915/ebMS3-part2-V55.odt

Revision:
This document is revision #25 of ebMS3-part2-V32-JD.odt.  The document
details page referenced above will show the complete revision history.


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration


  • 2.  RE: [ebxml-msg] Groups - ebMS v3.0: Part 2, Advanced Features (v55) (ebMS3-part2-V55.odt) uploaded

    Posted 03-21-2010 15:24 
    Hello,

In the multihop conformance section, error 0005 is referred
to as a new error, but it is an existing one. The 0020 is a
new error.  

In the conformance section for bundling, I think that
instead of making Bundling Policies optional we should
require support for the "undefined" value for
Pmode[].bundling.ordering.policy.  This basically has the
same effect but adds the requirement that bundling is not to
be used in combination with InOrder reliable messaging
policy.

In chapter 4 we have added some minor extension features
that are not described in the bundling or multihop chapters,
such as HTTP pipelining (4.3), transport security (4.4).  Do
we need conformance clauses for those?

Pim


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 3.  Large file transmission using AS2 restart

    Posted 03-24-2010 14:52 
     
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


  • 4.  RE: [ebxml-msg] Large file transmission using AS2 restart

    Posted 03-24-2010 16:13 
    I asked Terry Harding (author/editor) of the draft and he and I agree
that there is no obstacle in using the procedure with any HTTP POST
based protocol. There is a new HTTP header with an ID, and there is
state to retain on the receiver(and sender) side. The receiver also
needs to support the HEAD HTTP request. 

(It also pretends that a GET request on the resource URI exists and is
defined so that it would have a content-length associated with it that
the HEAD requests return. This content-length number allows the sender
to know where to restart, if necessary.)

Remember that the document is currently an Internet-Draft and not yet a
RFC.



    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 5.  RE: [ebxml-msg] Large file transmission using AS2 restart

    Posted 03-24-2010 19:01 
     
Hello Dale,

The draft IETF document expires on April 4th.   What is the
next step for this spec?

Pim


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 6.  RE: [ebxml-msg] Large file transmission using AS2 restart

    Posted 03-24-2010 19:06 
    New drafts will be issued until a decision is made about advancing it
through the IETF RFC process. I would have to find out whether there are
any dependencies on existing drafts. But mainly nothing unusual seems to
be in store for the draft's progress because it will meet the IP
policies and it is an informational RFC. Therefore, it does not have to
go through the same reviews as a standards track RFC would go through.


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 7.  Re: [ebxml-msg] Large file transmission using AS2 restart

    Posted 03-26-2010 15:51 
    

  


During last Wednesday's
discussion on the TC about using AS2 Restart, there were a number of
questions raised about the spec that couldn't be answered.  Would you
folks that raised questions, please post them here, so that I can
submit them to Aaron Gomez here at Drummond Group so that he and Terry
Harding (Axway; AS2 Restart spec editor) to brainstorm/prepare
responses.

    
Thanks!
    

    
Moberg Dale wrote:

    17957_1269457525_4BAA6275_17957_125228_1_822DFF5CD1096F4AA656A0F90E903E91041B31D4@wbe41.phx.us.sopra" type="cite">
  
    New drafts will be issued until a decision is made about advancing it
through the IETF RFC process. I would have to find out whether there are
any dependencies on existing drafts. But mainly nothing unusual seems to
be in store for the draft's progress because it will meet the IP
policies and it is an informational RFC. Therefore, it does not have to
go through the same reviews as a standards track RFC would go through.


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 8.  RE: [ebxml-msg] Large file transmission using AS2 restart

    Posted 03-29-2010 05:27 
    




    Hello,
    

     
    

    AS2 only supports "pushed" messages, and this is 
what AS2 Restart supports.
    

    A 
question is whether this mechanism could be used for large "pulled" 
messages.   
    

     
    

    Pim
    

     
    

    (I 
will post an updated version of the spec today or 
tomorrow)

    

    

    
From: Timothy Bennett 
[mailto:timothy@drummondgroup.com]
    Sent: 26 March 2010 
16:51
    To: Moberg Dale
    Cc: Pim van der Eijk; 
ebxml-msg@lists.oasis-open.org
    Subject: Re: [ebxml-msg] Large file 
transmission using AS2 restart

    

    During last Wednesday's 
discussion on the TC about using AS2 Restart, there were a number of questions 
raised about the spec that couldn't be answered.  Would you folks that 
raised questions, please post them here, so that I can submit them to Aaron 
Gomez here at Drummond Group so that he and Terry Harding (Axway; AS2 Restart 
spec editor) to brainstorm/prepare 
responses.

    Thanks!

    Moberg Dale wrote: 

    17957_1269457525_4BAA6275_17957_125228_1_822DFF5CD1096F4AA656A0F90E903E91041B31D4@wbe41.phx.us.sopra" type="cite">
    New drafts will be issued until a decision is made about advancing it
through the IETF RFC process. I would have to find out whether there are
any dependencies on existing drafts. But mainly nothing unusual seems to
be in store for the draft's progress because it will meet the IP
policies and it is an informational RFC. Therefore, it does not have to
go through the same reviews as a standards track RFC would go through.


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message
                                                
    
                                                
    --------------------------------------------------------------------- 
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


  • 9.  RE: [ebxml-msg] Large file transmission using AS2 restart

    Posted 03-29-2010 16:09


  • 10.  RE: [ebxml-msg] Large file transmission using AS2 restart

    Posted 03-29-2010 18:51 
    






     
    

    In the 
update (v56) I just posted, I've added a restriction to "push" mode when using 
AS Restart, to be able to use this feature without modification.  And left 
open the possibility to specify other transport-level restart mechanisms.  
AS2 Restart will still be useful for ebMS since deployments where 
this feature is needed will typically not be the small companies that motivated 
"pull" but medium or large organizations, so in practice many of the intended 
users would be served.  
    

     
    

    But 
perhaps we should still to a SOAP-level chunking/splitting mechanism to get a 
really general solution.
    

     
    

    Pim

    

    

    
From: Moberg Dale [mailto:dmoberg@axway.com]
    Sent: 29 March 2010 18:08
    To: Pim van der Eijk; 
timothy@drummondgroup.com
    Cc: 
ebxml-msg@lists.oasis-open.org
    Subject: RE: [ebxml-msg] Large file 
transmission using AS2 restart

    

    

    

    Good question. 

    

    

    Restart was intended 
mainly for POST HTTP messaging with the “payload” sent in the POST, not in the 
response. This can be seen in that the sender (the POSTer) needs to find out 
from the receiver (using HEAD) how much data was received for an identified 
payload.
    

    

    In the reverse case 
(using the “backchannel”) some other solution is needed. GET with a byte range? 
Re-POST with a payload identifier and something indicating the byte ranged that 
is still needed? 
    

    

    

    

    

    

    From: Pim van der 
Eijk [mailto:pvde@sonnenglanz.net]
    Sent: Sunday, March 28, 2010 10:27 
PM
    To:
    Cc: 
ebxml-msg@lists.oasis-open.org
    Subject: RE: [ebxml-msg] Large file 
transmission using AS2 restart
    

    

    

    Hello,
    

    

     
    

    

    AS2 only supports 
"pushed" messages, and this is what AS2 Restart 
supports.
    

    

    A question is whether 
this mechanism could be used for large "pulled" messages.   

    

    

     
    

    

    Pim
    

    

     
    

    

    (I will post an updated 
version of the spec today or tomorrow)
    

    

    

    

    

    From: Timothy 
Bennett [mailto:]
    Sent: 26 March 2010 16:51
    To:
    Cc: Pim 
van der Eijk; ebxml-msg@lists.oasis-open.org
    Subject: Re: [ebxml-msg] Large file 
transmission using AS2 restart
    

    During last Wednesday's 
discussion on the TC about using AS2 Restart, there were a number of questions 
raised about the spec that couldn't be answered.  Would you folks that 
raised questions, please post them here, so that I can submit them to Aaron 
Gomez here at Drummond Group so that he and Terry Harding (Axway; AS2 Restart 
spec editor) to brainstorm/prepare 
responses.

    Thanks!

     wrote: 
    New drafts will be issued until a decision is made about advancing it
    through the IETF RFC process. I would have to find out whether there are
    any dependencies on existing drafts. But mainly nothing unusual seems to
    be in store for the draft's progress because it will meet the IP
    policies and it is an informational RFC. Therefore, it does not have to
    go through the same reviews as a standards track RFC would go through.

    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message
                                                
    
                                                
    From: Pim van der Eijk [mailto:pvde@sonnenglanz.net] 
    Sent: Wednesday, March 24, 2010 12:01 PM
    To: ebxml-msg@lists.oasis-open.org
    Subject: RE: [ebxml-msg] Large file transmission using AS2 restart
     
    Hello Dale,
    The draft IETF document expires on April 4th.   What is the
    next step for this spec?
    Pim

    Original Message-----
    From:  [mailto:dmoberg@axway.com] 
    Sent: 24 March 2010 17:13
    To: Pim van der Eijk; ebxml-msg@lists.oasis-open.org
    Subject: RE: [ebxml-msg] Large file transmission using AS2
    restart
    I asked Terry Harding (author/editor) of the draft and he
    and I agree that there is no obstacle in using the procedure
    with any HTTP POST based protocol. There is a new HTTP
    header with an ID, and there is state to retain on the
    receiver(and sender) side. The receiver also needs to
    support the HEAD HTTP request. 
    (It also pretends that a GET request on the resource URI
    exists and is defined so that it would have a content-length
    associated with it that the HEAD requests return. This
    content-length number allows the sender to know where to
    restart, if necessary.)
    Remember that the document is currently an Internet-Draft
    and not yet a RFC.

    Original Message-----
    From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
    Sent: Wednesday, March 24, 2010 7:52 AM
    To: ebxml-msg@lists.oasis-open.org
    Subject: [ebxml-msg] Large file transmission using AS2
    restart
     
    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_work
    groups.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_work
    groups.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 
    ---------------------------------------------------------------------
    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


  • 11.  Pull'ing a specific document

    Posted 03-29-2010 21:20 
    










    


     Hi
    


    


    In initial conversations with partners/customers over AS4, I
have repeatedly heard the request to be able to Pull a particular document. The
unique identifier could be based on the UserMessage that has been exchanged
earlier e.g. PO # if a PO Message has been sent earlier. 
    


    


    Is there provision in the current spec to be able to support
that ? My  understanding is that it is a generic Pull where the next available
document is sent in the response.
    


    


    Any advice please ?
    


    


    Thanks
    


    Makesh


  • 12.  RE: [ebxml-msg] Pull'ing a specific document

    Posted 03-30-2010 05:37 
    






    Hello 
Makesh,
    

     
    

    We 
heard this requirement previously from German government 
users.
    

     
    

    There 
is a feature called sub-channels (see section 2.5.4 of the Part 2) that almost 
does this. If the response message is expected on the MPC 
    

     
    


     
    

    then a 
server could offer sub-channels like:
    

     
    

    messageid@sender.example.com">http://receiver.example.com/mpc123/?refToMessageId=messageid@sender.example.com
    

    

     
    

    or 
with an XPath expression that matches SOAP headers. Right now such a convention 
(to use URL query syntax) is not standardized.  But it might be the easiest 
way to handle this.
    

     
    

    The 
eb3:PullRequest has an open content model, so we could also invent some element 
syntax like
    

     
    

    <eb3:PullRequest mpc="http://receiver.example.com/mpc123">
    

        
<eb3:RefToMessageId>messageid@sender.example.com</eb3:RefToMessageId>
    

    </eb3:PullRequest>
    

     
    

    But 
this is a really an extension and again, is not standardized right 
now.
    

     
    

    Pim

    

    

    
From: Makesh Rao (marao) 
[mailto:marao@cisco.com]
    Sent: 29 March 2010 23:20
    To: 
ebxml-msg@lists.oasis-open.org
    Subject: [ebxml-msg] Pull'ing a 
specific document

    

    

    

     Hi
    

    

    In 
initial conversations with partners/customers over AS4, I have repeatedly heard 
the request to be able to Pull a particular document. The unique identifier 
could be based on the UserMessage that has been exchanged earlier e.g. PO # if a 
PO Message has been sent earlier. 
    

    

    Is 
there provision in the current spec to be able to support that ? My 
 understanding is that it is a generic Pull where the next available 
document is sent in the response.
    

    

    Any 
advice please ?
    

    

    Thanks
    

    Makesh


  • 13.  Re: [ebxml-msg] Large file transmission using AS2 restart

    Posted 03-31-2010 18:17 
    



Retrieving a range of bytes from a resource on an HTTP server is already part of the HTTP 1.1 spec by specifying the Range header in the request. To use this functionality in case of message exchanges you must be able to identify the message you want to retrieve the range from. For this the Etag header from the AS2 restart spec could be used. Although this looks similar to push restart I don’t know if it just as easy to implement as the http server has to use the message id to identify the resource being requested. If the id is in an http header it might not recognize it as a separate resource. I don’t know how if it would be easier if the id is part of the URL.

    
Assuming it can be done with the http header a section to specifiy this could look like:
    
===

    
    4.4.3.1 ebMS restart
    
    The AS2-restart specification only allows restart functionality for pushed messages. It is however useful to have restart functionality when pulling large messages. Therefore the restart functionality as specified in the AS2 restart specification is extended here to pulling. To identify this functionality a value of ebms3-restart MUST be set for Pmode[].Protocol.Restart.Protocol.   
    
When this protocol is used the endpoint responding to a PullRequest MUST include a Etag http header in the response with a unique transfer id. It is RECOMMENDED to use the ebMS MessageId as the transfer id. The pulling endpoint can now restart the pull by sending a HTTP GET (or POST depending on allowed methods) and specifying both the Etag and Range http headers.

    
===

    
Regards
    
Sander

    
On 29/03/2010 18:07, "Moberg Dale" <dmoberg@axway.com> wrote:

    

    Good question.
    
 
    
Restart was intended mainly for POST HTTP messaging with the “payload” sent in the POST, not in the response. This can be seen in that the sender (the POSTer) needs to find out from the receiver (using HEAD) how much data was received for an identified payload.
    
 
    
In the reverse case (using the “backchannel”) some other solution is needed. GET with a byte range? Re-POST with a payload identifier and something indicating the byte ranged that is still needed?
    
 
    
    
    

    

    

    
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
    
Sent: Sunday, March 28, 2010 10:27 PM
    
To: timothy@drummondgroup.com
    
Cc: ebxml-msg@lists.oasis-open.org
    
Subject: RE: [ebxml-msg] Large file transmission using AS2 restart
    

    

    
    Hello,
    

    

    

    
    AS2 only supports "pushed" messages, and this is what AS2 Restart supports.
    

    
    A question is whether this mechanism could be used for large "pulled" messages.   
    

    

    

    
    Pim
    

    

    

    
    (I will post an updated version of the spec today or tomorrow)
    
     


    

    

    

    
    From: Timothy Bennett [mailto:timothy@drummondgroup.com]
    
Sent: 26 March 2010 16:51
    
To: Moberg Dale
    
Cc: Pim van der Eijk; ebxml-msg@lists.oasis-open.org
    
Subject: Re: [ebxml-msg] Large file transmission using AS2 restart
    
    During last Wednesday's discussion on the TC about using AS2 Restart, there were a number of questions raised about the spec that couldn't be answered.  Would you folks that raised questions, please post them here, so that I can submit them to Aaron Gomez here at Drummond Group so that he and Terry Harding (Axway; AS2 Restart spec editor) to brainstorm/prepare responses.

    
Thanks!
    

    
Moberg Dale wrote:
    
    New drafts will be issued until a decision is made about advancing it
    
through the IETF RFC process. I would have to find out whether there are
    
any dependencies on existing drafts. But mainly nothing unusual seems to
    
be in store for the draft's progress because it will meet the IP
    
policies and it is an informational RFC. Therefore, it does not have to
    
go through the same reviews as a standards track RFC would go through.
    
 
    

    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message
                                                
    
                                                    --------------------------------------------------------------------- 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


Related Content