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

[Matthew MacKenzie <mattm@adobe.com>]

David,

A great idea, but I don't think this process needs to be defined in the 
ebMS specification.

ebMSv3 defines what are called Abstract Message Exchange Patterns.  A 
draft will be out soon on this by the way.  One of the AMEPs is a 
pattern which allows the receiver to request a sender to transmit any 
available messages via a signal.  The point is, we are busy providing 
much more flexibility for message exchange by enabling push/pull/poll.


Regards,

Matt

On Oct 7, 2004, at 9:03 AM, David RR Webber wrote:

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