[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, Ok - sweet! That sounds like exactly what I'd be looking for as a long term solution here. The ability to signal the sender would work out. The only other thing is the ability to put things on to the send queue with a 'pending' status - and / or a time-to-send setting - right now the ebMS implementations I've seen - soon as you put something in the queue they send it! Obviously in a push-pull environment with signals - they will need to extend that. Having a formal ebMS definition of a queue information model would ensure consistency here... On the BPSS side I think we can model that - using the JOIN mechanism on the signal - so the second part of the BTA would not happen until that signal is received. Need to look at the fine detail on that - but seems like BPSS V2 is close to being able to accommodate that.... Thanks, DW ====================================== Matthew MacKenzie wrote: > 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. >>>> >>>> >>>> >>> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]