Re: State alignment

Hi,

On Sat, Jun 26, 2004 at 12:21:02PM +0200, Anders W. Tell wrote:
> 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 ?

Sounds right, yes.

> A few questions though , how, when is this endpoint constructed (start 
> of its lifecycle) ?

In general, when its identity is established.  Consider an interaction
where a purchase order is POSTed to a purchase order processor
(identified by its own URI), and the client receives a 201 response
back containing a URI identifying the order.  In that case the URI
is formed at the time the agreement is formed.

But note that HTTP and http URIs are ultimately flexible in this
regard; URIs can be minted before any representation of the resource
is available, and coordination can still take place.

> How is the association established/maintained between logical endpoint 
> and contract ?

Hmm.  Well, that's up to the server; I don't see any problem doing it.
But it could communicate this relationship to clients simply by
answering GET requests on the URI and returning information which
makes that relationship clear.  If that's what you mean ...

> <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>

I really don't think that's a problem.  2xx means what it says in the
HTTP spec, and SOAP (1.1 and 1.2) doesn't change that; I made sure of
this during my time in the XML Protocol WG.  Though that doesn't stop
people misusing it, that's their problem.

As for the legal meaning, I am not a lawyer, but I don't see why there'd
be any problem interpreting an HTTP message in that way.

> <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.

Interesting.  But note that a multi-state transaction like that need
not have fine-grained response codes, but instead need only model the
transaction as a resource whose state evolves over time.

That said, there may indeed be a good reason for extending HTTP with
new response codes.  It's unclear to me whether that would be required
or not.

> 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")

See above.  It can be naturally extended to support proposals with a
multi-state application state machine.

> 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>

Right, but there will be the additional information; that from the
response message (and occasionally the request message, when the
response message isn't fully self-descriptive).  I see no reason why
this information couldn't be considered sufficient from a legal POV.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.

Received on Tuesday, 6 July 2004 23:17:24 UTC