[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
How about something like earliestTransmissionTime? On Oct 7, 2004, at 9:41 AM, David RR Webber wrote: > 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]