[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] Using BPSS/ebMS to implement staged message exchanges
Matt, More parts to your question! OK - at the CPA level - you can obviously set the transaction types. The time-to-perform, and time-to-respond stuff can be set so you don't expect to get an answer right away, apart from just an 'ACK' that the first ticket made it across. If you don;t get an error-message rejecting the ticket immediately (time-to-perform on error checking is say P1H) - then you can assume you are now waiting for the second confirmation - that will trigger the 100Mb PDF send phase. Using a data handler on the backend of the ebMS you can track all this currently - but instead we need some behaviour where the ebMS can do this itself - by knowing that this pattern is going on....oviously there are more goodies in V3 - such as the external validation service and more - that can make smarter flows occur..hopefully! 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. >> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]