Alex headshot

AlBlue’s Blog

Macs, Modularity and More

EclipseCon Day 2 in review

2009, conference, eclipse, eclipsecon

The biggest surprise news of EclipseCon day 2 was Amazon's announcement of the AWS Toolkit for Eclipse, a set of bundles for instantiating, managing and remotely deploying and debugging on Eclipse instances running in the EC2 cloud. (The source is currently aws-eclipse on SourceForge under an Apache license.)

Keynote The keynote was "Building Applications for the Cloud with Amazon", and whilst very Amazon-specific did touch on cloud-computing. Some of the numeric figures were pretty amazing; there was 40 billion S3 objects in 2008 (up from 1 billion in 2006) so the growth is pretty phenomenal. In fact, 2007 saw the tipping point between bandwidth consumed by Amazon and bandwidth consumed by all other AWS customers, with AWS racing ahead in terms of usage.

One claimed benefit of cloud computing is the ability to elastically scale with the demand; this was demonstrated with an advertising push from Animoto which bases its back-end on EC2, and needed to scale up from an approximate 40 instances to 5000 instances after a particularly successful advertising campaign on Facebook - all over a four day period. Good luck getting a purchase order approved for another 4900 computers to be ready in a couple of days in your own company!

The other aspect of flexibility is the decoupling between usage costs and ownership/maintenance/cooling/power costs. Although this has benefits for tax implications, the main one is the speed in which the servers can be acquired and utilised. The other author of the talk, from SmugMug, noted that at one point, their auto-scaling system inadvertently started 250 instances. (More recently, Amazon has allowed large-scale customers to block-book instances which makes it more efficient from a resource scheduling perspective.)

Where does this fit with Eclipse? Well, E4 is becoming more pervasive, and technologies like RAP already have server-side components that need to run on back end hardware. It's pretty clear that there are advantages (but that doesn't mean it's relevant for everybody) in the cloud computing world. I suspect a certain amount of new approaches to existing problems are likely to evolve using the cloud in the future.

The question immediately following Amazon's announcement was whether this could be used for Equinox or OSGi based applications. As luck would have it, Aleksey Aristov discussed this on day 3, and demonstrated a soon-to-be-free or open source Cloud Shield/Studio (name yet to be determined) which did exactly that. Using a customised Amazon instance, and an SSH tunnel, it was possible to bring up an Equinox app and provision it on the fly to start a remote OSGi engine. Together with OSGi's new Framework starting technology, it's quite likely that we'll see a few of these kind of approaches coming together for different kinds of cloud services; but at the moment, it's at the early adopter stage. By next year, I fully expect to see more demonstrations of this, possibly even from the E4 fallout.

OSGi Although the OSGi 4.2 draft specification was released earlier in the week, I haven't had much time to dig into it. However, there was an overview of a few services which are particularly noteworthy here which were covered in a couple of talks. Note that the OSGi 4.2 is currently an draft release and is subject to change

  • Blueprint service Costin Leau of SpringSource presented the Blueprint service for OSGi, which allows code to participate in an OSGi environment by being dynamically wired up to services without dependencies on the OSGi APIs. Anyone familiar with Spring will understand this Spring pattern immediately; the blueprint service is essentially a renamed version of the same (for trademark reasons). Although it's possible to mix-and-match these separately, chances are that Spring developers will continue to use the Spring namespaces/configuration and vanilla OSGi developers will use the OSGi specification. Either way, it allows a simpler way of wiring up services without having a dependency on OSGi code, which may be a benefit for testing or other circumstances where a dual OSGi-and-non-OSGi approach is used.

  • Framework launching Richard Hall (Felix fame) and Thomas Watson (Equinox fame) discussed Framework launching in OSGi. In essence, this standardises the way that an OSGi framework is launched, which will make it easier to have shell scripts that bring up a platform based on some kind of external configuration parameter (as well as standardising on some of the property names required for various configurations). Pax Runner already solved this problem of bringing up instances, but this extends the concept to provide a standard programmatic API. One of the neat aspects to this is that it should allow a normal Java program to bring up an OSGi instance and auto-instantiate the correct framework on the classpath. Anyone who embeds an OSGi engine might find this useful, or allow things like the ServletBridge to be more Equinox agnostic. A neat solution is that the Framework interface now implements the Bundle interface (for accessing the bundle context etc.) so that API will already be familiar to new users. It also leads to:

  • Composite bundles These allow a set of bundles to be treated as an independent (versioned) unit. In essence, they start up a mini Framework inside the existing Framework and perform all the bundle wiring as normal. This has great opportunities for being able to version whole apps and deploy them in a single OSGi engine without trampling on any other apps inside the same environment. It should be noted that not only is it a draft, but that it's also a proposed API and that not all the kinks are worked out, so it might not even make it into the final 4.2 release.

  • Service Hooks BJ discussed Symmetric services and the Service Hook service, which will allow bundles to depend on other services but not worry about startup ordering. It feels like this has overlap with the Blueprint service, which will provide you an instance but (thread) block access to the service until it's wired up. Unfortunately, much of the presentation was about the basics with not much time devoted to the new aspect, so my terse analysis could be way off.

Experience with OSGi and Eclipse Many companies are talking not only about the services and developer products, but also their success with Equinox, OSGi and RCP for their internal applications. LinkedIn has been a heavy OSGi user and discussed it in the past; Yan Pujante came to EclipseCon and presented it for this audience. There were also real-world pain points and advantages, with the takeaway being that it's quite possible to implement but (as with any technology) there are learning curves. Michael Galpin of eBay discussed their internal use of Eclipse @ eBay, along with some of their internal plugins that they used to support their development processes and toolsets.

DVCS This year's EclipseCon has co-incided with distributed version control systems growing in popularity, and I posted yesterday an overview of what's going on. At the Git BoF last night, a lot of good discussion was had; Doug will be updating the bug(s) on the subject before next week, so there'll be more accurate (and officialish) news on the subject then. Whilst there won't be anything officially supported for a while, it's probable that EGit will move from its current house to Eclipse by the end of next month if the proposal goes ahead. One reason why Git seems to be the favourite at the moment (other than momentum with other open-source projects and e.g. is that the JGit library is a pure-Java solution (and not a Java wrapper like the SVN implementation) with a permissive license, so we could logically expect an out-of-the-box experience with Git at some point in the future instead of having to download third-party tools as is the case with SVN at the moment. Oh, and also, many of the Git (and JGit) developers are using Macs for development, so that's a supported platform :-)

Day 2 has been a long and tiring day, and whilst it's good to catch up (and get out a few press releases) it means that I'm already behind the times. Expect my EclipseCon wrapup to be somewhat delayed ...

PS Eclipse con tie of the week now hosted at (top right of page) and up and running ...