On the use of REST and choreography in general, as has been stated already, the author uses WSCI which is not a standard in any way shape or form. It was simply a note to W3C.

On the use of WS-CDL with REST there is not impediment to its use at all. It can and has been used with RESTfull services.

And finally on its applicability to the enterprise, it is being used has been deployed in many enterprises and vertical standards bodies where it provides a notion of testable architecture that helps to drive the delivery of SOA solution using ESB’s and Event Based systems or indeed Web Services WS* based systenms or indeed REST based SOA.

Sorry about that. It is fixed now.

I wish what you are saying about bug-freeness and simplicity is true. But as you know, there are no silver bullets.

Is choreography necessary for the enterprise? – this was the question I raised several weeks ago. In response to that post, there were several mixed reactions. Some were positive while some were critical. Over the past week or so, I spent some time rea…

Thanks for correcting. But this document is also in the recommendation state (aka work-in-progress).

Choreography is not about execution, in the way BPEL is. It’s about describing the possibilities of interaction and verifying (through bisimulation) whether they actually occurred as intended. By the way, the “recommended” standard is WS-CDL:
http://www.w3.org/TR/ws-cdl-10/

I think the *idea* is a good one for verifying concurrent systems behaviour; concurrent interaction machines are thought (by some) to eventually replace Turing machines as the basis of computation:

http://www.cl.cam.ac.uk/~rm135/turing.pdf

Amusingly enough, Milner (whose work WS-CDL is based on), uses the (RESTful) web as an example of how interaction works!

What concurrent interaction lacks is the equivalent of a “compile time type checker”, this is what choreography and the pi-calculus seeks to provide.

As I said before, there were no quotes attributed to you :)

Subbu

a quote is a quote. Either you quote someone or you don’t.

A choreography expresses the sequence in which services invokes operations on each other. When a message comes in at an end-point, the choreography answers whether this message was expected (you would not invoke a payment operation until a processOrder operation would have been successfully invoked). A choreography is totally passive, unlike an orchestration. It avoids having to write all this logic at the endpoint to validate an incoming message before you pass it to your code (orchestration or Java/C#).

As you can imagine this concept is quite abstract for most people. And well, for REST? how can RESTifarians even comprehend that they need a choreography? they don’t need one of course because the “application state” will always the correct information all the time. Otherwise it is a bug? So why deal with bugs? The only reason is because there is not “one” system in SOA, talk to Amazon, when you have 100k+ “clients” using AWS, you can’t expect to always have bug-free clients. BTW, OASIS ebBP was developed with John Yunker who works at Amazon.

So I don’t think any RESTifarian would agree that you need a choreography specification, you would need a contract first, and then a transaction protocol and possibly a centralized context service to support n-ary collaboration. Ah yeah, I forgot, REST doesn’t do peer-to-peer relationship, so why bother anyway.

Incidently, your reply to “link” does not work. I thought REST systems were perfect, it was so simple that magically all applications could be written in no time, bug free.

Who knows what this post is about. It really starts like your typical RESTifarian post. You don’t need XXXX, all you need is HTTP + JavaScript.

Now you let me know how you can describe your favorite choreography in Java, C# or JavaScript. In case you have not noticed, a choreography express the sequence in which message are exchange for the purpose of scrubbing an incoming message rather than pushing this logic into the code or orchestration and have to describe the exception handling over there. The purpose is to give a change for the invoking service to retry with the correct information rather than failing the whole unit of work.

Sorry you see it that way, but I did not attribute the quoted statement to you. I have removed the quotes per your request.

> Your argument “In my view, this is nothing but an attempt to describe code in XML, and it is worth staying away from.” shows how much
> you understand about application semantics necessary to deal with long running activities.

In the interest of keeping a thoughtful debate, could you qualify your statement? Since your post says that “choreography is too abstract for people to understand”, you should perhaps explain the need for choreography better in the context of long-running activities.

> I feel very sorry that this kind of thing can happen since the REST community portrays itself as the white knights of the industry. IMHO, I
> start seeing you as probably worse than your typical BigSoftwareVendor sales rep.

:)

By the way, if you read this post carefully, this post is not about REST over WS or otherwise.

how dare you put quotes around that: “REST does not support Web Services Choreography, and hence REST is unfit for the enterprise”

I never presented my arguments in anyway shape or form that would come even close to what you are quoting me for.

Could you please remove these quotes or make an appropriate quotes of my arguments. I am arguing that REST is unfit for process and information federation and works perfectly well for presentation federation.

This kind of post is symptomatic to the extend with which the REST community is ready to go to push their arguments.

Your argument “In my view, this is nothing but an attempt to describe code in XML, and it is worth staying away from.” shows how much you understand about application semantics necessary to deal with long running activities.

I feel very sorry that this kind of thing can happen since the REST community portrays itself as the white knights of the industry. IMHO, I start seeing you as probably worse than your typical BigSoftwareVendor sales rep.