Enterprise Media Beans

[ricardoarguello]

I've been working on an implementation of the Enterprise Media Beans API for JBoss.

The Enterprise Media Beans specification is discussed in the Java Specification Request 086 (JSR-86):

http://jcp.org/aboutJava/communityprocess/review/jsr086/index.html
http://jcp.org/en/jsr/detail?id=086

The Enterprise Media Beans architecture allows the integration of rich media (image, audio and video) into the J2EE programming model. This means your media could take advantage of all the capabilities of the Java2 Enterprise Edition: transactionality, security, scalability, availability, just to name a few.

The specification divides the architecture in two parts: Media Foundation Beans and Media Entity Beans.

Media Foundation Beans let you represent your media independently of its kind. It represents media in a uniform way, letting you program against interfaces representing the media and its metadata (width, height, color dept, frame rate, etc.) instead of programming against a particular media format (GIF or MPEG video for example).

You could use Media Foundation Beans to transcode from one format to another, for example to convert your GIF files to PNG (due to patent problems) when serving them from a Servlet. You could resize your media to certain needed dimensions, or add digital watermarks to the stock photographs you sell online. All these media transformations are represented with interfaces, this allows to implement transformation chains of any kind, from any media to any media.

Media formats and media converters are designed in a pluggable fashion. In my implementation I'm using Java2 1.4's new Image I/O API to represent image media (PNG, GIF and JPG) and it's metadata, but since the architecture is pluggable, anybody could implement a new TIFF media format using Image I/O and it could be used to represent that type of image with Media Foundation Beans (TIFF format is not available in Sun's Java2 Standard Edition SDK 1.4). (http://java.sun.com/j2se/1.4/docs/guide/imageio/index.html)

I could have implemented every media format available using third party libraries found on the Internet, to read media headers (mostly magic numbers) and extract metadata information by hand, but the Java2 1.4 SDK has a whole API to represent graphics (javax.imageio.*), so I decided to use it. The only problem is that I'm only representing graphics, not audio or video yet. But since the API is designed to be pluggable, new media could be more or less easily supported, depending on the availability of utility libraries to decode media formats and their metadata. One thing that is remarkable is that the javax.imageio.* formats are represented internally as an XML document. (http://java.sun.com/j2se/1.4/docs/api/javax/imageio/package-summary.html)

According to the spec, Media Entity Beans (MEB) integrate the services provided by Media Foundation Beans into the Enterprise JavaBeans architecture, adding additional services that require media persistence. That means MEBs could participate in relationships with Entity Beans in J2EE! Imagine your Emmy Awards Enterprise JavaBean System (EAWEJB) representing media clips and domain objects (Artist -> Video Clip) in a transparent "CMP style" way. No more BLOB nonsense!

I'm planning to incorporate my work into JBoss soon.

If you want to help, please post in this forum.

[greenman]

Hey!

I'm most definitely interested in helping out!

Could the JMF stuff be used to handle some of the Audio / Video stuff (on certain platforms at least)?

[ricardoarguello]

I was also thinking about the Java Media Framework (JMF) to manage video/audio metadata.

There is another graphics API, the Java Advanced Imaging (JAI). It is a much more complex API than the Image I/O one, but it allows a lot of complex media transformations.

I'll be commiting some code to the JBoss CVS server soon. I'll be glad to work with you in the video/audio metadata implementation.

[greenman]

Great. I'll start (re) reading the EMB spec, and get re-aquainted with JMF.

The last thing I used JMF for was, by happy coincidence, server-side audio transcoding. Unless things have been seriously updated, we found that there were a few funnies w.r.t certain combinations of sampling rate etc. (Nothing that a few decent tests won't catch :).

Looking forward to your check-in...

[spsa]

Ricardo ,

I am eagerly awaiting for the initial cvs commit as well.

I will let you know more about my design ideas when I see the first release, but
have you thought about wrapping the MediaFormatRegistry singleton around a ServiceMBean?

Spyridon Samothrakis

[ricardoarguello]

I'll commit my code today.

Implementing the singleton as an ServiceMBean is an excelent idea.