Beware the Big Industry Specification Up Front

If you have done any development in Java-land, then surely you came across the dreaded three letter word EJB.  And you were most likely duped into thinking it was great.  I did!  Then I realised it was just a specification.  It was a great big, furry, non-executable PDF.  A specification for managing objects but the creating of these objects were just horrid.  EJB3 was a clean-up exercise, but still far from nice.
A couple of months ago I ran into OSGi again, but with SCA on top of it.  Horrid!  SCA is yet another warm and huggable specification.  But it’s so ugly to work with.  Everything feels so over the top complicated and restrictive in expression.  And the tools that I saw built on this SCA implementation were just awful.  Beyond being buggy, the enforced paradigm was just counter-productive.  When will tool vendors realise that talented developers do not want a diagramming interface to write code?  But the root cause is that the SCA specification describes the diagramming notation. Yuck!  Same reason that I do UML sketches with a lot of bastardisations with no tie-in with my code.

And let me not go into domain specific big vendor specs, designs, blue prints, etc. like IBM’s Insurance Application Architecture (IAA). Nasty stuff.

More commonly, I see so many self-confessed agile teams fearing the dreaded big design up front, and the big requirements up front document thrown over the wall.  If there is such a fear for big-x-up-front, why is there no fear for big-industry-and-vendor-specs-up-front like EJB, SCA, IAA, etc?

Why?

There are deep lessons and principles lurking beneath this surface.  Agile demands you to be a lot more aware of actions, decisions and consequences.

So why do you choose not to be agile when you are trying so hard to be agile?

OSGi Article on DZone

An article I wrote which questions the readiness of OSGi for enterprise development has been published in two parts on the EclipseZone at DZone.  Read the first part at http://eclipse.dzone.com/news/there-place-osgitm-enterprise-. Watch out for the hyphen at the end of the URL, it’s significant 🙂

Many thanks to the kind folks at DZone for the publication.

AWOL at TSS-JS

I was (still am) extremely disappointed at not having made the trip to Las Vegas to present my bit on OSGi at theserverside.com Java Symposium. To date, I am still waiting for my USA visa 😦 The TSS folk and myself have had a quick exchange about me doing a webcast later on this topic. Let’s hope we can pull it off.

Well, the event has come and gone, but you can download my presentation at http://wiki.javasymposium.com/download/attachments/501/Aslam+Khan-OSGiPresentation.pdf

OSGi Cookbook: #1. A Simple Bean

This is something that I have been meaning to do for some time now, i.e. an OSGi cookbook. So this is the first in a series of recipes, with each one building on the next in usefulness and complexity. This recipe is really for newbies, just to take some of the mystery out of OSGi and to introduce some of the emerging tools for OSGi development.  If you have never done anything with OSGi before, then I recommend that you work through Neil Bartlett’s excellent series on getting started with OSGi.

Getting ready

 Ensure that you have maven andthe pax-construct scripts installed.The installation is straight forward, just follow the instructions on their respective web sites.

#1. A Simple Bean

This recipe creates a service out of a simple POJO. The service doesn’t do anything useful, but the recipe is a simple way to getyour development environment up and running.

  1. Create a project using pax-construct.The pax-construct scripts uses maven and the maven-pax-plugin.Using the familiar maven terminology of groupId and artifactId, create the project with a groupId of net.aslamkhan and artifactId of osgi-simplebean.
    /> pax-create-project -g net.aslamkhan -a osgi-simplebean
    ...
    [INFO] Archetype created in dir: /Users/aslam/projects/osgi/osgi-simplebean
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESSFUL
    [INFO] ------------------------------------------------------------------------
  2. Have a look at what’s in the project and make sure that it does build cleanly (well, there’s actually nothing worthwhile to build here, but let’s make sure that everything is still ok).
    /> cd osgi-simplebean		
    /> ls -l
    -rw-r--r--   1 aslam  aslam  2354 Jan  9 10:26 pom.xml
    drwxr-xr-x   5 aslam  aslam   170 Jan  9 10:26 poms
    drwxr-xr-x   3 aslam  aslam   102 Jan  9 10:26 provision			
    /> mvn package
    ...
    [INFO] ------------------------------------------------------------------------
    [INFO] Reactor Summary:
    [INFO] ------------------------------------------------------------------------
    [INFO] net.aslamkhan.osgi-simplebean (OSGi project) .......... SUCCESS [1.689s]
    [INFO] osgi-simplebean - plugin configuration ................ SUCCESS [0.004s]
    [INFO] osgi-simplebean - wrapper instructions................. SUCCESS [32.144s]
    [INFO] osgi-simplebean - bundle instructions ................. SUCCESS [0.003s]
    [INFO] osgi-simplebean - imported bundles .................... SUCCESS [0.002s]
    ...
  3. We now need to add in the dependencies for Spring Dynamic Modules for OSGi.  Instead of hand crafting our maven pom.xml file(s), we again use a pax-construct script to add the repositoriesfor the Spring distributions.  From this point onwards, I will not show the output of commands unless it helps to illustrate a point.
    /> pax-add-repository -i spring-milestones 
       -u http://s3.amazonaws.com/maven.springframework.org/milestone
    /> pax-add-repository -i spring-snapshots 
       -u http://static.springframework.org/maven2-snapshots 
       -- -Dsnapshots "-Dreleases=false"
  4. Import the spring-osgi-extender bundle, and the slf4j logging service bundle.
    /> pax-import-bundle -g org.springframework.osgi 
       -a spring-osgi-extender -v 1.0-rc1 
       -- -DwidenScope -DimportTransitive

    If you look at the contents of the provision/pom.xml file, you will see a bunch of dependencies that have been pulled inthe moment we imported the spring-osgi-extender bundle.

    <dependency>
    	<groupId>org.springframework.osgi</groupId>
    	<artifactId>spring-osgi-extender</artifactId>
    	<version>1.0-rc1</version>
    	<scope>provided</scope>
    </dependency>
    ...
  5. Now that we have all the infrastructure things sorted out, we can start cooking. The quickest way to get cooking is to usethe pax-construct pax-create-bundle script. In this instance, we will create a sample bean with the necessaryboilerplate files needed for Spring Dynamic Modules. 
    /> pax-create-bundle -p org.example.bean 
       -- -Dspring -Djunit

    Notice that another directory org.example.bean has been created. Furthermore, this maven module has been added to the root (i.e. parent) ./pom.xml file. Also conveniently created, is asample bean and associated unit tests in org.example.bean/src directory.Edit the org.example.bean/src/main/resources/META-INF/spring/bundle-context-osgi.xml file to contain the following.

    <?xml version="1.0" encoding="UTF-8"?>
      <beans xmlns="http://www.springframework.org/schema/beans"			  
        ...
        xmlns:osgi="http://www.springframework.org/schema/osgi"
        ...>
    	<osgi:service ref="myExampleBean">			        
    	  <osgi:interfaces>			            
    	    <value>org.example.bean.ExampleBean</value>			        
    	  </osgi:interfaces>			    
    	</osgi:service>
    </beans>
  6. We should be able to build this and fire it up in the Apache Felix OSGi implementation.  But wait!  We have not downloaded, nor installed Felix.  Not to worry, maven-pax-plugin will download Felix and fire it up for you, allpart of the pax:provision goal.
    /> mvn clean install pax:provision
    ... properties (org.springframework.context.service.name=org.example.bean)
    ->

    Let’s check if our org.example.bean bundle is installed and active. From the Felix console, enter the following.Also notice that the spring-osgi-extender bundle and spring 2.5 jars are now available as bundles as well.

    -> ps
    START LEVEL 6			   ID   State         Level  Name
    [   0] [Active     ] [    0] System Bundle (1.0.1)
    [   1] [Active     ] [    1] org.osgi.r4.compendium (1.0.0)
    [   2] [Active     ] [    1] Apache Felix Shell Service (1.0.0)
    [   3] [Active     ] [    1] Apache Felix Shell TUI (1.0.0)
    [   4] [Active     ] [    5] spring-osgi-extender (1.0.0.rc1)
    [   5] [Active     ] [    5] jcl104-over-slf4j (1.4.3)
    [   6] [Active     ] [    5] slf4j-api (1.4.3)
    [   7] [Active     ] [    5] spring-osgi-core (1.0.0.rc1)
    [   8] [Active     ] [    5] spring-osgi-io (1.0.0.rc1)
    [   9] [Active     ] [    5] spring-aop (2.5.0)
    [  10] [Active     ] [    5] spring-beans (2.5.0)
    [  11] [Active     ] [    5] spring-context (2.5.0)
    [  12] [Active     ] [    5] spring-core (2.5.0)
    [  13] [Active     ] [    5] spring-web (2.5.0)
    [  14] [Active     ] [    5] spring-test (2.5.0)
    [  15] [Active     ] [    5] aopalliance.osgi (1.0.0.SNAPSHOT)
    [  16] [Active     ] [    5] backport-util-concurrent.osgi (3.0.0.SNAPSHOT)
    [  17] [Active     ] [    5] slf4j-simple (1.4.3)			
    [  18] [Active     ] [    5] org.example.bean (1.0.0.SNAPSHOT)
    ->

    Now, check that the service is available.

    -> services
    ...
    org.example.bean (18) provides:
    -------------------------------			
    org.example.bean.ExampleBean
    org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext, 
    ...

That’s it for this recipe.  Overall, pax makes it really painless to get your OSGi implementation up and running in your developmentenvironment.  Combined with the convenience of spring-dm, we have the start of something really productive.

Treading into OSGi

On my current project, the number of JavaBeans / Spring Beans is becoming a bit too much to handle. What’s becoming quite painful is that there is a significant number of combinations and dependencies between beans, and between the various web applications that we are rolling out. Simply including a few “common” JARs in multiple WAR’s is not good enough anymore.Modularity and dynamic modules has always been painful in Java, mostly due to its ridiculous class loader. But OSGi seems to offer significant improvements in this area.  The possibilities of having classes “plugging” into each other, resolving versions, etc., all dynamically is terribly exciting and, at the same time, frightening.Nevertheless, I will be venturing into OSGi land and will blog my experiences and hopefully provide a some simple HOWTO’s and tutorial style posts.