wwerner's blog

While I did not post anything here during the last year (was a pretty short year, anyway :-/), I actually did do some writing: (German) A piece on the Equinox OSGi Console, basically the same as in an earlier post here. Published in eclipse Magazin 2.11. HTML, PDF (German) Devising an RESTful architecture based on [...]

In this post, we’ll look into creating a RESTful HTTP interface using JAX-RS. We’ll see that it is pretty easy to expose ordinary java methods through HTTP.

We’ll create a trivial model of a movie database and expose it via RESTful HTTP services as JSON and XML using JAX-RS, a little JAXB, Apache CXF, maven and Spring. We’ll see that we need very little code to achieve that. This post focuses on the service front-end, the data is not persisted. We’ll add JPA based persistence in a later post.

Helios comes with an OSGi console that is accessible from the GUI directly. This reminded me of the existence of an API to add custom commands to the console. I found this to be a simple and powerful concept; yet I perceive this feature to be rarely used in practice.
With equinox being used on the server more and more, adding your own custom application management commands is a simple way to provide for executing application specific maintenance tasks. How about a command that gathers all logs, creates a heap dump, zips everything, puts it onto an FTP server and sends you the download link by mail? Or perhaps you simply want to run some sanity checks?

In this post, we’ll create a custom command for the OSGi console that simply executes a JUnit test and prints the results.

More importantly, we’ll have to snoop around in internal eclipse packages to figure out how to attach the command to the existing console. We’ll try to do our snooping effectively. And we’ll exploit the dynamic nature of OSGi to streamline our development/build/test cycle (and thats gonna be fun).

After having implemented the server application, we want to prepare ourselves for future changes. We want to be able to add new services to our application without impacting existing ones. We also may want to change the structure of the URIs in case they are not cool.

To do so, we’ll create extension points and the supporting code for the Restlet types used and contribute our implementations and see how that this helps us making our application more flexible and maintainable.

We’ll learn how to define an extension point, how to contribute to it and how to work with the contributions.

Now that we’ve implemented our greeting application, it’s time to make it more enterprisey. We can’t have it just echo any greeting, can we? We’ll need to make sure that only greetings from a predefined list can be chosen as current greeting, so we can have committees that can spend time discussing and defining greeting standards.
As we want to make our lives easier (let’s assume the committee will change it’s mind every few days or so), we’ll implement a greeting manager that can be used to edit the list of approved greetings.

Beside rants at software development for The Enterprise™, expect a short introduction of the Restlet base classes that are typically assembled into a server application.

In this series, we’ll look at creating modular and flexible server applications based on OSGi/Equinox and Restlet. The first article of this series covers the basics: It will walk you through creating a simple REST style web service using Restlet and show you how to roll it into a standalone application based on the equinox OSGi framework.

The next posts will go into how the different Restlet types can be assembled into bigger applications. We’ll then build extension points to lift the actual plumbing to a declarative level instead of hardcoding it.

We’ll see that the uniform interface proposed in the REST architectural style and the extension/extension point mechanisms in Equinox make quite a good couple.