I'm currently working on SpringSource dm Server which is a modular application server. I've been doing that for about 1 year and a half now, a little bit longer than that, and I will continue to work on that for the next couple of years.
I think the difference is in a number of different ways. One of the interesting things is that we don't define ourselves by being a standards based server, which isn't to say that we don't implement the standards. Many Java EE servers define themselves based on the fact that they are in fact a Java EE server. What we are more focused on is giving something that makes sense to the user, so I call that user oriented. We are concerned much more with user productivity and user happiness, so we say that we aren't necessarily taking off all the standards. Another major feature of the dm Service that's different from everybody else, is that we are very modular. A modular internally, which means that you as a user you got to choose exactly what it is you want to deploy and I think that is critical now, people don't want this large scale of monolithic application servers anymore. You don't want to have to start a 1GB process to run a 50 MB web application. You want your application server typically to be smaller than your application. Nor do you want to have to load a hundred components that you don't use. I have a lot of customers that use WebSphere, but their applications don't use the JMS provider, they don't use the Transaction Manager. So they don't want to load those components. With the dm Service we are focused on internal modularity and enabling users to choose which of those modules are in their runtime. What we've come with another step on modularity is to make that modularity available to end user and I think it's the critical piece. A lot of vendors are moving towards a more modular architecture based on a OSGi or a something similar, but very few people are taking the plunge and say "We got a lot benefit from this so let's let our users also get the benefit, let's give the modularity to them". In fact, that was a big challenge trying to marry the two worlds of traditional enterprise Java with the wealth of open source and commercial code that already exists and the new world of OSGi - that is our biggest challenge.
3. Speaking of OSGi, what's the role of OSGi technology in SpringSource dm Server?
We use OSGi in two distinct ways. OSGi is our internal implementation for modularity, so when we talk about the dm Server being modular, it's packaged all as OSGi bundles, which is the notion of modularity in OSGi, and using OSGi we can choose which components of dm Server to load, we can do so dynamically, if we choose, we can unload components of dm Server as well, and then OSGi forms one of the deployment options on the dm Server platform. And I say one of, because we don't define ourselves as being an OSGi application server, we're OSGi based, and then we have a number of different views on the dm Server, we have a WAR based view.
So if you want to deploy standard WAR files, that's fine, we have an OSGi-based view, so if you want to deploy OSGi applications in there as well, that's fine, and basically we plan to make that whole view, the personality notion extensible. We want to have lots of different kinds of application styles deployed on the dm Server. It's been some talk about supporting future Java EE specs, so one of the things that we are dedicated to doing is supporting the Java EE lightweight web profile, whatever that might be, so that's probably going to be servlets, maybe web beans, and potentially even EJB 3.1. We want to have all these different models, and that gives us I think a unique proposition for users. We don't care what model you use, we want to supply you with the model you need, and it's not just about saying, "Here is our model. Use it", we're really saying: "Here is our middleware, we want you to use that, and here are the extra number of models that you can use on top of that middleware ".
Sure, the roadmap is actually for support spans all the Spring products, and I think it starts primarily with Spring Framework itself, so with the 3.0 and the 3.1 releases, we'll be heading towards support for Java EE6. I think Spring 3.0 will come out before Java EE6 is finalized, so it'll be early support, if any, but when 3.1 comes out we'll be focusing on supporting the big standard like web beans, like servlet 3.0 - whatever makes sense, really. I mean it's easy to say we're going to support everything, but if it doesn't make sense, there's no point to do that, and if you really want to focus your resources where users will get the most benefit.
With dm Server, that's going to be focusing on servlet 3.0, so a lot of our users are already asking about that, we want to give those features to our end users, and looking harder, what it means to run web beans inside dm Server, what it means to run EJB 3.1 inside dm Server, those are the kind of things we're really looking at.
I think one of the things we're trying to do is not fight that battle, it's not a battle that we need to fight, nor a battle that we want to fight. What we're trying to do is give customers solutions for a particular problem, and that problem is this need to deploy their applications on a very small platform, but at the same time these need to have traditional enterprise styled features such as distributed management and distributed deployment. Many of our customers have got applications that are just web applications, but they need to use a full fledged Java EE server because they've got requirements around management and operation. What we're really focused on is a lightweight platform that has the same management and operations as you would expect from something like a WebLogic or a WebSphere. Of course, it's a journey, we're not there right now, and what we're focused on really for the 1.0 release, was giving customers access to the modularity. Customers have a big problem with the size of their applications, many people are building large applications, many people are struggling to deal with their third party dependencies. "How do I handle this 90 JAR files that I've got?" Popular, commercial, many open source projects use, I won't name names, has both Spring 2.0 and Spring 1.2.9 on it's directory. This makes you think "Why is that the case?" Do they even know which version of Spring are they really using? That kind of dependency however can't go on too much longer, it's getting worse and worse exponentially as your application grows. With the OSGi there is a solution to that. What we want to do is to give customers a means which I wish that could take advantage of that functionality but have it work nicely in traditional enterprise Java. Further to that, if you have got large application yourself, there is no real means you to modularize it right now. You can draw all the fancy architectural diagrams you want, but there is no way for you to embody the architecture in your implementation, nor is there a way for that architecture and that modularity to reflect the runtime. With OSGi you have the ability to package your application into discrete modules, talk about how those modules interact and then see those modules as runtime constructs. It is not just the case that you do this really nice architecture with a bunch of codes and it just disappeared when you packed it inside the WAR file. I think this is a real benefit to use this building medium and large application, especially across a large team, because it means you can easily modularize into unit work assignments for members of your team.
The traditional way that people address those issues is a number that I would refer to as really hacks, maybe OSGi implementation specific features such as buddy classloading in Equinox, that give you the ability to get around those problems but never do they really give you a full solution, especially when you've got an application made up of multiple bundles. The issue of managing thread context class loader, which is very commonly used by enterprise libraries, they want to see your application as a class loader - while they are multiple bundles, they are multiple class loaders. With dm Server we took this approach, I tell this story a lot it's probably getting quite boring now.
I remember an article about the development of Windows XP, Microsoft had a problem, they fixed a bug that broke SimCity2000. They put a shim into the code base and when the SimCity 2000 process loads it sees the Windows kernel as if the bug was still present, but the processes see the kernel with the bug fixed. This allows SimCity 2000 to continue to run. I was really impressed by this notion of a shim, this ability for the environment to adapt to the needs of the user. So we took this idea that we should do the same thing and we would put this shims in place, to make common libraries run. When we first started out we thought this is probably going to take four or five hundred common libraries, it could be four - five hundred shims, but, in fact, there are ten. There are ten common things that people do, that we have to fix open, in fact, there are ten common solutions that we have.
Examples would be resource loading. It is quite common for people to load a resource and say "If this is a file resource, it is a directory and I want to start scanning into it". "If it is a JAR resource, I want to open that JAR and start scanning into it, but if I don't recognize the protocol, I'm not going to do anything". Unfortunately many OSGi implementations return a custom protocol, so you might get access to what really is a file, but it would call it "bundle COA" or "bundle resource COA". We put a shim in between them, so OSGi sees what it expects to see and Hibernate or Tomcat expects to see. So that works really nicely.
And there are other examples such as "load time weaving". OSGi has no notion of the class loader being instrumentable. When you're using JPA you want to be able to instrument the class loader. A shotgun solution is to say "We'll put the a Java agent on the whole JVM", and the whole JVM can be woven. Not ideal if you're trying to deploy multiple applications side by side. With dm Server we make each class loader instrumentable and we have a semantics for how an application that is made for multiple bundles can be woven as a unit and how that weaving affects what the life cycle is. There are these base solutions that we are doing, and now we are able to run, I would say 96% of enterprise libraries without change, and when we have to make a change we preferred to patch the existing library, rather than to have the user do a work around, so we submitted a patch for common DBCP, just a small one, and a patch for Tiles as well, and those are the only two libraries we had to patch so far, so I was quite pleased with that.
The code that causes the most problems is stuff like javax.activation and javax.mail, things that you can easily patch, they do a lot of class load hackery, because they expect to be on the system class pattern so forth, in particular with this move now. In Java 5, some of those things are separate libraries, but in Java 6 they are in the platform, so managing those differences can be quite difficult. That must have been embodied in dm Server as well, so you should see very little of a difference if you move from Java 5 to Java 6, and that's another part of that shimming process - to make it easy for users to be able to migrate their applications as much as they want.
That is an interesting question. My belief is that load time weaving should have no difference when working in a cluster, each node work independently. I think if that's not the case, then load time weaving becomes extremely complicated. Class loading is an interesting one, what you typically want to do in an OSGi base platform is to be able to provision bundles on demand, you don't want the user to have to install every bundle by hand - an application might depend on 90 bundles. If I have to install those 90 bundles by hand and their dependencies, and their dependency dependencies it's going to get quite problematic. Nor do you want to have just a big pile of bundles, and install them all in the hope that some of them might get used, you really want to install the minimum profile.
When you are running across a cluster, you have a couple of ways to do it, you can solve this faulting behavior when a class tries to get loaded, you see that a class doesn't exist, you go across the wire, find the bundle that contributes in loading to solve RMI style class loading. With OSGi we have better mechanisms for doing that. The consuming bundle has to have been installed on the server beforehand. We know what its co-dependencies are, so while we do the installation we can always satisfy the dependencies. One of the things we have in the dm Server is this on demand provisioning function which is single node based. As I speak, the guys back in the UK are working on expanding that to be cross cluster. In this notion you have a centralized repository of all available artifacts.
You might install your application on Spring and Hibernate. It says that you need Spring, so I'm going to install Spring and Spring needs Tiles so I install Tiles, Hibernate needs dom4j so I install dom4j - and that way you don't have to worry about synchronizing. The interesting pieces when you install the app, because you really want to garbage collect those bundles that were installed, the end goal for dm Server is for us to have just a kernel running on every machine by default with nothing else. If you were to install an application, and for that to trigger the installation of everything else, not just third parties libraries that your application depends on, but the middle-ware components that dm Server needs to start your application. Think about a kernel running with no web container: you install a web app, we pull in the web container and install it. When you install the app you take the web container out and the kernel returns to its small minimum piece. All the base functionality is there, it's just putting those smarts around it. That it what to be done.
You are probably asking the single most complex question about OSGi related to version management. A common misconception about OSGi is that is solves all versioning problems. It is certainly not the OSGi spec makers or the proponents of OSGi who were promoting that, but certainly I have seen this common misconception "If I'm using OSGi there no longer will be a version problem". Running multiple versions side by side can be quite complicated, because of the way OSGi version management works. If you think about it is going to be necessarily quite complicated. I give you an example. If I have Spring 2.5 installed, Spring has a dependency on Hibernate, so I might have Hibernate 3.2.5 installed.
Spring and Hibernate they combine together, they are wired together. If I have an app that depends on Spring 2.5 and Hibernate 3.2.5, that's fine, if I install another app that depends on Spring 2.5 and Hibernate 3.2.6 it is going to break because my app can't wire to 3.2.6 and 2.5, because Spring is not wired to 3.2.6. This notion of pinning was recorded, where you can get to a situation where you are pinned in place and you can't get the dependency profile you want. This really comes from the fact that OSGi is a foundational piece. Is has this foundational versioning system but doesn't try to deal with whole application dependency profiles.
One of the things we are working with the dm Server for the moment, is the solution for that problem, where we can treat versioning much more as an application dependency profile. Your application needs 3.2.5 and Spring 2.5, so we'll get you that just what it needs to be. That might be done by installing new version of bundles or whatever. There are more ways to be done that than just plain OSGi. So, yes, there is base support for running multiple versions side by side, but in practice with complex applications, it often means that you can't run two applications side by side.
That's an interesting feature, I have not seen that yet. We don't have any implementation of that right now and it is not something that our users have asked for. We are certainly not adverse to any of that kind of functionality, I'm not sure how easy that would be to do, that sounds quite complicated, everything is possible if somebody else is already doing that. The point I would like to make is that we are very user driven, so we try not to do things for ourselves, it's very hard especially when you got all the new projects, all these things you want to do, in fact we have 10 times the number of features that we can practically do in our minds.
It is always this trade-off between what we do versus what we want to do and predominantly is driven by users. Our plan starts looking at these 20 features that we think are great, then we speak to a few customers and we get some feed-back from the community and it completely changes, so certainly if the customers are pushing for that, if they like that feature from WebLogic, then is certainly something that we'll look into. So far we've not heard any problems about the way our refresh works, when you are working in dm Server you are working with the Tools, you are changing bundles and you are doing a save in Eclipse and the changes are reflecting live in your running application without stopping or starting.
Some of this state is refreshed, not all of it, because of the modularity, it's all in the modules you change - they get refreshed, the rest of the state stays in place. It would be interesting to see how that kind of change works when you make large structural changes. If I'm removing fields and I'm changing map structures completely I don't know how the state can be reflected, but sure if the users are asking for that, then we'll definitely look into it.
We have already our open source Spring IDE which is focused on Spring frameworks, Spring Web Flow, and that is still very useful if you are building applications for dm Server because predominantly I would imagine people building Spring applications to run on dm Server - there is no requirement for that but a lot of customers are doing that. On top of that we have SpringSource, the dm ServerServer Tools, that are also open source EPL. If you are familiar with WTP - Eclipse WTP - you'll be very familiar with the way this works, it's another server's view, so you can run dm Server as a server inside of Eclipse. It gives you 2 new natures, a bundle nature and a power nature, so that this power nature bundles together as one application and this gives you things like code-completion for your OSGi manifests, it gives the ability to deploy bundles throughout the dm Server, it gives you the appropriate save hooks, then when you save a file changes a redeploy to the dm Server.
Then we have the SpringSource Tools, which is our commercial offering, which is all this stuff packaged together in a single unit. That's available if your company has a SpringSource subscription, it is also available in a personal use license. If you are looking to try it, I'm lazy I always do this, I always download the personal user license, everything is packaged for me in a convenient package, that contains all of our commercial additions, but also importantly contains dm Server tools and Spring IDE. If only want to go open source you can still get those 2 components and you can have everything you need to run for dm Server without having to pay any commercial and license fee.
JMX is a big thing because I'm on the JMX Expert Group. We have this principle in engineering dm Server, which is this notion of causally connected self representation CCSR and the idea here is that every component in your system has a runtime representation, and you can prompt this representation and just simply tweaking the representation, tweaks the component itself. You can think about this as being quite as simple as: I have a thread pool and this thread pool has a runtime representation, maybe it's on object called ThreadPool, and I can change the size of the ThreadPool and the actual representation of the thread pool grows and gets more threads - something quite simple as that.
It means that every module, every component, every piece of dm Server is fully ... at runtime. All the different dm Server subsystems, all the bundles that are installed, all the modules that are installed how they wire together, what their dependencies are - all these things exist as runtime concepts. We want to expose that for management and we have the principle that everything in dm Server is exposed by JMX. We have many number of consumers, including our own Application Management Suite, which consumes that JMX published information and you can do all you want with it. For us it is really about exposing everything about JMX.
That gives you a number of benefits. One is standard module and wherever possible we do like to use standards. JMX is moving quite quickly, especially the JMX 2 Spec. There are a lot of new features coming out, in particularly around how you deal with JMX federated across a large number of machines. To go away and build something new when that feature in particular, is coming out - it's kind of silly. There is a lot of technology going into that implementation that we want to build to take advantage of. It makes no sense to reinvent the wheel there at all.
Cloud is an interesting problem, I think. It's hard to know at first glance what it means to be cloud ready. Some work we've done internally to get cloud images and they are just images. I can run anything on the cloud. If the cloud's working properly I should be able to run anything that I like. Where having specific cloud support becomes important is in this situation when you got many nodes and they can be coming up and going down. The group of nodes together has to be built to grow and shrink dynamically.
Typically, we already have that in ... so they just cohere and while you can bring up new nodes and they join together. But there is no multicast in cloud, certainly there isn't one on EC2, there is no multicast. So I can't use multicast to discover all my nodes and it's not just my application server in there. I also think about Apache HTTP Server, fronting my application service with web serving, if that is its content resources. The load balancer needs to know about new nodes coming in, I need to know about load balance and nodes going away. Really, it's about the ability to adapt.
Also in a clouded environment, you want to have the smallest possible image, you don't want to be using unnecessary computing resources. Having a bunch of middleware components running without having any use and taking on memory, it's kind of pointless. In terms of image management, as well, I think is really difficult if you have to manage lots of different images for different purposes. We have a customer who was doing online gaming, and they are interested in being able to have the dm Server - the base kernel piece as their common deployment platform with different middleware components on each node. I think that's really nice for the cloud, what we want to be able to do, and this is the end goal, is to say "Here is the base dm Server image running on Solaris, on Linux - just the kernel."
You can start up any number of these and you can deploy any number of applications to them, and they just grow and shrink as appropriate, the appropriate middleware components, the appropriate third party components. You don't need to know in advance what needs to be installed on that image to install X application on that, and I think that is what is critical to the cloud for application service - is the ability to adapt, to grow and shrink, to move about as the cloud itself changes. If an application service is static it's not going to fit very well inside the cloud environment.
For OSGi, that is the easiest to tackle, I would like to see OSGi continue the way it's already been running, as far as specifications it is very well run. They are not resistant to change, but they are responsible about change. They don't like to just put the kitchen sink in there, and I think that's important when for us in particular, we are trying to use OSGi. As a foundation for our system, we want to see as little change as possible. We want new features, we want improvement, we don't want massive thrash.
They have a nice split between the co-platform that changes slightly and in a very control manner, and the enterprise expert group, which still in its infancy, thinking about how OSGi really runs and enterprise, and I think that is useful to us, because it means that we can select the pieces that make sense for our deployment without getting lumbered with stuff that doesn't necessarily make any sense. I think that OSGi needs to continue as it is. It would be nice if OSGi was an internal part of Java, I know there is some discussion of that, and it would be really useful. For application servers, I think, this is all I can say: it is not about the vendor, it is not about you as an application server vendor doing what you want to do.
Application servers have to change to be much more about what the users want, how the user wants to work and what the user needs. With dm Server, we have ideas, we have lots of ideas but they are no use if our users do not want to run with the idea. If it is not useful to a user, it is not useful to me. I like implementing technology, but what I really want is to see a lot of people using dm Server. And the only way to do that, is to give users what they want. What that seems to be right now, it's flexible middleware. I don't want to deploy everything, I want to deploy what I want to deploy, let me choose what makes sense to my application.
Ideally, if I can, I don't want to choose, I just want to deploy my application and give me the only minimum pieces that I need. I don't want to have to spend ages configuring it. More and more configuration is an issue, I think. How I cross large cluster of nodes, where the nodes are not the same? Do you size a thread pool? It is a complex problem. An ops have to size thread pools across 128 machines, when those machines are not the same and some of those machine are probably going away quite quickly - for cloud that's a perfect example. Self configuration is a very important thing. That's nothing fancy, it's just simple sensible self configuration needs to be implemented. More and more I think multi environment.
Application servers need to be flexible in where they can run: when they're in a cloud, when they're in a grid, when they're in a single node, in IDE. You need to be lightweight and small and compact and fast and agile to be able to run in all those different environments. It's not enough just to be this big 1GB image, bigger than your IDE. Certainly, if the application server is bigger than the IDE, I think something is a mess. With dm Server we're just heading down the road - we're constantly following what users are asking. It is great because, obviously, with open source we have such a passionate user community and I've been surprised already by the number of people who participated. We have had the community going about 6 months, and already there are people in the community who answer questions for the users before we have the chance to. That's a sign of a really healthy community, it is really encouraging to see that. We just want users to keep telling us what they want, and we keep delivering the best we can.
14. Is there a strategy to sustain mass adoption for OSGi?
It's interesting, the point I was saying before you came in is that for dm Server OSGi has 2 things: it's an internal implementation to know and it's also a user focused technology. Separate those 2 things is important. For us, OSGi is a long term implementation technology, it's not really important for us to use OSGi internally, as long as it gets long term adoption. For us as programmers there is just one option, the option we favor because it gives users a lot benefit. I hope that what will happen with OSGi is similar to what happened with Spring framework, because it's so pragmatic, because it does solve real problems.
It won't need to be sold. The point I was making before you came in, was that a lot people say that OSGi solves all of your versioning problems. There still is a class of versioning problems it doesn't solve. When people have been told this will solve every problem you have and it doesn't, they get disarmed. The critical thing is just to focus on what it does do and it gives you the ability to really modularize your application truly especially to open to modules that make sense. They are enforced at build time, they are enforced at coding time, they are enforced at runtime. That is a real benefit, not to be laughed to at all.
If you are building an application of any size, being able to split the code into manageable chunks is hugely important to the success of the application. So I think OSGi really doesn't need to have a massive amount of selling rate, what it does need is support from third party libraries - that integration between OSGi and Hibernate, OSGi and Tiles, which is really difficult. The first step along there is to make all those third party projects into bundles and to make them OSGi ready. We did that work, we built the SpringSource enterprise bundle repository. I think it is 500 open source libraries and made them ready for OSGi. Hopefully, over time we can push them all back, those independent projects, but for us we just needed to make that step and do it, and it had to be done quickly - we have a guy working on that full-time, bless him!
15. Is there a flagship company or project that you've been working on, a showcase?
Yes. We have a couple of interesting clients at the moment, there's a gaming company, I can't mention who they are, but my favorite customer at the moment, it's really interesting, I'm going to see a bank tomorrow, we have a large Silicon Valley company, which you all know and I can't say their name, they are currently using our dm Server against another OSGi vendor. I think what we were doing badly was telling them what dm Server was, because they clearly didn't understand, and one of their guys spent a week with one of our guys, and now they understand it and they are like" This makes perfect sense to me now".
What surprised me was that with 1.0 product you tend to get a lot of early adopters - alpha adopters in the open source space and that's great because you can develop and you get all this feedback. We have a couple of guys working on the team from IBM who have never seen that, they have worked in IBM and they have got to talk to customers occasionally, but they didn't have that direct interaction with the community. What I didn't expect was that 3 or 4 weeks after going into production with the 1.0 that was a complete new kind of product, we would have production customers who would pay us money. What was kind of frustrating, was that is was happening for a couple of weeks and the sales team hadn't communicated "Hey! Look, I sold a license of your software".
I stumbled across a chap, we meet, at JavaOne and we were talking for about 2 hours about GlassFish 3, about dm Server, and about what both were doing with OSGi, and he was evaluating at that point in time and this guy crops upon the open source list and he's a really active contributor and he's posting book reports and we get a lot of feedback from him. Then we got told by Sales that I have to go see this customer, they bought support contracts and they are using it in production, I walk into the room and I think " I've meet this guy before", and embarrassingly I couldn't remember his face, and he was the chap I met at JavaOne and he was also the chap who'd been posting actively on the forums.
What I found really interesting was that they had been posting a lot of stuff on open source, and asking for bug request and so forth, even though they did a commercial support contract with those, but when they had a really critical issue, they were able to get response like that. Usually a response was coming within 2-3 days, which I think is pretty admirable, but when it was serious, it was like "OK, we did it literally in 12 hours". It was really encouraging for me to see people actually running with it. I think for them the value was really modularity.
They wanted a lightweight platform on every node that they could choose what was running and they could also choose how to package up their application and made them in a modular fashion. What's great now is that we have this community of people who are telling us what they want, and this community of paying customers who are telling us what they want. By large, both communities have the same needs, and I think that's very encouraging, because obviously there is a large problem that we are trying to solve, the problem based we are on moving into - I am really encouraged by that.