[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] Manual Operations in BPSS"
A possible implementation "add on" may be a web service in which one group allows access to their state information by trusted trading partners. This would probably be a bigger security hole than an actual benefit however and I would suggest that we make every attempt to build a mechanism that will be capable of deriving state unilaterally and independent of the other parties information. Comments? Duane Tony Fletcher wrote: >Dear Duane and others, > >Yes but I was also taking the title of this thread - that there have been >some manual operations that have moved the state of one side on causing the >need to re-align, so there is nothing in the message store ton retrieve >because we did not use messaging for that bit. > >Best Regards Tony >A M Fletcher >Home: 35, Wimborne Avenue, IPSWICH IP3 8QW >Tel: +44 (0) 1473 729537 Mobile: +44 (0) 7801 948219 > amfletcher@iee.org <mailto:amfletcher@iee.org> (also >tony.fletcher@talk21.com <mailto:tony.fletcher@talk21.com> & >tony_fletcher@btopenworld.com) > > >-----Original Message----- >From: Duane Nickull [mailto:dnickull@adobe.com] >Sent: 19 February 2004 21:53 >To: Tony Fletcher >Cc: martin.me.roberts@bt.com; david@drrw.info; zbarch@rcn.com; >ebxml-bp@lists.oasis-open.org >Subject: Re: [ebxml-bp] Manual Operations in BPSS" > > >The answers lies again in the persistent message store. By accessing >the API to the persistent message store, each protocol machine could >derive its' state. If something died in transit, the ack (transport >level) would not be present, therefore the sender could not presume that >it got received and their state would be set to "Message not sent". > >There are no other possible scenarios. > >Duane Nickull > > > >Tony Fletcher wrote: > > > >>Dear Martin, >> >>Well yes you have the protocol machines at each end re-aligned, but suppose >>that there was information (data) exchanged in the bit that got lost. How >>do you know that the content / data stores on each side are in synch? So >> >> >as > > >>an example you may be re-aligned at state that means that a fault has been >>rectified but one side may have fault 'docket' with the repair action >>correctly shown and the other not. >> >>Best Regards Tony >>A M Fletcher >>Home: 35, Wimborne Avenue, IPSWICH IP3 8QW >>Tel: +44 (0) 1473 729537 Mobile: +44 (0) 7801 948219 >> amfletcher@iee.org <mailto:amfletcher@iee.org> (also >>tony.fletcher@talk21.com <mailto:tony.fletcher@talk21.com> & >>tony_fletcher@btopenworld.com) >> >> >>-----Original Message----- >>From: martin.me.roberts@bt.com [mailto:martin.me.roberts@bt.com] >>Sent: 17 February 2004 18:19 >>To: david@drrw.info; dnickull@adobe.com >>Cc: zbarch@rcn.com; ebxml-bp@lists.oasis-open.org >>Subject: RE: [ebxml-bp] Manual Operations in BPSS" >> >> >>Is the a simple solution that we can at least grasp for release 2.0 >> >>Depending on how you answer this question we may have a solution? >> >>How do you know what state your BPSS is in? >> >>For us in BT we have used forks and joins with names to indicate states. >>This means that we could exchange with our partner through an out of >>band collaboration, where each of our collaborations is. The customer >>could also send us that information. Depending on who gets there first >>we could replay any transactions or agree to leap to a named state. >> >>Very simple but effective. No replay required but you now have two >>gateways/systems stacks aligned. >> >>What do you think? >> >>Martin Roberts >>xml designer, >>BT Exact >>e-mail: martin.me.roberts@bt.com >>tel: +44(0) 1473 609785 clickdial >>fax: +44(0) 1473 609834 >>Intranet Site :http://twiki.btlabs.bt.co.uk/twiki >> >> >> >> >> > >-- >Senior Standards Strategist >Adobe Systems, Inc. >http://www.adobe.com > > > > -- Senior Standards Strategist Adobe Systems, Inc. http://www.adobe.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]