{"id":1438,"date":"2008-02-05T18:29:01","date_gmt":"2008-02-05T18:29:01","guid":{"rendered":"http:\/\/www.redmonk.com\/jgovernor\/2008\/02\/05\/osgi-and-the-rise-of-the-stackless-stack-just-in-time\/"},"modified":"2008-02-05T18:29:01","modified_gmt":"2008-02-05T18:29:01","slug":"osgi-and-the-rise-of-the-stackless-stack-just-in-time","status":"publish","type":"post","link":"https:\/\/redmonk.com\/jgovernor\/osgi-and-the-rise-of-the-stackless-stack-just-in-time\/","title":{"rendered":"OSGi and The Rise of The Stackless Stack: Just in Time"},"content":{"rendered":"

When I first heard about OSGi<\/a> I had no clue what it was. To be honest I initially confused it with OGSA<\/a>, 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. <\/p>\n

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. <\/p>\n

OSGi in the Wild<\/h2>\n

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<\/a> because it fears a loss of control of Java stack standards efforts. (How many times will I have to write that?)<\/p>\n

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.<\/p>\n

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.<\/p>\n

Meanwhile IBM Lotus Expeditor<\/a>, 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<\/a>. <\/p>\n

The Death Of The Stack: SOA for production<\/h2>\n

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<\/a>, marketing director of the Eclipse Foundation (client), which is a strong supporter of OGSi in the shape of its Equinox runtime<\/a> project, that my colleague Cote casually came up with a far better construction: “oh sure… you mean a Stackless Stack”.<\/p>\n

As Cote himself might say- blammo! <\/p>\n

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.<\/p>\n

Another technology carrying us towards the stackless stack is Spring<\/a>, 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<\/a> for the open source software. <\/p>\n

Starting Up With Distributed OSGi Runtimes<\/h2>\n

An interesting example of the stackless stack approach comes from RedMonk client Paremus<\/a>, which recently announced support for Spring Dynamic Modules in its Infiniflow Service Fabric product. Paremus uses the Service Component Architecture<\/a> (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. <\/p>\n

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.<\/p>\n

Springtime for Covalent<\/h2>\n

SpringSource<\/a>, 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<\/a>“. Well Rod Johnson<\/a>, 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<\/a> 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.<\/p>\n

Stackless, Microsoft and Green APIs<\/h2>\n

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.<\/p>\n

For more background we have some great RedMonkTV shows<\/a> about OSGi, Equinox and so on. <\/p>\n

update: super bonus OSGi buzz link roundup<\/a>.<\/p>\n

 <\/p>\n

 <\/p>\n

Technorati Tags:<\/strong> OSGi<\/a> – Sun<\/a> – Eclipse<\/a> – Equinox<\/a> – Spring<\/a> – SpringSource<\/a> – Covalent<\/a> – BEA<\/a> – IBM<\/a> – Microsoft<\/a> – Stackless<\/a> – Paremus<\/a> – Infiniflow<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

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<\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","footnotes":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false},"categories":[1],"tags":[],"class_list":["post-1438","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"jetpack_featured_media_url":"","jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p9wfjh-nc","_links":{"self":[{"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/posts\/1438","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/comments?post=1438"}],"version-history":[{"count":0,"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/posts\/1438\/revisions"}],"wp:attachment":[{"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/media?parent=1438"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/categories?post=1438"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/tags?post=1438"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}