Re: [ebxml-msg] Proposal for handling large messages

[Toon Vanhoutte <toon.vanhoutte@codit.eu>]

Good proposal, Sander.

One of the biggest advantages is the fact that it's only influencing the HTTP stack, so the impact of the ebMS processing is almost nihil.  In case of split & join, or external reference, it influences the ebMS processing in many ways: implementation, additional error handling, different non-repudiation,...

________________________________________
From: ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org> on behalf of Theo Kramer <theo@flame.co.za>
Sent: Wednesday, July 08, 2015 10:09 PM
To: Sander Fieten
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Proposal for handling large messages

Thanks Sander

Your reasoning sounds good on the HTTP restart (resume) for large messages and as mentioned by others also useful for not so large messages, particularly over not so reliable connections.

I am in favour of investigating this in more detail, and on a draft spec so we can take this further.

On 04 Jun 2015, at 13:22 , Sander Fieten <sander@fieten-it.com> wrote:

> Hi all,
>
> as agreed at our April meeting I would look into the options for handling large messages with a focus on using the external payload reference and alternatively HTTP restart.
>
> When creating a profile for handling large message with external payload references I think the target is that the MSH will completely handle the processing of the message which includes on the sending side that the external payload must be made available to the receiver and on the receiving side to download the payload(s).
> Making the payload available to the receiver is strictly seen not necessary because the sending MSH could also use the already uploaded payload for its processing. That however has two drawbacks: first the producer application has to arrange for making the payload available to the receiver and second the MSH has to retrieve the payload from this location.
> If the producer has to arrange for the payload being available for download by the receiver it gets involved in the message transport itself, if only limited, and I think the case for using ebMS is that the business application should not concerned about the transport of the message.
> That the sending MSH must also retrieve the payload from the location where it is made available by the producer application is not very efficient especially when the payload is hosted in the cloud. In that case the payload is first uploaded by the producer and then downloaded again by the MSH for processing (signing). It may also cause issues with network security because both the producer application and MSH must have access to external networks. Of course this is all solvable but it gets complicated and our target should be to create a profile that is simple.
>
> As already noticed during the call an exchange that uses external payloads is always a kind of pull exchange as the payload must be retrieved by the receiver of the message. This will limit the usability of the external payload if the sending MSH can only push message and can not operate as a server. A possible solution is to upload the payload to the cloud. I think this should be included in a profile although it will make it more complex (because an MSH must be able to upload the payload to the cloud and we need to determine which upload protocols must be supported).
> However a bigger issue that limits the usability of the external payload is that the URL included in the user message may not be accessible by the receiver when operating in a multi-hop context. For example because endpoints are in different networks and can not access resources out of their network. Because the URL is included in a possibly signed message the intermediary can not change it.
>
> I therefore think that a possibility to restart a transmission on the http level is better to meet the objective of a reliable transfer of large messages that works in a multi-hop environment and that does not create dependencies between endpoints. Because the restart function applies to the transport level it can be used only for the hops that need it.
> Because the restart takes place at the http level it is transparant to the ebMS processing and therefor does not requires changes to already implemented ebMS processing. Only the correct configuration for http transmission needs to be set.

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3520 / Virus Database: 4365/10179 - Release Date: 07/07/15