Gero Vermaas on...

And since I'm one of the JSR264 Expert Group (EG) Members this is a good day for me. The JSR264 Order Management API already passed the JCP ballot on August 27th, but getting through all the processes from both the OSS/J Community and JCP does take some time....

On the Xebia blog I posted an entry that describes the core features of the Order Management (OM) API. Make sure you read that one for details and of course you can download the specification and read all details of the API. The JSR264 Java.net page is also a good source of information.

My focus area in the EG was the Technology Compatibility Kit (TCK). Each JSR delivered through the JCP process must include this TCK such that implementors of an API can validate if the API is compliant to the specification. As part of the development of the OM API I started the OSS/J TCK Foundation project on Java.net. Why?

A little background... the Order Management API is part of the OSS/J Family of APIs. This group of API has it's origin in the telecommunications world, but several of the APIs (Order Management included) can also be used outside the telecommunications domain. All OSS/J APIs follow a common set of design principles, for example: all functionality exposed by the API must be available in 3 so-called integration profiles:

• EJB
• XML/JMS
• WebServices

These integration profiles are functionally equivalent and all expose the same operations. A TCK for an OSS/J API therefore has to test the same functionality on all three integration profiles. In a perfect world you would want to write one set of tests and execute it against the three integration profiles without developing integration profiles specific code. The OSS/J TCK Foundation project makes this possible.

Using the OSS/J TCK Foundation you develop one set of tests and are coded against the interface exposed by the EJB profile. The OSS/J TCK Foundation then enables you to execute these same tests against the XML/JMS and Webservices profiles. The advantages are obvious:

• OSS/J TCK developers can focus on developing tests.
• No need to develop plumping code for XML/JMS and Webservices profiles.
• A consistent set of tests is executed on all three profiles (previous OSS/J TCKs had variations in the tests for the various integration profiles).
• The amount of effort to develop a TCK is significantly reduced.

Currently this OSS/J TCK Foundation is used by the Order Management API TCK (yes, of course I eat my own dog food) and the Fault Management API TCK (so even better, others eat it too ;-)). More OSS/J API have shown interest so I expect that it's use will increase over time.

This week I realized how important podcasts have become for me as a news source.

I'm subscribed to a number of IT related podcasts (see list in sidebar on the right of this blog) and virtually always listen to podcasts on the daily 45 minutes commute to work. Using an iTrip as the FM transmitter on my iPod enables my to listen to them using the car stereo. Very convenient, you do loose a bit of sound quality but for podcasts that is not really an issue.

I was on vacation for a couple of weeks and did not listen to podcasts during that period. After returning back to work colleagues and friends started to mention stories that I was not aware of yet and I wondered why... While listening to the backlog of podcasts I realized it: I did not use one of my main news sources for weeks, podcasts.

Examples of what I missed:

• The JavaPosse podcast announced that JSR264 Order Management passed the JCP EC ballot (as EG member I knew we passed the ballot, but was kind of surprised that the JavaPosse already picked it up).
• There is an unlock available for the iPhone (from MacCast podcast)

And I still have 20 podcasts in the backlog...

On November 7th Andreas Ebbert-Karroum, John Wilmes and myself will be presenting a session titled "Converge your Order Management" at the TelemanagementWorld conference in Dallas. The theme for this conference is "Managing Operations for Converging Services" so with our presentation we're hitting the nail on the head. In our presentation we'll explain why using the Order Management API eases order management in a converging world (and we'll also briefly touch on the SOA buzzword). After doing the presentation with Andreas and John in Nice at Telemanagement World earlier this year I'm really looking forward to Dallas. It was a lot of fun in Nice and I'm sure it will be a lot of fun in Dallas again. There will definitely be surprises again with regards to people using the Order Management API without us knowing about it (especially now that we passed the JCP ballot and will publish the 1.0 version shortly).

Since a while I'm using iPhoto to manage my photo collection. One thing that kept annoying me was that I had to do manual actions to include selected photo's from iPhoto in my webalbum. Of course you can generate webalbums from iPhoto, but you need to do that over and over again each time you want to add more pictures to your webalbum. The solution I wanted to have was:

• Import pictures into iPhoto
• Tag them with keywords
• Have them appear in my webalbum automatically
  • sorted by date
  • sorted to subject

I only need to maintain iPhoto and the rest is automatic.

I've got this working now for the sorted by date part. What I now do is:

• In iPhoto I tag the pictures that I want to appear in my webalbum with a special keyword (webalbum)
• Scheduled a cronjob that periodically:
  • Runs a ruby script sortImages.rb [note: this is an updated version of the previous script, the description in the blog post is not 100% accurate anymore] which parses the iPhoto AlbumData.xml file. This scripts selects all pictures with the 'webalbum' keyword and exports these to a directory structure in which they are sorted by year/month. (The script first checks if the AlbumData.xml is changed since the last run to prevent unnecessary work.)
  • If the ruby script sortImages.rb [see previous note] found any changes, kick of the webalbum application to update the webalbum (I'm using JAlbum, but you can use any webablum application that takes a directory structure as input).

The shell script is really simple.

ruby sortByDate.rb webalbum /tmp/webalbum '/path/to/AlbumData.xml'

if [ $? -eq 0 ]; then
cd  /opt/JAlbum
java -Xmx256M -Djava.awt.headless=true -jar JAlbum.jar
 -projectFile webalbum.jap -appendImages
fi

The sortImages.rb [see previous note] script takes 3 arguments:

• The keyword that identifies the pictures to include in the webalbum.
• The directory to which the pictures should be copied. In this directory new directories per year/month will be created.
• The path to the iPhoto AlbumData.xml file

Writing the Ruby script was easy, it was the first time i really tried to do something with Ruby and I got it done pretty quick.... although I bet there is some improvement possible. Feel free to let me know ;-) The actual tricky parts were:

• Figure out the structure of the AlbumData.xml file
• Transform the DateAsTimerInterval element from the AlbumData.xml file into the date the picture was taken.

Next plan is to create a script that generates a directory structure using the other keywords set on the pictures. For example, group all pictures tagged with 'webalbum' and 'vacataion' and 'friends'. Sounds simple, but need to come up with some logic to be able to create a multi level structure where level one contains the images with only the 'vacation' keyword, level 2 has 'vacation' and 'friends' etc. What do I do with pictures that could end up in multiple parts of the tree?

*** Update ***

I just tested if this solution still works with iPhoto '09 and it works perfectly.