On a recent project I had to persist image features into a database to be used on a content-based image retrieval (CBIR) system. These features included the following:

• Color - represented as histograms for each color band; each histogram consisted of 256 float numbers.
• Shape - represented as 127 Fourier coefficients (complex numbers).
• Texture - represented as an array of the top 60 peaks locations (and sign) on a 128x128 wavelet decomposition grid; the wavelet decomposition is performed in each of the three color bands.

I normally do my modeling in terms of object orientation first. I created an ImageFeatures class which had references to other classes such as Color, Shape and Texture. Each of these classes ended up holding a primitive array of float numbers for the corresponding feature data. That's all well and good. Pretty simple stuff.

For those of you who were eagerly awaiting (who wasn't?) the approval and ratification of the JEE 5 specification, and more specifically EJB 3, here is a free book on the subject which can be downloaded from here. Hope you find it useful (at least is free!).

It remains to be seen whether JEE 5 will catch on with the developer community at-large when other (lightweight) alternatives already exist (a.k.a. Spring) that have made great strides and proven successful in terms of productivity and overall quality. There have been some threads already questioning the future of JEE in general.

In my previous blog entry I briefly mentioned a couple of lightweight remoting protocols, Hessian and Burlap, that are great alternatives when you only need to make simple remote method calls between Java processes and do not need to concern yourself with interoperability issues.

Both Hessian and Burlap have been developed and released by Caucho Technology, makers of the Resin application server. Both use HTTP as their transport mechanism. Whereas Hessian is a slim binary protocol, Burlap is a slim XML-based protocol.

On a recent project I needed to design 3-tier architecture system consisting of a rich-client application as the front-end, a middle tier J2EE-compliant server, and a database backend server. One of the design decisions that I had to make early on was how the front-end rich-client application would invoke remote methods on middle tier server components. What protocols or services would meet the project requirements?

To put everything in perspective, the proposed solution for the system, with the exception of the backend, was all Java-based. On the front-end we had an Eclipse RCP-based application, and a J2EE-compliant server sitting in the middle tier. What technologies are available to us that would allow a Java client application remotely invoke methods on server components? The alternatives that first come to mind are the following (in no particular order):

I do not have to be a melodramatic to say that Eclipse has taken the
Java development landscape by storm. Certainly during the last couple
of years Eclipse has captured the lion’s share of the Java IDE market.
Eclipse was designed from the outset to be a sort of universal tool
platform – an open, extensible integrated development environment - in
which vendors and individual tool writers could contribute various
pieces that would seamlessly integrate with other pieces. Along the way
came another thought – why not reuse the functionality provided by the
Eclipse IDE platform to create stand-alone end-user applications.