Just few hours after blogging about the Atom blogging feature being now developed in CXF, I thought it might be worth checking what was actually happening with Abdera which we currently depend upon in CXF.
I actually noticed before not much was happening in the project by briefly looking at the main page but did not pay any attention to it. This time I clicked few more links, and when reading the November archive I just experienced a number of conflicting emotions during few minutes :-), starting from the disappointment and ending with a cautious optimism.
What I do not understand is how a project which by many users is assumed to be a Reference Implementation of everything to do with Atom and AtomPub ended up being nearly retired ? How it could have happened given that just a couple of years ago AtomPub and Atom were probably one of the most talked about technologies ? They were touted as candidates for a complete replacement for SOAP given that Feed provides an envelope-like wrapper around (data) Entries ?
Well, it is not that important today. The thing is that actually many users do use AtomPub and Atom. Things are happening on the atom-syntax list. Abdera is obviously not the only way to create Atom Feeds or Entries but it just a very good library for doing it. IMHO it is a perfect library for users to use when they need to create sophisticated and real-life feeds or entries. I am not so optimistic about Abdera acting as a standalone server framework, IMHO it is not why most users are relying on Abdera. I would personally like to see it moving toward imlementing other promising Atom draft specs, etc.
In CXF we are sticking with Abdera for the time being. As far as the Atom logging feature is concerned, using Atom was a rather obvious choice due to the fact it was the most cost effective way to have the interesting events be delived to a variety of the existing Atom-aware consumers.
We hope Abdera will help us. We would like Abdera, the Atom and AtomPub RI to live and succeed. This project needs a leader and it is good to know James Snell is planning to reengage.
Do you remember Microsoft Web3S ? I thought it was a good effort, but the Atom won.
So will Abdera stay around ? Come on, Abdera !
Wednesday, November 25, 2009
Friday, November 20, 2009
Updates to the CXF JAXRS runtime
Updates to the CXF JAX-RS runtime have been somewhat limited during the last few months due the ongoing high-priority internal project I've been assigned to contribute to. This project is likely to continue for another couple of months.
Given this, I've focused on working on some of the issues which users have asked on the CXF lists a number of times, directly or indirectly.
So here is what has been done for CXF 2.2.5 :
1. Redirection support, both at the CXFServlet (check the Redirection section) and CXF JAX-RS levels. Users can redirect to static or dynamic resources such as JSP, or to some other servlets.
2. Additional updates to the way JAXB/JSON inputs/outputs can be customized. The purpose of this feature is to let users do simple input/output updates by changing, dropping or appending elements and or attributes. For example, it is now should be possible to deserialize the sequence of JSON arrays without a root element.
3. Few minor updates to JSONProvider, such as a BadgerFish convention support and a fix to let CXF JAXRS endpoints interact with the Dojo JSON RestStore (patch has been submitted).
4. Improvements to the way multipart/form-data requests are handled.
5. ResourceComparator extension which can let users affect the way multiple matching resource classes or methods are selected.
6. Documentation annotation has been added for more descriptive WADLs be generated
For the next couple of months or so, due the above-mentioned internal project, I will continue focusing on making the localized updates which will may make the difference for CXF JAXRS users. Plus do some JAX-RS 1.1 work and try to contribute to Andy's Atom logging project. I will not have time to do any Java EE work as mandated by the JAX-RS 1.1 maintenance spec - I'll rather focus on working on more down to earth issues for 2.3. By the way, if anyone out there is contemplating contributing to CXF JAX-RS then doing the EJB or other EE-related JAX-RS 1.1 tasks will be welcomed.
Given this, I've focused on working on some of the issues which users have asked on the CXF lists a number of times, directly or indirectly.
So here is what has been done for CXF 2.2.5 :
1. Redirection support, both at the CXFServlet (check the Redirection section) and CXF JAX-RS levels. Users can redirect to static or dynamic resources such as JSP, or to some other servlets.
2. Additional updates to the way JAXB/JSON inputs/outputs can be customized. The purpose of this feature is to let users do simple input/output updates by changing, dropping or appending elements and or attributes. For example, it is now should be possible to deserialize the sequence of JSON arrays without a root element.
3. Few minor updates to JSONProvider, such as a BadgerFish convention support and a fix to let CXF JAXRS endpoints interact with the Dojo JSON RestStore (patch has been submitted).
4. Improvements to the way multipart/form-data requests are handled.
5. ResourceComparator extension which can let users affect the way multiple matching resource classes or methods are selected.
6. Documentation annotation has been added for more descriptive WADLs be generated
For the next couple of months or so, due the above-mentioned internal project, I will continue focusing on making the localized updates which will may make the difference for CXF JAXRS users. Plus do some JAX-RS 1.1 work and try to contribute to Andy's Atom logging project. I will not have time to do any Java EE work as mandated by the JAX-RS 1.1 maintenance spec - I'll rather focus on working on more down to earth issues for 2.3. By the way, if anyone out there is contemplating contributing to CXF JAX-RS then doing the EJB or other EE-related JAX-RS 1.1 tasks will be welcomed.
The release of CXF 2.2.5
CXF 2.2.5 has just been released. I don't often, if ever, blog about individual CXF releases but I thought it was worth commenting about this release.
In CXF 2.2.5 improvements have been done to the core, JAXWS and JAXRS runtimes, but I'll post an update about JAXRS-related updates next.
What is remarkable about CXF 2.2.5 is that in the space of few weeks nearly 100 or so long-pending bugs and enhancement requests have been fixed. CXF core and the JAXWS runtime have been improved a lot. Dan, Benson, Christian and others have embarked on the bug fixing spree and the result has been impressive. I've become dizzy during the last few weeks getting the constant stream of merge emails to the trunk and 2.2.x in my email box.
I know it is next to impossible to do a perfect software product. The CXF JAXWS implementation is about to become the one.
In CXF 2.2.5 improvements have been done to the core, JAXWS and JAXRS runtimes, but I'll post an update about JAXRS-related updates next.
What is remarkable about CXF 2.2.5 is that in the space of few weeks nearly 100 or so long-pending bugs and enhancement requests have been fixed. CXF core and the JAXWS runtime have been improved a lot. Dan, Benson, Christian and others have embarked on the bug fixing spree and the result has been impressive. I've become dizzy during the last few weeks getting the constant stream of merge emails to the trunk and 2.2.x in my email box.
I know it is next to impossible to do a perfect software product. The CXF JAXWS implementation is about to become the one.
Wednesday, November 18, 2009
Atom Logging in CXF
Andrzej (Andy) Michalec, the CXF committer, has just committed the initial code for supporting push-style Atom logging in CXF.
It is only a beginning. It all seems quite straightforward to implement, but even a push-style Atom logger requires a lot of effort and thinking for it to be implemented well, and even more work will be needed to polish the original implementation. So it is a great effort from Andy, thanks.
This code will initially live in the CXF JAX-RS implementation code base but the idea is that all of CXF endpoints, JAXWS and JAXRS based ones, will be able to have their logging events handled by these Atom-based handlers, by registering them from the logging properties or from Spring.
The pull-style appender will be done later on, it will be more complex than the push-style one. Supporting Feed Archiving features, etc, is on the map, and we hope Abdera will help there.
Going forward, we can see users being able to selectively register callback URis with CXF endpoint-specific push-style loggers or subscribe to individual feeds, possibly finding the required feed from a master feeds endpoint. The users will be able to apply a lot of various configuration to both push and pull style loggers. Some of this configuration will have to do with the mechanics of the pull- or push- style deliveries, and some of it will have to do with how the log records will be presented in an Atom feed - there're quite a few possible options there.
This will also drive further requirements on the CXF JAXRS Client API, namely the support for one ways and asyncs will be on the map.
I'm thrilled. I really am. Hope you will be too once you start using this feature in CXF.
We'll start documenting it a bit later on, we might have it all done in time for CXF 2.3.
Think CXF, think Atom. Think Atom, think CXF. Enjoy :-)
It is only a beginning. It all seems quite straightforward to implement, but even a push-style Atom logger requires a lot of effort and thinking for it to be implemented well, and even more work will be needed to polish the original implementation. So it is a great effort from Andy, thanks.
This code will initially live in the CXF JAX-RS implementation code base but the idea is that all of CXF endpoints, JAXWS and JAXRS based ones, will be able to have their logging events handled by these Atom-based handlers, by registering them from the logging properties or from Spring.
The pull-style appender will be done later on, it will be more complex than the push-style one. Supporting Feed Archiving features, etc, is on the map, and we hope Abdera will help there.
Going forward, we can see users being able to selectively register callback URis with CXF endpoint-specific push-style loggers or subscribe to individual feeds, possibly finding the required feed from a master feeds endpoint. The users will be able to apply a lot of various configuration to both push and pull style loggers. Some of this configuration will have to do with the mechanics of the pull- or push- style deliveries, and some of it will have to do with how the log records will be presented in an Atom feed - there're quite a few possible options there.
This will also drive further requirements on the CXF JAXRS Client API, namely the support for one ways and asyncs will be on the map.
I'm thrilled. I really am. Hope you will be too once you start using this feature in CXF.
We'll start documenting it a bit later on, we might have it all done in time for CXF 2.3.
Think CXF, think Atom. Think Atom, think CXF. Enjoy :-)
Monday, November 16, 2009
The WADL Dilemma
The Web Application Description Language (WADL) is now being acknowledged by many as a language which is practical, functional, very capable of describing the advanced RESTful web services and yet simple and easy to read and understand.
WADL has now been submitted to W3C which is a great achievement for Marc Hadley. What is really unique about this submission is that it has not been submitted by the usual suspects like Microsoft and IBM but rather by the individual author. It seems that the time when various web services specifications have been discussed by a number of years by various companies is behind us, but you never know.
CXF has been supporting WADL since 2.2.3. The auto-generated WADL instances can describe live RESTful services quite well, with JAXB-generated schemas being included in WADL grammar elements and indeed with all the subresources being described too, as long as the static subresource resolution is enabled.
More enhancements have to and will be done but first I'll touch on what I call a WADL dilemma.
It is a Web Application Description Language. It is the way it describes the *Web application* that distinguishes it. For example, a WADL consumer such as a RESTful client test framework can read a given WADL document and let users test the application by following the application paths described by WADL.
I think it's of little doubt that the decision has been made to design WADL such that application interfaces (such as Person or Book, etc) could not be described in WADL. This is absolutely normal given that RESTful consumers are generally programming againt generic HTTP interfaces and programming with proxies is often considered to be an antipattern. Thus I guess adding the possibility to describe application interfaces was an obvious non-starter.
As a side note, before proceeding further, I think I might be nearly coming to the conclusion, that as far as choosing between proxies or http-centric clients for consuming restful services is concerned, it is really like choosing between different shades of grey. Some users, when they see proxies, think RPC immediately but it is not quite the case for proxies producing perfectly valid RESTful requests. Neither option is immune to the service changes though but good frameworks such as CXF will offer a lot of help for coping with such changes. I think it may be more a matter of the taste these days...
So back to the dilemma. What I think is currently missing from WADL is the fact it can not be used to generate what seems to be the main source of auto-generated WADL instances : JAX-RS annotated service classes. The WADL-first option will work well for the http-centric consumers but it is Java-first all the way for the JAX-RS services.
The Java-first approach to the services development has proved to be very popular and viable. However, the option of modeling web resources and generating service classes seems quite attractive too but enhancing WADL to support such an option would just basically turn it into WSDL. And this is where the dilemma is.
In meantime, a number of various approaches is being tried to create richer WADLs out of Java classes. One of those attempts is to do with extracting Java Docs for resource classes and methods and publishing them as WADL documentation fragments - it does seem like a step too far given that Java Docs are meant for the Java engineers using a given interface or class. But not for the users of Web Services backed up by such classes/interfaces.
In CXF we've added a Description annotation which is mapped to a WADL doc element and we will recommend users to use this annotation for documenting resources or methods using the language intended for the users of a given web service.
The other thing we need to think about is how we can let users do the WADL first developement. The question is how to avoid turning it into WSDL. That said, we should also probably look closer at the option of supporting WSDL2, especially for the users who do both SOAP and REST - having a single document describing both SOAP and REST may benefit them, though as far as describing RESTful services is concerned WSDL2 seems a bit limited.
Stay tuned.
WADL has now been submitted to W3C which is a great achievement for Marc Hadley. What is really unique about this submission is that it has not been submitted by the usual suspects like Microsoft and IBM but rather by the individual author. It seems that the time when various web services specifications have been discussed by a number of years by various companies is behind us, but you never know.
CXF has been supporting WADL since 2.2.3. The auto-generated WADL instances can describe live RESTful services quite well, with JAXB-generated schemas being included in WADL grammar elements and indeed with all the subresources being described too, as long as the static subresource resolution is enabled.
More enhancements have to and will be done but first I'll touch on what I call a WADL dilemma.
It is a Web Application Description Language. It is the way it describes the *Web application* that distinguishes it. For example, a WADL consumer such as a RESTful client test framework can read a given WADL document and let users test the application by following the application paths described by WADL.
I think it's of little doubt that the decision has been made to design WADL such that application interfaces (such as Person or Book, etc) could not be described in WADL. This is absolutely normal given that RESTful consumers are generally programming againt generic HTTP interfaces and programming with proxies is often considered to be an antipattern. Thus I guess adding the possibility to describe application interfaces was an obvious non-starter.
As a side note, before proceeding further, I think I might be nearly coming to the conclusion, that as far as choosing between proxies or http-centric clients for consuming restful services is concerned, it is really like choosing between different shades of grey. Some users, when they see proxies, think RPC immediately but it is not quite the case for proxies producing perfectly valid RESTful requests. Neither option is immune to the service changes though but good frameworks such as CXF will offer a lot of help for coping with such changes. I think it may be more a matter of the taste these days...
So back to the dilemma. What I think is currently missing from WADL is the fact it can not be used to generate what seems to be the main source of auto-generated WADL instances : JAX-RS annotated service classes. The WADL-first option will work well for the http-centric consumers but it is Java-first all the way for the JAX-RS services.
The Java-first approach to the services development has proved to be very popular and viable. However, the option of modeling web resources and generating service classes seems quite attractive too but enhancing WADL to support such an option would just basically turn it into WSDL. And this is where the dilemma is.
In meantime, a number of various approaches is being tried to create richer WADLs out of Java classes. One of those attempts is to do with extracting Java Docs for resource classes and methods and publishing them as WADL documentation fragments - it does seem like a step too far given that Java Docs are meant for the Java engineers using a given interface or class. But not for the users of Web Services backed up by such classes/interfaces.
In CXF we've added a Description annotation which is mapped to a WADL doc element and we will recommend users to use this annotation for documenting resources or methods using the language intended for the users of a given web service.
The other thing we need to think about is how we can let users do the WADL first developement. The question is how to avoid turning it into WSDL. That said, we should also probably look closer at the option of supporting WSDL2, especially for the users who do both SOAP and REST - having a single document describing both SOAP and REST may benefit them, though as far as describing RESTful services is concerned WSDL2 seems a bit limited.
Stay tuned.
Subscribe to:
Posts (Atom)
