I am busy working on my presentation for October Rules Fest this week — assembling the slides and double checking details with UBS. The abstract is below and the presentation is shaping up very nicely. Hope to see you there!

Distributed Data Processing with ILOG JRules

Abstract

UBS Bank operates in over 50 countries and employs more than 80,000 people. Learn how UBS uses ILOG JRules and a distributed grid architecture to generate internal and regulatory reports for all the regions around the world off a single dataset. In order to acheive this UBS is required to process 2 billion records every night, with over 30 million records passing through the rule engine. Performance objectives are in place to ensure the bank meets its regulatory and financial reporting requirements before the trading day starts.

I will be speaking at a new technical rules conference in Dallas October 22-24. The conference is unique in that it aims to assemble some of the leading implementors of rule engine technology to discuss the state-of-the-art, as well as new technical challenges and innovations.

Needless to say I am really looking forward to rubbing shoulders with these luminaries of the industry, though it’s fairly intimidating company! We are still working out the details of our presentation but I hope to present a really interesting customer use case which has extreme scalability and performance requirements. I believe the general application architecture deserves more attention as it could serve as a useful pattern for others.

If this sounds like your cup of tea I hope to see you in October - registration is open.

OK?

Next week we are going to have our internal “BRMS Offsite”. The BRMS Offsite, being held in Paris this year, is our yearly opportunity to get all the BRMS developers, QA, documentation and product marketing people together, along with some invited guests from Professional Services and Sales Engineering. There is a wide range of presentations, everything from updates from product management on the state of the market and competition, to technical demos of code that may not become productized for a year or more. We also take the chance to step back and review our progress in improving our internal processes: how quickly are we fixing bugs, how well are we working with the teams outside R&D, and are we organized to meet the challenges of the coming year?

Step 1: Call for Papers

Like all conferences there is an internal “Call for Papers” where everyone throws their great ideas for presentations into a bucket. We use Wiki pages for this part of the process with the submitter expected to contribute an outline of the presentation.

Step 2: Voting

Once the CfP is closed we proceed to the second phase of the process: everyone attending the conference gets to vote on which presentations they wish to attend. Everyone can cast 4 votes for example. Again, we track votes for the presentations on the Wiki page for each presentation.

Step 3: Presentation Selection

The votes are used to select the top N presentations based on the overall time available for the conference as well as the number of rooms provided by the hotel.

Step 4: Optimization

So, we now have a list of presentations with their associated votes, a list of people that have voted, as well as a set of time-slots for the presentations dictated by the overall time available for the conference and the layout of the hotel. All this data is processed using ILOG CP Optimizer which find the optimal solution (conference schedule), allowing the maximum number of people to attend the maximum number of presentations that they have voted for.

Results

This is the second year we’ve used this open, democratic and “optimal” process and so far our experience has been very good. For example, this year my presentation was not selected for inclusion (it only garnered 8 votes!) but because I know who voted for my presentation I could organize an unofficial BoF (birds of a feather gathering) for my special interest group. Let the greatest happiness of the greatest number prevail!

Wouldn’t it be great if some of the big technical conferences used this approach? Yes, JavaOne I am thinking of you! It builds community and removes a lot of the politics from paper selection.

This talk attempted to zoom out and present some of the impending challenges for IDE design — particularly around GUI. The current MDI stype IDE interface has remained essentially unchanged since inception, while using 2+ large monitors has become increasingly common. Many people now develop while on the road (train tracks in my case!) using a laptop, where screen space is much more constrained. Input devices are also changing, with support for multitouch and gestures already in mainstream use. Developers are also building larger systems and require more focused and efficient filtering of information. Multiple CPUs allow the IDE to be more proactive in offering developer assistance, without disrupting the developer’s chain of thought with modal operations. Apparently developers are also spending far more time exploring and reading code, rather than “just” editing source files.

I had a very enjoyable couple of drinks with Gabe from the Eclipse Foundation. Amongst many other things Gabe has been implementing the localization server for the Babel project. The server allows any Eclipse users to log in and supply translations for localized strings. These strings are then built and can be downloaded as a language pack. I took the opportunity to pick Gabe’s brain to understand how hard it would be to install a Babel server within ILOG to help us manage the localization for Rule Studio — currently a considerable challenge as we support English, French, German, Spanish, Korean, Japanese and Chinese.

The talk on the packaging efforts for Eclipse 3.4 (Ganymede) was interesting in that it described the process the Eclipse Foundation uses to create the master Update Site from the 30+ individual project Update Sites that compose the Ganymede release. Buckminster is used to resolve project dependencies while some custom scripts are capable of creating the master Update Site. The source code is (of course) Open Source — so I will have to take a look to see if there is something we can use to improve our internal build processes.

This short talk showed off the enhancements to JDT coming in Eclipse 3.4: code complete for classes that have not been imported, and automatic addition of casts after “instanceof” tests were my favourites. The breadcrumb navigation bar also looked useful, allowing you to navigate to classes from within the Java source editor.

The talk on Eclipse 4.0 (e4) made it clear from the outset that discussions were just starting. Details were sketchy, but one theme that emerged was web-enabling the Eclipse platform. There was talk of being able to implement plug-ins using Javascript, supporting CSS styling rules for all user interface elements and even supporting server-side deployment of the platform runtime to enable web applications. This ambitious effort will provide an Flash/HTML/AJAX port of SWT, allowing graphical Eclipse applications to run within a web-browser.

The presenters stressed however that they were still in the brainstorming phase and aim to produce more concrete plans and demos for EclipseCon 2009. They also tried to dispell any compatability fears by saying that Eclipse 3.x would be maintained and enhanced for many years to come.

Stefan Daume, a fellow University of Edinburgh AI graduate, was kind enough to give me a demo of the Cloudsmith software distribution solution. Cloudsmith is currently in beta and allows you to define custom software distributions, assembled from components published in Maven repositories or from Eclipse plug-ins. The very slick Cloudsmith GUI makes managing distributions easy, while the powerful runtime, based on the Eclipse Buckminster project, performs all the heavy lifting to ensure component dependencies are resolved. Distributions can be easily “materialized” into an Eclipse workspace. I’m definintely going to take a second look at Cloudsmith — perhaps it can help to manage the 80+ plug-ins that compose a Rule Studio distribution?

This panel discussion delved into the use cases for Services vs. Extensions. The most memorable analogy was that Extensions are like the relationship between a parent and their children, while Services are a like a peer-to-peer relationship between consenting adults. All the panelists agreed that both serve a valuable purpose, however there is some technical work to be done to ensure that the Extension lifecycle is as rich as the Service lifecycle and that the programming model for Services is as simple as the programming model for Extensions.