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

[Matthew MacKenzie <mattm@adobe.com>]

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.
>
>
>