[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Proposal for handling large messages
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***
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 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]