Bio Alasdair is a Senior Software Engineer working for IBM. Alasdair has been a developer on WebSphere Application Server for 11 years and is currently the Liberty profile development lead. He has a long history of making WebSphere easier to use (especially around messaging security) as well as more recently making it small, sweet and simple.
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 and I am here at QCon London with Alasdair Nottingham, IBM Liberty profile development lead based at the Hursley software lab in the UK. Alasdair, can you start by introducing yourself to the InfoQ community?
My name is Alasdair Nottingham, I have worked for IBM for 11 years now, seems a long time to be honest, and most of that time I’ve been working on WebSphere Application Server; over time various different bits, more recently around areas of OSGi and making the runtime more lightweight, more dynamic, more flexible; tastier, I like to say. There is this phrase 'consumability' that gets bandied around and I always liken that to eating a good apple; you know, tasty.
So, there are two areas were we use OSGi. We use it as a foundation technology in order to achieve the dynamic runtime that we have. So the whole runtime is composed of things called OSGi bundles which plug together to build the capabilities that users and developers want to make use of. We also allow customers to write their own applications, so a few years ago Enterprise OSGi was launched which is kind of a merging of Java EE and OSGi, to allow you to do modular Java EE and we also enable that as being a programming model on top of WebSphere Application Server. So it’s very important.
The Liberty profile is a new runtime profile of WebSphere Application Server; it’s designed to be developer first. That doesn’t mean it can’t be used in production, you absolutely can, but our whole ethos around designing and developing it has been “let’s make it a really nice experience for developers", so trying to remove all of those things that make it difficult for a developer to do their day job. Things like, in production, server start time doesn’t necessarily factor as a major burden; if you are a developer and you are expecting to restart an application server many, many times in your development, actually that start time can start to be a problem. So, focusing on what can we do make it easier for a developer to be productive and get the maximum value out of their time?
Yes. Just as the full profile is built on OSGi, it is also built on OSGi, but we are exploiting much more of the capabilities of OSGi as a technology than we were in the full profile. So it’s very much loosely coupled, service based runtime rather than something that is slightly more static in the full profile.
When we started working on it we had a huge list of design goals and some of them were very specific, and actually the more specific ones typically were the ones we threw away. The ones that remained were things like it needed to be simple; and trying to get simplified configuration, simplified development that was very core. We had this trap in the past, and some people still fall into it, which is “Oh well, it’s OK; x doesn’t need to be that usable because we will fix it in the tools.” And what we wanted to do, we wanted to completely change that, so instead of the tools fixing underlying usability things, actually the runtime itself was completely understandable and usable, and everything we did in the tools was really just value add. So it’s kind of icing on the cake to make you much more productive. So, stop putting work into the tools making the runtime usable and start actually having the tools provide additional value add to give your developers more ability to develop applications rather than having to deal with us, we are just getting to a level set in the tools.
Yes. That was one of the criticisms that we were trying to address. The configuration is one xml file and it’s very loosely typed so... I say loosely typed - if it’s not valid xml then we wouldn’t understand it, but anything you put in it other than that, if we don’t understand what it’s telling us, that’s fine, we will just skip over and ignore it. You can put anything into the xml and our runtime will deal with it and only process the bits of it it understands. And that's actually important for one of our goals, which was we wanted to ease the migration from version to version, and fix pack to fix pack, and one of the areas specifically that in the past has caused issues is the use of validating schema. So, if you validate a document against a schema and you have the wrong version of the schema for a particular document, then it’s not going to be valid.
So, by making sure that we didn’t validate it against a schema, by making sure that we were doing sensible things with what we had and ignoring what we don’t have, it means I could configure some capability for a version of the product that you are not using and it would be fine; it would work on the old level and vice versa. So, it was very much configuration by exception and we will just cope with anything that we don’t know about.
Charles: Ok, so to be clear the server xml defines the features that you're using within your application.
That’s one thing. It also configures how those features operate. So, the first thing that you would do when you’re configuring Liberty, is you'll tell us what capabilities you want. If you want to write a servlet app with JPA, you would tell us you are writing a servlet app with JPA and we would configure a server that does those two things without pulling in things like JSP and JSF. Once you’ve got that you need to tell the runtime, “Here’s an application, these are the JDBC resources I want to talk to” and that all goes into that same xml file.
7. If I am developing something and, in your example say I add JSP; so I’ve started with a servlet and JPA and then I want to add JSP to it, I drop that into the xml file. Do I then need to restart the app server?
No. By default when you change the configuration we will reread the configuration file, so when it changes on disk we notice, we make the runtime reflect that. Now, you can turn that off and if you turn that off, then you would need to restart the server; but going back to the goals, you don’t want to have to restart the server just because you’ve added some configuration. What you want is, you want to add the configuration and have the runtime go “Ooh, I’m going to make that take effect right now” or as close to right now as is practical, because monitoring file systems can be expensive.
Charles: Sure. That’s a lot more dynamic than I guess people are typically used to essentially with WebSphere.
It’s dynamic and it’s designed around the idea of trying to make the server runtime fit for the purpose of your application. I like to characterise... It’s a tricky concept to talk about “fit for purpose” because people read that phrase and think, “What do you mean it’s not fit for purpose?”, and it’s not about that. There’s a difference between giving somebody everything including the kitchen sink which means it’s fit for any purpose, including washing up, and actually all I need is a toothbrush and a glass of water. And that’s really the difference here which is, "All I need is some water to clean my teeth and all I want is the stuff for that. I don’t need everything that I would need to do the dishes."
8. How reliable is it from a cross platform point of view? So, suppose I’ve built an application using a Mac laptop or something and then I package it up using your packaging tool and I want to deploy it to a zSeries box or something. Will that work?
Yes, within some realm of... there are caveats. There are differences between, for instance, JVMs. So for instance if you... Standards say there shouldn’t be, but we all know that there are areas in standards where people take different implementation choices, and JVMs aren’t bug-for-bug compatible. So, if you go from platform to platform, you may find that there are areas where it doesn’t quite work the same; which is why I wouldn’t recommend somebody test on a Mac on a Sun JVM if they are going to deploy to Z/OS on an IBM JVM. They should at least do some level of testing on top. The criticism, I guess, of Java is it's write once test everywhere, but in this case I am not saying test everywhere, I am just saying it’s sensible to test in the target environment. But, generally speaking, that type of transformation is possible, you might need to make a few minor tweaks, depending on, for instance, if you are running on Z/OS typically things are encoded in EBCDIC, Macs on JVM doesn’t have EBCDIC support. So, there’s always a change something in your application won’t cope with that transformation. But the runtime should be fine.
Charles:And then you have server specific features as well, things the work-load classifications on zSeries.
There is some Z/OS integration code. So, for instance, people who typically run their applications on Z, like to be able to take advantage of the platform features around security and transactions, so those are available.
Now, that’s platform native code, so you can’t necessarily take a server packaged on a Mac and if you’ve got the runtime in it, deploy it to Z. In that environment you would actually want the WebSphere for Z/OS product on the Z and you would just take the application and configuration to the Z. But again, you would need to tweak to add the Z/OS specific features in, because the server configuration is what enables every capability. If your configuration doesn’t say to pull in something, we won’t pull it in, and that goes the same for those Z/OS platform capabilities. So if you took a distributed thing on to Z/OS you wouldn’t be using your Z/OS integration.
9. Right. You made use of some, I guess they were emerging standards at the time, from the OSGi Alliance. I’m thinking of things like subsystem spec and that sort of stuff. Are you tracking how those have developed and aligning Liberty with them?
Yes, very much so. In the current beta, the format that we are using... in fact in the release, the format we have chosen to use is the subsystem format. Now, we don’t use an implementation of the subsystem specification inside the Liberty runtime itself, but we read exactly the same metadata and we do with that metadata exactly what subsystems would do. So, there are some features in subsystems that you wouldn’t have available, but if you are trying to write a capability.... We use it internally in the current GA and in the beta you can actually write your own features for the Liberty profile and when you write them, you are writing them using the subsystem specification format for the features. There are a few value adds that we’ve added on top, but you can just write a subsystem standard feature and get it running on our runtime.
Yes. So if you go to WASdev.net we currently have a beta program running, so you can get an updated version of Liberty profile. And it contains features such as CDI, EJB Light, web services for JAX-WS and also some JMS support. So those are things that we were told specifically were missing and we’ve been trying very hard to flesh those out. The work isn’t completed, it’s a beta, but it does indicate what we are trying to deliver.
Yes, that is an interesting question. I think there are some things that won’t make it across; what we are trying very much to do is focus on what is it our customers and our developers and users are telling us they want us to provide, rather than... Because there is a lot of capability... It’s a lot of capability that is needing to be put on to Liberty in order to move everything. So, it’s "What do people need?" is the primary motivator.
The way we've characterized it is it’s a different kernel. Runtime is a very general statement; it’s a different kernel that is certain: different way of orchestrating the runtime, different way of configuring the runtime, different way of thinking about the runtime, all of those are true. But core pieces of the runtime like the web container, the EJB container, they are all common; they are essentially the same containers that are existing already on the full profile. So, when you say is it a different runtime, there are aspects of it which are very different, there are aspects of it, important aspects, which are the same, and we have taken the existing proven code that people have and understand their application’s dependencies on and we are still using those inside the Liberty profile. So, it’s not so much a totally new runtime as kind of more a hybrid of totally new and full profile runtime.
There are two sets of tools that we’ve provided, one of which is Rational Application Developer. Rational Application Developer has the ability to write Java EE applications and deploy to the Liberty profile, in addition to the full profile. We’ve also got something called WebSphere Application Server Developer Tools for Eclipse, which is a bit of a mouthful, but that is a small amount of tools that allow you to use the Eclipse Java EE product - I’m not sure if that’s what Eclipse would call it, but they have a download which is Eclipse for Java EE developers - and it plugs into that and then will enable you to publish to WebSphere Application Server Liberty profile and the full profile versions 7 through to 8.5; and that’s available from the Eclipse market place. So if you are using Rational Application Developer 8.5 you can use that, you can develop to Liberty profile and full profile and you’ve also got the option of WebSphere Application Server Developer Tools for Eclipse.
14. It seems to me that Liberty represents quite a significant, kind of philosophical shift in the way you are thinking about WebSphere Application Server, in that WebSphere Application Server has always been a popular tool with IT ops people, but maybe less popular with developers. And this is quite a different approach that you are thinking kind of developer first. Is that a fair comment do you think?
I think it possibly is, definitely it’s not been the best developer experience in the past and the reason we say it’s designed developer first... there is a reason why we are saying that, it’s not just because it sounds like a good thing to say.
The reality is that developers are important, developer productivity is of huge importance and what we are trying to do with Liberty is to ensure that, in addition to having the best possible operations experience, we also have the best possible developer experience. And we fell short; I can’t deny that there were things about full profile that did not meet the needs of developers and we are trying to change that with Liberty. I think when people pick it up and try it, they will be impressed by what we’ve done.
Charles: That’s a great place to stop. Thank you very much.