Re: Patently Ridiculous

After reading Ed's post about software patents I remembered a story that occurred around the time when I fell in love for the first time with the game of Go.

It must have been a good ten years ago, or more, when I frequently played on the Internet Go Server. When you are a beginner you have to work your way up the ladder by winning games. One way of winning is to challenge players of around your ranking.

When I challenged one of the lower rated players, I stumbled upon a guy who was hiding from his fellow Masters in Go by logging in with an alias. However, he forgot to unset the "open" flag so I found myself playing against a much stronger opponent. This is something you just cannot win (there is no such thing as luck in Go.)

While we were playing and chatting, he introduced himself as Jean-loup Gailly. I Yahooed him (no Google back then) and found out that he is one of the authors of gzip and masters several other crafts very attractive to the inner-geek (like his work on pulsars).

While I don't know his stance on software patents, I assume that he is against them. Jean-loup has analyzed several patents to make sure that the gzip software avoids all of them.

Jean-loup on his website [3]:

"I have probably spent more time studying data compression patents than actually implementing data compression algorithms. I maintain a list of several hundred patents on lossless data compression algorithms, and I made sure that gzip isn't covered by any of them. In particular, the --fast option of gzip is not as fast it could, precisely to avoid a patented technique."

He continues by making an interesting remark:

"The first version of the compression algorithm used by gzip appeared in zip 0.9, publicly released on July 11th 1991. So any patent granted after July 11th 1992 cannot threaten gzip because of the prior art, and I have checked all patents granted before this date."

I understand from this that patents are void if somebody can prove that the invention was done before it was filed. So filing patents for simple things might not be so damaging as it appears (somebody try to file a patent for the singleton pattern and see what happens). This is called prior art.

The big crunch

One interesting story of Jean-loup is about a compression technique claiming to be so effective that it could compress any file with at least one bit. Of course, a child can see that this would recursively compress the output file to zero bits. The US patent office worked on this patent for three years before finally granting the patent.

--

[1] While I was researching for this blog post I found out that there is a free iPhone client for Go.

[2] Carl Barks, the famous Donald Duck cartoonist, once drew a story where Donald Duck and his nephews salvaged a ship by pumping thousand of ping-pong balls into it. The word goes that this story prevented granting of a patent (unfortunately this appears to be a hoax).

[3] Jean-loup Gailly's site

Invitation to a sunny party

Hi There!

We would like to invite you to attend the Eclipse DemoCamp in Nieuwegein which will take place at June 23.

We will celebrate the Helios release at the end of June and the e4 release in July.

The Eclipse DemoCamps are an opportunity to showcase all of the cool technology being built by the Eclipse community. This is also an opportunity for you to meet Eclipse enthusiasts in your area.

Thanks

to the Eclipse Foundation for the text and Vahid "Pixels" Vafai for the cool graphics.

ECF Discovery: How many Zookeepers does it take to screw in a lightbulb?

If you use OSGi remote services (See OSGi Compendium Specs chapter 13) you have to know the other end. In large installations this configuration can be quite cumbersome.

At Remain Software we develop software to manage nodes in a network. We want our nodes to register themselves to us when they are in the network. This is fine if you manage a small office but not if you manage smart lightbulbs in a sky scraper.

As soon as the lightbulb is screwed into its socket, it can tap some power to activate its OSGi runtime. The runtime will activate the ILightBulb interface with methods dim(int), on() and off() as a remote service. Now, how do we get this service to interested parties...

ECF For the Win
The ECF discovery framework enabled us to create a Zookeeper based Discovery implementation. An addition to the already existing JmDNS (Zeroconf/Bonjour) and jSLP implementations.

An Apache Zookeeper server will replicate configuration data between other Zookeeper servers. The Zookeeper servers know each other and clients know one Zookeeper Server. So the smart bulb (which runs OSGi or did I mention that already?) is preconfigured with the address of its nearest Zookeeper server or gets this information dynamically by some kind of IP broadcast.



When the lightbulb publishes its Remote Service, ECF wakes up and publishes this service through the provided Discovery implementations. The Zookeeper discovery provider will immediately notify its nearest peers and the new lightbulb service is registered in all Zookeeper instances. When the Zookeeper instance that is connected to an interested party receives the data, the Discovery implementation will publish this service in that OSGi container.

The Lightbulb Control Center is waiting for the ILightBulb service and magically creates a UI in its console (the sparkles DO NOT appear in reality. I made that up).

The Building Maintainer can now control the lightbulb.

More..

For more information or if you want to Tinker with the code, please visit the wiki.

Acknowledgements

Ahmed Aadel, one of the great developers working at Remain Software created the Zookeeper Discovery Implementation. Thanks to Scott Lewis and Markus Kuppe from our ECF team for support and Chris Aniszczyk for easy access to Tinkerbell (tm)

Animations done with the Gimp.

Am I Fragment or am I Bundle

Sometimes you want to know if there are fragments attached to a bundle so you can perform some logic. Eclipse's Platform class is able to help you in this area because it lets you get a list of BundleDescription objects like this:

BundleDescription[] binfos = Platform.getPlatformAdmin().getState(false).getBundles();

for (BundleDescription bundleDescription : binfos) {

if(bundleDescription.getHost() != null)

System.out.println("I am Fragment");

}

OSGi: GESUNDHEIT!

This blog is about the upcoming OSGi course run by Neil Bartlett. If you are writing moderate to large size Java applications and you have heard about OSGi but are still a little puzzled about what it does: OSGi is the biggest thing that happened to Java this century. Here are three reasons why this is the case:

1. OSGi enforces modularity

Making systems modular feels good to every engineer. It is just a logical thing to do when systems grow. We define and design modules in our systems. But once implemented, they cannot be taken out or replaced by a better version because they get entangled so quickly. When coding OSGi style, this will not happen. Why? Read on.

2. OSGi defines module boundaries

One reason modularity is enforced is because you define a clear entrance point in your modules which is the interface to the rest of your system. No unclear API due to many public classes, but a well defined set of visible classes that were meant to be API. The rest is hidden, public or not public. Why is this handy?

3. OSGi helps you manage complexity.

Once you can see your modules as giant blocks of LEGO(tm) (having a clear interface) you can think about what the weak blocks are and how they can be replaced or hardened. Do all your work inside the module but be faithful to the interfaces with the outside world. This is how they build Skyscrapers.

Although it sounds to good to be true, true it still is. And even though OSGi sounds like a sneeze, it is all about the GESUNDHEIT of your applications.

We host an OSGi course in December. There are a few places left. Neil Bartlett will be your teacher. By the way, Neil did write the book, a free book and the eye opening first chapter is right here.

Apart from the course we will take you on a Amsterdam by Night tour where you will get a good, but not too good, impression of the unique Amsterdam culture. It is about 30 minutes drive from the training location to the center of Amsterdam.

See you there!

Eclipse API tools: Execution Environments

This content first appeared on the Eclipse Wiki!

Execution Environments in API Tools

Execution Environments (EE) are a neat concept within OSGi, however, things can become complicated when developing against multiple EEs. When you want to contribute code to Eclipse, chances are that you will be asked to downgrade your code to the lowest possible execution environment.

For example, suppose that you want to contribute a Twitter client to Eclipse, or any other open source platform. If you are already accustomed to the OSGi way of working you would probably want to split your code into several independent bundles (AKA modules or plug-ins). At least you would provide a module named org.eclipse.twitter.core and one called org.eclipse.twitter.ui. To be really useful, it would be the bomb if the core bundle could run on, say, a watch. For watches, and other minimal devices there is a special Java environment which is a subset of Java 1.4 (without regular expressions unfortunately) called Foundation 1.1 or CDC 1.1/Foundation 1.1. There is also a Foundation 1.0 but this is really stone age and hardly not used. From what I know, Eclipse uses the 1.1 as a minimum level.

Your org.eclipse.twitter.ui package would normally not require such a primitive environment, however, if somebody wanted to implement a twitter client on a watch, he or she could at least use your core to handle the difficult stuff.

Specify an Execution environment

Execution Environments for a specific (plug-in) bundle can be specified in the manifest editor. It is generally only necessary to specify the lowest EEs that your bundles require. In the preferences there is also a section Execution Environments in the Java section. Just type "exec" in the preference search box to get the indicated page. This merely states which installed JRE's are able to provide the required Execution Environment. It is clear that a Java 5 JRE cannot provide a Java 6 Execution Environment. The other way around is possible but that generally provides more than is required and can lead to confusion.

For example, a Java 5 JRE can provide the "split()" method for String but this method is not available in Foundation 1.1. Even if your execution environment was set to CDC 1.1/Foundation 1.1 in your manifest file, this problem would only be detected when it was executed against a Foundation 1.1 JRE.

Setup API Tooling

However, we want Eclipse to guard this and warn us when we try to use illegal (future) methods or classes. In order to set this up, we first have to get the available execution environments from the Eclipse update site. In order to do this, go to the preferences and type 'API' in the search box. Then select the "API Errors/Warnings" page. If you open the first section "General" and select "Error" for the "Invalid references ..." field, the "Supported Environments" box will be accessible and you can click on the provided link.

Clicking this link will open the familiar P2 installer dialog. Select the proper download site and then download all available Execution Environments.

Make sure to switch on the required Errors and/or Warnings. There are convenient buttons available to flip all switches at once to the desired state. Be restrictive if you are serious about your execution environment.

Activating the Project for API tooling

The last thing to do is to activate the project for API tooling, only setting the Execution Environment in the Manifest file will not do anything. Before a project is created, you are able to specify if the API Tooling must be activated by checking the "Enable API Analysis" field.

This will set a project nature that in turn provides special builder classes to check for EE JRE incompatibilities (amongst other things.) If you have forgotten to check this box then you can also do it later. Right-click your plug-in project and select the "API Tooling Setup" option from the PDE Menu in the context menu. This will apply the nature after the project was already created.

A dialog box will appear to warn you that an API baseline is not set. You can ignore this if you only want to use the API tooling to specify the Execution Environment.

Checking your Source

Surely, some of your sources will be showing the red cross. Open a source. Press CTRL+. (dot) to go to the first error and hoover to find the cause. This could look something like this:

Many thanks to the PDE team for this great tool!

Running Equinox OSGi and ECF on the System i - Part 2

In the previous installment of this series I have demonstrated what it takes to run OSGi on the AS/400 (or System i as it is called today.)

Goal

In this part we take the OSGi installation one step further by adding additional bundles to the initial installation. A bundle is OSGi slang for a group of Java classes that together perform certain tasks. They are also called modules or plug-ins (because of their plug and play nature).

Remote Services

As I mentioned earlier, our company is in the process of creating a multiplatform SCM for which we need a Multiplatform Communication Layer. Multiplatform can be mapped to Java and Communication Layer translates to the Eclipse Communication Framework, ECF. Since we have already decided to use the OSGi technology as the runtime container, we were also looking for a OSGi defined solution. As you might know, OSGi only provides specifications. It is up to others, like the people from Eclipse and Apache, to write an implementation. One of the new specifications in the upcoming OSGi release is referred to as RFC 119. It describes how an OSGi service should be addressed remotely.

Remote Services is important to us because we have to sometimes manage several hunderds end-nodes. Beeing able to do so in standard OSGi makes us free from the choice of using one specific remoting solution. The RFC 119 technology enables us to choose from different implementations and we have tried both the Apache and the Eclipse implementation.

Cleanup the OSGi installation

If you have followed the previous article, you will notice that there are a lot of bundles in the plugins directory. For our current purpose we don't need all of them and we also want to be as clean as possible. So we are going to move all the unused bundles to a special directory called "Equinox Bundles" we can get to this directory if we need another bundle later. Create a directory with the name "Equinox Bundles" in the /QOpenSys/Equinox directory and move all the bundles in the "plugins" directory into this directory. Now copy back the three jars from the "Equinox Bundles" directory that start with:

• org.eclipse.equinox.common
• org.eclipse.osgi
• org.eclipse.update.configurator

and are followed by a version number and a build identifier.

Setup the configuration.ini

OSGi is configured using the config.ini file in the installation directories 'configuration' directory. OSGi already created this directory for you after the first launch. If it is not there, please see the first article and run the framework.

Now we are going to create the config.ini file with the following content:

osgi.bundles=org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start

eclipse.ignoreApp=true

osgi.install.area=file:/Qopensys/Equinox/plugins/

osgi.console=667

osgi.noShutdown=true

Line 1 instructs the OSGi framework to first start the common bundle and then the configurator bundle. The configurator bundel will automaticall

y install all plugins that are located in the plugins directory of the install directory. In the next step we will put all of our non-framework bundles in that directory.

Line 4 will listen at the TCP/IP port 667 with a telnet server. You can use putty or any other client to telnet to port 667 of this machine. It will give you the console and enables you to run the OSGi framework in a batch job and still be able to control it. Mind you that many OSGi installations happily run without a console or are controlled through other means (e.g. a controlling bundle).

Running as a Batch job

To run the OSGi framework as a batch job start the following command (adapted to the id of your download)

SBMJOB CMD(JAVA CLASS('/QOpenSys/Equinox/plugins/org.eclipse.osgi_3.5.0.v20090520.jar')) JOB(OSGI)

Now fire up your favourite telnet client and try to access port 667. Keep in mind that you can only connect one session at a time.

Now type the "ss" command to show that the framework is running and indeed all our bundles are active.

The exit command will stop the framework and exit. The disconnect command will terminate the telnet session but will leave the framework running.

Setup ECF

Since we are Eclipse junkies we setup our distribution server with the ECF software from Eclipse. So download the ECF SDK. If this link is broken then just go to the Eclipse site and navigate to the ECF SDK and get the zip. Then drop all the bundles from this zip into the '/QOpenSys/Equinox/plugins/plugins' directory. That is correct, two plugins directories.

The reason for this is the org.eclipse.osgi.configurator bundle. It will install all bundles that are found in the plugins directory for us so we don't have to do that ourselves. Since we have installed OSGi in the /QOpenSys/Equinox/plugins directory, we have two directories with this name.











Now stop the framework and submit the job again. Telnet to port 667 and try the "ss" command. This time you will see a lot more. You can filter the list to show only the active bundles by using "ss -s active"

The Next Time
The next time we will create two plugins. One will consume the remote service that the other will provide.

Thank you for your feedback