Some comments...
- "Talking with Subbu, I think I understand the disconnect. He works for Yahoo (same would be true for Amazon, Google, Microsoft Live...). For these people, who operate vast data centers, every CPU cycle counts. It speaks directly to their user base: if yahoo is sluggish people will switch to Google and vice versa. I, on the contrary, work as an IT architect. "
Subbu is ex-BEA. I think he understands IT architecture, thanks.
- "For IT, If I can reuse a piece of code 2-5 times, this is a tremendous savings: imagine the cost of duplicating assets in IT? re-implementing, re-testing, integrating? how about maintenance? now I need to apply my changes to several code bases in different technologies?"
I've discussed this in email with you, but besides the technical challenges, SOA reuse is a pipe dream for most organizations because they are not willing to change their investment evaluation windows or mindset about the economics of software. Most are just looking to improve their agility -- which is about the way we design interfaces & interactions, not about reused logic.
- "Guys, in the Ganesh's style, I have news for you. There has been a big composite system running for decades: EDI. "
It's not news. Mark Baker has been talking about EDI for years as an example of interchange with a type of uniform interface.
- "Stu, I may misunderstand your point but you seem to say that one thing (we need actions) and the opposite (a uniform interface gives more loose coupling, therefore don't use actions)."
What I agreed with you was that we need a *contract* to generate shared understanding. I did not claim that we needed specific actions to generate shared understanding. On the other hand, I do think it would be useful to define higher-level abstractions in terms of uniform operations, though I am not convinced this will enhance interoperability.
- Your definition of loose coupling seems to reflect a very producer-focused view of services.
For example:
"RESTful Web Services indeed offer a coupling worse than CORBA, much worse because at least with CORBA you have an explicit interface to re-write the implementation on the opposite side. So in REST, if Pi changes, someone has to communicate to the other side (pick your method: email, blog, telephone, SMS...) what has changed."
Last I checked, Yahoo!, Google, or Amazon do not email me whenever they change Pi.
" As a matter of fact, thinking that any uniform interface is going to do the job is the biggest fallacy of the decade."
You have not demonstrated this beyond a bunch of hand waving that somehow "action oriented interfaces" are going to enable evolvability. I don't see it happening very often in practice. We'll see when your article comes out, but again, I caution against writing an article that is based on a strawman of your own design.
- Guy, this is no heresy, this is a fact and you know, facts are stubb
Gack, trucated. The full response is here
More comments - part1
* REST is incomplete: no process or information interactions?
REST is a style for interacting systems that send messages to transfer representations. What it means to transfer representations is the heart of the value, confusion, and current complexity with machine consumers (and producers I suppose.)
There seems to be two points where you don't think sufficient what REST offers:
1) machine processable descriptions of shared understanding,
2) P2P interactions between resources.
JJ, you consistently take the REST uniform interface constraint as the end of the story. Since the HTTP verbs are fixed no machine anywhere can ever make sense of what to do next!!! ARRRrrrghhh! (Sound of dying processes giving up...)
The content type is the key abstraction that is "transferred". Transferring a meaningful document is how our real human world works when things get complicated (i.e. lawyers are involved 
When I've bought a house I didn't send a message buy(that:House, for:Amount), or even buy(someBigDocument:XML). Instead the seller, broker, and I went back and forth with several documents (the bid, inspection report, ...) until we both agreed. That is exactly a transfer interaction. The rules for what could happen next were written in other the documents we were exchanging and other shared documents that represent the laws and practices of real estate.
My disclaimer: How do we build a new content type format that does a good job RESTfully describing a specific business interaction? I don't know! That is what I'm still fighting through this multi-blog distributed conversation to better understand.
more comments part 2
* REST is adding this and that
REST describes the constraints of an application transfer protocol. As such, the details of an application need to be build on top of it. You list some "enterprisey" topics with the default assumption they should be exposed in *every* system that is complete.
Security: Your critique of security is valid, but should be applied to HTTP. yes, HTTP security could use some improvements.
Transactions: I don't agree one bit. In any distributed system idempotent messaging, best effort under partial failure, and other techniques are much more important. Pat Helland has much to say on transactions and distributed transaction.
Reliability: RESTful techniques for reliable POST all convert a non-idempotent message ultimately into an idempotent one.
The mechanics for achieving transactional and reliable interactions in a resource/representation/transfer style are more visible (themselves resources that can be inspected) and therefore have a more mechanical feel than our middleware that magically makes everything ok today. Except it doesn't: it fails to scale, fails to handle partial failure, and adds hidden complexity to the system.
* Where is the REST community? Highly scalable....
For the enterprise I don't see the scalability of REST as more than a nice advantage. The primary benefits for REST I see are:
1) Independent evolution and reuse of exposed systems (Modifiability Property)
2) Better support for partial failure with best effort to keep partially working (Stateless Protocol and Visibility Property)
Further, in my last comment here I said that
1) In WS-* Pe -> 0 for broader reuse, while
2) In REST Pe is at least (identity, GET, links)
That omnipresent minimum shared interface promotes enterprise (and WWW) reuse in ways no WS-* custom contract Pe can.
* (Re-)Establish XML as the foundation to exchange information
I would never want my entire interaction environment to be tied to a single finicky encoding format. Just the use case of sending images around puts XML-only encoding on shaky ground.
More importantly though is the extensibility issue: XML is only extensible when it's just well-formed. If you want any validation today the only extensible option you have is schematron.
XSD is _terrible_ at promoting extensibility. The 'X' in XML does stand for extensibility, but only to create a single concrete XML language. Then you are stuck. Trying to compose those languages is difficult, error-prone, and down right painful. Yes, I've done it, with XSD.
Someday (maybe 10 years?) there will be a standard schema language for XML that does the "right things" wrt composing namespaces into documents in an extensible way.
* Define contracts based on extensions to a uniform interface...
Do you mean something like:
POST/closeAccount ...
POST/transferFunds ...
Hmmm, that doesn't mix up the URI and verb, inherits the semantics of POST (non-idempotent, unsafe), and might make for more visible messages. Also, could still be defined property in hypermedia with embedded forms.
Worth thinking about in my opinion.
JJ, what is your opinion/interpretation of this quote from the REST thesis (Section 5.3.3):
"The model application is therefore an engine that moves from one state to the next by examining and choosing from among the alternative state transitions in the current set of representations."
How to actually build a corportate representation (XML namespace, RDF annotations, ...?) and how to program the engine is still a big question for me, but this is how to add interactions to machine clients in rest.
John
Commenting by HaloScan
