Re: [ebxml-bp] Using BPSS/ebMS to implement staged message exchanges

[David RR Webber <david@drrw.info>]

Matt,

OK - simply put - the sender has some 100Mb PDF file to send in.  When 
they hit send two messages get built - the
first one is a submission ticket, the second is with the PDF 
attachment.  First message goes off right away to receiver,
who checks all the XML content, and then if their system is not already 
max'd out receiving other people's 100Mb PDFs
it sends back a receipt message, that references the ticket 
information.  When the senders ebMS gets that receipt XML,
then it releases to send the PDF that is queued up pending.

This does two things - its stops people sending in 100Mb messages where 
there's something wrong in the 10K of XML
of the ticket - so then they have to send the 100Mb again!  It also 
means that when 10,000 people are trying to all
send in their 100Mb PDFs all on the same day - that the receiver can 
stage and get them over a couple of days.

Thanks, DW

Matthew MacKenzie wrote:

> David,
>
> Can you describe in concrete language what your idea requires of the 
> ebMS transport?  I'm not seeing that here...
>
> -Matt
>
> On Oct 7, 2004, at 8:39 AM, David RR Webber wrote:
>
>> Team,
>>
>> I'd had some initial discussions with folks on the ebMS and CPA teams 
>> and I now think I have this
>> matured to the point to share with everyone.
>>
>> Below is a summary of what I have so far.  At a first pass this can 
>> be implemented today using
>> ebMS systems by adding logic to a data handler running on the ebMS 
>> servers themselves. So the issue is not - can this be done? - but 
>> rather - can we implement this such that this is
>> supported out-the-box by any ebMS systems.  And then just how this 
>> can be signalled by parties
>> via the CPA and ultimately included into a BPSS.
>> The hope here is to find the means using as much of what we have 
>> already defined, with some
>> small extensions, so that its not a major feature extension effort.  
>> The sense is that ebMS V3.0 may
>> well already provide means, so now the question is can BPSS V2 or V3 
>> support this pattern too?
>>
>> So - just to recap' - yes - you can make ebMS V2.x do this right now 
>> if needed - but can we
>> have formal support in the specification rather than resorting to 
>> one-off techniques to do it.
>>
>> Thanks, DW
>> ==============================
>>
>> Defining Staged Delivery.
>>
>> The following text is intended to quantify 'staged delivery' and 
>> understand
>> the pattern it uses and to be able to specify one of these in a BPSS, 
>> and
>> implement it with CPA / ebMS behaviour level details.
>>
>> An analogy here may be to the traditional supply chain equivalent 
>> being the
>> ship notice, followed by the delivery notice - but instead of using a 
>> truck
>> to exchange goods - this requires using the ebMS itself since the 
>> 'goods'
>> are electronic content or documents of some form in the electronic 
>> message
>> itself.
>>
>> There are all kinds of government administrative situations when this
>> applies - court submissions, bids and proposals, grant award 
>> submissions,
>> responses to demands for technical data, and so on. On the commercial 
>> side
>> would be multimedia content distribution as a use case - where a 
>> distributor
>> is sending out large files to subscribers, so they would notify that new
>> content is ready for delivery, and queue that content, and then the
>> subscriber could connect and release that exact content to them when 
>> they
>> were ready to do that, or vice versa, subscribers sending in content.
>>
>> This pattern applies particularly when the message size is extremely 
>> large
>> (relative to the available bandwidth) and there is some deadline or
>> constraint to its delivery, and there is the potential for the receiver
>> system to be swapped trying to receive one or more such transmissions 
>> within
>> a specific timeframe.
>>
>> So - in a formal staged delivery, the first email is the key email that
>> initiates the staging from the sender to the receiver - it contains 
>> ticket
>> information that must be validated by the receiver's backend system that
>> verifies the sender's submitter information and establishes the
>> time-of-submission, (as opposed to the final delivery time which may 
>> occur
>> later).  It also contains the metrics about the second message (the 
>> "goods"
>> to be exchanged) that can be used to authenticate that the second 
>> message
>> received is in fact the one referred to in the first ticket and 
>> created at
>> the original time-of-submission.
>>
>> Therefore the vital thing from the receiver's legal perspective is 
>> that the
>> second email is created and "sealed" at the time the first ticket is 
>> sent.
>> That first ticket must be received prior to the submission deadline 
>> date /
>> time. The second part of the packet is then held in a staging area 
>> status by
>> the sender messaging system until the receiver verifies that it's OK to
>> release it to delivery.
>>
>> The receiver will confirm back to the sender with a receipt 
>> acknowledgement
>> once the transfer is completed.  The time to perform would be set at 
>> some
>> length of time appropriately, but could be several elapsed days.  Any
>> subsequent exchanges would be a new or follow-on business transaction
>> activity; such as correcting errors in the second transmission content
>> itself, or providing additional information.
>>
>>
>>
>