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 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 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
  • 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:

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