Through Stefan Titkov I came across this comment by Benjamin Carlyle. Benjamin says :
"Perhaps the clearest contrast is between REST and a strongly-typed O-O language. In nice, crinkly java I get a compile error whenever two components disagree on the definition of an interface. The client tries to call method foo. There is no method foo. Bail. In this setting it makes sense to leverage the strongly-typed nature of the language to make sure you don't release junk. You define interfaces in a detailed and domain-specific way that is checked to yield a consistent releasable whole."
I briefly touched on it before but given that an interface with more than 4 methods is deemed unsuitable on the Web (for all the reasons associated by REST advocates with this approach) why does it seem so natural and acceptable to do OO finer interfaces in a single JVM ? Will it be the ultimate WEB experience everywhere if there were only generic methods everywhere, on the WEN and in virtual machines ? The only difference would be that when programming remote services clients would need to be able to catch up remote exceptions and handle them as needed ?
This is probably a lot of nonsense. But I hope it captures what seems like one the main reasons behind a 'split' between RESTful and WebServices communities : for some it's natural to program in terms of generic interfaces, some will eventually accept it, for others it's simply a non-starter and more specific interfaces are on the map - with the proper data extensibility policy they can fare pretty well too.
Benjamin then says :
"In REST, I want the client or the server I deployed literally 10 years ago to work with whatever I am putting out today. I also want whatever I'm putting out today to work with every bit of code written since that time, and every bit of code that will be written in the next 10 years. "
I think I've read on one of the Benjamin's blogs that in 10 years time it will be all about REST. I have to admit that prediction may be much closer to the reality as people are getting behind REST more and more.
The one quoted above is basically unrealistic IMHO. With one exception only. If you're a client doing GET. I've always believed that GET is one of the main driving force behind the Web (plus links to URIs which can be GETed). Doing POSTs, PUTs, etc, in 10 years time ? I doubt - but I'm happy to be eventually proven wrong.
Tuesday, July 15, 2008
CXF and JAX-RS
I've had a chance to get involved recently in a JAX-RS project in Apache CXF. This project is far from being complete yet but that's another story... I have to admit I've had a very positive experience while working on it.
CXF JAX-RS has entered the game quite late, with the leading implementations like Jersey, and very likely equally strong RestEasy and Restlets JAX-RS being there for a while already. Thanks to the work of my former colleague Jervis Liu, the feedback from the CXF users and the tremendous feedback from JAX-RS experts and the very open process behind the way JAX-RS and Jersey RI team operates has helped CXF JAX-RS to catch up a little bit with 0.8 api mostly supported now.
One can wonder what is next for CXF JAX-RS ? I hope that with the help of the large CXF community, its JAX-RS implementation will eventually become as solid as its top-notch (CXF) JAX-WS 'counterpart'. Will it be able to compete with the likes of Jersey, with it's client api gem (which will hopefully get standardized one day :-) ) ? It's hard to tell - not in the nearest future for sure.
Still I reckon CXF JAX-RS will eventually find its niche. While CXF JAX-RS users can certainly write RESTful service only with no JAX-WS (SOAP) involved, possibly its best 'argument' is that it sits on top of and is closely integrated with the same runtime which hosts quite possibly the best JAX-WS implementation out there. CXF users will be able to write the services combining JAX-WS and JAX-RS technologies, with one or more closely related Java classes involved, some will experiment and decide to move to JAX-RS altogether, some will use the combination of two technologies and some might get back to JAX-WS, you never know :-)
Generally, I'm somewhat pessimistic about Java code relying on various annotations which is what JAX-RS is all about. Having said that I have to admit that JAX-RS is much more involved in that it's not only about the annotations. Possibly the main achievement of JAX-RS authors is that JAX-RS 'breaks' the barrier for Java users at large and let them experiment with RESTful services while still being in the comfort of the their JAVA code. It's a great effort by those behind the specification and the RI.
CXF JAX-RS has entered the game quite late, with the leading implementations like Jersey, and very likely equally strong RestEasy and Restlets JAX-RS being there for a while already. Thanks to the work of my former colleague Jervis Liu, the feedback from the CXF users and the tremendous feedback from JAX-RS experts and the very open process behind the way JAX-RS and Jersey RI team operates has helped CXF JAX-RS to catch up a little bit with 0.8 api mostly supported now.
One can wonder what is next for CXF JAX-RS ? I hope that with the help of the large CXF community, its JAX-RS implementation will eventually become as solid as its top-notch (CXF) JAX-WS 'counterpart'. Will it be able to compete with the likes of Jersey, with it's client api gem (which will hopefully get standardized one day :-) ) ? It's hard to tell - not in the nearest future for sure.
Still I reckon CXF JAX-RS will eventually find its niche. While CXF JAX-RS users can certainly write RESTful service only with no JAX-WS (SOAP) involved, possibly its best 'argument' is that it sits on top of and is closely integrated with the same runtime which hosts quite possibly the best JAX-WS implementation out there. CXF users will be able to write the services combining JAX-WS and JAX-RS technologies, with one or more closely related Java classes involved, some will experiment and decide to move to JAX-RS altogether, some will use the combination of two technologies and some might get back to JAX-WS, you never know :-)
Generally, I'm somewhat pessimistic about Java code relying on various annotations which is what JAX-RS is all about. Having said that I have to admit that JAX-RS is much more involved in that it's not only about the annotations. Possibly the main achievement of JAX-RS authors is that JAX-RS 'breaks' the barrier for Java users at large and let them experiment with RESTful services while still being in the comfort of the their JAVA code. It's a great effort by those behind the specification and the RI.
Futile arguments about REST and Web Services
It's ongoing. It's not going to stop until the battle is over and Web Services inventors acknowledge their defeat and apologize to the WEB community at large for the damage they've done to the Web.
Many REST practitioners have stopped their campaigns a long time ago and moved on to implement the real specifications and applications - there's no point in trying to argue all the time. Atom and AtomPub, Microsoft Astoria and Google GData, Atom-based repositories and JAX-RS - a number of successful examples is growing. They speak and convince better than bitter arguments.
Likewise, many Web Services practitioners have just moved on with their work. There's no point to keep arguing non-stop.
Where camp do I belong to ? As it happens I didn't have a need to work practically with real Web Services for the most part of the last 2 years or so. Is it a strong enough reason for me to believe that Web Services have no real and practical use now that I know I can do an awful lot and more with plain REST ? I don't think so, not yet.
For the REST advocates who can't stop arguing : relax, REST is getting the momentum it deserves and sooner or later many developers will come to it - if it proves an ultimately better technology then it's just a matter of time. Just give people some time.
For the Web Service advocates who can't stop arguing : relax, Web Services have proved they can work - they can be overused like any other technology but they can deliver. And learn REST with open eyes and see what it can bring to you - don't ignore it.
Many REST practitioners have stopped their campaigns a long time ago and moved on to implement the real specifications and applications - there's no point in trying to argue all the time. Atom and AtomPub, Microsoft Astoria and Google GData, Atom-based repositories and JAX-RS - a number of successful examples is growing. They speak and convince better than bitter arguments.
Likewise, many Web Services practitioners have just moved on with their work. There's no point to keep arguing non-stop.
Where camp do I belong to ? As it happens I didn't have a need to work practically with real Web Services for the most part of the last 2 years or so. Is it a strong enough reason for me to believe that Web Services have no real and practical use now that I know I can do an awful lot and more with plain REST ? I don't think so, not yet.
For the REST advocates who can't stop arguing : relax, REST is getting the momentum it deserves and sooner or later many developers will come to it - if it proves an ultimately better technology then it's just a matter of time. Just give people some time.
For the Web Service advocates who can't stop arguing : relax, Web Services have proved they can work - they can be overused like any other technology but they can deliver. And learn REST with open eyes and see what it can bring to you - don't ignore it.
What happened to Web3S ?
Web3S is somewhat 'close' to me given that I dedicated my very first technical post in this blog to that technology :-)
I remember seeing an announcement, then I remember seeing a lot of very critical remarks, then there were some Web3S vs AtomPub discussions, then some silence followed, and then it was all over for Web3S.
I can still link to it - perhaps this link is alive because there could be some customers out there depending on it. Either way, there could a lot of reasons why Microsoft chose to go with AtomPub.
The momentum behind Atom/AtomPub is second to none and it has some attractive features which appeal to different categories of developers.
Still, there's something positive I'd like to say about Web3s - despite its somewhat complicated namespace schemes and some other drawbacks which may've been attributed to it, Web3S XML instances reminded me, well, plain and simple XML.
I remember seeing an announcement, then I remember seeing a lot of very critical remarks, then there were some Web3S vs AtomPub discussions, then some silence followed, and then it was all over for Web3S.
I can still link to it - perhaps this link is alive because there could be some customers out there depending on it. Either way, there could a lot of reasons why Microsoft chose to go with AtomPub.
The momentum behind Atom/AtomPub is second to none and it has some attractive features which appeal to different categories of developers.
Still, there's something positive I'd like to say about Web3s - despite its somewhat complicated namespace schemes and some other drawbacks which may've been attributed to it, Web3S XML instances reminded me, well, plain and simple XML.
The role of big Web Services ?
Dare Obasanjo posts an interesting analysis of what looks like a controversial new offering from Google, the Protocol Buffers. Personally I always try to see different sides of a given technology even though I may not like it. I like reading reviews which offer the same kind of perspective and this post certainly fits the bill, not that I'm planning to use Protocol Buffers any soon, but anyway...
I'm curious though, what would Dare have to say about the role of big Web Services given that he's explained when it might make sense to use Protocol Buffers ?
I'm curious though, what would Dare have to say about the role of big Web Services given that he's explained when it might make sense to use Protocol Buffers ?
Coldplay : Viva La Vida
I reckon I should create another category for off-topic posts, will do it if I find myself blogging about not web-servicy things a lot...
The latest Coldplay album seems to be their best so far. My criteria is simple : if this music can inspire me while I'm driving to work, possibly stuck in a traffic :-) then by definition it's a very good music - and thus Coldplay join Muse and Killers as one my favorite bands...
While the Killers' text "Higher and higher we're gonna take it, down to the wire we're gonna make it" is probably my favorite piece of 'applicable to the software business' kind of text, Coldplay's "If I'm losing it does not mean I'm lost" is also not too bad and is quite applicable.
The latest Coldplay album seems to be their best so far. My criteria is simple : if this music can inspire me while I'm driving to work, possibly stuck in a traffic :-) then by definition it's a very good music - and thus Coldplay join Muse and Killers as one my favorite bands...
While the Killers' text "Higher and higher we're gonna take it, down to the wire we're gonna make it" is probably my favorite piece of 'applicable to the software business' kind of text, Coldplay's "If I'm losing it does not mean I'm lost" is also not too bad and is quite applicable.
Thursday, June 26, 2008
Euro 2008 : Russia vs Spain
As you know, every fairytale comes to an end one day. For those cheering Russia this is what happened tonight.
The Russian team, thanks to its players and their Dutch master, has shown some truly brilliant football against Sweden and Holland. They really played well in those games. But one has to accept that they've been comprehensively beaten by even more brilliant Spanish team. I think they just shocked the Russians with their absolutely top display today, it was a soccer fan's joy to see them playing like that. Spain look like the true Euro 2008 champions.
The good news for Russian fans is that their team, being the youngest in the competition , showed some real quality and talent. They have a good chance to qualify and impress in South Africa.
Who knows, may be I'll be lucky to see Belarus playing in the major tournament one day too.
The Russian team, thanks to its players and their Dutch master, has shown some truly brilliant football against Sweden and Holland. They really played well in those games. But one has to accept that they've been comprehensively beaten by even more brilliant Spanish team. I think they just shocked the Russians with their absolutely top display today, it was a soccer fan's joy to see them playing like that. Spain look like the true Euro 2008 champions.
The good news for Russian fans is that their team, being the youngest in the competition , showed some real quality and talent. They have a good chance to qualify and impress in South Africa.
Who knows, may be I'll be lucky to see Belarus playing in the major tournament one day too.
Subscribe to:
Posts (Atom)
