The auto-generation of WADL documents has been supported in CXF JAX-RS for a while. Letting users get a WADL instance and use a tool like soapUI to test a live RESTful endpoint is very useful.
Don't get distracted by the fact WADL is not favoured by some REST advocates. Being able to test a live endpoint without spending time on writing a dedicated test code is good.
CXF JAX-RS also offers a CodeGenerator filter which can be configured on test/development/POC servers for possible users being able to download the source code, compile it and start experimenting immediately. Java is just the only option there for now but of course more languages can be supported easily.
That is all fine, but one limitation there is that what is possibly the most important WADL feature, underrated at the moment, is not really utilized. WADL is very resource centric and IMHO it's a perfect language for bridging would-be RESTful application modeling tools with the actual code. I'm not referring to UML-like modeling but a more high level approach with a tool linking entities representing root resources, subresources and data and using WADL as a internal link between a specific tool data representation and a wadl2java code generator. I'm not referring to a complex WADL XML editor here.
All/most of us do Java-first development and it's kind of easy to assume that nobody will need a document-first development. But the document-first approach has its followers as it has its benefits.
CXF is all about choice, options, diversity and letting users get their web services projects done using the strategies preferred in their teams. CXF 2.4.1 offers a server side WADL-first development support - give it a try and enjoy.
Sunday, June 26, 2011
Friday, June 24, 2011
Talend joins JCP and JSR-339
This week Talend has joined Java Community Process (JCP) and JSR-339 (JAX-RS 2.0) Expert Group (EG) with myself acting as the company representative in this EG.
This is a good news for us working on Apache CXF as it's another vote of confidence from Talend in CXF continuing positioning itself as the best-of-breed web services framework for developing WS and REST compliant and robust service endpoints and consumers which just work.
Talend has a history of supporting open source projects and communities. Joining JCP and supporting JAX-RS 2.0 specification is another step in that direction, simply because JAX-RS 2.0 will become important for Apache CXF users building RESTful services.
Another reason is that Talend has a lot of experience in data-integration technologies. Talend tooling is powerful and impressive which will be a subject of another post. REST and data are good matches. Many interesting opportunities will arise for exposing data as RESTful endpoints, letting people search and link to the data of interest. It's natural Talend would like to get involved in JAX-RS 2.0.
See this blog entry for more information.
This is a good news for us working on Apache CXF as it's another vote of confidence from Talend in CXF continuing positioning itself as the best-of-breed web services framework for developing WS and REST compliant and robust service endpoints and consumers which just work.
Talend has a history of supporting open source projects and communities. Joining JCP and supporting JAX-RS 2.0 specification is another step in that direction, simply because JAX-RS 2.0 will become important for Apache CXF users building RESTful services.
Another reason is that Talend has a lot of experience in data-integration technologies. Talend tooling is powerful and impressive which will be a subject of another post. REST and data are good matches. Many interesting opportunities will arise for exposing data as RESTful endpoints, letting people search and link to the data of interest. It's natural Talend would like to get involved in JAX-RS 2.0.
See this blog entry for more information.
Thursday, June 16, 2011
Failover support for CXF JAX-RS clients
You may recall all those discussions about "RESTful services can be consumed from browsers by humans only" statements. It was awhile back and of course it's been proven since then that it's possible to write a sophisticated client code consuming RESTful services in a number of ways.
In JAX-RS land, Paul Santoz innovated with introducing the fluent API with all/most JAX-RS stacks having custom implementations, and this API is now being standardized by JSR-339 expert group. Proxy based API is also supported by some stacks.
What is important to realize now is that JAX-RS client runtimes need to become more robust and sophisticated in order to move further, beyond supporting the assertion that "yes, we can do it, we can write the client code for working with RESTful services".
A human working with the browser has more space as far as time and decision making is concerned, when facing a connection failure for example. On the other hand, the code needs to be smarter and ready if the expectations that it does not exit immediately after a connection has become slow, broken or a target endpoint has been recycled is to be met.
This is where a failover feature comes in and it's been supported for CXF JAX-WS clients for a long time. Starting from CXF 2.4.1 it's also the case for CXF JAX-RS clients.
Please check this page for more info, experiment and provide the feedback.
It also confirms that in CXF we are committed to bringing the best support for developing SOAP and REST services. SOAP and REST developers have their 'differences' :-) but we understand them, bring both 'camps' together, and do our best to support them at the framework level.
As a side note, if you think about it, making clients failover-capable is a cheap way toward ensuring something close to 24-7 up time. If you are Amazon or BBC then you have all the hardware and experience in place to ensure the clients nearly never experience a "can't connect" problem. What if you are running an OSGI container hosting service endpoints and need to replace a service ?
Failover-enabling clients is a simple way toward making service endpoints replaceable without affecting the critical client code being executed somewhere. Configuring a CXF failover feature with a small timeout between retries will do the trick really well.
One thing which is really exciting for me is that my Talend colleagues are already working on providing enterprise-level failover-like features for CXF JAX-RS clients and I'm going to talk about it in one of the future posts.
If you have already integrated CXF JAX-RS in your higher-level product then I'd encourage you to follow Talend's lead.
In JAX-RS land, Paul Santoz innovated with introducing the fluent API with all/most JAX-RS stacks having custom implementations, and this API is now being standardized by JSR-339 expert group. Proxy based API is also supported by some stacks.
What is important to realize now is that JAX-RS client runtimes need to become more robust and sophisticated in order to move further, beyond supporting the assertion that "yes, we can do it, we can write the client code for working with RESTful services".
A human working with the browser has more space as far as time and decision making is concerned, when facing a connection failure for example. On the other hand, the code needs to be smarter and ready if the expectations that it does not exit immediately after a connection has become slow, broken or a target endpoint has been recycled is to be met.
This is where a failover feature comes in and it's been supported for CXF JAX-WS clients for a long time. Starting from CXF 2.4.1 it's also the case for CXF JAX-RS clients.
Please check this page for more info, experiment and provide the feedback.
It also confirms that in CXF we are committed to bringing the best support for developing SOAP and REST services. SOAP and REST developers have their 'differences' :-) but we understand them, bring both 'camps' together, and do our best to support them at the framework level.
As a side note, if you think about it, making clients failover-capable is a cheap way toward ensuring something close to 24-7 up time. If you are Amazon or BBC then you have all the hardware and experience in place to ensure the clients nearly never experience a "can't connect" problem. What if you are running an OSGI container hosting service endpoints and need to replace a service ?
Failover-enabling clients is a simple way toward making service endpoints replaceable without affecting the critical client code being executed somewhere. Configuring a CXF failover feature with a small timeout between retries will do the trick really well.
One thing which is really exciting for me is that my Talend colleagues are already working on providing enterprise-level failover-like features for CXF JAX-RS clients and I'm going to talk about it in one of the future posts.
If you have already integrated CXF JAX-RS in your higher-level product then I'd encourage you to follow Talend's lead.
Monday, June 6, 2011
Learn about major Apache projects with Talend
Talend Application Integration Division team is working on organizing 1 or 2 day courses designed to provide developers with free, hands-on training on Apache CXF, Apache Karaf, Apache Camel and Apache ActiveMQ projects.
Talend will organize the training days in locations where a reasonable number of people can attend.
Please take this 5 min survey and start looking forward to meeting Talend in your local area :)
Talend will organize the training days in locations where a reasonable number of people can attend.
Please take this 5 min survey and start looking forward to meeting Talend in your local area :)
Subscribe to:
Posts (Atom)
