Adam T's blog: Life in the FAST lane

I've added in some new features and fixed some bugs based on feedback and some new developments in Andrew's BPEL2SVG library. Existing users will have to modify their preferences table (see the Quick Install Guide for the relevant SQL).

From a layout point of view, you can now choose not to show assignment activities in automatically generated SVG, which means your display is less cluttered. You can also choose to scale the entire SVG so that it fits into the (too small?) frame that contains it. At some point in the future, I want to get rid of the frame entirely but it's not a trivial task; it would necessitate a move to the XHTML standard which the JMaki toolkit I'm using doesn't adhere to.

In-flight instances now show up, and the model automatically refreshes every 5 seconds so you can monitor a long-running process much more easily than before.

If you're upgrading from a previous version, you should only need to modify the preferences DB table and install a new BPMonitor.war file to get going. Again, the pieces are available from the wiki page.

The most requested feature by far for the BP Monitor is for it to automatically generate the SVG models. It's not very hard to build them using Inkscape but this is a good fallback option.

Andrew has built a library which will generate SVG which can be used in the monitor. I added in a preferences screen so you can control the orientation and a couple of other parameters associated with the diagram, and you can grab the bits you need from the wiki. The opacity setting is currently not working; when Andrew is back from holiday we'll get that fixed. It shouldn't cause any problems as the defaults are usable. I also need to hassle him to stop using PNGs for the activity icons and use SVG instead, and I'd like some additional options for controlling the layout (e.g. omit "assign activities"). You can help by leaving comments on his blog ;-)

If you have an existing installation of the monitor, upgrading is easy. Deploy the two webapps, and add the database table and data for preferences support. That should be all you need.

It's now in a position where it's usable as a demonstrator. I would have had this out at the end of last week, but the resulting webapp was marginally larger than the upload limit for the blog and I've had to find another home for it.

Graphical Business Process Monitoring

Feel free to download an have a play with it. I should say that this comes without support or warranty of any kind and usage is strictly at your own risk.

For the last week, I've been looking into ways to expose business process monitoring in GlassFish ESB in a way that makes more sense to a business analyst, rather than the person who actually implemented the process. There's a broad spread of technical interfaces available but options for graphical views are more limited.

Let's take an example BPEL 2.0 process which crops up often in demos and tutorials: the loan application. Here's the BPEL model I came up with:

You can figure out the flow here fairly easily - but you have to think about it and trace through the steps. From a high level, there's a lot here that you're not interested in and have to mentally filter out. All you really care about are the invoke statements, and the overall flow (in this case, which branch of the if statement it took).

Here's an SVG model of the pieces I'm interested in, modeled using Inkscape. The trick now is to marry this to the BPEL monitoring API and for this I've chosen to build a web application using jMaki.

Here's the a screenshot of the resulting application:

What's happening behind the scenes is that for an activity instance in the monitoring database, we look for an SVG element with the same name as the BPEL activity and modify the attribute so that it's either opaque (successfully processed) or translucent (not yet processed). This can be extended to show other states, such as in progress or to indicate an error.

There are numerous advantages for using SVG models:

• Easy to create
• The SVG model can be as abstract as you want
• Can look very nice!
• Support for animations
• Easy to manipulate programatically
• Potential to be interactive

So far I only have a prototype and I'm looking for feedback to see if this is could be useful to anyone. Leave a comment and let me know!

Most of the time, our software customers are pretty confident that the data their receiving from partners is safe. Or maybe just don't think it's a big enough risk - and almost always, they're right. But the other day a question came to me from a pre-sales guy: can we use virus scanners on received data?^* Hmmm. I'd not really thought about it before.

Curiosity piqued, I had a quick look at the plethora of anti-virus products available (well, Google did most of the work) but couldn't find one with a Java API. I'm sure such a thing exists, but no big deal. I'll do it myself.

ClamAV is a free, cross-platform virus scanner and a TCP/IP interface which is marvelously simple to take advantage of. Since my daily job involves using OpenESB and related technologies I chose to use this to knock together a quick web service to wrap it. After I'd proven that worked, I also wrote a small composite application which accepts HTTP POSTs, calls the virus scanner and let's you know if it's good or bad. If it's good, it'll also write it out to a file.

OK, so it's pretty trivial but it's a nice demonstration of how easy this was to do with OpenESB.

Project downloads and instructions are available for your perusal at the Java CAPS Grok wiki

^*Yes, no problem

Thanks to everyone for your interest - it caught me by surprise! I was on vacation last week, so I'm sorry that there's been no further news until today.

What's been built so far is only a technical proof and has some severe limitations as it was hacked together quite quickly. I was always expecting to re-write it properly and some of the suggestions in the comments are helping me direct the architecture into a more open and flexible way than I had originally intended.

One particular point that I must stress is that it is not my intention to completely cover the JMS API. Simplicity of use is the key motivator; anything that requires the user to think in a JMS way instead of interacting with the files and directories is likely to be excluded from the implementation. Of course, once the source is published then anyone is free to add whatever they like.

Some features which I've not really mentioned yet but I'm planning to build are:

• JMS Headers. Should map nicely into extended filesystem attributes. This may also enable the equivalent of message selectors.
• Pluggable JMS providers. My initial plan was to support SunMQ and OpenMQ. Clearly, there's demand for other providers too so the architecture will be open to this. However, successful implementation of, say, ActiveMQ depends on the richness of the APIs outside the JMS specification (e.g. fetching a list of queue names, creating durable queues).

Some things don't seem to map very well to the filesystem metaphor:

• Transactions. I don't currently see a "clean" way to implement them that would be natural to a filesystem user (although I'm open to suggestions).
• Request-reply. Done in the traditional JMS way, a temporary queue is generated automatically during the request and the reply is read from this queue. Synchronous messaging like this doesn't fit a filsystem model. However, we could probably emulate this by setting the JMSReplyTo header when creating the file (extended FS attribute). The reply would go onto a temporary queue with that name and the client would simply poll for it asynchronously.
• Queues vs Topics. This is an important one. When reading from a destination, it doesn't really matter if it's a queue or topic. However, when creating a new destination you would have to specify the type. How can we do this, when at best you have the "mkdir" command?

One other issue which came up is in-place editing of files. There's no reason for a user not to open a file in their favourite editor. There are a number of side-effects of this. For instance, the editor will commonly create a temporary file in the same directory for undo/recovery purposes. Obviously we don't want these transmitted to the remote server. Nor do we want the messages to be sent each time we hit the save button!

Hopefully you can see that some thought is being put into this... I'll keep you posted as things progress.

p.s. Keep coming up with project name suggestions!

Just once in a while, you have this idea that makes you think - wow, that would be cool. I had one of those a couple of weeks ago and when I spoke to other people about it, they had the same reaction. The idea is simple. Create a pseudo-filesystem on top of JMS. After 2 or three days of huddling over my desk I had a working prototype based on the FUSE and FUSE-J projects.

So far, you can do the following:

• Mount a JMS server at a specified directory
• The queues on the server become subdirectories
• ls -l on a queue shows the current queue depth
• mkdir and rmdir create and delete queues
• The messages become files in the subdirectories
• ls -l on a message shows it's size, and the creation date
• You can "cat" any message (or open it in an editor) to show it's contents - non-destructive!
• You can copy a message to a real filesystem
• You can delete messages
• You can copy files to a queue and they are published as messages

Essentially, you are interacting with a queue exactly as you would a filesystem.

There seem to be a lot of benefits in this:

• With a minimal footprint, a partner or remote office can send you messages over JMS, if they know how to copy files (even my dad could do this)*.
• If you're already doing file-based integration, there are no code changes necessary to send or receive data.
• You get all the failover and clustering aspects of JMS "for free".
• Monitoring of a server becomes trivial. Removing (or even changing) bad messages is a no-brainer.

Here's a screenshot. You can't tell that these are messages on a queue, can you? ;-)

Would any of you people out there in internetland be interested in seeing this? I'm considering making it an open source project on java.net very soon but the name "JMSFS" seems a little dull; feel free to suggest something else!

* After two hours on the phone this evening providing family tech support, I realise I might have been stretching the truth with this point.

A few days agao, I mentioned the VirtualBox disk image I had created for the mSOA reference architecture, and that falling back to Fedora 8 seemed to have fixed the intermittent freezing issues I had been experiencing.

It seems that when I gave the image to Dave to do some testing, he was getting the same problem. So there may be an issue with Fedora (or probably the kernel) when under load, and running inside VirtualBox.

Clearly if it's working for me but not for him (and we have identical laptops, by the way) then our configurations are different somehow. And sure enough, once I had him change his VirtualBox settings as shown in the following screenshot, it all seems to be working much better.

I've just put the finishing touches to the VirtualBox disk image which will form release 1.0 of the mSOA Reference Architecture.

I spent way too long getting tangled up in getting a stable image ready but in the end just dropped back to the previous release of Fedora 8 and it's been running under stress with no problems for a couple of days.

There'll be a first drop to internal Sun folks tomorrow when I'm in the office. I've got the size down to something almost manageable but my ADSL connection upload speed isn't going to cut it. Anyone else who's interested, it's coming...

With my able assistant, I've been working on a Java CAPS 6 project for quite some time and within the next couple of weeks it should be available for download (at least, internally and for existing customers).

What is it?

If you've heard about the Destination or Hydrazine projects, this will look somewhat familiar. The basic concept is that we take data from various sources and present it as web services to a mobile phone. Sounds simple? Yes, of course it is :-)

With a worked example, we show how to build sample applications in Java CAPS (repository and JBI), a simple MIDlet for display to your phone and a web page for end-user configuration.

To support this there is a framework providing a bunch of core services to manage users, applications, configuration and security. This means you can just focus on writing your app and not have to worry about the nuts and bolts. But if you want to get under the covers, we provide all the project source and lots of documentation.

Our last problem to overcome before letting this loose is packaging. We're distributing a VirtualBox image with everything pre-installed but are hitting random lockups with current Linux kernels. (We use Linux to avoid paying Windows licenses, and - unfortunately - there's no mobility pack for OpenSolaris). The other downside is that "modern" Linux distributions with all the goodies we need (see below) are creating disk images twice the size of a DVD right now. But I'm working on this...

So what's in the (Virtual)box?

• A Java CAPS 6 installation
• Directory Server 6.3
• Access Manager 7.1
• Visual Web Pack
• Mobility Pack

More updates soon.

I'm calling an AccuWeather service to get a short-range forecast for a given location. In the reply, there's a small two-digit numerical element which refers to the icon which represents that day's weather. I need to take that icon and base64 encode it before sending it out of Java CAPS.

You can fetch the relevant image by constructing a URL quite easily but obviously I don't want to be doing this too often and I'd prefer to have a local cache of those images. But how to access them from a java collaboration?

The solution is simple when you know how to do it - it took a fair amount of searching (and a stupid bug of my own making) before I came up with an answer.

1. Have all your images in a directory, then create a jar file with the contents of that directory. Mine are named 01.gif, 02.gif, ... and so on.
2. Import the jar into your java collaboration.
3. Access the image you need using getResourceAsStream().
4. Read the bytestream.
5. Perform the Base64 encoding.

java.io.BufferedInputStream is = new java.io.BufferedInputStream(
            this.getClass().getResourceAsStream( "/WeatherImages/" +
                                                 iconNum +
                                                 ".gif" ) );
if (is != null) {
    java.io.ByteArrayOutputStream bos = new java.io.ByteArrayOutputStream();
    byte[] buf = new byte[1024];
    int bytesRead = 0;
    while ((bytesRead = is.read( buf, 0, buf.length )) > 0) {
        bos.write( buf, 0, bytesRead );
    }
    sun.misc.BASE64Encoder encoder = new sun.misc.BASE64Encoder();
    String iconEncoded = encoder.encode( bos.toByteArray() );
    // Next line removes CRLFs which mobility pack Base64 decoder
    // doesn't seem to like    
    iconEncoded = iconEncoded.replaceAll( "\r|\n", "" );
    output.getForecastResponseType().getForecast( i1 ).setIcon( iconEncoded );
    is.close();
}

We have one main controller MIDlet (the "Service Manager" or "Application Manager") which gets a list of viable applications from the backend servers -- Java CAPS, Directory Server and so on. The user should then be able to launch any one of the MIDlets at will.

The J2ME security model doesn't want you doing that.

Until now, we've been making do with everything being packaged into a single giant MIDlet. Some of the problems with this are that:

1. It's not modular. It's one giant application. Ugh.
2. No separation between MIDlets. All UI code will be in a single class file. If you have more than one developer, they'll be treading on each other's toes all the time.
3. The flow design in the NetBeans mobility pack becomes impossible to follow after just one MIDlet. If you want to see how bad it is, this screenshot should give you an idea what it's like after just one application.

But work it does... take a look at the this project zip. It was built using NB 551 with the mobility pack and WTK 2.5.2. Run the Hello MIDlet in the emulator and when you press OK, it should then launch the Goodbye MIDlet.