Blogs

RedMonk

Skip to content

OSGi and The Rise of The Stackless Stack: Just in Time

When I first heard about OSGi I had no clue what it was. To be honest I initially confused it with OGSA, the Open Grid Services Architecture, which seems like another over-ambitious (and ultimately unsuccessful) initiative to enable pooled computing resources through traditional vendor standards efforts.

But I swiftly realised the error of my ways. OSGi has massive potential. It is an industry changer. Any time an initiative from the cell phone and device world is enthusiastically adopted by major middleware vendors you think it has to be worth examining. So what is the Open Services Gateway Initiative (OSGi) and what does it have to do with Stackless Stacks? Component-based development is a common idea, but component-based production is a whole different ballgame.

OSGi in the Wild

OSGi allows modules of Java classes to be loaded on demand. There is no need to load the entire Java stack to run an application – just the runtime services it actually requires. OSGi therefore enables a more dynamic, less constricted Java, which partially explains its enthusiastic backing from major vendors such as IBM, BEA and Oracle. Sun is not such a big fan because it fears a loss of control of Java stack standards efforts. (How many times will I have to write that?)

IBM and BEA are currently more aggressive in consuming OSGi than exposing it in their production environments. Nobody is talking about a Websphere OSGi Edition for example. But OSGi is underpinning some of IBM and BEA’s most interesting technologies.

BEA’s “micro-services” architecture, allowing it to be far more flexible in absorbing acquired technologies, and repackage existing technologies in different bundles, is OSGi-based.

Meanwhile IBM Lotus Expeditor, a client side integration framework, is extremely flexible. Customers can, for example, choose to deploy only those services which they require for collaboration applications. That is, the enterprise can define and deploy its own service bundle, based on a subset of the “stack” IBM provides. Another powerful effect of using OSGi in its Lotus products is the slick and seamless integration it enables- for example with Cisco IP Communicator.

The Death Of The Stack: SOA for production

When I planned to write this quick post I had a title in mind – the Death of the Stack. While I realised the inflammatory and possibly misleading aspects of the title, I felt it captured something of the move to more flexible production environments. The “stack”, after all, as seen on PowerPoint decks slide everywhere is a monolithic but comfortable place to run apps with confidence (and to sell middleware). It was on an OSGi call with Ian Skerrett, marketing director of the Eclipse Foundation (client), which is a strong supporter of OGSi in the shape of its Equinox runtime project, that my colleague Cote casually came up with a far better construction: “oh sure… you mean a Stackless Stack”.

As Cote himself might say- blammo!

In case you didn’t take that in – Eclipse, which used to be a developer tools framework is now evolving into a fully fledged component/service oriented runtime. SOA is one of the most hyped terms of the recent few years in IT, but the story has largely focused on design time, rather than runtime flexibility. What would a SOA for middleware deployment look like? Like OSGi.

Another technology carrying us towards the stackless stack is Spring, which simplifies interfaces for enterprise Java programming. Spring has exploded onto the Java middleware scene-already adopted by BEA, IBM (client) and Oracle in response to strong customer demand for the open source software.

Starting Up With Distributed OSGi Runtimes

An interesting example of the stackless stack approach comes from RedMonk client Paremus, which recently announced support for Spring Dynamic Modules in its Infiniflow Service Fabric product. Paremus uses the Service Component Architecture (SCA) descriptions to manage the component model, so a Spring application can be dynamically loaded and reloaded from a single machine to a massive cluster.  Build in Eclipse then choose a target deployment architecture. Sweet.

As Paremus puts it: “the production runtime is built in the same way as the application”. Its early days for the company but the kind of standards-based open source approach it is taking is finding favour, notably in financial services companies in London and New York. Spring is increasingly an ecosystem, but also an open source project with significant services revenues.

Springtime for Covalent

SpringSource, the commercial arm of Spring, recently announced it is acquiring Covalent (also a RedMonk client). This transaction will bring together two of the most successful examples of the new commercial software reality: paying vendors for services rather than code. Covalent is a major supporter of Apache, and offers support for the web and application servers. While traditional software companies encouraged customers to deploy applications on expensive JEE application servers, Covalent helps companies such as Bear Sterns, which are building enterprise-class scale out applications comprising hundreds of open source servers, but want enterprise support from a firm where the coders who built the runtimes work. SpringSource may just have lost some of its purity, but the transaction points towards the future economics of the industry. The Register developer zone calls the combo an “open source supergroup“. Well Rod Johnson, head of SpringSource, is definitely a rockstar. You’re going to hear a lot more from him. Frankly Rod is far more deserving of the tag Top Leader in Open Source business than anyone at RedMonk, but there you go. At this point I consider it a racing certainty that SpringSource is eventually acquired. Possibly sooner rather than later- the combination of Spring and Apache has got to worry traditional app server vendors. The game is changing.

Stackless, Microsoft and Green APIs

It is not just the Java world that is componentising. Microsoft is also delivering just-in time functionality to allow for targeted bundles, rather than needing to run the entire Windows stack. In discussion with Rob Bernard, Microsoft’s chief environmental strategist the other day, he suggested the approach had ecological implications. If you only run what you need you use less power. I mention Microsoft here primarily for context though, to show stackless isn’t just an OSGi story. It would be great to get your thoughts about where more flexible stacks are heading.

For more background we have some great RedMonkTV shows about OSGi, Equinox and so on.

update: super bonus OSGi buzz link roundup.

 

 

Technorati Tags:

Categories: Uncategorized.

Comment Feed

39 Responses

  1. Related to Eclipse and how it’s now evolving into a component/service oriented runtime, you might find interesting that Jeff McAffer, one of the first OSGi proponents as an alternate runtime model for Eclipse back in 2003 and the Equinox Project Lead, is leaving IBM to start a new company around enabling success with Equinox and Eclipse in the runtime space: http://dev.eclipse.org/blogs/jeff/2008/01/24/movin-on-well-sorta/

  2. Hi James,

    Re:
    > IBM and BEA are currently more aggressive in
    > consuming OSGi than exposing it in their production
    > environments.

    FWIW, if you want to build new functionality on top of the Rational Jazz platform – e.g. a new team tool or an extension to an existing team tool – you do it by creating new OSGi bundles.

    This is true for extending the Eclipse UI obviously, but also for contributing a new data type on the server, contributing a new REST service on the server to expose data on the web, or contributing new Ajax UI functionality. Everything’s a bundle.

    But I agree with your statement that generally speaking IBM is more prone to not expose its OSGi-ness.

  3. Fair post. I get a nasty feeling of déjà vu about all this – in my day it was componentsource that promised nirvana. Plenty of hurdles before mass adoption.

  4. What a load of bullocks.. The author are using so many vague terms that I wonder if he understands what he is talking about. “Modules of Java classes”, “Java stack”.. Ridiculous.



Some HTML is OK

or, reply to this post via trackback.

Continuing the Discussion

  1. [...] James Governor from Redmonk does a great job introducing the concept of a Stackless Stack and the rise of OSGi; which made me think about Eric Newcomer’s, chair of the OSGI Enterprise Work Group, blog [...]

  2. [...] OSGi and The Rise of The Stackless Stack: Just in Time James Governor. Time I went and took another look at OSGi. I really didn’t want to, but as it seems I spend my life in middleware… (tags: java javaee osgi redmonk via:monkchips) [...]

  3. [...] from. Cuomo is determined to respond to that. He is working from a blank slate, deploying to a stackless stack (or see another explanation of the stackless stack, very relevant in this [...]

  4. [...] do the same for runtimes. As James Governor and Michael Cote coined we are entering the age of the Stackless Stack and my hope is that Equinox will be an important part of making this [...]

  5. [...] become pretty huge. Taken literally, it could provide a new model for application integration, or in the words of RedMonk’s James Governor, a “stackless stack.” Governor provides a detailed listing of early offerings that are [...]

  6. [...] literally, it could provide a new model for application integration, or in the words of RedMonk’s James Governor, a ’stackless stack.’ Governor provides a detailed listing of early offerings that are supporting the OSGi model of [...]

  7. [...] literally, it could provide a new model for application integration, or in the words of RedMonk’s James Governor, a ’stackless stack.’ Governor provides a detailed listing of early offerings that are supporting the OSGi model of [...]

  8. [...] all of the projects in the new EclipseRT project (see EclipseCon slides). The whole point of the stackless stack is, of course, that selection is not only possible but [...]

  9. [...] beat things up pretty poorly there for awhile, and now we’ve got things like Mule and the old stackless-stack. That is: simplified, cheap, lean SOA. Now, never mind if those startups aren’t doing [...]

  10. [...] for drag and drop object manipulation [note to self and web - check if this client is OSGi-based, i am pretty sure the answer will be yes] . The beta is 15th April. The product is likely [...]

  11. [...] to load modules of Java classes on demand, Redmonk analyst James Governor wrote in a recent blog post : “There is no need to load the entire Java stack to run an application – just the runtime services [...]

  12. [...] of OSGi its time you did – its becoming an increasingly important standard, driving the rise of the Stackless Stack. It ties enterprise and client-side middleware together, with a compelling development model [...]

  13. [...] I agree, Equinox is one part of the solution, depending on the application other services are required to complete the solution.  The nice thing though is that Equinox’s modular architecture makes it possible for SAP to create a solution for their customers; reminds me of Redmonk’s Stackless Stack. [...]

  14. [...] for a fun install and setup experience. Setting up any piece of middleware is typically annoying, stackless stack or no. Part of the tool-chain Adobe is providing is built around addressing the [...]

  15. [...] Bartlett did a great talk about OSGI. I liked the Stackless Stack [...]

  16. [...] is OSGi? I explained in a post about what we dubbed the Stackless Stack. OSGi allows modules of Java classes to be loaded on demand. There is no need to load the entire [...]

  17. [...] dull its actually pretty important when it comes to Java runtimes. OSGi allows you to build a stackless stack, where modules of Java classes are loaded on demand. “There is no need to load the entire [...]

  18. [...] evolution instead of language evolution, and slimming down the application stack with a very “stackless stack” approach. Again, the hope is that VMWare would focus on keeping that work up rather than [...]

  19. [...] James Governor写了关于OSGi作为工业改变者的潜力,以及被供应商采用。并把OSGi and the rise of the stackless stack(James Governer’s Monk Chips, February 2008).发布在他的博客上 JCP activity被分成JSR 277 (Java Module System) and JSR 291 (Dynamic [...]

  20. [...] to use the smaller, higher performance, and sometimes highly customized stacks. What I call “stackless stacks.” Standardized and general stacks are sometimes available, but even if options are open [...]

  21. [...] is. What is OSGi and why do we need a new reference implementation? The answer is the delivery of a Stackless Stack, a more modular Java, and the delivery of code, rather than [...]

  22. [...] up. In 2010 modularity on the Java platform will gain considerable visibility in our industry. The stackless stack is coming to fruition, and it’s a game changer…a disruptor…that reaches from the [...]

  23. [...] writing infrastructure software and need to create a “stackless stack” (Kirk Knoerschild, James Governor) then OSGi is already the de-facto approach, and fully supported by the dm Server and the [...]

  24. [...] and dynamic application development and deployment. In other words, the faster Java gets to the stackless stack, the brighter its future will be. As James Governor said in his seminal article, “component-based [...]

  25. [...] VMWare/SpringSource announced that it was donating its dm Server product to the Eclipse Foundation yesterday. See the Eclipse Foundation proposal here for the details of the new project, Virgo. The dm Server is one of SpringSource’s post-appserver appservers, along with tc Server which wraps up Tomcat to be used as a stand-alone runtime. dm Server is more oriented around providing a runtime and the supporting tooling for OSGi-based applications, which I tend to view as the next phase of Java development. Us RedMonks like to call this the “stackless stack.” [...]

  26. [...] VMWare/SpringSource announced that it was donating its dm Server product to the Eclipse Foundation yesterday. See the Eclipse Foundation proposal here for the details of the new project, Virgo. The dm Server is one of SpringSource’s post-appserver appservers, along with tc Server which wraps up Tomcat to be used as a stand-alone runtime. dm Server is more oriented around providing a runtime and the supporting tooling for OSGi-based applications, which I tend to view as the next phase of Java development. Us RedMonks like to call this the “stackless stack.” [...]

  27. [...] said OSGi could underpin a Stackless Stack, but I wonder whether we should have called it a VMless VM. OSGi allows for component-based [...]

  28. [...] people have a lot of optimism around Groovy. Along with finally nailing down slimmer profiles and a “stackless stack” approach to Java applications, it’d certainly help to continue that dynamic language [...]

  29. [...] seems to have won out, if by sheer exhaustion in the Java Modularization War, largely forgotten): a “stackless stack,” as us RedMonks wickedly like to repeat. Open source seems required as well, if only to drive that extreme simplicity that, for whatever [...]

  30. [...] Thankfully it didn’t need to – because OSGi provides a mechanism to turn Java into a Stackless Stack, where a runtime consists of only the classes needed to run a particular [...]

  31. [...] are we witnessing “The Rise of the Stackless Stack” and the end of the industries infatuation with static configurations of virtual machine images? I [...]

  32. [...] happening. Two key standards seem to driving all this content management integration goodness- CMIS and OSGi. I should also strongly credit our client the Apache Software Foundation for providing [...]

  33. [...] commented on in “The Rise of the Stackless Stack” (see http://www.redmonk.com/jgovernor/2008/02/05/osgi-and-the-rise-of-the-stackless-stack-just-in-time/); these trends collectively shift the industry away from rigidly coupled, static, opaque [...]

  34. [...] the WebSphere Application Server Liberty profile, a lightweight Java application server based on Stackless Stack principles, new commitments to help customers build and make money from public APIs, and some [...]