The tutorial from Instantiations by Daniel and Eric on building commercial quality Eclipse plug-ins was a nice review of the core capabilities of the Eclipse platform, annotated with some best practices. They also spent quite a bit of time on the requirements of the Ready for Rational certification from IBM.

They included a couple of slides at the very end of their talk that were very relevant to Rule Studio — how Instantiations supports multiple version of Eclipse (in their case 3.0, 3.2 and 3.3). They have experimented with various techniques (including using different code branches, which is what ILOG does) but have now settled on a single code-base (single branch) that they translate using a custom tool to source code specific to each version of Eclipse. Code comments parameterize and drive the source translation approach. It sounds very challenging but the logic is that 95% of their code is independent of Eclipse version and this approach allows them to fix a bug in a single branch without having to deal with merges into different code branches. Unfortunately it also means that they are locked into JDK 1.3 language level for WSAD 5.1 support! They even had to backport some new Eclipse features to older Eclipse version, such as the Jobs API!

I’m skeptical that this approach could work for Rule Studio but it is true that merging bug fixes into all the branches we support (JRules 6.1, 6.5, 6.7 and trunk are the most active branches) is a drag on productivity.

I’d be interested in hearing how you and your company deals with supporting multiple versions of Eclipse.

I’m sitting in on a tutorial on the DSF Eclipse debugger framework. Pawel has had us complete some interesting coding exercises to illustrate the event-dispatch pattern used in DSF. The pattern allows DSF data structures to be unsynchronized because they are only accessed from a single event processing thread — essentially the event processing thread acts as a master lock over the whole data model (similar to how SWT prevents multi-threaded access to its data structures). This pattern could be useful for protecting the Rule Model within Rule Studio — using event dispatch to access the rule model (both read and write). DSF also uses some Java annotations to document which classes, methods and fields are immutable, thread-safe or should only be accessed by the event processing thread.

The alternatives are to create an immutable read-only model (by definition thread-safe, but probably memory hungry as we’d have to clone the sub-models to update them) or to synchronize the elements of the rule model to render it MT-safe (our current approach). The challenge with the existing pattern is that it can be difficult to develop and test as multiple Eclipse threads read and write to the rule model, especially when it comes to preventing deadlocks.

It’s interesting to note that while I was server-side programming I was largely insulated from these threading considerations. In the multi-threaded and highly interactive Eclipse environment data consistency and locking is a real challenge.

I just attended a tutorial on getting Maven to build plugins, features and Eclipse update sites. This is topical as we are in the process of moving our JRules build system over to Maven 2 — but have yet to tackle Rule Studio for Java which is based on Eclipse. The Maven 2 plugins Carlos showed are still on the bleeding-edge (not released yet!) but the approach looks promising. Reconciling the Maven 2 Project Object Model, that describes project dependencies, with Eclipse OSGi project bundles (which also describes project dependencies) would allow us to use a central Maven repository to distribute the sub-components (such as rule engine and language JARs) to the teams that require them — including the Rule Studio for Java team. It may also allow us to build an Eclipse Update Site for Rule Studio for Java with minimal manual work. As Carlos said however, these tools are not yet ready for production usage but are a work-in-progress.

That said, there may be other alternatives — the Eclipse Buckminster project as well as new Update Site (including Artifact Repository) support coming in Eclipse 3.4 and Eclipse 4.0…

I am leaving in a few hours for EclipseCon. I’m looking forward to learning about all the great new developments in Eclipse 3.4 and 3.5 — which never fails to get the creative juices flowing. If you are there and want to chat about business rules or Eclipse development (over a beer perhaps?) feel free to buttonhole me. I’ll be the jet-lagged Englishman…

By Chris Berg, ILOG.

ILOG and Microsoft have been doing great things together. One of our strengths has been combining ILOG’s years of BRMS experience with strong platform companies such as Microsoft. When we brought our BRMS to the Microsoft platform we created a theme called “Microsoft Centricity” and that guided the effort. Today, Rules for .NET is the best expression of a BRMS on the .NET platform and we have a lot to talk about.

Click on the image below to hear both ILOG and Microsoft talk about what we are doing together:

Moreover, we have a nice micro-site hosted by Microsoft. You can now visit us at http://www.microsoft.com/isv/ilog/.

Just a little note to say that Jerome Boyer from ILOG is covering some nice BRMS methodology material over on his Agile IT Architecture Blog. Interestingly he is starting to use the Eclipse Process Framework to describe some of the methodology around BRMS projects.

By Chris Berg, ILOG

The notion of a contract has gained a lot of attention in the past several years and like anything that get’s this sort of attention the general nature of the concept itself may either become fractured or worse incoherent. Moreover, depending upon your starting point (XML or objects), the implementation of the contract itself could hide things from you and further collude your view of critical integration requirements. However, after spending several years doing test-first-programming I have favored interfaces as a required artifact for some time. In fact it’s impossible to test without them–take for example the “mock object pattern”. But more striking has been the value achieved with this artifact within an N-Tier architecture. It’s critical for establishing the contract between application boundaries.

If this describes your architectural world at the moment, there is good news with Windows Communication Foundation (WCF). WCF provides a contract-first framework for creating services and it follows your N-Tier patterns. If you have a business object and it implements a specific interface, that interface can easily describe a service; however, unlike previous frameworks, it removes many implementation details by making them configurable service features.

Here at ILOG, the RES.NET team surveyed WCF for its potential and it won on many fronts—extensibility, standards, scalability, infrastructure and ease-of-use. Of course, we also considered that if the framework fit so well with our requirements, imagine the fit with yours. RES.NET sits on top of WCF as a service implementation but details can be tuned as you require. This keeps your focus on the value—shared decision execution for your environment.

We have published the Java to C# source code translator we use for our BRMS products as an Open Source project. The source code is licensed under the Eclipse Public License (EPL). The translator requires Eclipse and can convert an Eclipse Java project into a Microsoft Visual Studio C# project.

Alexandre Fau has spent the past 18 months developing and proving the project internally, and it is used within our products to translate our core algorithmic code from a shared code-base, for deployment within both JRules and Rules for .NET. The project represents the second generation of our code translation capabilities and includes support for Java 5 generics. Alexandre has created forums, a Wiki site and a blog to spread the word and answer your questions. You can of course also browse the source code!

We are soliciting community involvement, and judging from the messages in the forums we are off to a very good start. Don’t hesitate to get involved so all Java developers can benefit from a truly first-rate source code translator.

Congratulations Alex!

DIALOG 08 may be over, but the web never forgets, and Stuart Culshaw’s blog of the event lives on! Some great content there — hope to see you all next year!

The future runs on System z — don’t forget to pack your business rules!

We recently pushed out an add-on module to JRules: Rules for COBOL. This sweet little addition to the BRMS product family allows you to import a COBOL copybook into Rule Studio and then generate a Business Object Model. You then author rules against the BOM before generating COBOL source code to be compiled into your native COBOL application. ILOG Rules for COBOL supports IBM Enterprise COBOL 3.3.

My colleague Stuart Culshaw also blogged on the announcement from DIALOG 08.