Fabrizio Giudici is a Senior Java Architect with a long Java experience in the industrial field. He runs Tidalwave, his own consultancy company, and has contributed to Java success stories in a number of fields, including Formula One. Fabrizio often appears as a speaker at international Java conferences such as JavaOne and Devoxx and is member of JUG Milano and the NetBeans Dream Team. Fabrizio is a DZone MVB and is not an employee of DZone and has posted 67 posts at DZone. You can read more from them at their website. View Full User Profile

Designing APIs on the NetBeans Platform (Part 0): The Metadata API

  • submit to reddit

With this article I'm starting a new series of posts about the NetBeans Platform. It's about how I designed (and am still designing) a specific API of the blueMarine project that is completely self-contained (thus it's a good matter for teaching) and thought through in the context of a highly modular concept. This series will go in parallel with the one about "Idioms for the NetBeans Platform" and, of course, it's complementary to it. I will deal with the NetBeans Platform, but many things could be probably reused outside of it. Also, we're talking about design which is a general topic.

For the record, the whole API sources can be downloaded:

svn co https://bluemarine.dev.java.net/svn/bluemarine/trunk/src/Metadata --username guest

The most up-to-date javadoc (automatically created by Hudson) is available at https://bluemarine.dev.java.net/nonav/javadoc/Metadata/it-tidalwave-metadata/index.html

The project is managed by CI (http://www.tidalwave.it/hudson/job/blueMarine%20Metadata%20-%20nightly%20build/) and it has got a good coverage (70+% at the moment) so it is ready for inclusion in other's projects.

To keep this first post simple, today I'm just introducing the API and its specifications and describing the first class.

blueMarine is, among other things, a DAM - a Digital Asset Manager, which includes the capability of manipulating metadata. Manipulating means to extract them from files and eventually store them into a database for fast queries. Please note that "eventually": the idea is that blueMarine is not only a desktop application, but also a set of modules that can be recomposed and uses or other purposes (for instance, blueOcean is a server side version of it); requirements can be different in various scenarios and the database might be in or out. Also, the database could be a traditional RDBMS or "something else". 

Also, there are many different kinds of data to manage. blueMarine started with photos (= rasterized still images), but the incubator contains support for PDF files and some types of movies; in future more types will be added, such as sounds and possibly vectorial images. To keep the design general, the Metadata API (but indeed the whole blueMarine) doesn't depend on a specific class, but just on the generic DataObject that comes from the NetBeans Platform API (DataSystems API). A DataObject represents a datum described by a file (or a set of files) with an associated MIME Type: it's right the kind of abstraction I need.

Given the wide gamma of media types that can be supported, we have many different metadata types. For instance, photos have got EXIF, TIFF, IPTC, plus some proprietary stuff (metadata for the "camera raw" formats). PDF files and movies have different metadata. Since the thing must be modular, in some usages I might want to support all the metadata types, in others only a subset. This means that also the support for a specific kind of metadata must be modular, that is it needs to be implemented in a self-contained module that can be added or not to the project. Since beans binding is a good thing, the Metadata API requires that each metadata item is modeled by a fully featured JavaBean, that is a class with getters and setters and property change support. Furthermore, the Metadata API should accomodate existing implementations from third-party libraries (e.g. an EXIF class), thus it must be possible to automatically add support for properties if the original library lacks it.

This is a rough but decent picture of the requirements; we can now briefly introduce the first classes of the API.

Published at DZone with permission of Fabrizio Giudici, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)