OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ebxml-bp] Manual Operations in BPSS"


When documents are manually sent and received, the state is reflected by 
the both parties as "not received" until such time as the receiver has 
sent the next electronic message back to the sender.  If no further 
electronic messages (signals) are sent, then the state of the process 
will not advance and may ultimately die if a timeout threshold event 
occurs.  

Until someone actually uses the electronic mechanisms to update the 
process, of course there would be in way for the applications to 
understand what other steps have been done.  Accordingly, they should 
reflect the last known state based on the tokens they have available 
IMO.  If manual processes will play a part in the process, the process 
script has to be engineered to account for such.

On the lighter side - there is no way to mitigate this until an 
electronic API to the human head is made.  Progress is underway - at 
Linuxworld I saw a guy with a wearable computer who claimed he was 
getting implants for next years show so he can interface with his 
computer electronically (Ughh!).

Cheers

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]