We have completed the initial CXF JAX-RS integration into the DOSGi RI.
There is a number of various approaches out there to expose a given OSGI service remotely - DOSGi is a good effort which describes how this task can be resolved in a standard way.
So now DOSGi users will be able to expose a given bean either as a SOAP or RESTful service. There will be more updates coming in shortly for a given bean be exposed as a combined SOAP/RESTful service and for properties be applied in a way which will let users easily configure a large number of services.
Now, as far as RESTful services are concerned, one can also expose them without applying JAX-RS annotations. I'm actually quite excited about this option despite the fact it kind of tries to sway you from being a good JAX-RS citizen :-). One thing is that one of the promises of DOSGi is that users should be able to expose the interfaces transparently, without forcing the knowledge of JAX-RS/etc on the remote consuming bundles. While there will be cases when having annotations is perfectly acceptable in DOSGi it is still nice to have an option to do it without annotations.
As a side note, applying the external model info to a lot of existing applications out there which are exposed as RESTful services using expensive adapters or can not afford changing the code looks really promising to me.
I would also like to thank Josh Holtzman for his contribution. More updates to follow soon.
Saturday, June 20, 2009
Monday, June 8, 2009
Pragmatic Web Services with Apache CXF
Pragmatic web services are the ones which deliver, have been written with the interoperability in mind and which can cope with inevitable changes.
Pragmatic Web Services with Apache CXF article has been published at DZone Architects Zone and it attempts to look at how changes might be dealt with the help of various CXF features. It spends little time talking about REST and SOAP though it describes how some JAX-RS extensions can help dealing with the changes.
Arguably, the example which is looked at in the article is a bit contrived in that search parameters are presented in some methods as PATH variables. One can easily come up with a more suitable example where PATH variables can be used and I thought the example served the purpose of the article really well.
There are some minor formatting and link issues with the article at the moment but hopefully the DZone team who have helped a lot in publishing this article will fix them.
Comments are welcome.
Pragmatic Web Services with Apache CXF article has been published at DZone Architects Zone and it attempts to look at how changes might be dealt with the help of various CXF features. It spends little time talking about REST and SOAP though it describes how some JAX-RS extensions can help dealing with the changes.
Arguably, the example which is looked at in the article is a bit contrived in that search parameters are presented in some methods as PATH variables. One can easily come up with a more suitable example where PATH variables can be used and I thought the example served the purpose of the article really well.
There are some minor formatting and link issues with the article at the moment but hopefully the DZone team who have helped a lot in publishing this article will fix them.
Comments are welcome.
Tuesday, June 2, 2009
The benefit of a doubt
I have read recently some thriller which has nothing to do with a "web services" topic. I don't remember now the actual details of that thriller but I read there something which I thought might be relevant.
It was something like "If you'd like to be a good doctor then you have to continue doubt everything you have already learnt or are about to learn".
I think something similar can be advised to software engineers, myself including, and to web services developers in particular. Of course, there should be some compromise there, so that one does not become a doubts 'freak' :-) and so that the doubts don't wreck the success of the project. I think "being doubtful" is the quality which no one will ask you about at the interview :-) but having some healthy pessimism is a good thing nonetheless.
It was something like "If you'd like to be a good doctor then you have to continue doubt everything you have already learnt or are about to learn".
I think something similar can be advised to software engineers, myself including, and to web services developers in particular. Of course, there should be some compromise there, so that one does not become a doubts 'freak' :-) and so that the doubts don't wreck the success of the project. I think "being doubtful" is the quality which no one will ask you about at the interview :-) but having some healthy pessimism is a good thing nonetheless.
Apache CXF passes JAX-RS 1.0 TCK
The latest 2.2.2 patch release of Apache CXF is the first one which passes a JAX-RS 1.0 TCK.
It has been a long and rocky road for the CXF JAX-RS implementation. It came quite late into the game, with JAX-RS RI (Jersey), RestEasy, Restlets being already there. Doubts like "why a SOAP stack needs a JAX-RS implementation given that SOA has a new definition now or why duplicate what other JAX-RS implementations have done" combined with the lack of resources didn't help so by the time JAX-RS 1.0 RI (Jersey) was released in the end of last September, CXF JAX-RS was still suffering from some embarrassing bugs :-).
But we hanged on and CXF users started using it and helped us to move to the stage where it was sufficient to fix some edge cases during a 5-days spell to virtually claim a JAX-RS TCK 1.0 compliance.
One might say it is not a big news given that a JAX-RS 1.0 RI (Jersey) was released in the end of last September while RestEasy announced its compliance in January.
In CXF we are still seeing this result as an accomplishment which was only possible due to the fact that users tried it and helped us to push it forward. I'd also like to thank Dan for his support from the very beginning and Jervis Liu for his initial CXF JAX-RS effort.
So in CXF we have the best JAX-WS implementation out there and the JAX-RS implementation is now live and kicking. CXF does and will help users build their SOAs - it does not claim it knows the only definition of SOA. CXF JAX-RS has some interesting extensions and we have some more exciting ones in mind.
So stay tuned and thanks a million to all those who helped and supported us.
It has been a long and rocky road for the CXF JAX-RS implementation. It came quite late into the game, with JAX-RS RI (Jersey), RestEasy, Restlets being already there. Doubts like "why a SOAP stack needs a JAX-RS implementation given that SOA has a new definition now or why duplicate what other JAX-RS implementations have done" combined with the lack of resources didn't help so by the time JAX-RS 1.0 RI (Jersey) was released in the end of last September, CXF JAX-RS was still suffering from some embarrassing bugs :-).
But we hanged on and CXF users started using it and helped us to move to the stage where it was sufficient to fix some edge cases during a 5-days spell to virtually claim a JAX-RS TCK 1.0 compliance.
One might say it is not a big news given that a JAX-RS 1.0 RI (Jersey) was released in the end of last September while RestEasy announced its compliance in January.
In CXF we are still seeing this result as an accomplishment which was only possible due to the fact that users tried it and helped us to push it forward. I'd also like to thank Dan for his support from the very beginning and Jervis Liu for his initial CXF JAX-RS effort.
So in CXF we have the best JAX-WS implementation out there and the JAX-RS implementation is now live and kicking. CXF does and will help users build their SOAs - it does not claim it knows the only definition of SOA. CXF JAX-RS has some interesting extensions and we have some more exciting ones in mind.
So stay tuned and thanks a million to all those who helped and supported us.
Subscribe to:
Posts (Atom)
