I was reading a "REST : avoiding mistakes of SOAP toolkits" post from Steve Loughran. The post was not very different from other similar posts on the subject but there were at least 3 reasons I really wanted to comment. I might be stepping over a thin ice here :-), but I simply can't resist.
So here it goes. Steve 'Ant' Loughran says in his post that "Sanjiva 'Wsdl' Weerawana has stuck some slides comparing REST and WS-*". LOL. I hope Steve will appreciate it.
The post itself is quite interesting, and I think Steve actually concludes that the problem is not really to do with the use of description languages like WSDL but to the way the code generation works.
Lets forget about WSDL 1.1, SOAP encoding, and code-first services and the fact that one can have 100 operations described in WSDL. The problem of dealing with the generated code is universal and spans any type of services and both client and server runtimes, irrespectively of what description language you're using. While having no generated code makes the consumption of data more robust, the code generation is here to stay nonetheless. And there must be a way to make runtimes dealing with populating generated types smarter and client runtimes dealing with such types more adaptable to ignorable changes. And if changes are not ignorable it does not make that much of a difference what approach is used.
But it's really the Steve's 'association' with Ant which I wanted to comment upon in the context of the REST vs WS-* discussion.
Steve says in his "Migrating from Maven to Ant" post (I had hard time finding it, I remember reading it but couldn't find, Steve's blog shows the latest 20 pages, I found it on page 46, after I was about to give up :-)) :
"Maybe I should document how to move back from Maven back to Ant...Personally, I see many advantages of Ant above Maven, most of which come from the fact that the tool lets you do more complex things in your build process. Maven assumes that you are building and shipping components; Ant dictates less. Admittedly, this is personal opinion, but I getting tired of 'ant-sucks-maven-rules' propaganda"
I remember when I was reading it I was feeling the same. I didn't like Maven disrupting my comfort level I had with Ant. I really liked reading Java Development With Ant , it one of the best pragmatic books I've read, and I liked it as much as I liked Michael Kay's XSLT book. Because it taught me to think in Ant and not turn it into a programming language as far as dealing with dependencies is concerned. Then Maven came in. I still don't know how to write a simple 'mojo'. But it actually works and the strange thing is that many many projects use it, people complain but it delivers. Maven takes the dependency and build management to the extreme. If necessary you can go to the antrun plugin but doing so seems so low-level after dealing with Maven, or rather after Maven looking after all you need, as far as setting up target directories, etc, is concerned.
Now, in the above quote from Steve, replace 'Ant' with Web Services and 'Maven' with REST.
Sounds familiar :-) ? Sorry, may be it's only myself who finds the Ant vs Maven arguments so similar to the ones one can hear in REST vs WS debates
Friday, November 30, 2007
Writing a code to consume links
I was wondering, what does it mean to write a client code which deals with resources whose state include links ?
Suppose we have a resource which can be addressed like this :
http://host:port/collection/1/2/3/4
We start from http://host:port/collection, then we get http://host:port/collection/1, etc, until we get http://host:port/collection/1/2/3/4.
What kind of client application we're writing here ? It seems that a code which deals with more than 2 levels (starting from http://host:port/collection/1/2) is actually a navigation tool which should allow a user to get back. Is it a reasonable characterization ?
Suppose we have a resource which can be addressed like this :
http://host:port/collection/1/2/3/4
We start from http://host:port/collection, then we get http://host:port/collection/1, etc, until we get http://host:port/collection/1/2/3/4.
What kind of client application we're writing here ? It seems that a code which deals with more than 2 levels (starting from http://host:port/collection/1/2) is actually a navigation tool which should allow a user to get back. Is it a reasonable characterization ?
Sunday, November 25, 2007
Is ATOM the way to do REST ?
James Snell answered to the questions I posted earlier, thanks James.
In response to "Do you think AtomPub is the way to do REST ?" James replies (omitting the first sentence for brevity :-)) :
"There’s really only one way to 'do REST'. Atompub adhers to the REST architectural style to solve a particular range of problems. For that particular range of problems, Atompub is a very good solution".
I liked the answer. For the record, I agree that people wishing to understand REST better should look at the way AtomPub has been designed. My own awareness of AtomPub has risen a lot recently after James Strachan joined IONA :-)
That said, the reason I asked the question that way is that , as far as I can hear and understand, quite a few people reckon that if you want to do REST then just use Atom, due to the fact its format is understood by various tools, etc.
Here's what interests me. In my own understanding, exposing public data as REST resources is promising. AtomPub is good for dealing with collections of data, and thus it can be used not only to deal with feeds. It primarily deals with two levels of resources, parent resources (collections) and their children, entries.
So I'm wondering, would AtomPub be a good fit for dealing with RESTful services where parent resources have more than one descendant, ex : collection/child1/child2/child3 ?
Offtopic : I also liked James's response to "What is a better way to protect investments made into WS-* ?" :
"We should be more concerned about protecting investments in our business goals than in protecting our investments in any specific set of technologies."
It's interesting, I'm wondering how wide is a gap between these 2 concerns ? I'll muse more about it later.
In response to "Do you think AtomPub is the way to do REST ?" James replies (omitting the first sentence for brevity :-)) :
"There’s really only one way to 'do REST'. Atompub adhers to the REST architectural style to solve a particular range of problems. For that particular range of problems, Atompub is a very good solution".
I liked the answer. For the record, I agree that people wishing to understand REST better should look at the way AtomPub has been designed. My own awareness of AtomPub has risen a lot recently after James Strachan joined IONA :-)
That said, the reason I asked the question that way is that , as far as I can hear and understand, quite a few people reckon that if you want to do REST then just use Atom, due to the fact its format is understood by various tools, etc.
Here's what interests me. In my own understanding, exposing public data as REST resources is promising. AtomPub is good for dealing with collections of data, and thus it can be used not only to deal with feeds. It primarily deals with two levels of resources, parent resources (collections) and their children, entries.
So I'm wondering, would AtomPub be a good fit for dealing with RESTful services where parent resources have more than one descendant, ex : collection/child1/child2/child3 ?
Offtopic : I also liked James's response to "What is a better way to protect investments made into WS-* ?" :
"We should be more concerned about protecting investments in our business goals than in protecting our investments in any specific set of technologies."
It's interesting, I'm wondering how wide is a gap between these 2 concerns ? I'll muse more about it later.
Friday, November 23, 2007
REST for developers - it's only a beginning
In my last post I asked Steve Vinoski some questions about REST and WebServices. I'd like to comment on the questions a bit more. First though I'd like to thank Steve for taking my questions the way he did and providing interesting answers , likewise I appreciate the comments made by others.
One thing I'd like to clarify is that I personally do not need to be convinced about the viability of REST or the fact that WEB is going to affect one way or the other the way we do the distributed software. As I mentioned earlier and indeed as obvious from the public efforts of various vendors, REST is being noticed and thought about.
My questions were really a reaction to the very last "no contest" phrase in the Steve's post . I respect the Steve's visionary opinion and by no means it was kind of "how could you say it after all you've done with Corba" reaction. "No contest" may well prove to be much closer to the reality at a wider scale sooner or later , but it just does not work for me yet.
Generally, arguments like "If you do REST your application will scale to millions of requests" or "Look, Google and Yahoo does it" or "it's just simpler" simply do not work for me : it may well point to the serious lack of vision on my behalf :-) , but I find such arguments sometimes being somewhat detached from the reality and this is exactly why I liked RESTful Web Services : while favoring REST it was not very absolutist :-) at the same time.
So to some of the questions. Inspired by the Out Of the Frying Pan post where the first counter-argument is hidden in highlighted comments :-), I wanted to say through my random set of questions that IMHO there's still a lot which needs to be done for REST for it to truly start competing with WebServices, as far as attracting large groups of developers is concerned, as far as writing RESTful applications for more than just browsers and generic Atom readers is concerned.
Questions 1, 2 : Code generation, dealing with the change, large-scale client-side REST programming.
I'm not sure the problem of the generated code being too brittle is specific to Web Services for a start. The only thing which is specific to Web Services is the interaction model built around SOAP. Bill D'Ora in his post "Why To Use Atom" (it seems to have disappeared from Bill's blog :-)) says that one of the main reasons to use Atom is that Atom clients know how to ignore unrecognized extensions. I'd like to say that if you look at an atom:feed and hello:world elements coming from the wire, there's absolutely no difference as far as dealing with unknown extensions in atom:feed and hello:world elements is concerned.
Client runtimes dealing with the generated code have to learn how to optionally ignore unknown extensions. It won't solve all the problems arising from producers changing their services but it will mitigate the problem of dealing with the change. There's already some support in both NET and Java for it to start happening. Better code generation can benefit all types of client consumers but it can help popularize the client-side REST development too and let users to jump to their data of interest straight away. You might say it will trick users into believing WEB is not there, so what ? :-), it's just a start, don't get me started on the code-first development in REST on the server side :-)
WADL : it's strongest feature IMHO is to let to point to the data you want to deal with by using XPath expressions. I wonder, can one use it to deal with all the AtomPub services out there to avoid a need to install a client-side library for every type of AtomPub/GData like protocol ?
3. Is idea of interface is broken ?
I was referring to this comment further commented upon here : "we're not confused at all that a BIG part of the attraction to folks is opaque URIs and no metadata".
Are minimalistic interfaces viable ? I believe so. Coupled with a good extensibilty policy for data pushed through them can make such interfaces a bit friendlier to totally generic interfaces without compromising much the need to deal with changes. Ultimately, a generic interface is understood by all the generic tools but I don't believe that at the moment one can "switch communities" easier with generic interfaces when writing not so generic consumers : GET and friends do not tell you about the semantics.
4. Software modules using generic methods : I was somewhat emotional here, sorry :-) If everyone wants only generic interfaces then why don't we start advocating all the software components using the same generic interface WEB uses and have them relying on various properties passed through call contexts to understand what needs to be done. No need for assemblies, OSGI and for a first class diagram in the Stefan's presentation :-)
5. Is WS-Policy useless ? Dan asks Is Security The Killer Feature of WS-* ? I won't go into this topic :-). But IMHO WS-Policy is a very strong feature indeed . Facilitating the interaction with services which have complex requirements, both at the tooling level (design time) and at runtime is what WS-Policy can bring. That's why either a similar language, or may be even the same language needs to be used for RESTful services for doubts in their ability to deliver complex applications without forcing clients to do sophisticated bootstrapping code are to disappear.
There're more questions, but this post is getting long so I'll comment on one of the last ones :
"What is the difference between service factories found in Corba and RESTful services creating new child resources as part of POST (as far as managing child resources is concerned" ?
I agree, the interface is different. But what I was really trying to say that as far as dealing with transient resources is concerned to which few if any of possible advantages of REST can be applied, I'm not that sure at all that creating a new resource per every POST scales well. You need to delete them explicitly, extra call, what if the client ends up with a stale URI, etc. I think coarse-grained interfaces may have an edge here. Possibly in areas of distributed activities, etc...
That's it so far, thanks to everyone for commenting and reading !
One thing I'd like to clarify is that I personally do not need to be convinced about the viability of REST or the fact that WEB is going to affect one way or the other the way we do the distributed software. As I mentioned earlier and indeed as obvious from the public efforts of various vendors, REST is being noticed and thought about.
My questions were really a reaction to the very last "no contest" phrase in the Steve's post . I respect the Steve's visionary opinion and by no means it was kind of "how could you say it after all you've done with Corba" reaction. "No contest" may well prove to be much closer to the reality at a wider scale sooner or later , but it just does not work for me yet.
Generally, arguments like "If you do REST your application will scale to millions of requests" or "Look, Google and Yahoo does it" or "it's just simpler" simply do not work for me : it may well point to the serious lack of vision on my behalf :-) , but I find such arguments sometimes being somewhat detached from the reality and this is exactly why I liked RESTful Web Services : while favoring REST it was not very absolutist :-) at the same time.
So to some of the questions. Inspired by the Out Of the Frying Pan post where the first counter-argument is hidden in highlighted comments :-), I wanted to say through my random set of questions that IMHO there's still a lot which needs to be done for REST for it to truly start competing with WebServices, as far as attracting large groups of developers is concerned, as far as writing RESTful applications for more than just browsers and generic Atom readers is concerned.
Questions 1, 2 : Code generation, dealing with the change, large-scale client-side REST programming.
I'm not sure the problem of the generated code being too brittle is specific to Web Services for a start. The only thing which is specific to Web Services is the interaction model built around SOAP. Bill D'Ora in his post "Why To Use Atom" (it seems to have disappeared from Bill's blog :-)) says that one of the main reasons to use Atom is that Atom clients know how to ignore unrecognized extensions. I'd like to say that if you look at an atom:feed and hello:world elements coming from the wire, there's absolutely no difference as far as dealing with unknown extensions in atom:feed and hello:world elements is concerned.
Client runtimes dealing with the generated code have to learn how to optionally ignore unknown extensions. It won't solve all the problems arising from producers changing their services but it will mitigate the problem of dealing with the change. There's already some support in both NET and Java for it to start happening. Better code generation can benefit all types of client consumers but it can help popularize the client-side REST development too and let users to jump to their data of interest straight away. You might say it will trick users into believing WEB is not there, so what ? :-), it's just a start, don't get me started on the code-first development in REST on the server side :-)
WADL : it's strongest feature IMHO is to let to point to the data you want to deal with by using XPath expressions. I wonder, can one use it to deal with all the AtomPub services out there to avoid a need to install a client-side library for every type of AtomPub/GData like protocol ?
3. Is idea of interface is broken ?
I was referring to this comment further commented upon here : "we're not confused at all that a BIG part of the attraction to folks is opaque URIs and no metadata".
Are minimalistic interfaces viable ? I believe so. Coupled with a good extensibilty policy for data pushed through them can make such interfaces a bit friendlier to totally generic interfaces without compromising much the need to deal with changes. Ultimately, a generic interface is understood by all the generic tools but I don't believe that at the moment one can "switch communities" easier with generic interfaces when writing not so generic consumers : GET and friends do not tell you about the semantics.
4. Software modules using generic methods : I was somewhat emotional here, sorry :-) If everyone wants only generic interfaces then why don't we start advocating all the software components using the same generic interface WEB uses and have them relying on various properties passed through call contexts to understand what needs to be done. No need for assemblies, OSGI and for a first class diagram in the Stefan's presentation :-)
5. Is WS-Policy useless ? Dan asks Is Security The Killer Feature of WS-* ? I won't go into this topic :-). But IMHO WS-Policy is a very strong feature indeed . Facilitating the interaction with services which have complex requirements, both at the tooling level (design time) and at runtime is what WS-Policy can bring. That's why either a similar language, or may be even the same language needs to be used for RESTful services for doubts in their ability to deliver complex applications without forcing clients to do sophisticated bootstrapping code are to disappear.
There're more questions, but this post is getting long so I'll comment on one of the last ones :
"What is the difference between service factories found in Corba and RESTful services creating new child resources as part of POST (as far as managing child resources is concerned" ?
I agree, the interface is different. But what I was really trying to say that as far as dealing with transient resources is concerned to which few if any of possible advantages of REST can be applied, I'm not that sure at all that creating a new resource per every POST scales well. You need to delete them explicitly, extra call, what if the client ends up with a stale URI, etc. I think coarse-grained interfaces may have an edge here. Possibly in areas of distributed activities, etc...
That's it so far, thanks to everyone for commenting and reading !
Friday, November 16, 2007
Questions for Steve
First I've read a Dare Obasanjo story about getting disappointed in (Big) Web Services and having never to go back to them again. Dare refers to the James Snell's notes.
It's interesting how everyone picks up statements from these notes, which means they're good. Sanjiva Weerawarana picked up a note about the complexity of REST , while Dare picked up a note where James said he'd never had to go back to Web Services again since starting working in a WebAhead project. Don Box said he liked the notes too but I'd be interested to know what exactly he liked. It's offtopic but my favorite notes are :
* “Atompub + Required Vendor Specific Extensions == New Protocol”
* "Anyone who picks a technology just because it’s popular in 2007 is ..."
Anyway, Dare concludes :
"At this point I realize I’m flogging a dead horse. The folks I know from across the industry who have to build large scale Web services on the Web today at Google, Yahoo!, Facebook, Windows Live, Amazon, etc are using RESTful Web services. The only times I encounter someone with good things to say about WS-* is if it is their job to pimp these technologies or they have already “invested” in WS-* and want to defend that investment."
I've read the Dare's post and I thought, with sadness :-), why people like Dare and James have become so disappointed. Did they think that Web Services will rule the WEB ? Dare says he was not happy translating a SOAP RSS service into a RSS feed, I can feel his pain. Have they ever looked at Web Services as an integration technology ? I thought for a sec the last question would be a killer question...
Only if it was so simple :-). As it happens people who has seen the real stuff have become totally disappointed too. One of them is Steve Vinoski. Steve says in his post Dare is Right You build Real Working System with REST
"Finally, I realized that WS-* was simply not worth it to any customer or to me. My decision to leave WS-* behind and use only REST was based entirely on real-world commercial integration issues"
and concludes :
"Nowadays, all the distributed systems development I do is REST-oriented. I know from significant first-hand experience what both sides of the coin look like, and there’s no question that REST-oriented systems are easier and less expensive to develop, and far less costly to extend and manage. Like Dare said, anyone who thinks otherwise is either so emotionally or monetarily attached to WS-* that they can’t be objective, or they don’t actually write any code or build or maintain any actual systems. It’s no contest, really."
It feels like the last nail has been banged into a WS-* coffin. It feels like a strong message indeed. No compromise. Either REST or nothing.
I'd like to ask Steve few questions. It's tough asking Steve questions for someone like myself who was 'lured' to IONA by the desire to work with people like Steve . It was not only a desire to be together with IONA people like Steve though which eventually brought me to IONA, but a mission (impossible) to solve all the world problems with the help of web services :-) ! So I'd like to ask Steve few questions about software, web services and REST, in no particular order :
1. Do you think a client code generation is evil ? If yes, do you expect people to do manual programming on a large scale ?
2. If code generation is acceptable, would you welcome WADL? If yes, what to do with generated client types with respect to the change management ?
3. Do you think the idea of interfaces is broken ? Do you see any point in creating minimalistic yet not generic interfaces with encouraging users to focus on data ?
4. Would you expect in the future even software modules interacting with each other through a common generic interfaces ?
5. "WS-* was simply not worth it to any customer or to me" - was it not ?
6. Do you think WS-Policy is a useless technology ?
7. Do you think AtomPub is the best way to do REST ? Is AtomPub better than SOAP ?
8. What is a better way to protect investments made into WS-* ? Throw them away and start from scratch or start embracing the WEB while improving on what can be done with WS-* ?
9. Do you think an "integration" problem IONA has been so good at is an "overblown" problem ?
10. Can you please, if possible, describe a bit what kind of (software) clients will use your RESTful systems, (Web)UI tools or client software modules pushing the data up the response chain ?
11. What is the difference between service factories found in Corba and RESTful services creating new child resources as part of POST (as far as managing child resources is concerned) ?
12. Do you always prefer dealing with fine-grained resources ?
Perhaps more questions to come later.
Thanks.
It's interesting how everyone picks up statements from these notes, which means they're good. Sanjiva Weerawarana picked up a note about the complexity of REST , while Dare picked up a note where James said he'd never had to go back to Web Services again since starting working in a WebAhead project. Don Box said he liked the notes too but I'd be interested to know what exactly he liked. It's offtopic but my favorite notes are :
* “Atompub + Required Vendor Specific Extensions == New Protocol”
* "Anyone who picks a technology just because it’s popular in 2007 is ..."
Anyway, Dare concludes :
"At this point I realize I’m flogging a dead horse. The folks I know from across the industry who have to build large scale Web services on the Web today at Google, Yahoo!, Facebook, Windows Live, Amazon, etc are using RESTful Web services. The only times I encounter someone with good things to say about WS-* is if it is their job to pimp these technologies or they have already “invested” in WS-* and want to defend that investment."
I've read the Dare's post and I thought, with sadness :-), why people like Dare and James have become so disappointed. Did they think that Web Services will rule the WEB ? Dare says he was not happy translating a SOAP RSS service into a RSS feed, I can feel his pain. Have they ever looked at Web Services as an integration technology ? I thought for a sec the last question would be a killer question...
Only if it was so simple :-). As it happens people who has seen the real stuff have become totally disappointed too. One of them is Steve Vinoski. Steve says in his post Dare is Right You build Real Working System with REST
"Finally, I realized that WS-* was simply not worth it to any customer or to me. My decision to leave WS-* behind and use only REST was based entirely on real-world commercial integration issues"
and concludes :
"Nowadays, all the distributed systems development I do is REST-oriented. I know from significant first-hand experience what both sides of the coin look like, and there’s no question that REST-oriented systems are easier and less expensive to develop, and far less costly to extend and manage. Like Dare said, anyone who thinks otherwise is either so emotionally or monetarily attached to WS-* that they can’t be objective, or they don’t actually write any code or build or maintain any actual systems. It’s no contest, really."
It feels like the last nail has been banged into a WS-* coffin. It feels like a strong message indeed. No compromise. Either REST or nothing.
I'd like to ask Steve few questions. It's tough asking Steve questions for someone like myself who was 'lured' to IONA by the desire to work with people like Steve . It was not only a desire to be together with IONA people like Steve though which eventually brought me to IONA, but a mission (impossible) to solve all the world problems with the help of web services :-) ! So I'd like to ask Steve few questions about software, web services and REST, in no particular order :
1. Do you think a client code generation is evil ? If yes, do you expect people to do manual programming on a large scale ?
2. If code generation is acceptable, would you welcome WADL? If yes, what to do with generated client types with respect to the change management ?
3. Do you think the idea of interfaces is broken ? Do you see any point in creating minimalistic yet not generic interfaces with encouraging users to focus on data ?
4. Would you expect in the future even software modules interacting with each other through a common generic interfaces ?
5. "WS-* was simply not worth it to any customer or to me" - was it not ?
6. Do you think WS-Policy is a useless technology ?
7. Do you think AtomPub is the best way to do REST ? Is AtomPub better than SOAP ?
8. What is a better way to protect investments made into WS-* ? Throw them away and start from scratch or start embracing the WEB while improving on what can be done with WS-* ?
9. Do you think an "integration" problem IONA has been so good at is an "overblown" problem ?
10. Can you please, if possible, describe a bit what kind of (software) clients will use your RESTful systems, (Web)UI tools or client software modules pushing the data up the response chain ?
11. What is the difference between service factories found in Corba and RESTful services creating new child resources as part of POST (as far as managing child resources is concerned) ?
12. Do you always prefer dealing with fine-grained resources ?
Perhaps more questions to come later.
Thanks.
Monday, November 12, 2007
Out Of The Frying Pan and Eating the Cake
Don Box says :
"Personally, my dream stack would be ubiquitous WS-Security/WS-Trust over HTTP GET and POST and tossing out WSDL in favor of doing direct XML programming against payloads from VB9 (or XQuery), but hey, I have unusual tastes."
"Personally, my dream stack would be ubiquitous WS-Security/WS-Trust over HTTP GET and POST and tossing out WSDL in favor of doing direct XML programming against payloads from VB9 (or XQuery), but hey, I have unusual tastes."
In response Sam Ruby posts Out Of the Frying Pan. I've read it first time and thought, hmm..., I'm not getting it. Lets try few more times while focusing on the text Sam highlighted. Still my brain does not help me. Apparently, it was not only me who found a text to be a bit difficult to grasp so to say :-)
Ok, so I've tried to see what others are saying, may be they'll help to understand.
From Dare Obasanjo who keeps banging nails into the WS-* coffin (or WS-* vs REST discussion?) :-), I've found about OAuth. So little time so much to learn. Some knowledgeable people say OAuth may be incomplete yet and I'm wondering will it do well beyond web applications and social web-networks ? I need to learn this stuff. Anyway, I've seen him commenting on the vested interests of various web properties, it's getting closer but what is it that Sam was trying to say about WS-Security ?
Now, I'm seeing "Having one's cake and eating it too" from Don Box. These guys can understand each other from half a word :-). Following their exchange :
Sam : "Out of the box, exactly what security mechanisms does WS-Security provide? "
Don : "Without a mechanism for getting a token, not much. I typically think of WS-Security and WS-Trust as a unit, but you are correct, they are distinct. "
Sam : "Using only those two specs, what "ValueType" does one use for Kerberos? X509?"
Hmm... I think I'm nearly getting it now, but not quite. Dan's post comes to the rescue, or comments to be precise :
Sam Ruby : "Executive summary: Don’s criticism is that HTTP amounts to little more than a pluggable framework for incompatible authentication schemes. His proposed replacement? A pluggable framework for incompatible authentication schemes."
Here we go. It's brilliant. That's why I like the blogosphere. One day you can get something like :
"Guess what ? Web Services are like CORBA and half of your web services projects will fail". Do you really want to talk about it ?
The next day one can get something really interesting. I feel I've just learnt more about WS-Security and WS-Trust than I thought I'd known before.
And here's my 2c answer to Sam's question :
It's spot on that WS-Security is really a pluggable framework for incompatible authentication schemes. It's however the "framework" which makes a difference, at least for a time being. It makes it easier to deal with Kerberos and X509 by dictating that all goes into soap headers. This and the fact that some services to be secured are coarse-grained. No problems with security departments ignoring the interop concerns :-) It can make it easier to do a product-level support for doing advanced web services security. And WS-Policy can make it easy to consume WS-Security expressions.
Have I missed the subtle point of Sam's question ? may be, but it was fun trying :-)
Dan asks :
"Maybe the question we need to ask is how do we do WS-SX related stuff over Just HTTP"
How about :
atom:feed/atom:headers/ :-) ?
Sunday, November 11, 2007
Pragmatic notes
James Snell posts excellent notes on the notes about QCon Stefan posted earlier.
These notes are interesting to read because they're pragmatic in nature.
I don't want to select certain entries there to prove that, you know, even people which
support REST strongly do believe that it's complex. They still believe REST is better but
such notes are much more thought-provoking. Such notes have more potential to convince and generate healthy debates.
One note from James has attracted my attention :
"Now that I’m working for IBM’s WebAhead group, building and supporting applications that are being used by tens of thousands of my fellow IBMers, I haven’t come across a single use case where WS-* would be a suitable fit."
This is a strong point all right. One thing I'd like to say though that there're not too many people out there now which believe that Web Services can rule the WEB. It seems perfectly normal that no Web Services are used in the applications WebAhead group is working upon. I don't know much about those applications, but I'm presuming we're talking about clients being able to consume with their (Web)UI tools the *data* coming out of the blogs, push new data into those blogs, etc. Blogs may not the the only web apps, but we're talking about generic tools dealing with the data, right ? May be I'm just not understanding, I apologise if my one sentence analysis misses the actual reality.
These notes are interesting to read because they're pragmatic in nature.
I don't want to select certain entries there to prove that, you know, even people which
support REST strongly do believe that it's complex. They still believe REST is better but
such notes are much more thought-provoking. Such notes have more potential to convince and generate healthy debates.
One note from James has attracted my attention :
"Now that I’m working for IBM’s WebAhead group, building and supporting applications that are being used by tens of thousands of my fellow IBMers, I haven’t come across a single use case where WS-* would be a suitable fit."
This is a strong point all right. One thing I'd like to say though that there're not too many people out there now which believe that Web Services can rule the WEB. It seems perfectly normal that no Web Services are used in the applications WebAhead group is working upon. I don't know much about those applications, but I'm presuming we're talking about clients being able to consume with their (Web)UI tools the *data* coming out of the blogs, push new data into those blogs, etc. Blogs may not the the only web apps, but we're talking about generic tools dealing with the data, right ? May be I'm just not understanding, I apologise if my one sentence analysis misses the actual reality.
Friday, November 9, 2007
Pragmatism vs Religion
Stefan posted notes on some of the presentations made at QCon SF. Going a bit off topic I'd like to say that Stefan does a really great job of providing a lot of links to various resources about REST, and Web Services. His blog reminds me of the great Eric's Pulse Java blog which unfortunately is now defunct. I don't agree with some things Stefan says but I love his blog nonetheless :-)
So back to Stefan's notes. First, a Sanjiva Weerawarana's talk was presented. In his talk Sanjiva is talking about pros and cons of REST and trying to say that WS-* may not be the dead horse yet. Going to the QCon with this presentation was quite an extraordinary thing to do I'd say.
One of the other talks Stefan presented was a Pete Lacey's talk. Here's the first note :
"Agrees with everything Steve said, disagrees with almost everything Sanjiva said".
and then
"scalability: both at runtime (1 million simultaneous clients) and ability to connect (500,000 to begin with)"
> Yea, you can't beat this argument, all right
and
"information accesible to one degree or the other to anyone: managers, shadow IT, proto-geeks and mom"
> Really ? One can just take any URI out there and share it with everyone ?
etc, etc...
Sigh...It's like listening to a broken record which starts from a beginning and then reaches the end and then gets back to the start, etc.
It's so typical. It also leads to an interesting observation.
When Web Services where starting to take on the world, most of people thinking of them as being a good step forward would likely say : REST ? Huh ? No way, it just does not work. One can remember Mark Baker trying to raise an awareness of REST on all the forums out there and being ignored nonetheless, what is he talking about ?
So some time has passed. Most of the people in the enterprise world are well aware now of what REST is. Enterprise is watching and trying to get something out of it. People start to understand that Web is powerful and rather than fight with it it's better to learn how to be closer to it. Vendors start providing tools making it easy to expose data to the WEB. Other things are happening.
It's a pragmatic approach. Web Services proponents are listening, learning, adapting and thinking. They understand Web matters. They'll be the first to adapt their products once they understand and see it's working.
So what about RESTafarians ? Do they listen to what Web Services proponents are saying to them ? No. Just No. REST wins. Period. Web Services are going to die. If you're with REST you'll scale, you'll manage versioning, extensibility in a much simpler way and you can share your information with everyone. And no one will call you being 'enterprisey' so you can afford facing everyone else on the beer party rather than being ignored.
When I was young I used to feel stronger with my older and bigger friends standing behind me.
It reminds me of RESTafarians just throwing at you all the time the same arguments while blissfully ignoring whatever one says to them about Big Web Services. REST is simple, Web Services are complex, just do everything with REST and take it easy. You can never lose if you have friends like WEB, Google and Yahoo standing behind you. Do Google's services scale naturally, because their resources are addressable or do they scale because of things like BigTable ? Who cares.
This is a religion. Can a religious person admit something may not be ideal in the religion. No. You're either in or out, if you admit it you're going to lose the trust of others...
Pragmatism leads to results being achieved. Religion leads to conflicts and wars.
So back to Stefan's notes. First, a Sanjiva Weerawarana's talk was presented. In his talk Sanjiva is talking about pros and cons of REST and trying to say that WS-* may not be the dead horse yet. Going to the QCon with this presentation was quite an extraordinary thing to do I'd say.
One of the other talks Stefan presented was a Pete Lacey's talk. Here's the first note :
"Agrees with everything Steve said, disagrees with almost everything Sanjiva said".
and then
"scalability: both at runtime (1 million simultaneous clients) and ability to connect (500,000 to begin with)"
> Yea, you can't beat this argument, all right
and
"information accesible to one degree or the other to anyone: managers, shadow IT, proto-geeks and mom"
> Really ? One can just take any URI out there and share it with everyone ?
etc, etc...
Sigh...It's like listening to a broken record which starts from a beginning and then reaches the end and then gets back to the start, etc.
It's so typical. It also leads to an interesting observation.
When Web Services where starting to take on the world, most of people thinking of them as being a good step forward would likely say : REST ? Huh ? No way, it just does not work. One can remember Mark Baker trying to raise an awareness of REST on all the forums out there and being ignored nonetheless, what is he talking about ?
So some time has passed. Most of the people in the enterprise world are well aware now of what REST is. Enterprise is watching and trying to get something out of it. People start to understand that Web is powerful and rather than fight with it it's better to learn how to be closer to it. Vendors start providing tools making it easy to expose data to the WEB. Other things are happening.
It's a pragmatic approach. Web Services proponents are listening, learning, adapting and thinking. They understand Web matters. They'll be the first to adapt their products once they understand and see it's working.
So what about RESTafarians ? Do they listen to what Web Services proponents are saying to them ? No. Just No. REST wins. Period. Web Services are going to die. If you're with REST you'll scale, you'll manage versioning, extensibility in a much simpler way and you can share your information with everyone. And no one will call you being 'enterprisey' so you can afford facing everyone else on the beer party rather than being ignored.
When I was young I used to feel stronger with my older and bigger friends standing behind me.
It reminds me of RESTafarians just throwing at you all the time the same arguments while blissfully ignoring whatever one says to them about Big Web Services. REST is simple, Web Services are complex, just do everything with REST and take it easy. You can never lose if you have friends like WEB, Google and Yahoo standing behind you. Do Google's services scale naturally, because their resources are addressable or do they scale because of things like BigTable ? Who cares.
This is a religion. Can a religious person admit something may not be ideal in the religion. No. You're either in or out, if you admit it you're going to lose the trust of others...
Pragmatism leads to results being achieved. Religion leads to conflicts and wars.
Friday, November 2, 2007
JAX-WS 3.0 Wish List
JAX-WS is a good effort. It's much better compared to JAX-RPC , it's much more flexible, and one can use it to write all types of services. Granted, it's used most of the times for building Plain Old RPC SOAP Services (PORSS :-)), but it does have good features and it relies on all those cool Java things like annotations, generics and Executors.
JAX-WS is quite widespread but there's also a new kid on the block out there, JAX-RS. At Sun, JAX-WS and JAX-RS are implemented in two different projects. There's also a clear indication that future runtimes will attempt to combine the best out of all worlds, they'll try to catch two rabbits at the same time, if you wish.
So I'm curious what the future holds for JAX-WS ? Will it survive ? Or will we see a single JAX specification only in some time ? Whatever the future for JAX-WS holds, here's a wish list for its version 3.0 (if it ever happens to come to live) :
1. Deprecate Java-first web-services development. Yea, developers like it, things like annotations are so appealing. There's a catch though. It just does not work. Do you blame WSDL for the perceived interoperability issues of Web Services ? Nope, huge WSDLs are just partly to blame. It's that code-first development which makes it so easy for developers to quickly come up with a web service and send around that byte[] array or that List or Map.
By the way, I think I've seen proposals to quickly generate a WADL contract out of your code, sounds familiar, doesn't it ?
Code-first web services development is evil which many people have talked about before.
Well, ServiceContract-first development is not exactly a very pleasant experience either but it's better nonetheless. Policy-First Development which I'll chat about later will make it easier. Tools like Artix Registry/Repository are doing it (briefly referring to IONA's offering here) and it's going to blow away the code-first development and make it easier to deal with WSDL and indeed WADL contracts.
2. Deprecate doc-literal-wrapped. This one is a strong opponent. It helps you to create little nice-looking signatures completely shielding you from the reality that it's an implementation of the web service which you're dealing with :
int doIt(int x, int y);
It's nice, isn't it ?
The only problem that as soon as you add an ignorable property to the type which have been unwrapped all the signatures break. This is actually a problem of the code-generation, not that of web services. Sometimes this is exactly what people want. But there's a better way to control the change, just don't add extensibility points into your schema thus ensuring the validation will fail. Either way, the signatures should always be something like :
ComplexTypeReturn doIt(ComplexTypeRequest in);
This way one can control the change much better. More on it later, on the code generation for client runtimes and on 'must ignore'.
I'm wondering, when a WADL contract will be used to generate the code, will Sun come up with the schema design pattern which will do the same thing doc-literal-wrapped does ?
JAX-WS is quite widespread but there's also a new kid on the block out there, JAX-RS. At Sun, JAX-WS and JAX-RS are implemented in two different projects. There's also a clear indication that future runtimes will attempt to combine the best out of all worlds, they'll try to catch two rabbits at the same time, if you wish.
So I'm curious what the future holds for JAX-WS ? Will it survive ? Or will we see a single JAX specification only in some time ? Whatever the future for JAX-WS holds, here's a wish list for its version 3.0 (if it ever happens to come to live) :
1. Deprecate Java-first web-services development. Yea, developers like it, things like annotations are so appealing. There's a catch though. It just does not work. Do you blame WSDL for the perceived interoperability issues of Web Services ? Nope, huge WSDLs are just partly to blame. It's that code-first development which makes it so easy for developers to quickly come up with a web service and send around that byte[] array or that List or Map.
By the way, I think I've seen proposals to quickly generate a WADL contract out of your code, sounds familiar, doesn't it ?
Code-first web services development is evil which many people have talked about before.
Well, ServiceContract-first development is not exactly a very pleasant experience either but it's better nonetheless. Policy-First Development which I'll chat about later will make it easier. Tools like Artix Registry/Repository are doing it (briefly referring to IONA's offering here) and it's going to blow away the code-first development and make it easier to deal with WSDL and indeed WADL contracts.
2. Deprecate doc-literal-wrapped. This one is a strong opponent. It helps you to create little nice-looking signatures completely shielding you from the reality that it's an implementation of the web service which you're dealing with :
int doIt(int x, int y);
It's nice, isn't it ?
The only problem that as soon as you add an ignorable property to the type which have been unwrapped all the signatures break. This is actually a problem of the code-generation, not that of web services. Sometimes this is exactly what people want. But there's a better way to control the change, just don't add extensibility points into your schema thus ensuring the validation will fail. Either way, the signatures should always be something like :
ComplexTypeReturn doIt(ComplexTypeRequest in);
This way one can control the change much better. More on it later, on the code generation for client runtimes and on 'must ignore'.
I'm wondering, when a WADL contract will be used to generate the code, will Sun come up with the schema design pattern which will do the same thing doc-literal-wrapped does ?
WS-Policy will rock the world of web services
WS-Policy is the most important thing which happened in the world of Web Services since their invention (since SOAP, for better or worse, depending on what your appreciation of it is, came to the scene).
One will see complex specifications like WS-Security and WS-BusinessActivity, touted as being the cause of interoperabilty problems, coming to life, with UI tools completely hiding the details from developers and with client runtimes getting closer to requiring very little if any configuration at all.
Policies are obviously not specific to SOAP-based web services. One can do, for example, a message-level security for RESTful services, no probs. And yes, these services may want to advertise their runtime capabilities so that the client tools can ensure no manual coding is done. Look no further, WS-Policy language is simple yet powerful to cover a lot of ground in the world of policies.
By the way, a short off-topic statement on WS-Security, SOAP and REST. Yes, HTTPS just works and yes one can do a message-level security for RESTful services. WS-Security may offer a way too many options but there'll always be some customer out there whiich will find the use for all of those options. The thing about SOAP is that it makes it easier to productise something like WS-Security. Once a customer will get it working, with the help of WS-SecurityPolicy at the start and those SOAP headers at runtime, it will be a tough decision to make to drop it because the underlying protocol (SOAP) is considered to be a way too complicated especially after all SOAP nodes will learn how to reply to GETs.
It can also be tough to describe that a message-level security is done on a per-resource basis. It's the multitude of resources which can make it difficult to do something like message-level security on all or some of them, by describing such requirements in advance for example. A policy language like WS-Policy can help here too by facilitating the auto-discovery of requirements.
One will see complex specifications like WS-Security and WS-BusinessActivity, touted as being the cause of interoperabilty problems, coming to life, with UI tools completely hiding the details from developers and with client runtimes getting closer to requiring very little if any configuration at all.
Policies are obviously not specific to SOAP-based web services. One can do, for example, a message-level security for RESTful services, no probs. And yes, these services may want to advertise their runtime capabilities so that the client tools can ensure no manual coding is done. Look no further, WS-Policy language is simple yet powerful to cover a lot of ground in the world of policies.
By the way, a short off-topic statement on WS-Security, SOAP and REST. Yes, HTTPS just works and yes one can do a message-level security for RESTful services. WS-Security may offer a way too many options but there'll always be some customer out there whiich will find the use for all of those options. The thing about SOAP is that it makes it easier to productise something like WS-Security. Once a customer will get it working, with the help of WS-SecurityPolicy at the start and those SOAP headers at runtime, it will be a tough decision to make to drop it because the underlying protocol (SOAP) is considered to be a way too complicated especially after all SOAP nodes will learn how to reply to GETs.
It can also be tough to describe that a message-level security is done on a per-resource basis. It's the multitude of resources which can make it difficult to do something like message-level security on all or some of them, by describing such requirements in advance for example. A policy language like WS-Policy can help here too by facilitating the auto-discovery of requirements.
Subscribe to:
Posts (Atom)
