Hello Ian,
Amid all the discussions on multihop, and with a F2F meeting coming up, it
may be good to take up this item again too as this is an important issue in
many user deployments. Here are some comments/ideas/questions, mainly on
the fragmented payload concept.
1) One interpretation of fragmenting at MSH level is that in some "message
service interface", the Submit() and Deliver() operations would refer to one
"logical" message. After Submit(), a suitably configured MSH would split
the message in fragments, and send them as separate lower-level messages.
Similarly, prior to invoking Deliver(), it would reassemble the message
fragments into a single "logical" unit. An MSH that does not support this
natively but still conforms to v3.0 Core would not support the
splitting/merging in the MSH, but could allow applications to set the
relevant metadata programmatically?
2) Would we expect each fragment to contain a copy of the (or a) full ebMS
header? If yes what would be the ebXML MessageId of a fragment message? Do
we assume multiple parts messages with the same ebMS message Id, or
different ones? If different, there has to be some reference to the larger
structure they should be reassembled into. Fragments would have different
message Ids at WSRM / WSR level and (if used) at WS-A level. To support
routing, each fragment message should contain all relevant ebMS metadata,
like From, To, Service, Action, ConversationId, too?
3) Similarly, in the response to a message sent as fragments, the
RefToMessageId would refer to the whole message, never to a single part. If
that response message is a large message itself, multiple fragment messages
would all refer to the same RefToMessageId. This is to express that the
ebMS concept of a MEPs is more a logical concept from a business process
point of view concept?
4) Most natural use cases for large messages sent in fragments assume
reliable messaging, and reliable messaging for all fragments. So either the
entire logical message (all message fragments) is delivered or it is not
delivered at all. If the message is split in fragments, any resending of
last parts would not trigger a retransmission of the full "logical" ebMS
message but just of the missing lower-level message containing the message
fragment. So a requirement could be that all parts are sent over the same
WSRM SequenceId, with the ordering of parts (1 < i < n) reflected in the
message number. The fragments could be sent over some existing sequences,
so fragments from different logical ebMS messages could be sent on single
WSRM sequence, as long as the partial order is preserved.
5) We need to think about the mapping of message fragments and the logical
structure of message parts. An ebMS message transporting a single 2GB MRI
image could still have just one eb:PayloadInfo element. An ebMS message
transporting 35 small JPEG images as 35 eb:PayloadInfo elements may not need
to split them in as many separate messages.
6) A common messaging pattern is Claim Check pattern, see
http://www.enterpriseintegrationpatterns.com/StoreInLibrary.html.
I remember discussions in the past about a need to "push" part of the
information and allow other information to be "pulled" on demand. Perhaps
different fragments could have their own P-Modes. A common use case is that
structured metadata (typically a small XML document) is pushed immediately
to the destination, but that large supporting data (XML or binary) could be
pulled with lower priority. Gateway intermediaries could add value here too.
Pim
Original Message-----
From: ian.c.jones@bt.com [mailto:ian.c.jones@bt.com]
Sent: 31 October 2007 21:59
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Groups - Initial thought draft Large Paylod handling
(Largepayloadsupport.htm) uploaded
The document named Initial thought draft Large Paylod handling
(Largepayloadsupport.htm) has been submitted by Mr Ian Jones to the OASIS
ebXML Messaging Services TC document repository.
Document Description:
This is an intial thought draft of the large payload handling module for
part 2 based on the work at the September 2007 Face to Face
View Document Details:
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?document
_id=25928
Download Document:
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/25928/La
rgepayloadsupport.htm
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