Hello All from AU;
Just as a matter of interest; why are we not proposing to use the Splitting and Joining profile here for handling large messages?
Regards,
David Tuke
Enterprise Architect
Oban Pty Ltd | Ground Floor 19-23 Prospect St
| Box Hill 3128 | Australia
ABN 18 163 365 080
T: +61 3 9044 1702 | M: 0408 017 962 | F: +61 3 9044 1799
E:
David.Tuke@obansolutions.com.au | W:
www.obansolutions.com.au
***NOTICE***
This e-mail may contain confidential or legally privileged material and if you are not the intended recipient, you are advised that Oban Pty Ltd does not consent to you reading or copying the material and does not waive any confidentiality or legal privilege
associated with it. This e-mail may also contain material which is protected by copyright and if you are not the intended recipient, you are advised that Oban Pty Ltd has not consented to your reproduction of the material and there is no intention to provide
you with an implied licence to exercise any of the rights of the copyright owner or an authorised licensee. If you have received this e-mail in error, please advise Oban Pty Ltd immediately by return e-mail or by telephone on 61-3-9236-1900.
The recipient of this e-mail is solely responsible for conducting such tests and virus scanning as may be necessary, before using any attachment, to ensure that the attachment does not
contain any virus and that use of the attached materials will in no way corrupt the recipient's data or systems or those of any other person.
From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org]
On Behalf Of Sander Fieten
Sent: Thursday, 4 June 2015 9:23 PM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Proposal for handling large messages
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.