The screen-cast showing how to create a basic DB browser within Talend Open Studio is now available on the Talend Channel.
This presentation is more involved than the one showing how to create a simple REST endpoint. This time a basic database containing a list of customer records is exposed via HTTP and we go through a number of steps showing how the task of creating an arbitrary DB browser can be approached.
Initially the complete list of records is returned and then the optimized one containing smaller records but with links pointing back to complete individual records is returned.
What are we going to present next is the job which also supports the various data updates with a bit more complex database involved. Some options for dealing with exceptions will be shown. I haven't mentioned that JSON is also supported by default so we'll show the way it is supported out of the box too.
As I've already mentioned before our REST Tooling project is an ongoing effort and there will be quite a few things enhanced and improved over the near future. We are brainstorming with my colleagues various ideas such as how to make it feasible to bind the data to views in the most transparent way, how to secure the services, how to make the integration with other Talend components more complete, etc.
So I expect us producing quite a few exciting demos over the time :-)
In meantime, please view the presentation and provide us with the feedback.
Tuesday, February 14, 2012
Tuesday, February 7, 2012
Distributed OSGi RI 1.3 is out!
The signs are that the fortunes of Distributed OSGI are looking good.
Distributed OSGI RI based on Apache CXF (Apache CXF DOSGi RI) has been around for a while, and quite a few OSGI developers have experimented with and built custom applications on top of it successfully.
However, it's been more than a year since DOSGi RI 1.2 has been released and this project has been inactive recently. In meantime, two more Distributed OSGi implementations have been announced by two OSGI heavyweights, one by my colleague JB, and another one by Guillaume Nodet.
Now, as far as Apache CXF DOSGi RI is concerned, we are seeing users asking the questions quite regularly and this is a sign this implementation and the whole idea of the Distribured OSGI is of interest to some OSGI developers, more on it below.
So after getting some of issues reported against DOSGi RI 1.2 for the last couple of months, we have released Apache CXF DOSGi 1.3. Please see the release notes for more information (note there is a minor typo in the release notes, it is CXF 2.5.2 which this release is based upon, not CXF 2.5.1).
The major improvement in this release is that it is now possible to register custom CXF interceptors (pre-configured if needed) as service properties with the underlying JAX-WS and JAX-RS frontends.
WSDL-first approach is also supported now which is a good news for SOAP developers, see this project for an example. Of course, the JAX-RS frontend was trying to offer something similar :-), so a new org.apache.cxf.rs.wadl.location property has been added. Please see this updated page for more information on all the new properties.
If you are an existing user of the DOSGI RI then please try this new release.
If you have never tried it and wonder what is the story with DOSGI then try it too. DOSGI RI is quite sophisticated in that not only the basic endpoint and consumer creation is supported but also a mechanism for the distributed discovery is wired in.
But it is this fact that the OSGI programming model is used to drive the creation of the web service endpoints and consumers which is appealing to some developers and that is what one should focus upon first when experimenting with DOSGi.
If you think about it, the way to create a new web service endpoint or stop the old one in OSGI is typically to deploy a new bundle or stop the existing one from the shell or possibly from the UI management console. I guess it is quite rare that the custom application bundle will deal with updating the bundles itself.
In DOSGI, the creation if web services endpoints and consumers is actively driven by the typical OSGI BundleContext and ServiceTracker calls. If this style of managing the web services indirectly by the custom application registering or looking for OSGI services does appeal to you then DOSGI could become a perfect fit for your project.
In DOSGI 1.3 we fixed some basic blockers to get the project active again. The future releases will likely focus on making the distributed discovery working really well and also on improving the way the custom configuration can be applied.
One more thing which I'd like to mention is that if you are interested in OSGI in general and possibly in DOSGi and looking for a way to get involved in the open-source project and make a difference then please think of contributing to this project.
Distributed OSGI RI based on Apache CXF (Apache CXF DOSGi RI) has been around for a while, and quite a few OSGI developers have experimented with and built custom applications on top of it successfully.
However, it's been more than a year since DOSGi RI 1.2 has been released and this project has been inactive recently. In meantime, two more Distributed OSGi implementations have been announced by two OSGI heavyweights, one by my colleague JB, and another one by Guillaume Nodet.
Now, as far as Apache CXF DOSGi RI is concerned, we are seeing users asking the questions quite regularly and this is a sign this implementation and the whole idea of the Distribured OSGI is of interest to some OSGI developers, more on it below.
So after getting some of issues reported against DOSGi RI 1.2 for the last couple of months, we have released Apache CXF DOSGi 1.3. Please see the release notes for more information (note there is a minor typo in the release notes, it is CXF 2.5.2 which this release is based upon, not CXF 2.5.1).
The major improvement in this release is that it is now possible to register custom CXF interceptors (pre-configured if needed) as service properties with the underlying JAX-WS and JAX-RS frontends.
WSDL-first approach is also supported now which is a good news for SOAP developers, see this project for an example. Of course, the JAX-RS frontend was trying to offer something similar :-), so a new org.apache.cxf.rs.wadl.location property has been added. Please see this updated page for more information on all the new properties.
If you are an existing user of the DOSGI RI then please try this new release.
If you have never tried it and wonder what is the story with DOSGI then try it too. DOSGI RI is quite sophisticated in that not only the basic endpoint and consumer creation is supported but also a mechanism for the distributed discovery is wired in.
But it is this fact that the OSGI programming model is used to drive the creation of the web service endpoints and consumers which is appealing to some developers and that is what one should focus upon first when experimenting with DOSGi.
If you think about it, the way to create a new web service endpoint or stop the old one in OSGI is typically to deploy a new bundle or stop the existing one from the shell or possibly from the UI management console. I guess it is quite rare that the custom application bundle will deal with updating the bundles itself.
In DOSGI, the creation if web services endpoints and consumers is actively driven by the typical OSGI BundleContext and ServiceTracker calls. If this style of managing the web services indirectly by the custom application registering or looking for OSGI services does appeal to you then DOSGI could become a perfect fit for your project.
In DOSGI 1.3 we fixed some basic blockers to get the project active again. The future releases will likely focus on making the distributed discovery working really well and also on improving the way the custom configuration can be applied.
One more thing which I'd like to mention is that if you are interested in OSGI in general and possibly in DOSGi and looking for a way to get involved in the open-source project and make a difference then please think of contributing to this project.
Monday, January 30, 2012
OAuth without the end user explained
One is the most confusing things in OAuth is a so-called 2-leg OAuth flow where an explicit authorization step involving the end user pressing an Allow or Deny button is not taken.
There are many resources on the web explaining what is an OAuth 2-leg flow. Most of those explanations are effectively describing the process where the 3rd party consumer accesses its own space on the resource server, possibly with the end user itself 'hiding' behind such a consumer.
But the classical OAuth is about the 3rd party consumer being able to access one way or another the resources of the end user. How does a 2-leg flow gets into the picture ?
Please read this blog entry. This is the best explanation I've seen so far and it was so good I had to stop doing my current task immediately and quickly update the CXF OAuth 1.0 code to be able to handle all the variations of the 2-leg flows better.
I think this 'pure' 2-leg flow described by Andrew is really close to a client credentials flow in OAuth 2.0. Without a pre-authorized access token (authorization code) the options are limited for a 2-leg flow.
Please see the updated documentation for more information on how CXF supports OAuth and its 2-leg flows in particular.
There are many resources on the web explaining what is an OAuth 2-leg flow. Most of those explanations are effectively describing the process where the 3rd party consumer accesses its own space on the resource server, possibly with the end user itself 'hiding' behind such a consumer.
But the classical OAuth is about the 3rd party consumer being able to access one way or another the resources of the end user. How does a 2-leg flow gets into the picture ?
Please read this blog entry. This is the best explanation I've seen so far and it was so good I had to stop doing my current task immediately and quickly update the CXF OAuth 1.0 code to be able to handle all the variations of the 2-leg flows better.
I think this 'pure' 2-leg flow described by Andrew is really close to a client credentials flow in OAuth 2.0. Without a pre-authorized access token (authorization code) the options are limited for a 2-leg flow.
Please see the updated documentation for more information on how CXF supports OAuth and its 2-leg flows in particular.
Thursday, January 26, 2012
Make your Application Server CXF JAX-RS friendly
Now and then I'm seeing users reporting issues on the forums to do with deploying web applications with CXF JAX-RS libraries into some of the popular Java EE application servers.
So I thought, while investigating a problem reported on the CXF users list to do with using a CXF Redirection feature in WebLogic, that it was also worth giving it a try and experimenting with deploying a complete OAuth demo web application packaged as a war archive that we are working upon into several popular application servers.
Initially I focused on testing Glassfish, JBoss and WebLogic and you can see the notes on how to overcome various deployment issues here.
It was a rather interesting exercise and I had few observations at a time.
WebLogic was the simplest to work with, as far as deploying the application was concerned without having to tweak anything at the container level. The management console of WebLogic is quite sophisticated and seems like this application server is still very capable. I only had to tweak the servlet configuration to get a CXFServlet using a wildcard URI pattern redirecting to WebLogic specific JSP engine properly as advised by the user who reported the issue.
Glassfish is OSGI-enabled and it was interesting to see Apache Felix serving as the default OSGI framework, which is a good news for the OSGI community at large, as it should drive the fixes back to this Apache project.
I had hard time though getting past the Jersey filter trying to deal with this application - it was failing eventually due to it not able to inject a CXF-specific JAX-RS Context instance. I only managed to get it work after removing one of Jersey jars from the available libs - one would only have to do it or may be something simpler :-) if the war has JAX-RS Application implementations and the OAuth demo has 5.
JBoss 7 was easy enough to deploy to. RestEasy also tries to load Applications but it was much easier to deal with it in JBoss. As a side note I thought the way JBoss 7 managed to move away from having to dump all the libs into common folders was very impressive. It is somewhat similar to the Apache Karaf's features mechanism, with Karaf having the repository of libraries and features linking those libraries together. In JBoss the repository itself has some additional metadata.
One thing I thought about after finishing this exercise was that the fact that the deployed applications are eagerly scanned for JAX-RS interfaces exposes a possible issue with these scanners. And the issue is that these scanners need to check if a deployed war contains a /META-INF/services/javax.ws.rs.ext.RuntimeDelegate resource or not and if it points to some alternative implementation then just leave this web application alone.
It would make it simpler not only for CXF JAX-RS users who may want to work with Glassfish or JBoss but for Jersey and RestEasy users too who may want to try the containers where either of this popular implementations is not natively supported. Besides, it would meet the general expectation that a self-contained war should be deployable to any Java EE container.
In meantime, please consider contributing the tips to this section. The tips in the WebLogic section have been provided on the CXF users list, so please keep them coming.
So I thought, while investigating a problem reported on the CXF users list to do with using a CXF Redirection feature in WebLogic, that it was also worth giving it a try and experimenting with deploying a complete OAuth demo web application packaged as a war archive that we are working upon into several popular application servers.
Initially I focused on testing Glassfish, JBoss and WebLogic and you can see the notes on how to overcome various deployment issues here.
It was a rather interesting exercise and I had few observations at a time.
WebLogic was the simplest to work with, as far as deploying the application was concerned without having to tweak anything at the container level. The management console of WebLogic is quite sophisticated and seems like this application server is still very capable. I only had to tweak the servlet configuration to get a CXFServlet using a wildcard URI pattern redirecting to WebLogic specific JSP engine properly as advised by the user who reported the issue.
Glassfish is OSGI-enabled and it was interesting to see Apache Felix serving as the default OSGI framework, which is a good news for the OSGI community at large, as it should drive the fixes back to this Apache project.
I had hard time though getting past the Jersey filter trying to deal with this application - it was failing eventually due to it not able to inject a CXF-specific JAX-RS Context instance. I only managed to get it work after removing one of Jersey jars from the available libs - one would only have to do it or may be something simpler :-) if the war has JAX-RS Application implementations and the OAuth demo has 5.
JBoss 7 was easy enough to deploy to. RestEasy also tries to load Applications but it was much easier to deal with it in JBoss. As a side note I thought the way JBoss 7 managed to move away from having to dump all the libs into common folders was very impressive. It is somewhat similar to the Apache Karaf's features mechanism, with Karaf having the repository of libraries and features linking those libraries together. In JBoss the repository itself has some additional metadata.
One thing I thought about after finishing this exercise was that the fact that the deployed applications are eagerly scanned for JAX-RS interfaces exposes a possible issue with these scanners. And the issue is that these scanners need to check if a deployed war contains a /META-INF/services/javax.ws.rs.ext.RuntimeDelegate resource or not and if it points to some alternative implementation then just leave this web application alone.
It would make it simpler not only for CXF JAX-RS users who may want to work with Glassfish or JBoss but for Jersey and RestEasy users too who may want to try the containers where either of this popular implementations is not natively supported. Besides, it would meet the general expectation that a self-contained war should be deployable to any Java EE container.
In meantime, please consider contributing the tips to this section. The tips in the WebLogic section have been provided on the CXF users list, so please keep them coming.
Friday, January 20, 2012
CORS Support in CXF
Cross-Origin Resource Sharing (CORS) is a W3C specification (Working Draft) which "defines a mechanism to enable client-side cross-origin requests". Please see the Introduction for more information.
We had several users asking questions about how CORS could possibly be supported in CXF. Then at some point of time a mysterious :-) sergkorney offered his help with prototyping an initial code for a CORS filter, and the process moved forward.
Benson took charge and wrote a comprehensive and well-documented filter implementation which follows the specification very closely.
This filter can do the preflight and simple request checks. It interacts with the JAX-RS runtime by relying on its selection algorithm to confirm that an application has a resource method which is capable of dealing with the current request in cases when the filter does not block. If a JAX-RS resource method which can handle the HTTP OPTIONS verb indicates via a dedicated annotation that it will handle the preflight check, then the filter will delegate to it. JAX-RS root resources and individual methods can be customized for them to take part in the CORS process.
It is likely to grow into a more complex security feature in time.
Please review this initial documentation (with the link to the package.html), start experimenting and provide the feedback.
We had several users asking questions about how CORS could possibly be supported in CXF. Then at some point of time a mysterious :-) sergkorney offered his help with prototyping an initial code for a CORS filter, and the process moved forward.
Benson took charge and wrote a comprehensive and well-documented filter implementation which follows the specification very closely.
This filter can do the preflight and simple request checks. It interacts with the JAX-RS runtime by relying on its selection algorithm to confirm that an application has a resource method which is capable of dealing with the current request in cases when the filter does not block. If a JAX-RS resource method which can handle the HTTP OPTIONS verb indicates via a dedicated annotation that it will handle the preflight check, then the filter will delegate to it. JAX-RS root resources and individual methods can be customized for them to take part in the CORS process.
It is likely to grow into a more complex security feature in time.
Please review this initial documentation (with the link to the package.html), start experimenting and provide the feedback.
Wednesday, January 11, 2012
RESTful endpoint in 60 seconds in Talend Open Studio
I briefly mentioned in the end of this post that we are working on the tooling for creating RESTful endpoints in Talend Open Studio for ESB.
I'd like to offer to your attention my first screen-cast available on the Talend Channel. It shows how one create and test a basic HTTP Service endpoint echoing the POST payload back to the client. I timed it all for some fun, so it actually did took me 60 seconds to create a service and about 60 seconds to test it.
Of course one would spend much more time on developing a more involved service but the idea was to give you a glimpse of how easy you can create a RESTful service as well as to point to the flexibility of the tooling as far as wiring the extra components in is concerned.
Future presentations will show how to create more involved services, those supporting multiple HTTP verbs, with more components facilitating the access to the real data.
Please listen to this short presentation, download the Studio and try creating your own HTTP service and also check what it offers with respect to working with SOAP services and Camel routes.
Oh yes, one more thing, if you are into languages and you'd like to hear what an Irish-Belorussian accent is about :-), then please listen indeed to this screen-cast
Enjoy !
I'd like to offer to your attention my first screen-cast available on the Talend Channel. It shows how one create and test a basic HTTP Service endpoint echoing the POST payload back to the client. I timed it all for some fun, so it actually did took me 60 seconds to create a service and about 60 seconds to test it.
Of course one would spend much more time on developing a more involved service but the idea was to give you a glimpse of how easy you can create a RESTful service as well as to point to the flexibility of the tooling as far as wiring the extra components in is concerned.
Future presentations will show how to create more involved services, those supporting multiple HTTP verbs, with more components facilitating the access to the real data.
Please listen to this short presentation, download the Studio and try creating your own HTTP service and also check what it offers with respect to working with SOAP services and Camel routes.
Oh yes, one more thing, if you are into languages and you'd like to hear what an Irish-Belorussian accent is about :-), then please listen indeed to this screen-cast
Enjoy !
Friday, January 6, 2012
Maven archetype for creating CXF JAX-RS applications
A number of Maven plugins that CXF JAX-RS users could try for generating the initial code they could build upon for creating working applications was close to zero not too long ago, in fact it was actually 0.
Then we added a wadl2java plugin so the numbers started to look better :-).
And now starting from CXF 2.5.1 an archetype plugin for creating Spring-based JAX-RS applications is also available, all thanks to Benson.
Please see this page for more information.
The generated project will get the integration tests running too, so having a simple end-to-end application created and tested in less than a minute is really cool.
Then we added a wadl2java plugin so the numbers started to look better :-).
And now starting from CXF 2.5.1 an archetype plugin for creating Spring-based JAX-RS applications is also available, all thanks to Benson.
Please see this page for more information.
The generated project will get the integration tests running too, so having a simple end-to-end application created and tested in less than a minute is really cool.
Subscribe to:
Posts (Atom)
