Bio Graham Charters is a Senior Technical Staff Member at IBM's Hursley laboratory in the UK. He is currently working on the WebSphere Application Server product, defining how OSGi is provided to WebSphere customers. He is the IBM Application and Integration Middleware division's technical lead in the OSGi Alliance Expert Groups, and a member of the Apache Aries incubator project management committee.
Software is changing the world; QCon aims to empower software development by facilitating the spread of knowledge and innovation in the enterprise software development community; to achieve this, QCon is organized as a practitioner-driven conference designed for people influencing innovation in their teams: team leads, architects, project managers, engineering directors.
1. My name is Charles Humble from InfoQ, and I'm here with Graham Charters, IBM WebSphere OSGi Applications Lead Architect, based at the Hursley Software Lab in the UK. Graham, can you start by telling us a little about yourself and your work at IBM?
So I’ve been with IBM for about 15 years now. I’ve done a variety of jobs from application adaptor architecture, business integration architecture. I spent a few years doing incubator projects, looking at the sort of things a couple of releases beyond where the products are, and then one of those is something that we took into the product as the OSGi application support in WebSphere; and that’s where I’ve been for the past few years now.
OSGi is a set of standards defined by the OSGi Alliance. It’s probably best known for its modularity - for providing modularity to the Java platform. So what that means is you can define the concept of a component or module; those two things are kind of typically used interchangeably. You define what the component provides in terms of capabilities - also what the component requires in terms of capabilities - and then once you’ve done that, everything else is internals and private to that module, and so you can reason about the module and deploy that into some environment. It’s been used from anything down from small devices, mobile phones, all the way up to enterprise servers.
Beyond the module layer it also defines a life cycle layer, so it’s dynamic; you can install modules into the environment/un-install them from the environment, without having to restart the JVM. And also then, beyond that, there’s a service layer, so you can do local interactions between modules within the JVM; so they can register services that are then discovered by other modules and used by other modules so they can collaborate.
There are a couple of ways it's relevant. We started out using OSGi with WebSphere back in, I think it was 2006, when we released WebSphere 6.1. That was the first time the application server had actually been written using OSGi for its internal runtime engineering, which wasn’t particularly relevant from a customer perspective; but then over a period of two to three years, there was this kind of realization that if we found it valuable as a technology for engineering our runtime, then our customers are going to have the same engineering requirements that we do, and so it’s therefore going to be useful for people building applications that run on the application server.
So, in 2009 we shipped a feature pack on WebSphere version 7 which provided OSGi application support. That then went down into the base application server release in version 8, and you’ll see, if you’ve seen the current beta - 8.5 beta - we’re continuing to add new capabilities to the OSGi application support.
Beyond that, we’ve done some more internal engineering work around the WebSphere 8.5 beta Liberty Profile, and that’s kind of taking the internal engineering a step further. So, rather than it being a kind of pure engineering exercise, we’re also giving customers the ability to exploit the fact that it’s based around OSGi modularity, so they can then customize the runtime, customize the features that they have in the server when they deploy it.
I’d say definitely. We have a lot of customers that have requirements for better modularity in their applications. They are looking for the tools to enable them to do that kind of thing, and OSGi is the tool for modularizing Java applications.
One of the issues that they come across is the need to be able to pull in third-party libraries; so there are lots of libraries out in open source that people use - frameworks for doing dependency injection, or persistence, or logging, for example, and to pull those into an environment where they've built a modular application requires those things to be modularized themselves, to work in that environment.
So, yes, the more support we have for modularity in the environment, and in terms of existing projects, then the better.
So with Java EE; Java EE provides some excellent component models. For creating Web applications, for example, you’ve got servlets, JSP and so on, JSF; component models for writing business logic, EJB, for example; persistence support with JPA.
But what it defines in terms of modularity is, I guess in my opinion, not ideal. So when you deploy a Java EE application, it gets its own classloader for the EAR, and there is a classloader assigned for the WAR, and it’s put into a kind of hierarchical classloader model, and customers, when they assemble their applications, they’re not guaranteed to use what they think they’re going to be using. So, for example, if you’ve written your application using some third-party library capability and packaged that up as part of your application, if the server runtime happens to have used the same thing, then you might end up picking the one up from the server because you will delegate to your parent first rather than using the one in your application.
And so what we’ve done is, as part of the OSGi Alliance standards and also in open source and in the WebSphere Application Server, is taken these Java EE technologies, and said, "These are great component models. What can I do to mix in OSGi modularity, and life cycle and service capabilities into those component models, so I get the best of both worlds?"
So customers now, with the OSGi application support, can take their existing Java EE applications, and where they’ve been kind of running out of steam in terms of being able to evolve them modularity-wise, they can start using OSGi to decompose the application into a set of loosely-coupled modules, and then they can re-assemble that application or use those modules in other contexts.
This is an interesting one. When we first shipped the OSGi application support in the version 7 feature pack, we focused on the kind of modularity from a kind of development and deployment perspective, but just, “This is how you assemble an application from a set of modules and this is how you deploy an application.” But there wasn’t really much consideration for the life cycle that those modules go through between those two phases. And so we talked to customers, typically development teams first, about how to modularize their applications, because they were coming to us with these pain points that OSGi can address; and then quite often we’d follow up with the operations teams and they'd say, "Well you've told our development team, here’s how to modularize your application, break it down into a set of modules; but how do I put that into production from an operations perspective? I’ve got all these loosely-coupled modules that you’re asking me to then pull together.
I used to get this big EAR file that I was quite happy with." And I guess one observation is, it’s not really OSGi; OSGi is just highlighting the fact that you’ve built your application from these set of things, but it’s not as if when you create a Java EE application and use some third-party library, that that third-party library stands still. It still evolves, it’s still being developed by the provider of that thing.
But it did kind of highlight the need for better governance of assets when you build enterprise applications. So we’ve done a bit of work with the Rational Asset Manager team to turn Rational Asset Manager into a governed bundle repository; so you can now, as part of your development, develop and build modules, put them into this governed repository, perhaps in some kind of submitted state. They can go through some governance process, might go through some automated tests, or some approval process and then be approved, then you can highlight them all, label them as being ready for production use. So modularity doesn’t, I guess, really create a new requirement; it just highlights the fact that there is this existing requirement there that hasn’t really been focused on in the past.
Yes, so again, when we first shipped WebSphere 7 feature pack, the focus there was on web applications, and modularity of those; so being able to modularize your existing, perhaps Java EE web applications, or take some Spring application you’ve got and move it to the standardized Blueprint component model, and so on.
And it was really thinking about it from the perspective of our traditional Java EE customers. But some of our early adopters, I guess, primarily coming at it from an OSGi perspective, but also some of the Java EE customers who were kind of looking at OSGi and thinking there is some additional value here, they started asking us about the dynamics; the fact that there is a dynamic life cycle there. Because they wanted to kind of break out of this …I’ve got this Java EE application, I deploy it, if I want to change it, I have to take the whole thing away and put the new one in.
And so they were asking things like, “How do I update the application to apply some critical fix without having to take the whole application down?” Or, one of the really interesting ones was a payment provider customer who wanted to be able to extend the application as it's running; so they have this - a bit like Eclipse extension points - this notion of, “I’m going to have multiple instances of these kind of services and I want to be able to take some of them away during the life of the application and add new ones in.”
So in version 8, we added some capabilities for the dynamics to be able to do in-place updates, but also to be able to extend applications as they’re running.
One of the nice things about the OSGi Alliance is it doesn’t try to re-invent the wheel; so when it’s looking at an area to do standardization, if there isn’t an existing standard there, then fine it’s a green-field site and we can look to create a standard for that, and we’ll take in input from various vendors who’ve perhaps done some proprietary work in this area.
But a lot of the standards, particularly in the enterprise space, what we’ve done is we’ve taken the existing standards like the Java EE ones, such as servlets and JSPs, or JPA, and we’ve said, “Well, those are great component models; how should they work in an OSGi environment?” So if I take a servlet or a WAR file, a web archive, what does it look like if I actually turn that into a bundle and have it use OSGi for its classloading model?
There is then the next level of consideration which is, well OSGi is a dynamic environment; so if I want to take that web application bundle away and put a new one in, what happens in terms of the life cycle - the things that it interacts with, but also the things that interact with it.
And so that’s the approach we tend to take in OSGi Alliance; it’s kind of mixing in so you get the best of both worlds – you get the modularity and the dynamics and the service capabilities of OSGi mixed in with the kind of robust component models that have been used for a number of years from the other areas.
It’s going to be, I think, a bit of a two-way street; IBM and the industry has a lot invested in OSGi. So you just need to look at things like Apache and the number of projects that are built using OSGi; so you've got Aries, as I mentioned (editor's note: this is actually the first time Aries is mentioned), Geronimo, CXF, ServiceMix, Karaf, and so on. Look at Eclipse; pretty much the entirety of Eclipse is built up on OSGi.
So I think it’s in the industry’s interest to ensure good interoperability between the two. So, to that end, we’re working in OpenJDK, collaborating with Oracle and other vendors; we’ve just created a project called Penrose, which is really about ensuring good interoperability between Jigsaw, SE modules and OSGi. And so Jigsaw is still a work in progress; OSGi is continually looking for new requirements and I’m pretty optimistic that we’ll be able to come up with a solution that shows good interoperability between the two.
There’s actually a great tool out there created by Peter Kriens; so if you go to, I think it's aQute.biz. It’s called BND and there’s build integration for BND for Maven and Ant and Gradle; and so what you can do is - and we did this quite a few years ago in the Apache Tuscany project - is you can take your existing, for example, Maven builds, your Maven POMs and, say that you want to turn the packaging to be bundle and then you provide configuration to the Maven bundle plug-in that says, “These are the things I want to export; these are the things I want to import." BND or the Maven bundle plug-in will do some analysis for you to make sure you import the things that you require and it does a pretty darn good job of that.
So that’s kind of a first step, but once you’ve done that really what you’ve done is documented the existing state of your system; what you thought were the modules in your system and the modularity. You might find, and we did in Tuscany, that there are maybe dependencies you didn’t think you had, where certain things are using packages from certain other modules, so it’s a good idea, once you’d done that, to then do some analysis and understand where the dependencies are and see how you can perhaps refactor your environment to make it more modular and more loosely coupled.
One of the things I tend to talk about with, when I talk about OSGi and the benefits in modularity, and particularly the benefits of enforced modularity, is that it kind of forces you to have conversations. So when we consume third-party libraries, or if in your large development organization such as WebSphere, which is distributed, if you have a number of modules that have actually described their externals, and those externals are enforced, you know immediately what the module is intended to provide. If it’s not providing what you need, then, rather than being able to go in and drill down into the internals of that thing, you go and have the conversation with the provider of that module, and they can understand your requirement, perhaps match it with other requirements that they've got on their module, and create some capability that satisfies those requirements. Rather than, what we see today is where people drill down and dig into the internals of things and use those things, only to be broken later because the provider of that module didn’t actually consider that to be their external API, and they go and change that thing and you consume the next version and you’re broken; so having those conversations up-front is always a good idea.
I think we’re going to continue to see the standards evolve, open-source environments and products; so if you’ve been following the OSGi standards work, you’ll see that we’ve done some draft releases of enterprise OSGi. So part of that is a standard application model; so a standardization of how to define an application, and deploy that into an OSGi environment. A standard model for features. Features is quite a common thing in OSGi; there’s the concept of features in the WebSphere Liberty Profile; there’s the concept of features in Apache Karaf, and so on. So a feature is essentially just a list of bundles that you want to provision into an environment, or remove as a collection that has no additional isolation rules around it. There’s also spec work around repositories; there is a repository service capability, and a resolver capability so people can build provisioning systems out of those components.
Open-source wise, I think we’ll continue to see the programming model evolved, so more recently in Apache Aries, for example, we’ve just done an EJB support; I think we’re going to continue to see the Blueprint specification fleshed out.
As part of the standard application model it defines an archive format, so the application definition itself ... it’s actually called a subsystem specification, and that encompasses applications, composites and features. So the definition itself is really just a list of requirements for bundles that you want to be managed as a whole. There’s also an archive format with that, so it’s essentially just a .zip; you can optionally put the bundles into that archive. There’s an argument that a good practice is to not do that because you end up creating these kind of bloated archives – that can become a convenient way of doing things. I think, from my perspective, a nicer model would be to put things into a repository; so you’ve got essentially the list of requirements for bundles and then you have repositories that you provision out of.
Yes; so from a standards perspective, there’s a requirements document that’s actually now, I think, been voted on and kind of approved; it’s called RFP 133, and it was being created for a couple of years. That’s captured the requirements on OSGi from a cloud perspective. And at the up-coming EclipseCon there’s going to be another cloud workshop run, where that’s going to evolve that and try and take it to the next level.
From a WebSphere perspective, we’ve got IBM Workload Deployer which is our solution for private clouds, and that deploys WebSphere Application Servers, and WebSphere Application Server is OSGi based. So there’s a kind of runtime provisioning perspective, and from an OSGi application perspective, you can run those applications in the cloud.
So the interesting thing, cloud is mostly about operational change, not about the developer’s perspective; so I think developers want to be able to develop their applications and then have the choice of deploying to the cloud or deploying on to a managed host inside your own IT shop.
On the operations side, I think there are some good technologies in OSGi that potentially add value here for the provisioning of runtimes; so the fact that you’ve captured the dependencies of your modules, the fact that there is repository specifications coming along, and resolver specifications, I think, all have potential to add value in the cloud provisioning.
I’d say they're there already today. With WebSphere Application Server, for example, and the OSGi application support, when you define an OSGi application, you describe what the core content, the key modules or bundles, are of that application, and when you deploy them into the environment, into WebSphere, they resolve; they have an affinity to using each other’s packages and services. Then anything that’s not provided internally inside that application can then be provided by shared bundles within the environment. So you can define a number of applications, deploy those into the application server environment; they use their own things internally and they’re isolated. So any services that those content bundles provide aren’t seen by the other applications, but then they can use common services shared between the applications.
We’ve found that this is quite a nice model, because a number of customers we’ve spoken to have teams that are responsible for providing infrastructure to their applications teams. So that infrastructure team can provide those packages and services, that are going to be shared between applications, and then they have the application teams building the applications; and they don’t actually intend to share or collaborate around any kind of packages and services between the applications.
The Modularity Maturity Model is something I defined as part of … it was for a keynote session at the OSGi community event last year. It came about through experience of talking to lots of customers about their adoption of OSGi; and also sort of reading about other people’s experiences of OSGi; so it’s not trying to be a capability maturity model as such, but it’s inspired by some of those models.
So the idea is that it kind of captured the progression through the adoption of OSGi in terms of the number of layers, and the idea is you can look at what you’re doing today, classify yourself against one of those layers, and then understand where your next steps might be. So, "How can I move to the next layer? What would be the benefits in doing so?" And if you decide that actually the benefits aren’t worth the investment, then that’s fine; stay at that layer; but hopefully you’ll see that there is value to be had and it’s worthwhile moving up those layers.
So the bottom layer was kind of defined as 'ad hoc', in other words you’ve done nothing; which kind of fits with the CMM models. The next layer up was 'modules', so you identify modules by identity; you give them a name and a version, for example, a bit like a Maven module. But that doesn’t really give you the value of modularity, which is about describing the externals and being able to understand the true dependencies, the true runtime dependencies between your modules. So the next level up is 'modularity' and then it went into things like dynamism and so on.
So this was really capturing what customers had been doing. They’d start out perhaps with a modular build system, but then realized that didn’t give then enough; they needed modularity and runtime enforcement and so on. So that’s where adopting OSGi and perhaps, as you asked before about changing your Maven build to produce OSGi modules, that kind of carries the identity aspect through and then you add in the externals.
So in the latest draft specification ... so OBR, or the OSGi Bundle Repository specification; it’s been quite a long haul of a spec. It’s evolved quite a lot in the last year; so those who are familiar with Felix OBR, that’s kind of where the spec originally started out; so it had some provisioning aspects associated with it.
What it has done now is evolved into two concepts really: one is the notion of a repository service which is a service that you can consult and ask questions of, so you can say, “I have a requirement for something providing this capability" and it will come back with a set of answers – so that’s the first part; the second part is a resolver, so the resolver is the thing that, given some requirements and some resources, it will come up with the next set of questions to go and ask of the repositories. And then people using those technologies plug in a kind of context, or an environment that basically describes what the current environment or the environment they’re looking to provision into is, and they can put policies in place in that part of the solution. And then finally there’s an XML format, an interchange format, so you can actually, using XML, describe a repository. I’m pretty optimistic that that’s going to be out fairly soon.
There are probably two answers to this: OSGi has a layered architecture - module layer, life cycle layer, service layer. And the way OSGi works is to get to the service layer, you need modules; and so the starting point is to create modules for the things you have today. You then probably want to look at considering what are the APIs in my system and what things are implementation; so looking for the factories and those kinds of things. Factories are usually where you’re collaborating around an implementation, and it’s those things that you then want to change to using the OSGi service layer.
The great thing about the service layer is it enables collaboration around implementations whilst the two parties don’t directly know about each other. So one module can register a service, another can be notified that that service exists; so you no longer have a kind of tight coupling where you’re importing or exporting packages between implementation modules.
So the short answer is, create your modules, understand and separate out your APIs and implementations, and then look for the implementation collaborations, and those are the things you turn into services.
The second answer is, there’s an interesting technology called PojoSR, or sometimes referred to as OSGi Connect; it’s not part of any standard, and I think only time will tell whether it does get adopted as a standard. What that’s done is, it was an interesting experiment - and it was done by Karl Pauls - where you can get to the OSGi service layer first. So the idea is you define your modules but you still put them on a flat classpath, and then you get access to the OSGi service layer capability, so those modules can register services, and use services.
So with that kind of approach, you can actually take a kind of service-collaboration-first notion, and define the services between your modules and your system, and then start enforcing the module boundaries around the package importing and exporting.
Yes; there are a couple that are actually standardized in OSGi: one is called Declarative Services and the other is called Blueprint.Declarative Services was the one that came first, and what that essentially lets you do is define a notion of a component and the services it provides, and the service dependencies it has. It's done using an XML format, or there’s annotations that you can use as part of your build. And then when you install that into the runtime, the Declarative Services runtime will process your XML and handle the injection for you, but what you’ve written code-wise doesn’t actually directly use. There are some APIs you can use, but they are all optional, so you don’t have to directly use any OSGi framework APIs.
The second one is Blueprint, which was led by SpringSource, or VMware now, and it's a standardization of the Spring component model. So it goes a little bit further than Declarative Services, in that it allows you to wire up beans within a module; so to have dependencies injected between your beans within an OSGi bundle. And again, it’s an XML model; so you put your XML in the bundle, the Blueprint runtime will process that; and again, it doesn’t require you to directly use any OSGi framework APIs.