Saturday, 27 December 2008

Logging in OSGi

Remember that OSGi is a dynamic environment. Also remember that there is a specification for a logging service, 'LogService', which is my preferred approach to logging inside OSGi. Considering that OSGi is a dynamic environment this of course means that the log service may not be available.

Within Solstice we use a static implementation of the LogService interface which we can access through a static final variable and is made available in the core bundle which pretty much all other bundles import a package from. This implementation simply logs to System.out and is cunningly called SystemOutLogService. The reason it exists is just in case a LogService has not been registered with the container. To be honest, this seems pretty redundant since Solstice is an OSGi implementation (based on Equinox) and we're fully in control of what is in the distribution. Also, this doesn't seem very elegant.

In our recent release of AMF3 for OSGi I have assumed (and it is in the documentation) that a LogService will be available. At least one of the bundles tracks LogService implementations and then injects them were needed. However, OSGi is dynamic, so I can't assume that everyone will want to have a LogService implementation. So what is the solution?

One idea is to re-implement the SystemOutLogService, but I don't want there to be a core bundle that each of the bundles depends on (either explicitly, or implicitly through packages). Further more, I might as well just register my own implementation of LogService if I am going to do that - but then how do we make sure that other LogServices get priority? Well, this is possible by setting the OSGi service priority to a low number and then making sure we use the one with the highest priority. However, this is moot since I don't want to provide this functionality at all, or put any logic to handle the priority of LogService implementations in to my trackers.

So, we fall back to System.err by doing a null check on the injected LogService implementation. I'm not really happy with this either, but it is the default thing to do for Java as it is the only thing that can really be depended on to exist.

My feeling therefore, is that logging should be available at a more fundamental level, i.e. in the core specification. A logging API has been available in Java since 1.4, not that I have ever used it as I have generally used Log4j outside of OSGi. I don't think that LogService should be deprecated, but rather than having to look up a log service, you should be able to call a log method on the BundleContext which does something 'default' or delegates to any registered LogService implementations by priority. I guess that implies that a default LogService could be accessed from BundleContext instead, which further implies that LogService should become part of the core specification ... any thoughts on that out there?

By the way, we've created a Jira for Solstice, AMF3 for OSGi and any other open source projects, please feel free to create issues:

And finally ... anyone who's already downloaded the AMF3 for OSGi distribution already may have noticed that the source for the HTTP bundle was a copy of the Flex Remoting bundle. That's been fixed, please re-download it!

Tuesday, 16 December 2008

AMF3 for OSGi, 1.0.0, released

Today, Arum Systems Ltd released AMF3 for OSGi, 1.0.0.

AMF3 for OSGi is a collection of bundles that adds AMF3 serialisation, AMF3 over HTTP and Flex Remoting of OSGi services capabilities to your OSGi applications.

Best of all, this is released with a LGPL license.

For the full details and downloads visit this page:

Sunday, 7 December 2008

This blog has moved!

You may have noticed that this blog has moved to a new URL. Please update your bookmarks!

Coming soon:
- AMF3 for OSGi release
- OSGi and db4o tutorial
- a vacation! :)

Monday, 1 December 2008

Seasons Greetings!

Here's a little something I knocked up using images from Flickr (mostly subject to the this license) and a couple of useful APIs, namely FlexBook and Flint (the Flex particle system).

Thanks to Matt at Arum for finishing it off by adding all the images - even I don't know what's in there! :)

Wednesday, 26 November 2008

flex, cocomo and the diablo iii fansite kit

It has been a while and lots of things have been happening. I'm still working away on the first implementation of DataEye which should go live any day now.

I have also managed to create a set of bundles which allow Flex Remoting via AMF3 in a pure OSGi environment (i.e. no BlazeDS). However, they are not a replacement for BlazeDS, they are just something different and provide no "data services" to speak of, other than allowing developers to register their OSGi services and then access them from their Flex applications. A sample application will be provided. Once I get the thumbs up from the lawyers and my boss I intend to release them, so watch this space.

Since I couldn't sleep this evening (I have only been in my new house less then a month and things are still a little strange) I decided to see how Diablo III was progressing. I am really looking forward to this game. I noticed they had a Fansite Kit available for download, so I took a look. I didn't intend to build a fansite, I'm not a web designer, but I have been looking for an opportunity to play with Adobe's Cocomo SDK and see what it is about.

The result is the linked page.

Cocomo is really simple and seems to be very comprehensive in the things it lets you do. My application is really just a simple Flex application with no server back end. All the server stuff is provided by the "connectnow" service at (

The only things I don't like about it are the examples aren't really good examples of best practice approaches and even goes against some of the things Adobe says not to do (lots of containers within containers) and the other thing is to do with containers directly. Adobe seem to love them and seem to love inheritance as an approach to specialism. I prefer composition over inheritance, and while there's a bit of that in there too, what you end up with is a complicated mess of container hierarchy, models and so on.

But really, if you're used to Flex, this won't be a shock, so don't let it put you off!

I am thinking that Cocomo combined with the the Facebook API for Flex that I found here might be very interesting...

Friday, 17 October 2008

OSGi Primer

I find myself explaining OSGi from time to time, so decided to try and write a very brief primer to describe the essentials of OSGi which I can simply link to in the future. This short entry is aimed at people who no nothing or very little about OSGi and should be just enough to make the penny drop.

Here goes!

Firstly, I'm going presume that the reader is familiar with Eclipse IDE. If so, then the reader has already been using OSGi and probably doesn't even realise it.

The Eclipse IDE is constructed from Plugins. Plugins are effectively OSGi bundles with a bit extra (usually a plugin.xml, sometimes a little more).

Eclipse is built on top of Equinox which is an implementation of the OSGi specification and then goes on to extend it with the Plugin Registry.

At its core an OSGi bundle is a standard Java JAR file with some extra information in the MANIFEST.MF which describes the bundle to the OSGi platform it is deployed to. The manifest describes things like the bundle's name, version, what packages and/or other bundles it depends on, what packages it exposes, and probably a fair chunk of other stuff I haven't mentioned.

OSGi is a service oriented architecture. This is quite an important point to me as most people hear or read SOA and automatically assume Web Services. Well Web Services are just one type of SOA. The specification of OSGi is inherently, and by design, service oriented.

Like I said, bundles can declare what packages they expose, but more importantly they declare and/or register services.

A service is essentially a Java interface and can be implemented by one or more bundles. A bundle that needs to use a particular service looks it up (or "tracks" when services are registered/unregistered) and then decides which service to use either by taking the first one it finds, or by homing in on a service that meets a specific need by specifying some service properties.

The most important thing is that services are dynamic. They can come and go and this is a part of the specification and something that any one who writes bundles has to accept and deal with.

As a result, OSGi has a tightly defined classloader mechanism which manages version control. You can have two bundles installed on your OSGi platform that expose the different versions of the same package, then other bundles can be explicit about which package version they depend on or not.

The OSGi specification consists of a core specification and a service compendium. The core specification is enough to write modular Java applications and the service compendium details a selection of services that OSGi implementations will usually implement a common set of, if not all of. These include things like Logging, Declarative Services (services can be declared using XML), HTTP service (you can expose web resources from a compliant container, some even support JSPs!) and others. See this page for more information:

Finally, what I haven't mentioned is that OSGi has been around for nearly a decade. It was originally intended for use as a dynamic platform for embedded devices but IMHO is really starting to make its mark through use on the desktop and (enterprise) server areas, especially in the last couple of years.

When you get in to it, the power of OSGi is mind boggling. Yet OSGi is simple and logical, while remaining comprehensive. OSGi is the modularity that Java is missing.

I hope my brief description of OSGi does it justice. I deliberately wanted to keep it short and sweet and whet some appetites.

Monday, 6 October 2008

how to sell RIA

I was just discussing with my colleague Vince the merits of discussing technology as part of a sales pitch. For instance, if you're selling your services as an RIA consultancy you don't want to be describing Ajax or even GWT. It's just confusing and irrelevant. "Can you do the job or not and will your platform fit in to our infrastructure?"

Talking abot technology is just too low level for that first business pre-sales pitch... but as Vince pointed out, and I have to agree, this is not the case with Flex.

Somehow Flex has a "coolness" about it that can sell itself. So while pitching yourself as RIA specialists, if you used Flex you would most likely mention it and mention Adobe and the majority of customers would probably feel pretty good about your pitch as a result.

This is pretty funny, because the Adobe marketing machine is pretty agressive, but apart from a few minor features I am yet to see something done in Flex that couldn't be done in GWT (or some other Ajax/RIA framework).

This raises question, "why am I using Flex?". The one thing it does have, which the other frameworks don't seem to, is modularity. I've mentioned this before, it gives Flex developers the ability to put big lumps of code in to different SWF files which are loaded as needed. We take advantage of that (and OSGi on the server) in Solstice to create our modular RIA platform.

Can't do that with GWT, it's an all or nothing approach. Want to add a new feature? Recompile you're whole application.

I just wish Adobe would see the value of OSGi and get on board. BlazeDS would be an awesome OSGi bundle.

Saturday, 27 September 2008

music brain - part 1

I sometimes feel as though I am so focussed on one particular thing (at the moment Arum DataEye) that my various other skills that I am not using so much at the time might become rusty.

As a result I have embarked on a little side project... Music Brain. It has probably been done before, but it is really just a programming exercise for myself more than a serious project.

Problem: The new Metallica album, Death Magentic, was released recently and I want to know how "Metallica" it really it is. My gut feeling has a human is that it's pretty Metallica. :) But I got to wondering if a computer could make the same judgement?

Solution: Train a neural net with my library of Metallica tracks, except for the current album. Then run the new album through the neural net and see if the program agrees that this is a Metallica album. I will also run a few other band's tracks through the neural net after training has been completed and see what it "thinks" about them. Hopefully the program should be able to differentiate between existing Metallica tracks and other bands, while being able to identify new Metallica music.

Approach: Somehow I will have to extract the music from my music library and feed it in to the neural net. How many input nodes will I need? How can I extract the raw music?

Today's first steps were to read up on the WAV file format. It is a pretty straight forward format and using the information on this page I was able to create a "WAVIterator" class which takes an input stream and using the Iterator pattern allows me to pull "MusicSamples" out of a WAV file. In my API a "MusicSample" contains a one or more channels of data for a very small slice of time.

I have placed some restrictions on the files I am going to be able to parse in order to make life easier. Basically the WAV file must have been recored with 16 bits using PCM (Uncompressed) at 44100hz. I figured this is close to CD quality and good enough for the human ear so it would be good enough for this program.

The resulting test program was an interesting and humbling reminder about how slow using an unbuffered FileInputStream really is. My test code was taking nearly 100 seconds to parse the WAV file which was a little disappointing. So I decided to load the whole file in to memory first and use a ByteArrayInputStream instead. Wow! This reduced the parse time to just over 4 seconds, much more like it.

However there are a number of problems with this approach. Firstly, what if the file size is greater that Integer.MAX_VALUE? i.e. larger than the maximum size of a primitive array in Java. This is unlikely to happen since Integer.MAX_VALUE is 2^31 - 1, or 2147483647 (i.e. about 2gb), but that leads on to the next problem, you're soon going to run out of memory if you create 2gb byte arrays. It just isn't good practice to make the assumption that your files will be small enough and/or risk trying to allocate an array that big.

Of course, after a minute's pondering I remembered that there's a class just for this type of occasion; BufferedInputStream. So I replaced 9 or 10 lines of code and wrapped my FileInputStream in a BufferedInputStream and the performance was just as good. It feels good to get back to basics sometimes.

My next tasks will be to work out how to create a neural net in Java with appropriate inputs and outputs for my extracted music data. I don't really want to code a whole neural net, so I will probably use an existing framework... more next time.

Thursday, 11 September 2008

Arum DataEye

In work related news, I have been continuing work on Arum DataEye, our near-real time management information dashboard built on Solstice.

Our first customer is getting ready to go live soon and now Vince is back from his medical leave the team is back at full strength and eager to get DataEye delivered. I'm sure there will be a case study when that happens, so watch this space.

Below is an extremely simplistic Flex application that I put together which helps to demonstrate what Arum DataEye is essentially about. (Sorry about the size)

Arum DataEye has a customer and technology agnostic data repository which is easily extended through our pluggable administration interface allowing us to integrate DataEye with any host system you care to throw at us. Our consultants are experts at analysing host systems so that Arum DataEye can make periodic requests for live data without impacting operational performance. The data is retrieved, stored in our data repository and then displayed on a user's dashboard on demand using Flex, providing a rich and interactive dashboard for monitoring the performance of everything from user and team based call centre statistics to host system uptime.

While Arum DataEye is primarily a tool for getting your management information now, future versions of DataEye will also support forecasting, allowing you to make predictions and pro-actively change your strategies in order for your business to satisfy its key performance indicators.

If you'd like more information about how Arum DataEye can unlock your data now, instead of next week or next month, feel free to contact Arum by clicking here.


Google Chrome was released earlier in the month.  At first I greeted the news with trepedation as all the world doesn't need is yet more browser chaos.  

However, I was really impressed by the comic style of the documentation.  I was suckered in and decided to give it a try.

First impressions were good - it starts up fast.  I'd say about 3 times faster than Firefox 2 just based on casual observation, but about the same as Internet Explorer 7.  It feels fast when I use it and it's responsive, more so than Firefox, but again about the same as IE7.  It feels clean cut and modern, compared to Firefox 2 which now feels clunky and I never liked IE's interface anyway.

However, after using it almost exclusively for a while there are a few things about it which annoy me.  

Firstly, I admit it, I'm a Facebook user (don't bother adding me, I only add people I know in real life).  Chrome is hit and miss with Facebook and seems to only work about 50% of the time.  I've been told this is because Facebook delivers Ajax/Javascript appropriate to the browser being viewed and doesn't know what to do about Chrome.  I'm not convinced since it seems to work some times and not others.

Next up - Google's own homepage doesn't even show up right.  The radio buttons to allow me to choose to search my location (UK) just aren't visible, though they do seem to be there.  In fact, radio buttons ahve gone missing all over the Internet, from what I can see.   Then the biggest shock was that right mouse button support in Google Spreadsheets doesn't work at all when trying to get up a context menu for the rows and is fiddly at best on the cells.  It is a little shocking that Google's own applications don't work with their very own browser, it would seem logical to me that is where they would start.

I wouldn't have minded so much except that the marketting propoganda documentation states that they have a massive server farm testing all the most popular sites and have this almost miraculous approach to working how a web page should "conceptually" thus reducing the number of human testers required.   Smells of BS to me.

Next is how they say they've "redesigned web browsing" from the ground up.  Well not really, all the usual things are there... well nearly.  Most things you take for granted in Firefox (or even IE) are generally there - if you can find them.  I've not really noticed anything special that Chrome does the other browsers don't, apart from ...

Process per tab.  This is actually really good and makes Chrome feel really stable.  In fact, Chrome probably uses more memory than Firefox for the same kind of browsing, but the fact that when I close a tab I know I'll get that memory back (and it really does seem to work that way) makes me feel all warm and fuzzy inside.

Finally, Webkit.  A few people I know go on about how cool this is - I don't see it's much different from Firefox 2's rendering or even IE's.  I'm still trying to work out what makes it "cool".

So in conclusion, I'm still using Chrome primarily, but sometimes I really have to switch back to Firefox 2 to do some stuff (editing spreadsheets and adding friends in Facebook mainly).  I can only imagine that it will improve over time, though I am slightly worried that I am still "up to date" even after using it since it came out.  Perhaps the rumours about automatically downloading self-updates are true ... ?  

But anyway, if you haven't tried Chrome yet I'd recommend it so long as you remember that's still very new compared to Firefox 2 and especially Internet Explorer.

Thursday, 14 August 2008

Arum DataEye v1.0

I haven't blogged for a while and that's mainly because of two things.

Firstly (and most importantly) I got married and then had a two week honeymoon in the Maldives. It was lovely and I managed to avoid using computers for the whole time we were away. Bliss. I hate computers. :)

Secondly, I've been working hard on Arum's flagship product, Arum DataEye and I am happy to report that we successfully deployed v1.0 of the software to our first of many customers yesterday.

Arum DataEye is a near-real time, management information, dashboard and alerting system build on Solstice which, as readers will know, combines Flex and OSGi to enable rich modular Internet applications. As such, we can deploy new components for the dashboard as well as provide a dynamic integration layer simply by providing new bundles. This also means we can customise the application for a customer's specific needs without affecting the entire code base. Existing customers can rest assured that they'll receive the latest code as part of their support agreement without having to worry that another customer's specific requirements will affect their system.

For those interested in Solstice, an alpha version of Solstice can be downloaded from Arum's website and I'll be updating this in the next couple of weeks with the production version we deployed yesterday. I'll also be providing some much needed documentation and an example application for interested people to dissect.

My workload for the next few weeks mainly involves designing and implementing the integration bundles for our customer before we go live in October as well as making a concerted effort on the book I've been promising to write for a couple of months.

Tuesday, 20 May 2008

Axis2 and OSGi

Thanks to Davanum for the heads up about the OSGi bundle hidden away in side the Axis2 trunk. I intend to try and run it, but having just had a look at the code it seems a little incomplete in the Activator of the bundle at least: :
- If the services it depends on are not available (HttpService, LogService) then it continues to activate, when really it should throw an exception, or even better use a ServiceTracker to dynamically track the services.

- What if there's more than one HttpService?

- It requests a LogService then uses System.out

- It registers itself as a bundle listener before creating an instance of the ServiceRegistry. In the unlikely event that a bundle state changes while this bundle is activating you could get a NullPointerException in the bundleChanged when trying to called the methods on the registry instance.

- Note the big block of code already commented out... that would stop any services which are already registered from being exposed as web services. Remember that OSGi is a very dynamic environment things can come and go as well as already be there when your bundles start.

- While not strictly required (I believe), during the stop() method it is good practice to call ungetService on any services references that have been acquired.

As for the rest of the code, I'm not qualified to comment as I don't know the inner workings of Axis2, so I'm just going to give it a try and see what happens. Watch this space.

Tuesday, 13 May 2008

flex regular expressions

I really like how you can inline regular expressions in Flex. For instance:

var split:Array = someString.split(/\./);

which will of course split "someString" using "." as a delimeter. Of course, all that's really happening is that the regular expression is being converted to an object by the compiler, so the following is the same:

var regexp:RegExp = /\./;
var split:Array = someString.split(regexp);

This is superiour to Java's approach which allows you to specify a regular expression as a String when calling split, the problem being that the above regexp would look like this:

String regExp = "/\\./";

Note how I have to escape the escape character!

Of course, Java has a whole package for regular expression handling, but they all suffer the same problem of having to encode the regular expression in a string and thus having to escape the escape characters... which makes long regular expressions very complicated and as a result I suspect a lot of Java developers simply avoid using regular expressions for that reason. In my view inlining regular expressions is definately a candidate for being added to the core Java language.

Thursday, 1 May 2008

SpringSource Application Platform

Yesterday SpringSource announced the release of their application platform:
a completely module-based Java application server that is based on the new SpringSource Dynamic Module Kernel™ (dm-Kernel). The dm-Kernel harnesses the power of Spring, Apache Tomcat and OSGi-based technologies to give the platform incredible flexibility and resilience for both development and production.
Effectively an OSGi container with some Spring stuff thrown in and another step in the right direction away from the J2EE world.

Referred to as S2AP, the SpringSource Application Platform announcement generated a fair amount of interest and discussion so I decided to cut to the chase and ask Rob Harrop of SpringSource to clarify a few issues.

Firstly, not being a lawyer or Open Source license expert I was a little confused about the implication of using GPL as the Open Source license for the server. Rob managed to clarify this succinctly:

If you are running applications on the S2AP, then there are no requirements placed on you. If you distribute an application including S2AP or GPL components thereof, then you would either need to license your application under GPL or purchase a commercial license from us.

A useful summary of what using GPL means. Next up, I was interested in what S2AP brings to the table if, like me, you're not a user of Spring and currently have no plans to be.

S2AP contains a lot of additional benefits on top of plain OSGi. For starters, OSGi aside, its just a good, solid server platform. We have extensive serviceability features including active deadlock monitoring, detailed trace and first failure data capture. We have provisioning support that makes it easier to handle the installation of hundreds of bundles into your runtime environment. The pre-embedded Tomcat is plus point - that was a lot of work.

There a lot of under the hood tweaks, including resource loading support that works in standard libraries such as Jasper (JSP), load-time weaving support and advanced refresh that handles more module dependencies than those currently handled by the OSGi spec.

My interest is definately peaked now, so I think I will be checking it out in my next development lul or as a distraction from development grind. However, I had one outstanding question regarding a specific piece of functionality that I have been hoping someone would save me the bother of having to implement. It occurs to me that it would be very helpful if I can register a service with the OSGi context and some other bundle automatically makes that service available as a web service. Spring has some functionality enabled rapid development of WebServices, so I asked Rob if this is something that S2AP can help me out with.
Publishing OSGi services as WebServices is on our roadmap, but it won't be available for 1.0 final.
Fair enough. As it happens there is already a Knoplerfish bundle that can do this, but its implementation is not compatible with newer SOAP clients.

So in conclusion, it looks as though S2AP is worth keeping an eye on for the future of OSGi containers. If it lives up to its instant hype and the features described by Rob it is will be a robust platform for purist OSGi developers like myself, as well appealling to those already in the Spring camp.

For more information on S2AP, you can check out Rob's blog entry: Introducing the SpringSource Application Platform

Friday, 18 April 2008

Solstice Architecture

Wednesday, 16 April 2008

OSGi adoption by Sun

... well, not quite, but close and I always thought that Sun were dead set against OSGi. It is brilliant news if they are starting to realise how important OSGi is and how much time it can save in endless discussion about putting modularity in to the Java platform.

Yes, Java is missing modularity, especially when compared to what the OSGi specification adds, but I like Java just the way it is. OSGi is a fantastic specification for enabling modularity on a great a programming language. If you "clutter" (for want of a better word) the core language with such things, it stifles creativity at the foundation level. So I will always vote to keep them seperate, but adoption of the specification by Sun is fantastic news for everyone.

I also think this is fantastic news because I see J2EE and RDMBS becoming obsolete eventually. My "dream architecture" is based on OSGi and OODBMS and some kind of open UI specification not implemented in the core language. Swing is cool, don't get me wrong, but again I'm all for seperating the core language from such things as UI.

As readers will probably know my current UI preference is Flex, which is obviously nothing to do with the core Java language, but it is highly compatible and an extremely productive environment for developing applications with a UI. Adobe are often criticised for not opening Flex in to an open specification, but I can understand why it isn't and the underlying programming language (ActionScript) actually is an open specification already.

Right now, for enterprise web based applications my technology choices would be:
  • "Server enabled" Equinox
  • Db4o for the database
  • Flex for the user interface
This architecture may not sound very scalable, but I have removed a number of layers which do nothing but transform objects and reduced the stress on the server by adopting a rich client platform.

For desktop applications I will still jump back to using Eclipse RCP, but AIR is becoming more attractive and I am heading to it as a preference because now that I am becoming more experienced with Flex I am finding it easier to build user interfaces with Flex than with Eclipse, even with my Eclipse SDK experience. A lot of that is down to the simplicity of the APIs and some of the language features (e.g. variable bindings). Also, the skinning you can do with Flex apps is very good indeed. My current favourite skin/theme is this:

How could you do that with Eclipse?

Still, with E4 on the horizon and the rumours I've been hearing and screenshots I've been seeing, Eclipse will continue to have a lot of attraction to a lot of people. I will be finding out more about it in detail on Friday.

Friday, 14 March 2008

Eclipse vs OSGI and Solstice vs RCP

This post is in response to the comment on my Solstice announcement linked above.

What is the difference between OSGi and Eclipse?

OSGi is the foundation of the Eclipse platform. Eclipse is built on top of OSGi.

OSGi has the concept of "bundles" which are modular Java components. Eclipse takes that concept and extends it to what most developers know are "plugins". A plugin though is just a bundle with a plugin.xml file. The plugin.xml file tells Eclipse how to deal with that particular bundle and defines extensions and extension points, more concepts that build on OSGi, though OSGi is predominantly service oriented.

The high level stack for Eclipse is:
  1. Java
  2. OSGi
  3. Equinox (an implementation of OSGi)
  4. Eclipse (SWT, JFace, etc)
I should point out that extensions and extension points are not only extremely useful for the UI/RCP side of things, but are a useful tool in general. My perference however is to try and remain as service oriented as possible using only OSGi services and interfaces that are in the specification and compendium where I can. That said, the Eclipse "plugin registry" can be used on any OSGi platform so developers shouldn't worry about tying themselves in to Eclipse if they want to use plugins and or instead of bundles.

Solstice vs RCP

Eclipse is a great platform for building modular rich applications for the desktop and there is certainly progress towards being able to deliver these applications over the web (I'm talking specifically of RAP). My understanding though is that RAP isn't mature yet and personally I'm not keen on AJAX or in fact having any dependancy on browser technologies. I prefer cross-platform runtimes such as Java or Flash Player.

For me the advantage of using Flex (especially when used with Solstice) over Eclipse RCP are:
  • Reduced footprint for installation of the software. Flash Player is small and the binaries for your application will be much smaller compared to Eclipse.

  • Easier to deliver the software to the users. Flex applications are delievered via the web, whereas Eclipse requires some installation.

  • Consistent platform for development.
    • Flash Player is identical across all supported platforms and according to Adobe at least some version of Flash Player is now present on 98% of all computers with FlashPlayer 9 coming in around 90%-95%.
    • SWT doesn't support all platforms in the same way.
    • Eclipse UIs look native.

  • Flex is easier to learn than RCP. I'm a software engineer / developer with more than 10 years experience (8 of that using Java) and found the learning curve for Eclipse to be very steep, but I persisted because Eclipse is "cool". Though I can create simple plugins quite quickly these days when I try and do something with Eclipse the complexity of the platform leaves me feeling unproductive. When I got my job with Arum I learnt Flex in a matter of weeks.

  • Flex allows developers to be creative with the UI. This is a duel edged sword really. Eclipse has a constistent UI (subject to native look and feel), but I have seen some stuff done with Flex that I couldn't dream of doing in Eclipse. Either that or you have to install or develop entire new frameworks to achieve something relatively (e.g. GEF for graphical editing, but it can't even rotate a text label!). The other side of that sword is that the UIs I personally produce still look very developer oriented (like an Eclipse app) and you really need that creative flare to do the exciting things I seen done with Flex. My focus is on the Java/Server side of things anyway, so I'm not too worried about that aspect of things. My colleagues are much better at Flex UIs than I am.

Flex is great but I felt as though I was missing out on the modular power that OSGi and the Eclipse RCP gives developers, which was my starting point when putting together Solstice. Using the Equinox and BlazeDS I managed to put a Flex UI in front of an OSGi container in an afternoon and I just carried on from there.

Flex has the concept of modules, but mainly for the puropse of reducing perceived load times. It seemed obvious to me that the dynamic ability of the Flash platform could end up creating an alternative to RCP.

Solstice is a good step towards that. Developers can still use the OSGi and all those good things that go with it (component oriented, service oriented) without feeling as though the only option for a UI is the Eclipse RCP or HTML website exposed through the HttpService.

Tuesday, 11 March 2008

MediaWiki Preview Eclipse View Plugin

I created the plugin (see link above) to render text files that I write in Eclipse using MediaWiki syntax. It suits my needs, but thought I would share. Simply drop it in to your Eclipse plugins folder and restart Eclipse. Then go to Window, Show View and select the MediaWiki Preview View from the Brindy category.

A view will appear that will attempt to render the current document as though it was a MediaWiki page.

Have fun!

Monday, 10 March 2008

Solstice alpha 0.3 released!

I'm very excited to announce that today Arum has released it's first of it’s kind modular rich internet platform combining Adobe’s Flex with OSGi has now been released as an alpha. Arum invites interested parties to download and try it out. For more information see the Solstice product page via the above link.

Solstice is based on the following technology:
  • Adobe Flex
  • BlazeDS
  • OSGi
  • Eclipse Equinox
  • Eclipse Equinox Servlet Bridge
  • Apache Felix
  • db4o
It's very alpha and we'll be doing more work on it as we develop our main product (DiDo), so in the mean time I'm prepared to field questions about it here or via the email address on the Solstice product page.

Wednesday, 27 February 2008

flex: a single object as a dataProvider for a chart

I'm still really enjoying Flex and 3.0 (and Air 1.0) has officially been released now. After working with Vince, my relatively new colleague, I can see that I'm still in the learning curve for Flex, though I'm confident I could hold my own and will catch up pretty quickly.

This evening I'm tinkering with my "webwar" game again. I decided to use a ColumnChart instead of a form and labels (ahem, very developerish!) to show the status of "resources". The problem I was having was that my resources are expressed as properties on a single object:

public class Resources
public var earth:int = 0;
public var fire:int = 0;
public var metal:int = 0;
public var water:int = 0;
public var wood:int = 0;

The dataProvider for a ChartBase subclass has to implement the IList or ICollectionView interface which obviously Object does not. I played around with various bindings, setting the dataProvider on the ColumnSeries instead of the chart, with little success. Eventually I came up with this, which seems to work, but I'm not sure if it's the most appropriate method or not (will check with Vince tomorrow!)

<mx:ArrayCollection id="chartData">

So rather than setting the object as the dataProvider, I set this array collection as the dataProvider and bind the elements of the Resource object to my custom collection.

So apart from that, we're still doing some cool stuff with Flex and OSGi at work and we will have an alpha release of our Solstice framework this week! Promise.

Wednesday, 13 February 2008

Arum's new website

Arum Systems' new website just went live. Expect to see some interesting stuff appearing here about our particular industry focus (business consulting to debt collection and recovery) and the work of Arum's relatively new RIA team, which of course I am a member of.

Tuesday, 12 February 2008

A New Dawn - OSGi and Flex

I can't say too much about the actual project I've been working on at Arum Systems just now, but what I can say was that we decided to adopt my proposed architecture as it fits the business model we're planning to employ for the product very well.

As a result, we have combined OSGi, Flex and BlazeDS in order to develop a Modular RIA/RS (Rich Internet Application/Rich Server) Framework that we've called Solstice. An official announcment will be made before the end of this month, but I wanted to give a quick overview of what's going on in my head ahead of that announcement.

I had previously tried to achieve the same thing with GWT, but I had two main problems with GWT:
  1. lack of modularity
  2. lack of visuality
Don't get me wrong, it's a pretty funky technology, but by modularity what I mean is, it is impossible to create dynamic modules for a UI that you create with GWT mainly because of the way you have to code it up in Java and then convert it to a JavaScript application at compile time. This leads on to the second problem, which I am sure there is a better word for than "visuality".

Although I'm not a Microsoft technology fan, I have to admit that I have always admired their approach to building UIs. That is, a developer literally builds the UI. Of course, they can add code on clicks and so on, but they know exactly what they are going to get as they are building it because they can see the graphical representation of it at build time, rather than runtime unlike GWT (and even Java) which is only recently starting to see fairly immature graphical builder tools being made available. However, throughout my career I have found Microsoft technology to be quite inaccessible and have never been lucky enough to be in a job where I can get my hands on the tools and have time to play with them at the same time.

All this changed when I joined Arum Systems' RIA team. My background is Java/J2EE of course, and they needed a strong developer with good Java experience and all the other "senior" stuff (aka "hardcore") to round off the team's skillset. Being "hardcore" I set about learning Flex, which was helped a lot by the fact that it is so easy to get your hands on, install and just get going with. I was very excited when I saw the visual nature of the Flex Builder tool, especially that it is part of the Eclipse IDE - I felt right at home from the outset.

I'm the first to admit, I'm no UI expert. Some of the Flash/Flex stuff out there is just amazing, but my focus really is software engineering and product development. I think this is why Eclipse RCP appealed to me - it removes the choices about the UI from the developer which is good and bad for many reasons. Ultimately, RCP and even plugin development appears to be a very niche/elite developer market because the learning curve is so steep and some of the architectural decisions made by the Eclipse team are questionable. Flex on the other hand is very easy to get in to whether you come from a web design background or a Java background. The learning curve is long, but shallow.

So, the business model for our new product calls for a lot of flexibility (no pun intended). We don't plan on mass selling a shrink wrapped product, instead we plan on targetting a selected group of new and existing customers with varying integration needs. One option was simply to "copy and paste" the product for each customer, but this seemed wasteful to me, so instead I drew on my experience of Eclipse plugin development, and more specifically my growing experience with OSGi, in order to propose an architecture that lets us build a product that is 80% complete for all customers, with only 20% left as integration consultancy.

Combining those concepts with Flex allows us to build modular ich internet applications and rich server applications. Combining these two key technologies in to the Solstice framework allows us to:
  • extend our product quickly and easily for multiple customers without having to maintain multiple codebases
  • maximsing profit by enabling re-use
  • reduce time to market and costs for our customers

Solstice will be available by the end of this month as a fully open source framework. Documentation, examples and tutorials will be available and I am hoping to talk about it at Flex360 Europe in April.

Wednesday, 6 February 2008

Flex UI Experiment

This is a Flex UI experiment that I knocked together in a few hours last night. I kind of had an Eclipse feeling at the time, which may explain why it looks the way it does. It's for a game that I'm writing in my "spare" time, which may or may not go somewhere...

The main thing I wanted to play with last night was the “graph” in the middle section, which is “SpringGraph” by Mark Shepherd (Flex Builder team). The graph uses a custom renderer in order to draw the pie charts and show a tool tip. I had started writing my own and realised this graph view had probably been in the past so did a quick Google and there was SpringGraph.

The pie charts are just drawn as “wedges” on a custom component created using a Drawing library from Ric Ewing updated for AS2 by Kevin Williams and now for Flex by me. You can get a copy of it using the link below.

My main change was to pass a graphics context in to each of the methods and a few other bits of tidying up. It's pretty cool and lets you easily draw polygons, stars, wedges and "gears". Very handy for weird shaped custom components. Just subclass Canvas and draw using this library. Flex is neat in that by default it only seems to detect mouse events over drawn areas making those weird shaped components feel as though they are really weirdly shaped rather than just a rectangle with a drawing in them.

Tuesday, 29 January 2008

monitoring continuous integration

It has been a while since I last posted anything - sorry about that, I've been beavering away at Arum Systems building some interesting stuff with Flex and OSGi. More of that later.

For now though, just for fun, I decided it would be nice to be able to monitor our continuous integration environment (CruiseControl) in a slightly different way.

I got myself a USB experiment kit which has various inputs and outputs that can all be accessed via USB. Our CruiseControl runs on Linux, but exposes various ways of querying the status of the builds. I decided to run the hardware on the same Linux box, but use the XML for CCTray interface over HTTP, so in theory the USB kit could run anywhere - subject to an appropriate library being available for the OS.

The kit ships with a DLL for Windows but this wasn't going to be much use on Linux, so I downloaded the k8055 library for Linux which kindly replicates the DLL as a linux library.

My usual programming language is Java and that's what I wanted to work with for this project, so I decided to try out JNA which saves you the bother of writing JNI code - it simply wraps a shared object or DLL and maps it to an interface at runtime. Very handy!

In no time I had a Java program wrote which queried the XML from Cruise and was controlling the experiement kit.... a Cylon/Knight Rider display for when Cruise was building and a all lights flashing output for when the build was broken.

The only real problem I had was that when I first tried to run my code on Linux (I had it working on Windows in Eclipse IDE first using a stub for the interface which simulated the USB device), I got the following message:

symbol lookup error: /usr/lib/ undefined
symbol: usb_init

The solution was simply to add "-shared" as a linker option for the shared library in k8055's Makefile, clean build and that was it!