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.

No blog entries for 2 months and then two within minutes of each other!

My 10 minute intro for the JavaCAPS 6 mSOA Reference Architecture has finally found its way onto the screencasts section of the documentation site.

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!

I've never really got on that well with building GUIs on mobile phones. Primarily, it's been the very basic look and feel of components, or the limited options for laying them out on a small screen of undefined size. There are plans afoot to give the mSOA Reference Architecture for CAPS a makeover so that it's more visually appealing, so I've been keeping an eye out for technologies we could use.

I'd heard of LWUIT from JavaOne (I was manning the Hydrazine stand part of the week, literally over the wall from the LWUIT team). Although it's being used in a project I'm involved with I didn't give it much thought until I saw it in use this week.

LWUIT is a GUI toolkit for phones, and other small devices. A lot of the concepts are borrowed from swing, although it's not as complex. The LWUIT homepage has good documentation and some easy tutorials... shouldn't be a problem to knock a test MIDlet together, right?

Here's the NetBeans project - binaries are in the "dist" folder. I've only tested on the WTK emulator and my phone (Nokia N95) by copying the jad and jar files to the device and installing them through the file manager.

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!

Today, someone on a mailing list I was reading asked about how to do Base64 encoding and decoding in Java. Surprisingly, it's not part of the core libraries and although there are a couple of them hidden away they're either private or not recommend for use. Usually I end up googling for an implementation I can use (which may be what you've done to find this page).

I thought that I ought to be able to make my own, so here's the result of a couple of hours of hacking around. Consider it freeware. Use it wherever you like. No warranties. If it doesn't work for you either let me know or just grab another one from the Internet...

Download

Example usage:

  String x = "To the batmobile! Atomic batteries to power. Turbines to speed.";

  // Encode, no linefeeds
  Base64.encode(x.getBytes());
  // Same as the above
  Base64.encode(x.getBytes(), false));
  // Encode, linefeed at 76 chars (MIME encoding)
  Base64.encode(x.getBytes(), true));

  // Decode
  Base64.decode( Base64.encode(x.getBytes()) );

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.

For a long time, I've had this nagging feeling that I should invest some time into learning Lisp. More and more I've been noticing posts on reddit talking about how great a language it is, and how much more productive it is than pretty much any other language. Well, I'm not sure about that; there are a lot of great languages and it's your familiarity with it that makes you productive. But anyway, I'm not a complete novice having done plenty of work with Monk (SeeBeyond's proprietary Scheme implementation from some years back) and I understand the basic concepts and know that it can be used to produce some really elegant code.

So I armed myself with a couple of good books and found some little projects to work on.

Last night I came across a bit of a shocker.

I have a need to generate a short sequence of random numbers. Lisp has a function for generating them. Perfect. Hmmm. Not quite.

Here's a bit of code to print 5 random numbers between 0 and 9. There's nothing complicated about it.

Feeding this short program into GNU Common Lisp produces the following output:

So far, so good. Let's run the program again and see what random numbers it comes up with this time:

Wait a minute... didn't it print those the last time?

OK, so maybe there's something I'm missing. Off I go into the Common Lisp specification. A-ha! There's a global variable called *random-state* which acts as the seed. Promising. But there's no function for setting it to some other value and its structure is implementation-dependent so if you did manage to hack its internal structure directly, you would end up with something non-portable.

The specification does acknowledge this but defends it by saying that "there is no simple way to guarantee that any user-specified seed value will be random enough." In other words, Lisp knows better than you what you want. Then it goes on to say that to avoid repeated invocations of the same program producing the same values, you should write the *random-state* variable to a file periodically and read it in again every time the program starts. Really? I don't recall ever having to do that in any other programming language.

Now I don't know about you, but I still don't think what Lisp calls random is in fact random. I call it predictable.

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.