feedREST does not support Web Services Choreography, and hence REST is unfit for the enterprise - so goes the argument for WS-* over REST. See, for example, the latest one by Jean-Jacques Dubray. But does WS-* need choreography? Does anyone need choreography? Having not cared about web services choreography activities at W3C, I was intrigued about this question, and wanted to find out.
The basic premise of Web Services Choreography Interface (WSCI) is that WSDL does not describe how an application can interact with one or more web services under a given context. For instance, if an application needs to operate with three different web services in some sequence, possibly based on some application constraints and flow, the argument goes, WSDL alone does not describe those interactions. The goal of the web services choreography was to define a language to describe the interactions between the application and web services. This language includes some interesting constructs:
- Sequential (
sequence) or parallel (all) execution of activities. - Looping (
foreach,while, anduntil) and conditional execution (switch, andchoice) based on XPath expressions. - Properties, aka variables, which are defined using
selectors. Aselectoris equivalent to the right-hand-side expression of an assignment in programming languages. - Context (
context), which is akin to variable scoping in programming languages like Java. For instance, contexts can be nested, and inner contexts can refer to local properties and process definitions defined in parent contexts while outer contexts can not refer to the same defined in inner contexts. - Exception handling (
exception) on time-outs (onTimeoutor upon faults (onFault). - Compensation for transactional activities (
compesate) to define how to compesante (akin to rollback) for failures.
See Web services choreography in practice for a comprehensive overview. As you can see from the examples in this paper, most of the above constructs mimic programming languages.
In my view, this is nothing but an attempt to describe code in XML, and it is worth staying away from. WSDL itself is hard to parse for mere mortals. Adding choreography makes it worse. Secondly, while choreography seems to be attempting to formalize interactions in some context, why not describe the same in some other form - like plain English or some programming language of choice? Take, for instance, Listing 1, in the above paper reproduced below.
<context> <foreach select="ns1:arrayOfStockList/leg[position()>1]"> <process name = "PlaceBuyOrder" instantiation = "other"> <action name = "PlaceBuyOrder" role= "tns:trader" operation= "tns:placeBuyOrder"> </action> </process> </foreach> <process name = "ConfirmBuyOrder" instantiation = "other"> <action name = "ConfirmBuyOrder" role= "tns:trader" operation= "tns:confirmBuyOrder" > <correlate correlation = "defs:buyStockCorrelation" instantiation= "true" /> </action> <exception> <onTimeout property = "tns:confirmationTime" type= "duration" reference="tns:PlaceBuyOrder@end"> <compensate transaction = "tns:reverseBuyOrders"/> </onTimeout> </exception> </process> <process name="transferMoney" instantiation="other"> <action name = "cashTransaction" role= "tns:trader" operation= "tns:debitMoney" > </action> </process> <exception> <onMessage> <action name = "reverseBuyOrders" role= "tns:trader" operation= "tns:cancelBuyOrder"> </action> <fault code = "tns:creditCardTxFaultCode"/v </onMessage> </exception> </context>
This could very well be described as follows
For each stock, place a buy order. After placing orders, request the user to confirm each order. If the user does not confirm an order, reverse the buy order. Once an order has been confirmed, transfer money from the user's account.
This is plain and simple to understand, and any developer writing the application can easily interpret this flow, and implement it. Such a description is no less formal than the description using the choreography syntax.
Would I write or recommend someone write complex distributed applications using such a language? Of course not. For starters, this language is complex to parse for both humans and machines. Building a runtime to parse and execute a choreography is complex and complicated. Even if a such a system is avilable, interacting with such a system would be tremendously more complicated. Writing distributed applications is hard in itself. Writing distributed applications in a complicated language that is hard to parse, while ignoring simpler alternatives, is inviting more trouble.
TrackBacks
TrackBack URL for this entry: http://mt4.subbu.org/mt-tb.cgi/63
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... Read More
> For each stock, place a buy order. After placing orders, request the user to confirm each order. If the user does not confirm an order, reverse the buy order. Once an order has been confirmed, transfer money from the user's account.
> This is plain and simple to understand, and any developer writing the application can easily interpret this flow, and implement it. Such a description is no less formal than the description using the choreography syntax.
Except that if you want to automate this process, make it discoverable, or some as-of-yet-thought-of thingie, unless you have a pretty good natural language processing system in place, the shorter, less-formal documentation is only helpful for developers.
OTOH, despite the bloat of XML, the other can be transformed to natural, or near-natural language, \*and\* can be used to create application flow, diagrams, etc. all automatically.
There's no reason not to have both, especially since (at least in this case) it's a pretty straight-forward step from the XML to a (near?) natural language.
The example you give is interesting, but there is one important difference between the XML formaliztion and the English formalization of the process: the XML formalization can be read and manipulated easily by a computer, whereas the English version cannot.
The WS-* technologies seem to be made primarily for being manipulated by computers, and written by people using visual interactive editors.
An interesting development of your article would be to evaluate how one could describe the "choregraphy" (or flow) of a REST application in a more declarative way, suitable both for the human and the developer.
You're right - XML formalization allows some machine to process and execute the choreography without writing any code. However, expressing all the syntactical power available in programming languages in XML is a laborious thing to do and can never be complete.
Secondly, we are yet to see proof that enterprises are jumping with joy to implement their applications on top of engines that can parse and execute choreographies for all their web services. Why? Because it is complicated. Take for example, security. It is true that you can attach a policy to a WSDL to specify security policies of an individual service. Now, bring in five different services with five different security policies all interacting together under a context defined in WSCI.
There are a lot of theoretical and esoteric promises in specifications like choreography, but reality is much more complex. This is independent of whether the underlying framework relies on SOAP or REST.
hey guys
can you remove that XML so that the viewer can understand the idea behind it? :)
the closing tags and indent is annoying... remember XML is from humans for computers, not really from humans for other humans ;)
> However, expressing all the syntactical power available in
> programming languages in XML is a laborious thing to do and
> can never be complete.
Of course it can be complete, you just wouldn't want it to be.
> Secondly, we are yet to see proof that enterprises are jumping
> with joy to implement their applications on top of engines that
> can parse and execute choreographies for all their web
> services.
Except that we *are* starting to see just that with frameworks like SEAM, WebFlow, etc. If you aren't using a framework, you're doing it via some ad-hoc method anyway.
Whether or not it's captured in XML is secondary to the fundamenal issue: state and sequence are important. I'd be about the last to argue that XML is the best mechanism for doing this, but *something* has to, and I'd rather it was trivially exposed and documentable rather than hidden underneath layers of code.
> Of course it can be complete, you just wouldn't want it to be.
and why is that? Remember where we started. We started with an interface description language (WSDL), and then asking client applications to author their application logic in a similar language (choreography), completely ignoring the fact that the same application may have to talk to other services that are not web services themselves.
This premise will only work if every service and backend is expressed in terms of a WSDL. This is a questionable assumption. As I was arguing in a later post,
SOAP, WSDL and the Paradox of Homogeneity,
the enterprise is not and can not be homogeneous. We need frameworks/languages that can deal with heterogeneity.
> Whether or not it's captured in XML is secondary to the
> fundamenal issue: state and sequence are important. I'd be
> about the last to argue that XML is the best mechanism for
> doing this, but *something* has to, and I'd rather it was
> trivially exposed and documentable rather than hidden
> underneath layers of code.
I totally agree, and we have modeling languages for that.
Subbu:
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.
> How dare you put quotes around that: "REST does not support Web Services Choreography, and hence REST is unfit for the enterprise"
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.
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.
Thanks for your comments. I do see where you are coming from, although I am not convinced that such a grand scheme would work, given the complexity and heterogeneity of enterprise software. I can see it working in homogeneous environments, though. I would also like to note that the challenge is to bring in heterogeneous systems together, and we should examine choreography in that context.
As I said before, there were no quotes attributed to you :)
Subbu
I can put you in touch with John if you want, last time I talked to him, this was the kind of things he was doing. So again, it is not because a single individual does not believe that "you don't need this" or "you can't do this" that the REST of the planet should stop everything they are doing. Guys, wake up.
"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."
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.
Hi Subbu.
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.
> intended. By the way, the "recommended" standard is WS-CDL:
> http://www.w3.org/TR/ws-cdl-10/
Thanks for correcting. But this document is also in the recommendation state (aka work-in-progress).