>Let's look at the case when no human is in the loop
All right, now I've got it. I know why you don't understand "restafarians" and we don't understand you. We are not doing the same job. You code for machines! I code for people. You are trying to get rid of the biggest problem in the software industry: the end user!! I totally agree with you, things would be so much simpler without the human factor. I've got a bad news for you: it doesn't work this way in real life.
Nobody says it better than Kent Beck, try not to mis-quote him:
"Software is written by humans–emotional, fallible, creative, and messy–for other humans. Any attempt to treat development as robotic will end in tears."
Guys:
you will never stop, how can you say such a thing afer I wrote this article: http://www.infoq.com/articles/se...allacies-of-
bpm
Surprisingly, I can use the exact same arguments in both dicussions. Doesn't that tell you something?
The problem guys, is that YOU the RESTifarians don't understand what an information system is, you code one line at a time, YOU are the problem. YOU are on a path to make us back to the 70s.
The way forward is Composite Software. Composite Software can only achieve when composition technologies will be available at all level:
- presentation (yes REST plays here in case you don't understand what I am saying)
- process
- information
So STFU.
JJ-
If I understand your arguments correctly, your proof is based on the following assumptions:
- REST apps offer a uniform interface for operations (GET, PUT, POST etc.)
- Producers don't describe the data beyond the uniform interface offered by REST.
If these assumptions are true in practice, yes, I would agree with your conclusion. In fact, it is even worse than strong-coupling - it is like wild west.
But that is not the case. Producers describe two things:
- Set of URIs for the verbs that they can respond to
- Request and response encodings. Unlike, WS, these encodings are not limited to XML, and depending on the use cases, multiple encodings are possible, as you may have seen with several publicly available RESTful services. Are they machine readable, like a WSDL is? Obviously not, at least today. Do we have to have machine readable descriptions? Given my experience implementing/supporting WSDL, I am hesitant to say "yes". And of course, those descriptions can deal with forwards/backwards compatibility as well.
Sorry - I don't buy your proof.
Subbu
>> In fact, it is even worse than strong-coupling - it is like wild west.
good, we are making progress, REST is the wild west.
>> Set of URIs for the verbs that they can respond to
hum... is this RESTful? never heard of that before. I thought URI pointed to resources not verbs? Am I missing something? Parsing a representation, how would you make sense of "this is verb", "this is a resource URI"?
I would argue that what you just wrote simply and explicitely buys my proof.
Now, XML has a very intersting property, which made me fall in love with it 10 years ago, no other technology has it: extensibility. Extensibility is essential for loose coupling (evolvability and variability) and I am not sure I am ready to trade it for anything else.
So I think your very answer prooves my point.
"I would argue that what you just wrote simply and explicitely buys my proof."
So be it. LOL.
Subbu
I'm not sure (feel free to correct me)
> you constantly rewrite application semantics protocols on top of this uniform interface.
Aren't application semantics protocols supposed to be expressed and well-defined in standard Internet Media Types? E.g. AtomPub protocol is defined by a series of media types.. no?
Once AtomPub protocol is standardized, many C and P start to reuse it to coordinate their interactions.. is there a need to rewrite it constantly?
or rather, extend and evolve it by introducing new features gradually.. through its standard (must ignore) extension mechanism?
IOW, isn't AtomPub protocol a shared understanding between C and P? which already explicitly defined and expressed in a series of Internet media types? .. IOW, it seems like media type is a place to agree on application semantics shared understanding.. no?
> you can't test the two components independently because there is nothing to test against
conformance test against AtomPub spec?
"hum... is this RESTful? never heard of that before. I thought URI pointed to resources not verbs? Am I missing something? Parsing a representation, how would you make sense of "this is verb", "this is a resource URI"?"
By verb, I mean HTTP methods like PUT, GET etc.
Subbu:
the misunderstanding comes from your usage of the preposition "for", in the context of what we were talking I thought you were talking about modeling actions (verbs) with URIs. My question was is that RESTful?
JJ-
Teo:
the problem is I thought REST was self-standing. All you needed is REST. Now you say, well APP does that too and you need APP. Then Bill and Harry argue about how to achieve durable messaging.
Now Stu talks about how choreography are important to REST.
Guys, you are running a scam, I am sorry to use that word, but I don't have another one. You are saying WS-* is too complicated and the first thing you do is creating REST-*.
I spoke some more with Subbu and the disconnect is really big between our contexts. I work in IT, he works at Yahoo. In IT a server is nothing compared to a week of developer. For Yahoo, every CPU cycle counts. Caching is important. For me, in IT, cashing is unimportant. Do you think I am going to make a transaction based on your cached representation of your bank account? or I am going to pay a claim based on a cached policy? I can't even get an accurate stock quote on my browser in Yahoo finance, I have to hit F5 to make sure that it is not using the cache, and more often than not, sure enough, I get a different value after I hit F5.
So you have your world, we have ours. In ours "reusability", "right-sourcing", "business Processes", "Human tasks" are very important. We don't need hacks to deal with it. We need robust conceptual framework that achieve reuse, enable right-sourcing, manage processes...
So LEAVE US ALONE, I'll see you in 2017 when REST-* is completed, and then maybe, I'll use it other than at the presentation layer.
The only point I was trying to make is that you in fact need REST-*. The problem is that you guys are so religeous about the existing REST semantics that you are going to flunk it. The discussion between Bill and Harry is just the beginning. Stu gave me a glimpse of what's to come and having been there for 10 years, I think I have enough authority to say what I say.
Good luck,
JJ-
> the problem is I thought REST was self-standing. All you needed is REST. Now you say, well APP does that too and you need APP.
but JJ, the web interaction model seems to reassemble tuplespace. If this observation is valid, perhaps it might explain why we need a general protocol to get/put information into a shared space, then rely these shared information to coordinate our interaction.
Teo:
I can easily admit that I am not qualified to understand your statement. The little I understand makes sense to me. I am not discussing that having a uniform interface is a benefit and that REST is a great step moving forward "to coordinate interactions".
Again, the problem I see is that REST is incomplete. The first step to "coordinate interactions" is to establish a "shared understanding" of the interaction. Again, and again, when a human is in the loop, the shared understanding happens because of "shared semantics". I don't dispute that one day, computers will have an ontology solid enough to achieve a similar result -without talking about AI. I built such a system using Objective-C back in 1996.
For now, people can do without these AI technologies, all they need is a composition mechanism, and a composition mechanism relies on a shared understanding that REST inhibits, it "forces" the understanding. Again and again and again, the part that REST deals with is great, it should not be changed but it is incomplete.
JJ-
I agree when you're pointing out that get,put,post,delete aren't enough for two participants to interaction within a Web application, since participants still need shared understanding about the application semantics.
But if I understand correctly, uniform actions (e.g. HTTP methods) and resource identification (e.g. URI) are just a portion of REST Uniform Interface. Hypermedia is the another portion.
Perhaps the shared understanding is supposed to be conveyed through hypermedia. As Stu mentioned [1], hypermedia is a place to agree on why and when a request should be sent. (I guess that's the shared understanding and application semantics you mentioned?) AtomPub is an example of that kind of shared understanding.
[1] http://www.stucharlton.com/blog/...ves/
000141.html
Teo:
thanks for point out this article from Stu: http://www.stucharlton.com/blog/...ves/
000141.html
great read !
For me, the minimum for "reuse" and "wiring" is a bi-directional interface definition. Again, my problem is to create elements of business logic that can be assembled into solutions.
I don't see in REST any bi-directionality. Even Roy claims that some of the constraints need to be relaxed to allow a peer-to-peer model.
Hypermedia works really well when a user is in the "consumer" because a user is going to adapt naturally to my state machine. I don't see that happening when the two components are software components.
Now, what I don't know yet, is what is the impact of bi-directional interfaces on hypermedia.
REST is very "client/server" oriented. You ask for a representation, it contains some links which invoke some actions and return another representation. In this model there is no notion of the consumer sending its own representation. REST does not really have the notion of two resources talking to each other. How does hypermedia works in a peer-to-peer scenario? I don't know.
JJ-
> In this model there is no notion of the consumer sending its own representation. REST does not really have the notion of two resources talking to each other. How does hypermedia works in a peer-to-peer scenario?
I'm not sure either, but that's what I will see too when I think consumer equals to client. E.g.:
(client-server = consumer-provider)
[Client]----------[Server]
But interestingly, because there is a virtual information space (a graph of hypermedia documents) to interface between components.. a service can be a server or a client or both.
Consider a spelling-checking service. Is it a server or can it be a client? In the Web, it can be a server. Consumer submit a text document and receive spelling correction. But it can also be a client, i.e. automated agent scheduled to tag/comment spelling mistakes found in consumer's text documents (listed in Atom feeds?).
Perhaps once participants has agreed on the graph structure of a set of hypermedia documents (e.g. AtomPub), a virtual information space will form and start to grow.. As long as the graph structure is stable, services can be replaced or switched easily (e.g. replace a spelling-checking client agent with another)..
IOW, it seems like a stable graph structure is the interface to coordinate among participants. A service can always be a server or a client or both.. as long as the service provider and its consumers agree with the graph structure.
(client-server + hyperlinked resource abstraction)
[Client] [Client]
| |
| |
============== (a graph/web of hypermedia documents)
| |
| |
[Server] [Server]
Teo:
I appriciate your comments, but I still can't see how a shared understanding can be built. I think there is enough of an agreement that a resource has an action interface, in addition to the uniform interface (GET, PUT, DELETE).
A client and a consumer can only interact if there is a shared understanding of the actions. I don't doubt that REST supports resource interactions via a hypermedia graph.
I think Subbu in this last post agrees:
"The clients know how to compose applications out of resources offered by various servers, and each client needs to be able to exercise control over composition. To be able to exercise such a control, client applications can not be universal, and the benefits that John list above cannot be completely realized."
JJ-
And the conservation goes on:
http://blogpro.toutantic.net/200.../#comment-
24160
Sorry we have an interface problem with my response. There is a strong coupling with french language. May be I should add a representation in english, you could GET it without having to re-implement anything.
Or should I create a version 2 of my blog interface to access the content in a different language? You'll have to code a new client to access
getTheEnglishVersion(commentNumber) Or getComment(commentNumber,commentLanguage)
In reality getting these large middleware stacks to work together in a distributed environment is very very difficult. This in-and-of-itself is reason to prefer a RESTifarian approach. In the real world these distributed frameworks and specifications change just as much as your application does, so what you have is complexity squared. By the time your organization realizes where it could reuse your distributed application, these distributed frameworks and specifications have usually gone through *at least* one major revision.
Complexity = Application Complexity * Middleware Complexity
And middleware Complexity isn't just an application developer problem, its also an operations one.
Bill:
thanks, for commenting, I agree with you that the complexity is increased by the middleware complexity and evolution, this is why I work on wsper (http://www.wsper.org).
This is an approach similar to GWT, JavaScript is a very powerful language, way to powerful for most developers to deal with it properly. In SOA we need to create a language to decouple the architecture from the solution, because the architecture is evolving.
Now, arguing that REST is not having this problem is IMHO incorrect. Most of the best practices are not defined and REST-* will be coming. So I am not sure why you are actually advocating that REST is making this equation any simpler, again, IMHO REST introduces another dimension of complexity by its inability to deal naturally with resource-to-resource interactions.
JJ-
REST-* may be coming, but I don't intend on using it. I would much prefer to redefine the problem when my requirements get too complicated and keep distributed architecture simple. Only simplicity will allow for scalable, reusable distributed applications that can withstand the test of time.
Ah... yes, this old dream that we somehow have not found the holy grail of computing, that there exist this ultimate programming model that will make everything easy, that somehow it could even be the fault of the business analysts who can't define their problems well enough for us developers and architects to do a good job.
Have you ever looked at the work they do at Intentional Software?
Bill, "Distributed" is precisely the problem. You guys have done a great job at "Distributed" this problem is pretty much solved, even guys like me can write a system that scales (out) today.
The problem at end is not a "distribution" problem but a "connection" problem. Reuse is about connecting meaningfully software agents to perform a unit of work. It has nothing to do with scalability. Yes some software agents might need to scale, but this is totally separate from "connectivity".
With all due respect, Bill, I think you might be targeting the wrong problem.
JJ-
JJ, I don't think REST is a silver bullet and I think you missed my point. Building a scalable application is one thing and I believe you could do it with CORBA, WS-*, REST or whatever.
Building a reusable one is another matter entirely. REST over HTTP is ubiquitous (every platform/language has an HTTP library), lightweight, and stable. Stable as in I bet HTTP will be around after I am dead and burried. I can't say the same about CORBA, WS-* or whatever. These attributes are crucial for re-use. The thing is re-use takes a *long* time to actually happen in an organization. Projects take years to mature, new projects that might re-use a distributed application take months/years to build. This is even worse B2B. 2 years in distributed middleware like CORBA and WS-* is a lifetime, beyond the complexity of these stacks is the fact that they are completely unstable which will kill "real" re-use intra/inter organizationally.
I hope you are following me now....
Bill:
I understand your point, I disagree with you on two parts:
a) versioning is a form of reuse (i.e. changing code without breaking what works), versioning happens all the time. Solving the versioning/maintenance hell would be a major benefit for IT
b) now, if you read my article on BPM: http://www.infoq.com/articles/se...allacies-of-
bpm (I quote you in it)
I explain that the industry has collectively missed the factoring of a process centric/service oriented programming model.
This is tragic on 2 counts:
a) we can't really get BPM to work, this is what Bruce Silver and Marlon Dumas (and others) are banging their head against
b) we miss completely the opportunity to reuse resource lifecycle services (since they are buried in an overall BPEL definition suposedly matching a BPMN definition).
RLS are highly reusable across variations of processes or different processes altogether, they are "systems of record" without any process related business logic or data elements. RLS prevent having to duplicate business logic and data elements across processes.
So in general I agree with your points, in particular, there are some pressing needs to solve the reuse problem and there are vast areas of unchartered services that are highly, very highly reusable.
The factoring I suggest is nothing that have been done before (to the best of my knowledge), yet it can be totally implemented with today's technologies. We can't do it in REST because REST does not have an explicit "contract", as soon as it does, then the same programming model can be deployed in REST, probably even better than with WS-*, I have no doubt about it. I personally don't care, all I care is having this process centric/service oriented programming model.
JJ,
I'm playing catch-up and these are a few quick comments.
* "All you'll ever need is REST"
I don't think that is what people are saying in general, but let me speak for myself, I say:
REST is a simpler infrastructure for the most common human and machine interactions than anything else. The less common cases are still possible (like reliable POST).
* Defining loose-coupling. "These components should be able to evolve (to a certain degree) without breaking the solutions that rely on them."
Absolutely! Where we, and a lot of people, are talking clear past each other is how to achieve that. Oh, and what "certain degree" we are setting our goals on.
Where did the four tenets of loose-coupling come from? The first two don't seem quite right to me... more like consequences of loose-coupling.
* Visualizing loose-coupling
All well and good, but whose point does this make?
Is WS-* Ce and Pe are defined with an IDL, in REST they are defined by a shared single interface and one or more content types. There are very different styles.
On naming: I don't think using "interface" to name these things make much sense anymore. I am fine with contract, but "interface" implies code-able artifact implies code generation implies RPC.
* REST and Loose-coupling
Pi is running in the consumer? What?!?
A Representation, with optional mobile code, is running in a universal client.
You say: "no human... that Ce = Pe", but you are assuming only the uniform interface. This ignores the content type - with all of the rules and implications (even mobile code) that is definable there.
I would say that for a "universal user agent" that Ce () for more generality.
In REST, Pe is at least (identity, GET representation, links).
* "if all you do ... is use WS-* like CORBA", and "some time understanding XML, XSD, ..."
I've said that authoring a content type to provide machine enable consumer processing in REST is not easy, and I haven't found good examples to boot!
I interpret the words I've quoted as trying to build good services with WS-* is hard too.
Then you say "I have a simple solution for you, it is not perfect..."
Did you mean to say simple there?
John:
thanks, these are all great comments, let me try to address them in the paper.
Again, my purpose is not to negate REST and promote WS-*, my purpose is to create an understanding of what we are talking about otherwise we will keep yelling at each other for another 10 years. At the end of this discussion, I want to be able to make the best recommendation(s) for my company, this is all I care. I have no emotional or financial stake in one or the other.
Traditionally, I would have created a metamodel of both REST and WS-* but, I think the questions are too complex to be answered by a metamodel, or at least we are not in the position to create a metamodel yet.
So let me make some progress on the paper and I will try to answer your questions one by one.
JJ,
Fair enough, I can wait for the paper.
I've got a few more comments for some of your other posts coming as well...
John
Commenting by HaloScan
