State alignment

On Thu, Jun 24, 2004 at 07:31:39AM -0700, Jean-Jacques Dubray wrote:
> Mark:
> 
> I apologize I don't have such an extensive historical perspective.

Don't worry, you're in good company. 8-)

> Is this why REST talks about State without talking about State
> Alignment? 

REST talks about state transfer.  Some state transfer semantics are
very conducive to state alignment.  Imagine a couple of agents GETting
and PUTting state from each other, purely with the intent of either
getting up to state with the other guy (GET), or getting the other guy
up to state with you (PUT).

> I am wondering how State Alignment works over the web with web
> technologies I have the feeling that this might not be implemented
> properly by application developers all the time.

I think you'd be surprised.  Even those who don't really know the
architectural basis for what they might be doing, generally get it
right in my observation.

> I cannot tell you the
> peace of mind it gives me when I receive an email with a subject like
> "Your order..." (I don't even look at it...). 
> 
> Anyways, reading your response lead me to believe that I might want to
> explain one more time state alignment in BPSS (which is a business
> document exchange choreography standard).

FWIW, I'm not familiar with BPSS, but am very familiar with the general
notion of state alignment.  Let's see how they match up ...

> 1) RM tells you only that a message got to its receiver safely (and in
> the right sequence if necessary)
> 
> 2) However, it is not because I got a message that I will be able to
> understand its content, it is not because I can understand it that I
> will act on it.
> 
> 3) Therefore BPSS has 2 signals: 
> 	a) a receipt signal that says that the message I received
> matches the agreement that we have (this message was the one I was
> expected as defined in the collaboration, and it had the right message
> format if specified). 

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.

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

> I content that state alignment requires at least the acceptance
> acknowledgement.  The receipt ack is rather used for non repudiation and
> is not part of the state alignment question per se but helps provide
> feedback about what might have gone wrong. If you get a negative
> receipt, you know you may not have sent the right thing based on the
> agreement you had with this party.

I more or less agree.  It's possible, in many cases, to do state
alignment with just a one way channel, but having a confirmation is
always nice.  Consider GPS clock synchronization.

> The acceptance ack is often called a non-substantive response. It does
> 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).

Yup, HTTP 2xx again.

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

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 Thursday, 24 June 2004 15:53:52 UTC