Aehso’s Output

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

Bugzilla 106176 (Provide more flexible workspaces) documents the evolution of Eclipse 3.2 Flexible workspaces:

…a project can now be created whose files and directories are stored on a network, in a database, or any facility capable of storing hierarchies of files and directories. This new ability to decouple resources in the workspace from the local file system is called flexible workspaces.

This should be interesting! Projects containing resources that are stored in databases, WebDAV servers and all sorts of other hierarchical repositories. I’m sure the Visual Age veterans out there are already dreaming of the return of the Code Repository Looking around, I don’t yet see any alternative extensions of the underlying org.eclipse.core.filesystem.filesystems extension point but I am sure they will appear with time. (The CVS team plugin provides one that seems to handle the cvs scheme although I havn’t yet found any documentation on using it directly.)

In the meantime, I think I’ll knock up a provider for resources stored at “http” URIs – we need one for our product (so we can link remote WSDL files directly into projects). More when I have an implementation to speak of…

aehso eclipse

Mike’s reference to Google’s new Web Toolkit piqued my interest. It is quite novel in several ways

• It allow web client developers to code in Java rather than JavaScript. The code is translated prior to “deployment” by a Java-to-JavaScript compiler. The generated Javascript code uses a Javascript-based JRE emulation library that provides “most of java.lang and a subset of java.util”.
• The toolkit UI uses Eclipse SWT and (I’m pretty sure) the Java-to-JavaScript compiler is built on top of the JDT code model. Interesting use of JDT!
• The toolkit ships a command line utility that generates template Eclipse projects. Import the skeleton project into an Eclipse workspace and code away. I had to do a little hacking to use the generated launch configuration file to launch the toolkit from within Eclipse but it works. (Drop a copy of the .launch file into <workspace>\.metadata\.plugins\org.eclipse.debug.core\.launches, restart the workbench and then use Debug… and you’ll see it listed under “Java Applications”). This leads to one of the most powerful features. You can debug your application (as Java) when the toolkit is launched and/or you can write/run JUnit tests. Assuming the toolkit behaves itself when translating it all to Javascript you can be pretty confident the end user experience will be consistent.
• You can mix Javascript into your Java source if things get a little hairy.
• The toolkit uses Tomcat to host the “deployed” Javascript/HTML.
• The Javascript generated code (and library) provides lots of web client development conveniences like browser history management and major browser compatability.
• They’re giving it away for free but they only ship some of the source for the toolkit. It would of course be better if they shipped all of the source for the toolkit itself when integrating that much open source software (Eclipse/Tomcat/Mozilla/Rhino) into a free toolkit. Quid pro quo and all that.

See the overview for all the gory details.

All in all, it is not for the Javascript purists but it looks very handy for all those Eclipse/Java developers out there who occasionally need to knock up a web based application…

aehso dev, eclipse, java

A while back I wrote that perhaps more needs to be done to coordinate the efforts of the various top level projects and the conversation seems to be evolving. Some of the subsequent discussion raised an interesting question – what is the relative importance of producing exemplary tools versus extensible frameworks? The difficulty, it seems, is in striking a balance in developing both.

A quick search (in the Eclipse Bylaws and Development Process) produces the definition of exemplary tools. It is worth reproducing here:

Eclipse Platform tools are exemplary in that they verify the utility of the Eclipse frameworks, illustrate the appropriate use of those frameworks, and support the development and maintenance of the Eclipse Platform itself.

To verify and illustrate the appropriate use of frameworks.

Ed thinks the tools are the basis of the Eclipse phenomenon and I fully agree that JDT was the primary driver for the phenomenal rate of adoption of the Eclipse platform. JDT served as the exemplary tool for Platform and subsequently, under the guises of Eclipse.org, it is evolving as both a best of breed tool in its own right and also as a domain specific framework for reuse by other Java centric projects. The JDT exemplary tools alone are not enough to facilitate the requirements of these downstream ‘consumer’ projects.

(It is also worth remembering that the bulk of the Platform and JDT/Team was created by one organization – IBM’s OTI Labs.  Eclipse.org is a very different organization – an open meritocracy, backed by many commercial interests running many top level projects that are tackling more varied and diverse problem domains.)

Then there are the two other types of consumers that Eclipse.org also services:

• Adapters. These comanies consume projects developed under the auspices of Eclipse.org and
  build derived tools outside of the Eclipse.org umbrella. Adapters consume extension points and also some exemplary tools (e.g. the WSDL editor in WTP). But for the most part adapters are building on Eclipse because of the powerfully integrated frameworks it supplies.
• Users. Those millions of downloads don’t come from nowhere! Users are interested only in taking the output of one or more Eclipse.org projects (or derived products) and consuming them as-is. For example a user might choose to use WTP instead of a commercial Eclipse based IDE like Rational Application Developer or one might choose to use TPTP instead of Rational Functional Tester. These users are mostly interested in free tools – derived commercial tools usually provide more function but at a price.

The danger, in terms of under-investment in framework integration, is faced by the downstream projects, adapters and users. As they consume more top level Eclipse.org projects into a single product they might find themselves inheriting frameworks and/or tools that either do not integrate at all or worse duplicate core functionality. In this case, all the exemplary tooling in the world won’t compensate for the inability to get disparate frameworks from different projects to play well together.

So we can hope this will never happen but with the Eclipse.org project count expanding the risks are escalating and as Murphy’s Law states, “If anything can go wrong, it will”. A neutral Eclipse.org mediation facility may be the only way to ensure that top level projects – that are managed by different concerns that compete on a commercial level – produce frameworks that meet the high standard set by the original Platform/JDT contributions and integrate in a consistent fashion into a larger Eclipse “Platform” (hmm, is there a better term for that?)

aehso eclipse, process

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

Lots of discussion in the past few weeks about the gap between REST/POX/Web2.0 and SOA/WS-*:

• Daryl Plummer stoked the fire with his Web Services at a Crossroads piece.
• Tim Bray suggests “Web Style” is a better moniker than “REST”. He also suggests the label “Web Service” should be taken out back and shot (haha).
• Joe McKendrick agrees that the SOA hype has gotten out of hand.
• Dion Hinchcliffe is still trying the align the two approaches and references yet-another-Gartner-acronym, “WOA” – Web Oriented Architecture.
• Tim Bray finally sums it all up by reiterating that he thinks this really is very important.

Thats a lot of clever folks trying to figure out how WOA will fit into the enterprise. It does seem likely to happen given past trend of internet technologies migrating into enterprises but at this early stage nobody seems to have a clear idea of exactly how, where and when.
I’m not suggesting that it will lead to the death of WS-*, too many large organizations have invested too much in WS-* for it to go away any time soon.

It is also interesting that nobody has yet mentioned how early WOA adapters will end up with a JBOWS architecture instead of a WOA, as has happened to some early SOA adapters. WOA doesn’t seem to offer anything to help alleviate this tendancy – if anything it may well suffer from it even more.
They also need to figure out how WOA will fit into developers and IT departments hands – they won’t get far without better development and management tooling.

Don Box wrote a while back asking for suggestions on how to split a hypothetical $100 budget to best improve the Microsoft HTTP/XML/REST platform. That Don hasn’t yet provided his own solution to the problem suggest that a) it isn’t as easy as he thought or b) MS don’t want to give too much advice away to their competitors Either way, there’s an opportunity for some clever Eclipse folks to get their thinking caps on and produce a WOA tools platform, maybe targetting the huge LAMP server platform.

My guess is, in the time honoured tradition of software engineering, someone will produce a new “architecture” layer that sits on top of both SOA and WOA, and over a long period or time one of the architectures will capture the magical point-of-no-return mindshare. Maybe the SaaS (Software as a Service) banner will evolve into that role?

aehso eclipse, soa, software

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

Lattix LDM is a very cool tool for visualising, analysing and constraining dependencies in Java code (check out an online demo). Interestingly, it generates Design Structure Matrix based models to represent (and manipulate) dependencies.

Standalone analysis tools like these are great (I like Headway Structure 101 too) but Lattix piqued my interest when I heard they are joining Eclipse.org. Capabilities like this built into an Eclipse would be fantastic but I’d be interested to find out how deep the integration will go – will they change from analysing bytecode and build on the JDT core Java Model instead? If they did, then we’d be able to analyse and refactor at the same time. Hmmm.

Alas, it’s worth remebering that tools like this cannot easily spot dynamic dependencies introduced by use of the Reflection API and IOC containers, both powerful and very popular facilities used in many modern enterprise projects…

aehso eclipse

Eclipse.org have decided to release ten major Eclipse projects at the same time. Given that many of these projects have interdependencies on each other (e.g. WTP depends on EMF/GEF/JEM/Platform) it will be an interesting exercise in the art of project planning and automated staging and integration of components from a pretty complex graph. It’s also about time, Eclipse project versioning has been all over the place for far too long.

All in all, a brave undertaking, and the distributed nature of Eclipse.org development process making it just that little bit more difficult, if they pull this off they deserve big kudos…

aehso eclipse