Sam Ruby says in his Progressive Disclosure post :
"Without intending to take anything away from Roy’s (valid) criticism on labeling, REST isn’t an all or nothing proposition. One can get significant value from partial adoption."
IMHO this message is much stronger and much more likely to be heard in the SOAP quarters than the "drop WS, adopt REST" message. For the latter message to (ever) get mostly if not fully materialized, the former needs to be heard well.
+1.
Indeed, Apache CXF preaches this message too with its best-of-breed JAX-WS support and its fledgling but being constantly improved JAX-RS support, now supporting 1.0 API with just few exceptions.
Tuesday, November 4, 2008
On How to Get a Cup of Coffee
InfoQ has recently published a How To Get a Cup of Coffee article about RESTful services.
I did like reading the article : it talks about workflows, shows with the help of state diagrams how clients actually drive and execute applications and overall it entertains the reader so I'd like to join those who welcomed this article. It was the only technical article I read last week, on vacation, and I was nearly killed when I was spotted reading it :-)
What surprised me a bit though is what the authors say about clients discovering which method, say PUT which may be invoked on a given resource service. For example :
"to find out if we can change the order, we ask the resource what operations it's prepared to process using the HTTP
Next :
"From Figure 6 we see that the resource is readable (it supports GET) and it's updatable (it supports PUT)."
I think this use of OPTIONS is of no practical use at all. I agree it does show what OPTIONS can be used for but I find it difficult to imagine a compiled client code checking how a given resource can be updated, especially given what is said next in the article :
"Although partial updates are the subject of deep philosophical debates within the REST community, we take a pragmatic approach" and (authors) decide to use PUT to do a partial update. Big +1 on the pragmatic approach by the way.
In meantime Mark Nottingham provides some insightful comments but again this comment on the use of PUT for partial updates catches my attention :
"This is a flagrant abuse of the semantics of PUT; if you want to combine a representation with the existing state of the resource, use POST or the emerging PATCH. "
To me it all means only one thing : the RESTful HTTP-aware compiled client code is as tightly coupled to a given resource with a generic HTTP interface as the client code generated from either WSDL or WADL is. One service will use PUT, the other one will do POST and the 3rd one will use PATCH - but the knowledge of the verb to be used when doing a given type of update is embedded in the client application code - unless it's a totally generic client application, say a browser handling HTML forms.
Here's one more excerpt from the article.
"Consumers typically agree the semantics of representations and transitions with a service during design and development. But there's no guarantee that as service evolves, it won't confront the client with state representations and transitions the client had never anticipated but knows how to process – that's the nature of the loosely coupled Web. Reaching agreement on resource formats and representations under these circumstances is, however, outside the scope of this article."
I'm curious what can be said about reaching agreements under these circumstances ? I'm seeing the client codes being recompiled in these cases if the newly introduced data or semantically important links are to be noticed.
I did like reading the article : it talks about workflows, shows with the help of state diagrams how clients actually drive and execute applications and overall it entertains the reader so I'd like to join those who welcomed this article. It was the only technical article I read last week, on vacation, and I was nearly killed when I was spotted reading it :-)
What surprised me a bit though is what the authors say about clients discovering which method, say PUT which may be invoked on a given resource service. For example :
"to find out if we can change the order, we ask the resource what operations it's prepared to process using the HTTP
OPTIONS verb, as shown on the wire in Figure 6." - please refer to the original article to see Figure 6.Next :
"From Figure 6 we see that the resource is readable (it supports GET) and it's updatable (it supports PUT)."
I think this use of OPTIONS is of no practical use at all. I agree it does show what OPTIONS can be used for but I find it difficult to imagine a compiled client code checking how a given resource can be updated, especially given what is said next in the article :
"Although partial updates are the subject of deep philosophical debates within the REST community, we take a pragmatic approach" and (authors) decide to use PUT to do a partial update. Big +1 on the pragmatic approach by the way.
In meantime Mark Nottingham provides some insightful comments but again this comment on the use of PUT for partial updates catches my attention :
"This is a flagrant abuse of the semantics of PUT; if you want to combine a representation with the existing state of the resource, use POST or the emerging PATCH. "
To me it all means only one thing : the RESTful HTTP-aware compiled client code is as tightly coupled to a given resource with a generic HTTP interface as the client code generated from either WSDL or WADL is. One service will use PUT, the other one will do POST and the 3rd one will use PATCH - but the knowledge of the verb to be used when doing a given type of update is embedded in the client application code - unless it's a totally generic client application, say a browser handling HTML forms.
Here's one more excerpt from the article.
"Consumers typically agree the semantics of representations and transitions with a service during design and development. But there's no guarantee that as service evolves, it won't confront the client with state representations and transitions the client had never anticipated but knows how to process – that's the nature of the loosely coupled Web. Reaching agreement on resource formats and representations under these circumstances is, however, outside the scope of this article."
I'm curious what can be said about reaching agreements under these circumstances ? I'm seeing the client codes being recompiled in these cases if the newly introduced data or semantically important links are to be noticed.
Friday, October 17, 2008
Football : Belarus vs England
Belarus played versus England on Wednesday 15th of October and lost 1 : 3. Even though I was disappointed they did not manage to draw or even win, I was still encouraged by quite positive reviews of the way Belarus played.
They managed to get level after losing 0:1 and who knows what could have happened if Rooney hadn't rediscovered his lethal attacking skills by the time this campaign started.
I was on a plane when the match was on, but I have it recorded. The only thing which concerns me a bit is that my (soon to be) 6 year-old son Alex is getting crazy about football at the moment and he's so excited about watching Rooney playing. I'm concerned that if I show him this match he'll start supporting England even when they play Belarus :-) May be I should wait and see if Belarus manages to shock England in the away game :-)
Slightly orthogonal note : BATE, a football club from Borisov, a small town near Minsk, is playing in the Champions League this season. In fact, it's the first ever club from Belarus which managed to achieve it. And they play Real Madrid (0:2 - in their 1st meeting in Madrid), Juventus (2:2 in Minsk) and Zenit St Petersburg (1:1 - away). Well done - great effort and it brings that much needed experience and indeed finances into the Belarussian football.
They managed to get level after losing 0:1 and who knows what could have happened if Rooney hadn't rediscovered his lethal attacking skills by the time this campaign started.
I was on a plane when the match was on, but I have it recorded. The only thing which concerns me a bit is that my (soon to be) 6 year-old son Alex is getting crazy about football at the moment and he's so excited about watching Rooney playing. I'm concerned that if I show him this match he'll start supporting England even when they play Belarus :-) May be I should wait and see if Belarus manages to shock England in the away game :-)
Slightly orthogonal note : BATE, a football club from Borisov, a small town near Minsk, is playing in the Champions League this season. In fact, it's the first ever club from Belarus which managed to achieve it. And they play Real Madrid (0:2 - in their 1st meeting in Madrid), Juventus (2:2 in Minsk) and Zenit St Petersburg (1:1 - away). Well done - great effort and it brings that much needed experience and indeed finances into the Belarussian football.
Tuesday, September 2, 2008
Fixing capitalism with the open source
I never thought I'd write about capitalism on this blog :-)
So I was flying to Minsk the other day and I was about to enjoy my holidays at home. While my fellow passengers were reading the home newspapers, I was reading an article by Bill Gates "How to fix capitalism" published by "Time". I knew I was looking a bit pretentious :-) at a time, but it was an interesting read. I picked up my copy of Time in the Dublin airport for the only reason - Bill Gates was looking at me from the front page. Actually, the article is called differently online, not sure why, possibly because 'fixing' sounds a bit strong to some hard-core capitalists :-).
That article is a brief and concise guide on how businesses can help those in great need and still make money out of it. For someone like myself knowing not much about how the business is really made it was quite an inspiring read - I was flying high - literally :-) at that moment of time and I was imagining myself doing some strategic business decisions which would make the world a better place.
Like the way the open source movement is affecting the way the business is made in the software industry, it's likely what Bill Gates wrote about will affect the way the business is made in general, sooner or later. Customers will prefer to buy from producers who are known to be associated with good causes.
The open source business model is primarily based on the promise that once the ubiquity is reached there will always be customers which would prefer to buy a certified version of the open-source product, that is, pay for the top-class support.
The open source, by definition, is free and it's being doing well in making capitalism more creative by lowering the cost of entry for those who need to write functioning applications fast. Not everyone who is using the open source software is in great need but those who really are can certainly avail of the freely available software.
And it's likely that customers will eventually reward vendors who're investing in the open source - simply because the open-source vendors will be seen as the ones who are associated with the good cause.
So I was flying to Minsk the other day and I was about to enjoy my holidays at home. While my fellow passengers were reading the home newspapers, I was reading an article by Bill Gates "How to fix capitalism" published by "Time". I knew I was looking a bit pretentious :-) at a time, but it was an interesting read. I picked up my copy of Time in the Dublin airport for the only reason - Bill Gates was looking at me from the front page. Actually, the article is called differently online, not sure why, possibly because 'fixing' sounds a bit strong to some hard-core capitalists :-).
That article is a brief and concise guide on how businesses can help those in great need and still make money out of it. For someone like myself knowing not much about how the business is really made it was quite an inspiring read - I was flying high - literally :-) at that moment of time and I was imagining myself doing some strategic business decisions which would make the world a better place.
Like the way the open source movement is affecting the way the business is made in the software industry, it's likely what Bill Gates wrote about will affect the way the business is made in general, sooner or later. Customers will prefer to buy from producers who are known to be associated with good causes.
The open source business model is primarily based on the promise that once the ubiquity is reached there will always be customers which would prefer to buy a certified version of the open-source product, that is, pay for the top-class support.
The open source, by definition, is free and it's being doing well in making capitalism more creative by lowering the cost of entry for those who need to write functioning applications fast. Not everyone who is using the open source software is in great need but those who really are can certainly avail of the freely available software.
And it's likely that customers will eventually reward vendors who're investing in the open source - simply because the open-source vendors will be seen as the ones who are associated with the good cause.
Friday, July 25, 2008
Rest and Soap united in CXF
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.
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.
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 ?
Subscribe to:
Posts (Atom)
