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.
Subscribe to:
Posts (Atom)