... it's probably the only conference where there is a line for the gents toilet instead of the womens toilet... This is the  line for the gents toilet at JavaPolis in Antwerp.

Just committed the 0.6 version of the OSS/J TCK Foundation to Java.net. Highlights of this version are:

  • Support for the web services integration profile
  • Simplified configuration
The project is now also a first class citizen of the Java Enterprise Community on Java.net, it graduated from Incubator to Java Enterprise Project and is (currently) listed on the Java Enterprise Community homepage.

From now on the OSS/J TCK Foundation will be actively used by the OSS/J Order Management Expert Group to build the TCK.

One of the functionalities that OSS/J TCKs need to test for is notifications. As you might know OSS/J APIs have 3 integration profiles and notifications are supported in all three profiles. Both the EJB and XML/JMS integration profile rely on JMS Topics to sent notifications from the OSS/J Server implementation to the clients that subscribed for it. For the web services integration profile JMS Topics cannot be used, WS-Notification is used Instead. Since I did not want to implement all the nitty gritty of WS-Notification myself, I searched a bit an came across Apache Muse. Now, that was a real help. Working from the wsn-consumer and wsn-producer examples that are included in the download I was able to build the WS-Notification support into the OSS/J TCK Foundation real quick. I did run into a couple of question, but the support on the user mailing list of Muse was outstanding. Using this support, I was able to resolve questions quickly and get a working implementation in no time.

In summary: two thumbs for Apache Muse!

Yesterday I had my first hot air balloon flight,quite an experience. Maybe not exiting enough for the adrenaline junkies that like to (bungy-)jump of bridges, but if you want to have a different view on your home city a ballon flight is really nice. The flight was a present for my mom's 65th birthday and we needed a couple of volunteers to join her. Someone has got to do the dirty job... so my sister, two of my mother friends and I went up. The trip was booked at A3 Ballon and around 17:00 our pilot arrived in a van with the balloon basket on the trailer.

Getting the balloon ready to go was quite some work. The balloon itself was 25x18 meters and it required a serious fan to first fill it up with cold air and then heat up the air with the burners. Once the air in the balloon was hot enough, it lifted itself, we jumped in and our 'safety-line' attached to the van was released. Pretty impressive how fast we gained more and more height by just heating the air above us. The first sights of Woerden were really beautiful, here's the castle in the center of Woerden with the church next to it. It felt like playing Google Earth , but instead of seeing pictures of over a year old this was live. The silence up there was amazing, you don't feel the wind (since you're moving as fast as the wind), and you really feel free like a bird... with one problem, you have no clue where you're going to end up. The wind is just going to take you somewhere.... Marijn (our pilot) did bring some maps, but the only thing he's able to control is the height of the balloon.

After leaving Woerden we past Kamerik, Kockengen, Breukelen (with it's infamous Chinese Building and traffic jams), crossed Breukelen and then started to prepare for the landing. While  preparing for the touch down we  lost some height and started to touch the top  of trees, here you can see that we  were on the same height as the trees. Just before the landing we noticed a weird building just left to us . There were bars all around it and it definitely did not look like a nice place to be. The landing was perfect, one little bump and we were back on earth, two thumps up for Marijn, our pilot on this flight. Soon after we landed we learned from people passing by that the weird looking building is was the womens-only prison in Nieuwersluis, it took only  minutes before a couple of guards came out to check the situation. I wonder what would have happend if we landed on their territory...

This is the route we took (red line running from green balloon to red balloon):

Think you're done after the touch down? No way, pulling the balloon down, getting all air out of it, folding it and getting it back in the van and then finally The Ceremony, the thing we all did this trip for: because the survived the trip we wre promoted to Baron and Baroness  "from Woerden till Nieuwersluis":

  1. First we had to kneel down
  2. Then some grass was planted on our heads
  3. Using a lighter the grass was 'symbolically burned'
  4. A bottle of  the best champagne available was opened and was poured  over our head
  5. And finally we got to drink some champagne

All in all a really special happening and if you ever have a chance to join a balloon flight: do it, it's worth every penny!

If you're interested: at the A3 website there's a set of pictures of this flight.

I mentioned before that I'm working on a framework to ease development of OSS/J TCKs. One challenge for the OSS/J TCKs is that each OSS/J API exposes the same functionality via three so-called integration profiles:

  • EJB
  • XML/JMS
  • Webservices
All three profiles expose the same functionality and the TCK for a OSS/J API should validate the functionality on all three profiles. The OSS/J TCK Foundation enables TCK builders to focus on the functional tests that must be executed against each integration profile without having to worry about the plumbing needed to access one of the specific integration profiles. The OSS/J TCK Foundation provides a proxy that - depending on what type (EJB, JMS, webservices) of proxy is requested - executes the operations defined in the OSS/J API against the correct integration profile. The proxy has the same interface as the JVTXyzSession interface that is defined in the OSS/J API. The actual tests are written as unit tests and executed against the proxy. The OSS/J TCK Foundation website contains samples on how to use this.

We're currently using this OSS/J TCK Foundation to build the TCK for the OSS/J Order Management API, but it is set-up such that it can be used for building TCKs for other OSS/J APIs. During development  tests have been done against the OSS/J Service Activation and OSS/J Trouble Ticketing APIs. The OSS/J TCK Foundation contains sub projects that that illustrate the examples for OSS/J Service Activation and OSS/J Trouble Ticketing.

The current version of the OSS/J TCK Foundation has support for the EJB and XML/JMS integration profiles. Support for the webservices profile will be added next.

The what?!?

Completing the "Elfstedentocht" (dutch for Eleven Cities Tour) is the dream of every dutch guy that likes speed skating. Finishing the Elfstedentocht can be quite challanging, not only because of the distance (200 kilometers) or the fact that weather conditions can make it a rough ride.

The first hurdle to take is to become a member of the Vereniging "De Friesche Elf Steden". You can only subscribe as a member in the first half of the year and your subscription must be backed 2 two members of Vereniging "De Friesche Elf Steden" stating that you are capable of completing the tour. Because of the large number of people that want to skate the tour not all members are allowed to skate the tour. Each year in November there is draw in which the lucky ones for that year are picked. And even if you're one of the lucky 16.000, you're not sure yet. The Elfstedentocht can only be organized if  the winter is cold enough, since 1909 the tour was only organized 15 times and the last one was in 1997. With the heathing of the earth chances of participating seem to decrease as time goes by. So you need to be extremely lucky twice in the same year, and last but not least... you'd better be well prepared. The last couple of races have been relatively easy from the weather perspective, but 1963 was a real killer.

So why am I blogging about this? Well, a stumbled across a DVD of the Elfstedentocht of 1985, the Elfstedentocht fever immediately caught me. Even though it's summer at the moment. Next year it is 22 years after the tour of 1985, after the tour of 1963 it took 22 years before the next tour could be skated...the obvious difference of course being the fact that between 1985 and now the Elfstedentocht already took place twice (1986 and 1997)... so that logic doesn't really help... but hey, you've got to get your motivation for training somewhere. Someday I will complete the tour and get my Elfstedenkruisje ;-)

With JavaOne coming up there are lots of announcements, here's another one: JSR 264 Order Management is released for public review  (download).

I'm participating in this expert group for a couple of months now and it's fun. You get to work with a lot of interesting people and ... at "interesting times", the standard weekly conference call is at 06:00 AM in my timezone ;-) Feels good that the API is now for public review, we're all interested in your comments, feel free to mail them to jsr-264-comments@jcp.org. For more information regarding JSR-264 refer to https://jsr264-public.dev.java.net/nonav/jsr264/.

Next up are the TCK and RI, I'm currently doing some proof of concept work for the TCK.

Mmmm, the first post using Performancing did not go as well as I hoped. The title of the blog entry did not make it to the blog. This time I selected the MetaWeblog API as the API to be used to submit new entries to the blog (used blogger API in previous post), let's see if the title shows up now...

Till now I've been using the standard web based interface of Pebble to post entries to my Blog. Wilfred mentioned Performancing as a blog client that runs in Firefox 1.5 and can can work offline. I must say, the first impression is good... if this post ends on on my blog of course... I'll hit the publish button now!

After doing a couple of architect and design projects in which the OSS/J Service Activation API played a role, this week we had to actually define a couple of extensions to the OSS/J Service Activation XML Schema's. You learn something new everytime you do something for the first time...

The core of the problem was that we had to define and use subtypes of the abstract orderValue type which is defined in the OSS/J SA spec. Defining the sub types was not the problem, that was done in a breeze. Using them in an XML document appeared to be a challenge. This was mainly caused by the fact that the abstract orderValue is used as a element in for example createOrderByValueRequest. Some snippets might clarify the issue:

The definition of the createOrderByValueRequest is as follows:

<element name="createOrderByValueRequest">
  <complexType>
    <sequence>
      <element name="orderValue" type="sa:OrderValue"/>
    </sequence>
  </complexType>
</element>
orderValue is defined as:
<complexType name="OrderValue" abstract="true">
  <complexContent>
    <extension base="co:ManagedEntityValue">
      <sequence>
        <!-- SNIP -->
      </sequence>
    </extension>
  </complexContent>
</complexType>

Our extension to orderValue is:
<complexType name="CustomOrderValue">
  <complexContent>
    <extension base="sa:OrderValue">
      <sequence>
        <element name="somefield" type="string"/>
      </sequence>
    </extension>
  </complexContent>
</complexType>

Our initial attempt to use CustomOrder as part of createOrderByValueRequest was as follows:

<?xml version="1.0" encoding="UTF-8"?>
<sa:createOrderByValueRequest 
  xmlns="http://xyz.com/ServiceActivation"
  xmlns:co="http://java.sun.com/products/oss/xml/Common"
  xmlns:sa="http://java.sun.com/products/oss/xml/ServiceActivation"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
  xsi:schemaLocation="http://xyz.com/ServiceActivation XmlXYZServiceActivation.xsd"
  >
  <CustomOrderValue>
    <co:lastUpdateVersionNumber>1</co:lastUpdateVersionNumber>  
    <!-- SNIP -->
    <someField>bla</someField>
  </CreateVASOrderValue>
</sa:createOrderByValueRequest>
This did not work since the definition of createOrderbyValueRequest dictates that a orderValue is expected as the only subelement. Aside from that, the validator is also not able to resolve the sa:createOrderByValueRequest. We assumed this would be resolved by the xsi:schemaLocation attribute that points to the XmlXYZServiceActivation.xsd schema file which includes the imports the XmlServiceActivationSchema.xsd file containing the OSS/J SA schema.

Mmm, now what... I'll leave all the failed attempts out, but this is what worked. The changes we had to make are:

  • The xsi:schemaLocation attribute of the sa:createOrderByValueRequest now points to the OSS/J SA schema instead of our custom schema. Now the sa:createOrderByValueRequest is resolved.
  • The sub element of sa:createOrderByValueRequest now is a sa:orderValue, but using the xsi:type attribute the validator is hinted that the actual element is the CustomOrderValue sub type of the abstract OrderValue.
  • The previous point was not enough to actually resolve the CustomOrder type. In order to get that resolved an xsi:schemaLocation attribute that points to our custom schema file.
<?xml version="1.0" encoding="UTF-8"?>
<sa:createOrderByValueRequest 
  xmlns="http://xyz.com/ServiceActivation"
  xmlns:co="http://java.sun.com/products/oss/xml/Common"
  xmlns:sa="http://java.sun.com/products/oss/xml/ServiceActivation"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
  xsi:schemaLocation="http://java.sun.com/products/oss/xml/ServiceActivation XmlServiceActivationSchema.xsd"
  >
  <sa:orderValue xsi:type="CustomOrderValue" xsi:schemaLocation="http://xyz.com/ServiceActivation XmlXYZServiceActivation.xsd">
    <co:lastUpdateVersionNumber>1</co:lastUpdateVersionNumber>  
    <!-- SNIP -->
    <someField>bla</someField>
  </sa:orderValue>
</sa:createOrderByValueRequest>

Sound fine, problem resolved... however, is this The Way to tackle this problem? XML Schema seems to provide various options to tackle this problem and I'm not sure yet if this is the best way. One alternative we considered was to redefine the createOrderByValueRequest element in our custom schema, but that would in practice imply that we would be redefining the whole OSS/J SA schema in order to extend it. That's definitily not how it's intended to be. Any other options?

As of Jan 1st I switched jobs, left Sun and started at Xebia. Feels really good to be surrounded by all those experienced guys that have a passion for Java!