[insert image here. i need to find a good one ;-)]
i am at an Adobe event in San Jose for the analyst unveiling of the company’s Customer Experience Management platform and strategy.
Rather than focusing on CEM for this post, which I talked to indepth already here, I thought I would nerd out a little bit and talk about Adobe’s approach to what I call the Stackless Stack.
I asked David Neuscheler, CTO of Adobe CEM – who joined the firm as part of its Day Software acquisition, whether OSGi was something customers do, and should, care about.
The question is a live one – there is currently quite a debate going on about the value of OSGi – led by voices such as Ross Mason of Mulesoft.
I see both Adobe and Dell using OSGi in new toolsets, so its certainly relevant to vendors. But what about users?
Neuscheler said OSGi was more relevant to people running apps than building them.
“OSGi gives us the power to modularise our solution. its a java spec that allows you to deal with java in a 24×7 environment – with no need to bring down the app for updates. that modularisation puts a burden on the developer – they need to think more about modularity.”
[note- OSGi is a Java spec, but not in the JSR sense. OSGi is a separate standardisation stream – in the multipolar Java world].
“Usually OSGi comes with maven, continuum etc for continuous integration.
But there are 2 classes of developers- those that love tooling – the more complex, and automated, the better they like it- I call them class 2 developers.
i am not one of them. i don’t like to spend three days installing a development environment. i like to just get going, we’re scripting types, more agile.
However, once 100 people are using it, it needs to be hardened for osgi containers etc.
Makes sense. Build Agile, deploy Modular. Don’t optimise prematurely.
Kevin Cochrane, VP of marketing, CEM at Adobe then jumped in.
There are 3 OSGi use cases relevant to customers:
1. updates. ie bug fixes to customer production systems. there is no need to bring them down.
2. extending new services. you might have 12 services, and a huge user community – you can still roll out extensions with no downtime.
3. discovery of new services. find a pre-packaged piece of code. browse, integrate and deploy.
Arguably that’s two use cases- hot swappability and reuse. But those are very important use cases, and could be foundational.
Adobe is going to move to appstore like offerings going forward; like every other software vendor it needs to deliver more and more services as a service, for its own apps and those of partners.
The use cases Adobe describes chime pretty well in my thoughts on the Stackless Stack from February 2008.
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.
In conclusion: OSGi certainly shouldn’t be exposed to end users, or even all developers, but it can have significant value in large Java development shops serving big user populations.
Any disclosure to make? I am one of the founders of the OSGi UK user group, the OSGi Alliance is a client, as is Adobe.
Ian Skerrett says:
June 15, 2011 at 7:30 pm
> In conclusion: OSGi certainly shouldn’t be exposed to end users, or even all developers, but it can have significant value in large Java development shops serving big user populations.
Is this your conclusion about OSGi or Adobe’s?
Neil Bartlett says:
June 15, 2011 at 7:45 pm
>OSGi certainly shouldn’t be exposed to end users, or even all developers
This is basically true, but I’d like to qualify it.
Certainly not all developers should have to worry about the OSGi API’s, package resolution, service dynamics, etc etc. That’s low-level plumbing and is best left to a small number of professional plumbers. The majority of developers should just write nice clean code that is oblivious of OSGi.
The caveat is that developers should still be instilled with the OSGi mindset of watching out for dependencies, cleaning up after themselves, not messing with classloaders and so on.
So developers cannot be completely isolated from the conerns of modularity, though they can and should be isolated from the specifics of achieving modularity through OSGi.
OSGI and simplicty « Adventures in systems land says:
June 15, 2011 at 11:04 pm
[…] I was still at IBM; I hadn’t realized how much though until our recent discussion, and his blog entry for today, James quotes Kevin Cochrane, VP of marketing, CEM at Adobe. Kevin says of […]
Richard Nicholson says:
June 16, 2011 at 5:02 am
IMO – I think this messaging is consistent with my (Paremus) experiences over the years. OSGi (modularity) is fundamentally important to large organisations. Especially those that bring a wide ranging set of service to a large user base. The Financial Services industry is an excellent example here. And it is important for EXACTLY the reasons stated by Adobe.
However most BAU developers shouldn’t see OSGi or much else for that matter! Just the target PaaS/SaaS environment for which they are releasing their new piece of functionality.
The “hard infrastructure stuff” is developed / delivered by a core team of infrastructure architects and developers along with the vendors they work alongside.
Gregor J. Rothfuss says:
June 16, 2011 at 6:46 pm
Name is Nuescheler.
James Governor says:
June 20, 2011 at 1:21 pm
Gregor – thanks. that totally ruined my title! I actually realised during a one to one with neuscheler on wednesday.
Ian – i am to some extent reporting adobe’s thoughts. but clearly OSGi is not for *everyone*.
Neil – stat. All that said – its hard to encourage better development behaviour if developers are not exposed to the forcing factor for modularity.