Please ignore the fact that Rest and Soap are presented as two alternatives - even though it's not very accurate this just helps me to make a shorter title for this blog entry.
I was quite interested in a 'Restifying' SOAP-based services idea awhile back, especially after a Web Method Feature was introduced. I'm not sure anyone relies on it today, when writing practical SOAP-based web services - I just don't know.
The arrival of JAX-RS introduces some new interesting possibilities in this area - from the perspective of the server-side application development at least.
Consider the ever popular Bank-Account scenario which uses a Factory pattern.
Here's a typical JAX-WS class :
@WebService
public class BankService {
public javax.xml.ws.wsaddressing.W3CEndpointReference createAccount(AccountInfo ai) {
// code omitted for brevity
}
}
This class will return EPRs, one per every new Account created.
Now consider the same class slightly updated :
@WebService(wsdlLocation="bank.wsdl")
@Path("/bank")
public class BankService {
@POST
public javax.xml.ws.wsaddressing.W3CEndpointReference createAccount(AccountInfo ai) {
// code omitted for brevity
}
}
It is the same class with JAX-WS and JAX-RS annotations mixed in.
In case of SOAP, POST createAccount requests will be targeted to, say, http://localhost:8080/bankservice endpoint address, while in the other case POST requests will be targeted to http://localhost:8080/bank address.
The only missing bit is a JAX-RS MessageBodyWriter which can handle the handling of W3CEndpointReferences :
public class W3cMessageBodyWriter {
public void writeTo(W3CEndpointReference epr, ..., MutivaluedMap<String, Object> headers, OutputStream os) {
// just update the headers, do not write into the stream
headers.putSingle("Location", getEprAddress(epr));
}
}
Now, the problem is that status code needs to be set to 201 in this case and it's not possible to set a custom http status code in JAX-RS MessageBodyWriters. Enter CXF JAX-RS filters. They will be invoked before the headers and status code is set on a CXF private Message class :
public class EprResponseHandler implements ResponseHandler {
public Response handleResponse(Message m,
OperationResourceInfo invokedOperation,
Response response) {
Object entity = response.getEntity();
if (entity != null
&& W3CEndpointReference.class.isAssignableFrom(entity)) {
return Response.created(getEndpointAddress(entity)).build();
} else {
return null;
}
}
}
Note, the need for a custom MessageBodyWriter goes away now.
Finally, one needs to configure both JAX-WS and JAX-RS endpoints using Spring for ex, and you're done.
A couple of additional notes. There's really no need to go for all this trouble of creating custom filters unless you'd like to preserve the same interface you've already used before starting to play with JAX-RS - this may not be that far-fetched a requirement at all. And sorry for writing a lame and incomplete code - hopefully it still makes sense :-)
Finally, note how very similar the programming model on the server can be, when using both JAX-WS and JAX-RS. Big Web Services are often compared to Corba for a number of reasons, one of them the use of EPRs - this is definitely a red-herring. It's the non-support for GET and fine-grained interfaces which put the sides apart.
Friday, July 25, 2008
A RESTful Core for Web-like Application Flexibility
I spotted a RESTful Core for Web-like Application Flexibility article on the ServerSide.
Please read it.
I was musing a bit about the universal web programming in a couple of previous posts, using an "if REST approach is considered so appealing to the web application developers then why don't we just have the generic interfaces even in the local JVM" kind of argument, without any practical suggestions.
Looks like some clever people are after it - and my take on it is that it's just a matter of time before we'll see a new programming language, say, W#, pronounced as 'Web Sharp'. It will come out from Microsoft or Sun or IBM or Google or indeed from 1060 Research labs. I don't see how this would be W# language ever replace Java , but I have little doubt it will be unveiled eventually.
The authors do not propose to replace, say, a java.util.List interface with a more generic version such that a client code is never even compiled against a fine-grained interface. Given that what they write is considered 'extreme' by some of the readers of their article, deprecating the whole notion of the interface is not a starter even in the nearest longer future :-) What the authors propose seems like an interesting and promising idea, of some moderate 'extreme' :-).
Interesting stuff.
Please read it.
I was musing a bit about the universal web programming in a couple of previous posts, using an "if REST approach is considered so appealing to the web application developers then why don't we just have the generic interfaces even in the local JVM" kind of argument, without any practical suggestions.
Looks like some clever people are after it - and my take on it is that it's just a matter of time before we'll see a new programming language, say, W#, pronounced as 'Web Sharp'. It will come out from Microsoft or Sun or IBM or Google or indeed from 1060 Research labs. I don't see how this would be W# language ever replace Java , but I have little doubt it will be unveiled eventually.
The authors do not propose to replace, say, a java.util.List interface with a more generic version such that a client code is never even compiled against a fine-grained interface. Given that what they write is considered 'extreme' by some of the readers of their article, deprecating the whole notion of the interface is not a starter even in the nearest longer future :-) What the authors propose seems like an interesting and promising idea, of some moderate 'extreme' :-).
Interesting stuff.
Tuesday, July 15, 2008
Is it all about agreement ?
I remember reading one of the Mark Little's posts (sorry can't find the link) where he was saying that, yes, it was possible to write transactions in REST, in fact he'd even had some practical experience in that area before.
Yes, while I don't have such experience I know now how I can do it now with REST.
Then Mark said that a number of partners had managed to demonstrate the interoperability of one of WS-* Transaction specification as part of some of the interoperability events.
This makes me wonder : is it what actually defines Web Services ? Not only the actual technology per se but the fact that multiple businesses can do the same technology and successfully interoperate ?
Will it ever happen with RESTful services ? Will it be possible for multiple companies to interoperate with more sophisticated things involved such as transactions, for ex, something which is possible to do with WS-BusinessActivity which does not really lock all involved ?
Or is it something which will not be ever needed in practice ? Local transactions, different business alliance-specific standards is all what will be needed to either just do transactions or achieve the interoperability in say the transactions area ?
Yes, while I don't have such experience I know now how I can do it now with REST.
Then Mark said that a number of partners had managed to demonstrate the interoperability of one of WS-* Transaction specification as part of some of the interoperability events.
This makes me wonder : is it what actually defines Web Services ? Not only the actual technology per se but the fact that multiple businesses can do the same technology and successfully interoperate ?
Will it ever happen with RESTful services ? Will it be possible for multiple companies to interoperate with more sophisticated things involved such as transactions, for ex, something which is possible to do with WS-BusinessActivity which does not really lock all involved ?
Or is it something which will not be ever needed in practice ? Local transactions, different business alliance-specific standards is all what will be needed to either just do transactions or achieve the interoperability in say the transactions area ?
About the 10 year plan
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.
"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.
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.
Subscribe to:
Posts (Atom)
