bhaugen32 wrote:
>
>...
>
> I'm having some trouble getting the business *conversations*
> RESTified correctly, though, and maybe you can help.

I think we can be mutually helpful here! I may have to be short today,
though. Other stuff to do.

> For example:
> The business protocol for a Order is Offer-Acceptance.
> A Purchase Order is an offer to buy.
> To be binding, it must be explicitly accepted by the supplier.
> The offer must have a time constraint - it is not good forever.
>
> So a Purchase Order as a Web resource is also an element in a dialog
> between Customer and Supplier.
>
> The offer-acceptance protocol for a Purchase Order in RosettaNet and
> ebXML includes stages of requesting and responding messages with
> timeouts:
> 1. The Customer places the Purchase Order.

POST.

> 2. The Supplier sends a receiptAcknowledgment quickly signifying both
> receipt and schema validation.

Response to POST. Generates a new URI representing the eventual target
of its acceptance or rejection.

Customer uses HTTPEvents to WATCH the new URI (call it /acceptance).

> 3. The Supplier sends an acceptance or rejection (for which they
> would typically have more time). Acceptance means contract formation
> or binding - a Purchase Order is a type of contract.

A notification comes through that the client should check /acceptance
because something has changed at the URI. The customer sees that
/acceptance says <accept/> (with a date, digital signature, contract,
list of things supplied, etc.)

> 4. The Customer sends a receiptAck of the acceptance or rejection.

Customer POSTs their ack with a digital signature and a URI pointing
back to /acceptance.

> There are reasons for these signals. If the receiptAck times out,
> the Customer may retry or go to another Supplier without wasting any
> more time. If the acceptance times out, the offer failed. B2B
> orders are usually not like consumer ones where the customer prepays
> using a credit card. B2B orders are often postpaid, on credit. So
> business state alignment is important: meaning both parties must
> agree explicitly and deterministically on whether the order was
> accepted (or not).

That's where the digital signatures and URIs help.

> "Business state alignment" implies that a Purchase Order has a state
> model: for example, pending, accepted, rejected, fulfilled, etc.
> (That was not a complete list of states, by the way.)

You might think of those as different kinds of resources, pending_po,
accepted_po, rejected_po, fulfilled_po. Because they all have URIs, you
can say: "LOOK, I rejected that PO. Here's the URI." Of course one
cannot necessarily trust one's business partner so you need to have a
mirror on your side also.

> Allowed actions will be constrained by PO state: for example, a PO
> in the "fulfilled" state cannot be canceled; a "rejected" order
> should not be fulfilled. In other words, orchestration of actions is
> conditioned by resource state. (Not by message sequence.)

Another good reason to have separate resources. A fullfilled_PO will
simply reject the cancellation POST.

> ebXML (among other initiatives) is attempting to express the
> orchestration rules as XML documents. Which means the business
> process can become a Web resource as well as the business objects. I
> think this is very similar to what Paul is trying to do with SWSBL,
> except that (1) it may be more complex than what you have in mind,
> and (2) the ebXML guys for the most part do not have a Web resource
> model in their collective mind.

Agreed.

I'll have to look at the rest of your stuff later.

I think it is important to show real business examples. I admit that I
think in terms of technology and not business. I just know from what I
hear from business people that the technological problems are similar to
more standard protocol problems.

Maybe we could work together sometime on an article about the
intersection of ebXML and REST. I think that the ebXML crowd should be
fertile ground for REST thought. Many of them are old SGML heads who
would understand the benefits of linking. Others probably have a sense
that the web services world is going in the wrong direction and would
like to see something going in the right one.

Paul Prescod