Using BPSS/ebMS to implement staged message exchanges

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

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.