In this podcast Joe Chacko talks about the WebSphere Application Server v8.5 Alpha Refresh Liberty Profile and the changes that have gone into the runtime and the tooling. He talks about OSGi and how you can now use OSGi to create enterprise applications and run them on a Liberty Profile server.
Hello, I’m Joe Chacko, back for another quick chat about the WebSphere Application Server version 8.5 Liberty Profile. We’ve had some valuable feedback on our alpha release and we’ve just published a refresh with quite a few changes. I’d like to tell you what we’ve been up to, what’s new in this refresh, some highlights from our tooling (including a brief discussion of OSGi), how to get hold of the tools & the runtime to try them out, and how to get involved in the WASDev community.
We’ve been hard at work to enable more function from the WebSphere Application Server full profile. You might be wondering why merely ‘enabling’ something would require hard work. It’s partly because we are making the server composable. That means that we have to whittle down the dependencies to make the components as slim as possible.¬† However, this is not just a composable application server, it’s a dynamic composable application server. That means you can change your configuration on the fly and the server will load and unload parts as necessary, and bring up the new configuration. For many versions now the full profile server has been engineered to be robust and scalable, but dynamic configuration and composability are new requirements.
Engineering these qualities in while maintaining the behaviour of the full profile server runtime is non-trivial. It’s just the kind of challenge we relish, with plenty of intense brain workouts along the way. If our work included the same level of physical challenge, we’d probably be in pretty good shape for the London Olympics in 2012. One of the technologies we’ve been using to meet this challenge is OSGi – but more on that later.
‘Just what is all this function?’ I hear you mutter in anticipation. This is a refresh, and we’ve been extending what’s already there. We’ve improved data access, adding support for the @PersistenceUnit and @PersistenceContext annotations in JPA, and getting JPA better integrated with JNDI. We now support shared database connections to Oracle, DB2, SQL Server, and Derby. You’ll also find support for multi-part forms, and better authentication support and resource injection for servlets as per the Servlet 3.0 specification, and we’ve introduced new JMX commands for restarting and stopping the server.
Some of our work has been forging new ground too, especially with our tightly integrated tooling. We have demos internally every couple of weeks to showcase changes and the tools demos always leave me thinking, ‘Now that’s the way this stuff should work.’ For example, if you hit an error in an app you are developing and a page fails to load, as long as you are viewing it from within our tooling you’ll get a notification in the internal web browser to show you the stack trace of your error. You can click on a line in the stack trace in the browser to go straight to the relevant line in the code.
When you create a server from the tools, they generate the config for you, and also provide a GUI and source view for editing the config. If you drop an app onto your server, the config is automatically updated to include the app. The tools now auto-detect more of the features you will need including Servlet 3.0, Blueprint, WAB, JSP, and JSF, and your server.xml gets updated with the declarations you need. Let me illustrate how that might work for you. If you have a running server and you drop a JSP app onto it, the config will get updated, and the server will fire up the JSP feature and start your app. No restarts, and no fumbling around with config! Hurrah!
Now, I promised to come back to OSGi. OSGi is a set of specifications that build on the Java programming language to add modularity. ‘Java is already object-oriented’, I hear you say, ‘so why does it need modularity?’ Well, Java’s classes are very fine-grained. Java does provides a module-like structure – the Java ‘package’ we have all come to know and love – but the tools for managing packages and package dependencies are very limited. OSGi addresses that problem. In fact, it addresses it so well that you can have many different versions of the same package available at once without conflict. If you tried to manage this yourself, you would need a master’s degree in Java class loading just to get started. With OSGi, it becomes possible to clean up the mess that can sometimes happen in Java when you re-use code from multiple projects or even different versions of the same project. I started using OSGi in earnest this year, and it has been an epiphany. It allows me as a developer to keep components loosely coupled, which is something of a holy grail in software development. I’ve also found that I can take an OSGi bundle (a specialised jar) from another project, drop it into our server and (at least sometimes) everything just works. When it doesn’t work, the OSGi framework tells me why it couldn’t resolve the bundle and doesn’t even bother trying to start it! Let me put that another way: if your package dependencies can be resolved, things will work smoothly – if your dependencies cannot be resolved, the system fails early and cleanly with good diagnostics; you won’t see half-initialised structures and obscure NoSuchMethod- or NoClassDefFound- errors during normal operation.
OSGi has been great to learn and I’ve found it very helpful in designing, writing, and maintaining an application server. You may not have a server to write, but you can use OSGi to create and package enterprise applications too. In this refresh we now support Blueprint, which provides a simple programming model for writing applications as OSGi bundles. If you are using Eclipse, just search for OSGi in the marketplace, and you’ll find the free IBM Rational tools to help you build an OSGi application. Alongside those tools, the Liberty Profile tooling allows you to publish your OSGi applications direct to a running Liberty Profile server. As with Java EE applications, the tools will look at what you are using and add the features you need into your server configuration automatically.
By now you should be itching to try out this refresh. As before, I recommend fetching the tools into an Eclipse for Java EE Developers 3.7 installation – search for Liberty in the Eclipse marketplace and you should see our alpha refresh. The tools will let you fetch the server runtime when you first create a server.
I also invite you to take a look around the wasdev.net site. From the homepage, take a look at the Download tab for more ways to get the tools, the Learn tab to find the latest InfoCenter with our product documentation and the Participate tab to start or join a forum discussion.
OK, I’ve told you what to expect in the alpha refresh and where to get it.¬† Now please tell us what you think of it.
My sincerest thanks to my colleagues who worked so hard to get this refresh out, and thank you for listening to this podcast. Toodle pip.