Re: State alignment

Mark Baker wrote:

> There are other ways to do this without a separate "signal". One would
>
>be to associate the message endpoint with that particular agreement,
>rather than having a single message endpoint and having to do the
>association in-band as you describe.  So for example, a change order
>request could be sent directly to an endpoint for a particular purchase
>order.
>  
>
<AWT>
Interesting idea, to use a communicative feature for associating 
Contracts with exchange of data messages.

Could this be equivalent to saying that a case worker (logical endpoint) 
handles all contracts of certain types/id ?

A few questions though , how, when is this endpoint constructed (start 
of its lifecycle) ?
How is the association established/maintained between logical endpoint 
and contract ?

<AWT>

>>	b) an acknowledgement signal that is returned when the message
>>was successfully processed by the receiving application, system, ...
>>whatever (you don't want to expose this kind of detail to the other
>>party in general)
>>    
>>
>
>Sounds like an HTTP 2xx response message.
>  
>
<AWT>
In some case it would be true that 2XX could have the same effect, but 
in a multiphop environment with many SOAP nodes returning 2XX, the 
meaning of 2XX becomes muddled. The "Reciept" message/signal has legal 
meaning and is mentioned in national and international laws and as such 
must be very vell defined.
</AWT>

>>not mean yes or no to a request, it simply means that the receiver of
>>the request was able to process the request (it did not get lost
>>internally).
>>    
>>
> The acceptance ack is often called a non-substantive response. It does
>
>
>Yup, HTTP 2xx again.
>  
>
<AWT>
There is another interpretation of messages/communicative acts such 
UN/CEFACT::BPSS::AcceptanceAcknowledge
which is: NO means EarlyRejection. YES means continued processing. It is 
*extremly* important to differentiate these types of data messages from 
Contractual Acceptence.

With respect to 2XX the problem remains with SOAP nodes, multihop and 
that Receipt and EarlyRejection are sent/dispatched at different times 
between Offer and ContractualAcceptance.

In ebXML you have many returns that is related to a single data message 
that carries a meaning:
HTTP 2XX
IntermediaryAcknowledge
Acknowledge
Receipt
EarlyRejection
</AWT>

>>If the states have business semantics associated to them (Order
>>Processed) I am wondering how this information can be "signaled" back to
>>guarantee state alignment.
>>    
>>
>
>POST an order to an order processor.  The HTTP response will give you
>the signal you need to know that the state was successfully transferred.
>  
>
<AWT>
This work for "declarations" but not for "proposals" since a proposal is 
followed by "acceptance, rejection" ("withdrawal, revocation, late 
acceptance, notice")

When looking at different legal texts regading criterias for Receipt one 
can easilly see that they are not the same. This means that it will be 
difficult to use 2XX without any additional information that with 
precision describes it meaning.
</AWT>


/Anders W. Tell

Received on Saturday, 26 June 2004 06:21:45 UTC