Aehso’s Output

Glassfish V3 introduces a new kernel, HK2 (Hundred Kb Kernel) , that has yet another modules model. An interesting statement on the H2K home page is tantalizing:

Modern Java software usually rely on a module subsystem to offer a better level of isolation between parts of the application. Many technologies have been around for years, HK2 proposes a model which is aimed to be friendly to existing technologies such as OSGi yet will provide a path to the implementation of modules in Java SE 7.

Scant details on the OSGi integration/adaptation layer so far, but it’ll be interesting to see how this one pans out…

aehso java, osgi

I’ll not be at EclipseCon this year (it conflicts with polishing our next major product release this week) but if I was there I’d be going to any sessions related to the new Rich Ajax Platform (RAP) incubator project. Think the Eclipse UI running in your browser, with the Eclipse application, developed as plugins, running remotely on a web server.

The Yoxos Eclipse On Demand online Eclipse distribution builder is a good example of the types of applications this framework could support. In fact, given that Yoxos is run by Innopract, the folks who are driving the RAP project, it is probably the best example out there. It’d be interesting to find out how far along they are with their RWT API implementation – attempting to build a remote client framework based on a local client framework like SWT is perhaps a dangerous thing to attempt to do but we’ll see how they fare.

(Not to be confused with the WTP 2.0 AJAX Tooklit Framework (ATF) incubator project or the Google Web Toolkit (GWT) which are designed to also support development of AJAX applications, albeit using other frameworks and user interfaces…)

aehso eclipse, java, osgi, web2.0

The java modularity train-wreck-to-be is still ploughing full steam ahead.  The recent publication of the JSR-277 Early Draft has resulted in a some very sharp criticism.  Lots of posts aggregated in this great post but Patrick Beno’s review is one of the most comprehensive I’ve read. 

InfoQ have just gone and stoked the flames further with post where their questions (solicited from the community) met with laughable responses from the JSR-271/JSR-294 spec leads.  Honestly, the companies and individuals represented on the ECs for this JSR should be asking themselves some hard questions about whether they want to continue to associate themselves with this mess.

aehso java, osgi, process

So IBM are making good use of OSGi in Websphere 6.1.  The OSGi security, module and lifecycle layers can provide can substantial benefits to a server runtime – capabilities like dynamically loading/updating/unloading bundles etc.  These don’t come for free though – most require that the hosted bundles contain code that is properly ‘component-ized’ and adheres to the constraints imposed by the hosting OSGi runtime.  Refactoring a legacy codebase like WebSphere to integrate with a new component model like OSGi would be, I imagine, a mammoth undertaking.  And there is the question of how much of OSGi to integrate with – which subset of OSGi Services are worth using instead of legacy alternatives?

Still, they are stepping in the right direction and it is part of a larger trend.  At ApacheCon Europe a month ago I bumped into one of the JOnAS guys who
told me they are building JOnAS 5 on OSGi.  As I mentioned in the past, I expect most Java based servers worth their salt to be running on OSGi runtimes within a year or two, it’ll be interesting to see to what degree…

aehso eclipse, osgi

So ApacheCon Europe ‘06 has been on in the Burlington for the past few days )anyone wandering around Donnybrook/Leeson Street in the mornings/evenings over may have noticed a “geek increase”. It was a bit smaller than I expected but the quality of the content was superb if one bears in mind that these guys are doing this stuff part time (well, some of them!). The sessions I attended were all SOA/OSGi centric and all were worth attending, from an educational point of view. A very partial summary:

• The OSGi/JSR#291/JSR#277 issue is still very much alive although some efforts are being made to try achieve some degree of compatibility by using a common subset of Manifest headers. However differences apparently already exist in the drafts (such as the version range specifier format used) It is pretty sad to see such open (or should I say JCP-closed) disregard for interoperability between two overlapping JSR. Both are due for delivery in Dolphin (Java 7), perhaps by then the whole Java platform will have been rendered unusable by the plethora of other overlapping JSRs and we (the users) will all have moved on to coding in Ruby.
  Actually, by then, it may not matter – OSGi seems to be gaining considerable traction. Tuesday afternoon had a whole afternoon of talks and discussion from Richard Hall (Felix), Peter Kriens (OSGi Alliance/aQute), Marcel Offermans (Luminis) and a round table discussion involving folks from Apache Maven, Felix, Harmony, Directory Server projects. It seems some efforts are being made to try get Apache Jakarta projects to OSGi-fy their Manifests (via capabilities built into Maven)
• Woden looks good. It’ll be the WSDL2.0 processor that all Java folks end up using (if you need to parse WSDL2.0 that is!). It replaces WSDL4J which is being put out to pasture (it must be, I logged a bug against it over a year ago and still no feedback!)
• Axis 2 apparently has WSDL2.0 HTTP binding support with some restrictions (messages must be “IRI style” compatible). I’m not sure if one even needs to declare a HTTP binding in the WSDL, it seems to be automatically available for all services that have SOAP endpoints.
• Apache Synapse looks nice, in a cute kind of way. I’m not sure I’d call it an ESB since it is really just a very thin routing framework that runs on top of Axis 2 – it doesn’t have any management interface per say and the overview might have been a bit forward looking with regard to the capabilities of the current implementation Synapse looks more like an endpoint intermediary that you one might use to implement specific tasks (XPath/RegExp based routing, binding conversion, logging, endpoint authentication & authorization, transformation (XSLT, E4X, POJO based). I’m not sure you’d host your service implementations on it.
• Apache Tuscany work is ongoing and I bet it will be for some time yet! I’m not certain of their claim that it will simplify the development of business solutions, if only because it is based on SCA which is turning into an absolute beast of a set of specifications – think “one spec to rule them all” type big, and with big specifications comes complexity, not simplification. From an implementation point of view, a huge problem is that the SCA specifications do not have either a reference implementation nor a compatibility test suite and according to Simon Nash and Jeremy Boynes (both of IBM) there are no current plans to develop either. Also it seems curious that the SCA specifications are not being developed under the auspices of an open body like OASIS, W3C or the OMG – why not? Some would say the overall approach seems incredibly vulnerable to repeat the mistakes of CORBA. It will also be interesting to see if any convincing response is given to Ron Ten-Hove’s recent critique of SCA.

aehso dev, java, osgi, oss, soa

The new Rich Server Platform proposal does seem very interesting – tooling for packaging Web Applications (Java /Lazlo/PHP based) into OSGi bundles and deploying them onto Equinox/OSGi runtimes that are running on remote server VMs.

The goodness here comes from leveraging the OSGi R3 runtime’s dynamic bundle management capabilities to manage the lifecycle of bundles. And of course there is value to some in the fact that the underlying OSGi frameworks are neither Eclipse nor Java centric. So rather than dealing with technology centric deployment and packaging tooling and APIs, server side components are packaged into OSGi bundles and deployed using OSGi’s built in mechanisms. That includes being able to execute an (non-UI) Eclipse plugin on the server side. RSP takes this approach one step further by providing the tooling necessary for users to be able to create applications composed of local and remote bundles (i.e. hybrid RCP/RSP applications). RSP-UI will make this technology a lot more accessible to users.

From a server developers point of view, the OSGi R3 ‘kernel’ is the ideal foundation for dealing with the complex issue of creating an open and extensible server runtime – if only we had the luxury of re-writing existing servers from the ground up to take advantage of it! However, users are already experimenting with running bundles on remote VMs – they’ve even got Equinox running on a Slug and of course there are other OSGi
runtimes out there.

Wolfgang Gehner thinks this is a disruptive technology, and I’d certainly agree that is has the potential to be very compelling for server developers, tools developers and users alike. The problem might be bootstrapping adaption – getting the OSGi core into the server distributions and convincing users to start packaging their components as OSGi bundles (rather than .war files, for example).

I wonder how these initiatives will relate to IBM’s Autonomic Computing efforts.  In a previous incarnation, I had the pleasure of participating in a AC Solution Install working group that was working on providing solutions in a related space (supporting self-configuring servers).  I wonder will the AC toolkits need to incorporate OSGi at their core – I suspect so…

aehso eclipse, java, osgi

Mike Milinkovich and Gunnar Wagenknecht picked up on my earlier post about Eclipse.org project disarray. It’s great to see the issue being discussed openly so I thought I’d clarify where I’m coming from (before someone jumps on me from a height).

On the topic of inter-project interactions, to me there are four main types of interaction

• pushing functionality down (“top down”) proposals
• promoting framework reuse by downstream projects (“bottom up” interaction).
• peer project driven cooperation (usually via refactoring to a common upstream project) as Doug describes.
• project “splitting” interactions, where a project splits to decouple unrelated components.

The comments on Mike’s blog have good examples of each and I suspect there are many, many more that might potentially make sense but have never even been broached publicly. I’ve witnessed obvious integration points being missed possibly out of ignorance – these top level projects are big, it’s hard to know them all inside out So, lots of interaction types.

To the external observer, the process for these interactions is to wait for one conscientious party to instigate ad-hoc discussions, perhaps on a PMC and/or a committer level (often facilitated by Bugzilla). We all know approach does work well for micro issues, years of practice in the OSS community proves that. It sometimes even works well for macro level issues where the parties know each other well and have a shared interest in cooperating.

But Eclipse.org is fostering frameworks that not only build on a common base platform (and sometimes shared sub-frameworks), it is publishing multi-tiered frameworks that commonly have interdependencies on each other. This is a more complex problem space to manage than, say, Apache Commons, or even Apache HTTPD. (That said, I do agree with John A’s comment that perhaps platform can be broken up a bit more – splitting Equinox was great, treating RCP as a separate top level project (away from IDE) might also make sense).

Macro level integration issues like proposing change of ownership of extensions or evaluating the risk of introducing dependencies on extensions developed elsewhere are sometimes contentious and they do not always progress via the above process. Sometimes they don’t progress at all and that in itself isn’t necessarily a problem, until the project hits 1.0. Then it has an API set to maintain that doesn’t fit with other Eclipse.org frameworks. The requirement to support 1.0 APIs is where the problem really starts hits home – before then projects are in their “honeymoon period” and I’m not sure the cost is fully evaluated by the younger projects. I think this is perhaps where the foundation (and Planning/Architecture Councils?) can perhaps facilitate a little more. Not necessarily driving or forcing these types of interactions, but mediating them, from the “bigger picture” perspective.

This point should be taken in the context of the recent explosion in growth of Eclipse.org, both in terms of new members and top level projects. It is a growing pain that the foundation needs to look at. As I mention above, the problem space that Eclipse.org is trying to govern is a little more complex than that of most OSS communities. Perhaps projects need to be monitored just a little in order to end up with a truely consistent framework.

aehso eclipse, osgi, process

So JSR #291 (Dynamic Component Support for Java), a.k.a. OSGi R4, has been approved. It is interesting to read the concerns expressed in SE Executive Committee’s voting comments. There is a huge overlap with the work that is being done under JSR #277 – that project looks kind of dead in the water now. Exactly how the JCP SE/EE can allow two competing module specifications to evolve is beyond me but it happened so it would seem the JCP is now broken. That said, JCP cannot expect to write every new specification from scratch and even not meddling with de-facto specifications (e.g. DOM) is also ocassionally appropriate.

Unfortunately, Eclipse.org is also starting to exhibit similar cracks. A cursory look at the architectures of many of the top level projects (WTP, STP, TPTP, BIRT etc.) shows the lack of intra-project cooperation is resulting in frameworks that simply don’t integrate with one another in they ways we all want them to. I’m not sure whether the PMCs are responsible for this failure or if it is also the committer’s responsibility to “fit in” to the larger Eclipse eco-system better.

The end result is a selection of overlapping frameworks (and derived vertical commercial products) that will not peacefully co-exist on a single Eclipse runtime or integrate in any meaningful manner. So much for re-usability. Of course Eclipse.org are trying to get their release processes in order (and I hope that effort works out) but architectural inconsistencies and overlaps in the platforms is a much larger and deeper rooted problem altogether.

aehso eclipse, java, osgi

A while back I blogged about the LinkSys NSLU2 (a.k.a. the slug). Here’s a flash demo of developing, deploying and running Equinox plugins on the slug using Eclipse and a little ssh. Impressively easy…

aehso osgi