WAS V8.5 Alpha and the WebSphere Liberty Profile

Earlier this year I took on the role of Chief Architect of the WebSphere foundation and have been busy with the team since then working on the development of our next release. We launched the first fruits of our labour last week through our new WASdev community site: the WAS V8.5 Alpha. This is an early glimpse of what's coming next in WAS and it is heavily focussed on making the WAS runtime and tools the best environment possible for developing and testing web applications. At the heart of the Alpha is a new dynamic profile of the WebSphere runtime that we've called the WAS Liberty Profile. Rather than being a static profile of runtime features, Liberty adapts to the requirements of the application and ensures - at a really fine-grained level - that only the necessary application container functions are started. It gives you the freedom to deploy web applications with wide-ranging requirements and provides all the pieces they need (like security, transaction management, connection pooling, persistence through JPA or JDBC, and so on) without pulling in any more than they need. And it provides fidelity with the full-profile WAS runtime to which applications are deployed in production because the containers and services started by the Liberty profile are the same.

One of the key innovations in Liberty is a new kernel that processes the specific "features" required by an application to load the required container(s) and WebSphere platform services: WAS has been an OSGi-based runtime for many years (since WAS V6.1) but, with the Liberty profile in the WAS V8.5 Alpha, we've moved beyond simply modularity and gone to town on exploitation of dynamic OSGi services. This is what delivers the tiny runtime footprint and a WAS server that starts up in a couple of seconds. And this is only one aspect of what's new for developers - we've also dramatically simplified server runtime configuration so that a test/debug WAS server instance can be configured easily, either inside or outside an Eclipse environment, with a single XML file covering all aspects of the server, the applications and the resources required by the applications. If you've ever looked at a WAS configuration and wished you could treat it more like a development artefact - storing the configuration in an SCM system, versioning or diffing it, sharing it between developers - well now you can. While the server config can be as simple as a single XML file, there are also flexible ways to compose a configuration from fragments that are aggregated through include statements.

The WASdev home page lists "8.5 Reasons why the WAS Liberty Profile is awesome". For more details, including an overview of the new simplified server config, take a look at the Introduction to the Liberty Profile article I posted to WASdev.



And did I mention that its free? And so, now, are our most popular web development tools which we're making available as Eclipse features (in addition to being bundled inside RAD). You can get all this from WASdev downloads page.

But enough talk....lets see how quickly we can download the tools, the WAS server, configure a server instance, install a simple app and bring the whole thing up. I'll assume you already have the Eclipse IDE for Java EE but if not you can get that from the Eclipse site. The only other thing you need is an IBM ID for the downloads - if you don't have one then simply register for one here.

OK. Open up your Eclipse IDE (3.7 or 3.6.2), start your stopwatch and follow these steps:

1. Go the WASdev download page to install the WAS Liberty Profile tools into Eclipse. This gives you a rich set of web development tools along with the ability to launch and control instances of the WAS Liberty Profile server. For Eclipse 3.7, its as easy as dragging the install button from that page onto your Eclipse IDE title bar.
2. Accept the license terms (I'll take the liberty of assuming that, under these "beat the clock" conditions, you have already squared this with your friends in the legal department) for the install to proceed. The total size of the tools being added to your Eclipse environment here is less than 3M.
   
3. Restart Eclipse. The tools are now installed - we can use these to now install the WAS server runtime itself for use testing and debugging applications. This is going to download and install a whole WAS Liberty profile server. Sounds scary? It isn't - the whole runtime is just another 25M and there's no additional installation program required.
4. In the Eclipse workbench, open the Servers view. Right-click the Servers view and select New > Server. Under the server type list, expand IBM then select the WebSphere Application Server v8.5 Alpha Liberty Profile server type. Click Next.
5. The WebSphere Runtime Environment page is displayed. In the Installation folder section, click download and install. Choose the WebSphere Application Server V8.5 Alpha site and enter your IBM ID and password and click Next. Accept the license terms for the runtime. (You'll have already mentioned this to the same lawyer you talked to about the tools license). Click Next.
   
6. In the Download and Install page, specify the installation target folder for the WAS runtime to be installed to. (Just 25M, remember).
   
7. Click Next. WAS is now installed. (Note that, if you just want to install the WAS Liberty profile runtime independently of the tools for test and debug puposes, then you can skip all the steps above and simply download the WAS Liberty Profile runtime directly from the WASdev downloads page and unzip it).
8. There's a pre-configured defaultServer instance but lets go all the way and create our own server instance using the New button. Call it whatever you like e.g. firstserver. Click Finish. You now have a WAS server instance to which you can install and test web applications. On your filesystem, there will be a firstserver directory structure in the usr/servers directory of your new WAS install.
   
9. Now we need to deploy a web app to this server and run it. You can download this simple StopWatch WAR file and import it into Eclipse.
10. In Eclipse: File > Import WAR file. Click Next. Enter the location of the WAR file on your filesystem and make sure the Target runtime is set to WebSphere Application Server V8.5 Alpha Liberty Profile. Click Finish.
    
11. In the Project Explorer, right click on the new StopWatch project and choose Run As > Run on Server.
12. The WebSphere Application Server V8.5 Alpha Liberty Profile should already be highlighted. Click Finsh.
13. Stop the Clock!

If you're looking for the fastest, cheapest and easiest way to develop web apps for WAS then this is it.

I've been busy spreading the message about Liberty since we started the WAS V8.5 Alpha - you can take a look at my slides from the WebSphere Technical Conference in Berlin, where we launched the Alpha:

WAS Liberty Profile

And if you happen to be in Mumbai on Oct 19 or 20, come and hear me talk about Liberty at the IBM Software Universe.

God Dad, You're Soooo Embarrassing

...the words every proud parent longs to hear, to know they've succeeded in keeping their offspring alive long enough for them to become a teenager. I heard this as I walked through the door yesterday and was doubly pleased when I found out why. The video I made a little while ago to kick off the new Enterprise OSGi YouTube channel has successfully attracted enough attention for my daughter to be teased at school, once again proving the value and reach of social media. Result.

OSGi and SCA come together in the WebSphere OSGi Application Feature Pack

28 May 2010: The WebSphere V7 OSGi Application and JPA 2.0 feature pack is now generally available (and free!) and supported for production use. This is something we're pretty excited about in the WebSphere team as it offers some truly powerful techniques to simplify the development, management and maintenence of complex enterprise applications. I described some of the primary use cases for enterprise OSGi applications in a previous post about the early program we've been running since the end of 2009. Some significant additional capabilities have been added since then.

The first one I'd like to talk about is SCA. If you install both the OSGi Application feature pack and SCA feature pack then you'll find not only do you have the ability to assemble SCA composites and OSGi applications but you can also include OSGi applications as components in SCA composites - the combination of these two feature packs is greater than the sum of the parts. So what does it mean to use SCA with OSGi? The two technologies are used for quite different purposes but are extremely complimentary.

OSGi provides a means to break down your enterprise application into (i) modules (bundles) that are specific to the applicaton and (ii) bundles that are common across applications. The latter can be separated out from the application archive and placed in a common OSGi bundle repository that WebSphere is configured to use during application deployment. Immediate benefits include smaller applications, a standard mechanism for using shared libraries in enterprise applications and a smaller memory footprint when two or more enterprise applications share common libraries. And you haven't needed to write any new or different Java code to take advantage of this. Another feature OSGi brings is a standard extensibility model - through OSGi services. You can design your application to take advantage of OSGi's rich and dynamic service-based model to consume services from the OSGi service registry. Service interfaces then become extension points that you can design into your application and extend it in the future via service provider implementations introduced through separate bundles with no change to the original application code. OSGi defines Java APIs for registering and discovery OSGi services but a declarative approach to use OSGi services is much simpler. This is where the OSGi Blueprint container comes in - the Blueprint container (which is added to the WebSphere runtime when the feature pack is installed) manages the lifecycle and dependency injection of POJO bean components and is configured through an  application-level XML bean definition file which is a standards-based evolution of the Spring bean definition XML. Blueprint provides a fine-grained bean assembly model for OSGi applications and simple declarative means to publish a service provided by a POJO bean component. For example, the following bean definition snippet defines a bloggingServiceComponent bean, implemented by the BloggingServiceImpl class for which a BloggingService service is registered to the OSGi service registry.

<blueprint>
  <bean id="bloggingServiceComponent" class="com.ibm.ws.eba.example.blog.BloggingServiceImpl">
    <property name="blogEntryManager" ref="blogEntryManager"/>
    <property name="blogAuthorManager" ref="blogAuthorManager"/>
    <property name="blogCommentManager" ref="blogCommentManager"/>
  </bean>
  <service ref="bloggingServiceComponent" interface="com.ibm.ws.eba.example.blog.api.BloggingService"/>
</blueprint>

So now we can build a modular, extensible application assembled from POJO components described by a standardized XML bean definition file. No SCA so far - when does that become interesting?

Say you wanted to remotely publish the BloggingService and make is available over an ATOM binding. Or you wanted to compose your OSGi application into a coarse-grained composite with other non-OSGi components. These two scenarios are where SCA comes in. The WebSphere OSGi and SCA feature packs support both these patterns through the introduction of a new SCA implementation type, impl.osgiapp. By defining an SCA component for your OSGi application you can assemble it into an SCA composite with any other SCA implementation type - for example an EJB component (impl.ejb). And by promoting the OSGi <service> definition into an SCA component definition, the service becomes remotable with a choice of any of the standard SCA bindings to determine how the service invocation and parameters should be serialized. Thats a pretty powerful extension to raw OSGi applications and enables OSGi applications to be used as part of a SOA application deployed to WebSphere.

And then there's the tooling. The second major addition to our OSGi Application support that I wanted to mention is our Eclipse-based tooling to simplify the development and deployment of OSGi Applications. Integrated into the new RAD Beta are new project types for OSGi Applications, graphical tools for editing OSGi Application and OSGi bundle manifests and a Blueprint XML editor for blueprint module definition files. These offer familiar design and source views so you can choose to edit the metadata directly or through a form-based editor. And of course there's all the content assist, validation and re-factoring productivity tools familiar in RAD. The RAD Beta also integrates a test server environment augmented with the OSGi feature pack to enable simple run-on-server testing.

RAD Beta OSGi Blueprint XML Editor


The feature pack contains a number of comprehensive samples that illustrate the primary use cases. Try it out - and if you have any questions or comments, visit the OSGi Application feature pack technical discussion forum.

Apache Aries - An open source project for Enterprise OSGi Applications

I spoke at the recent OSGi DevCon London conference (part of JAX-London 2010) as it extended late into the evening - Oracle's Mike Keith and I were competing with the bar in the 9-10pm slot as we talked about the Apache Aries and Eclipse Gemini open source projects. For those of you who chose the bar, or who couldn't make it to the gathering in West London, here are my slides on Apache Aries. They describe the primary goals and capabilities of Apache Aries, including how to get involved.
The 1-line summary is: Take a look at Aries if you want ready-to-use components that provide enterprise OSGi capability or if you want to join the development community to drive the technology forward.

Apache Aries Overview

View more presentations from irobins.

WebSphere: up to its EARs in OSGi

WebSphere Appplication Server has been up to its neck in OSGi for ages, running as a collection of OSGi bundles on an Equinox framework since WAS 6.1 was released in 2006; now, with the WAS V7 OSGi Application Alpha, its up to its EARs as well enabling enterprise web applications to be optionally developed, assembled, deployed and managed as a collection of versioned OSGi bundles. The Alpha is an early program to showcase and get feedback on WAS enablement of OSGi exploitation by applications. 

OSGi Application support in WAS is complementary to the Java EE programming model and aims to enable the use of familiar Java EE technologies - for building web UI components, accessing resources, using container managed transactions and security - as well as familar WebSphere adminstrative tasks for application deployment and management. OSGi Applications are assembed from a collection of modules and optional metadata into an archive and deployed to WAS in a similar manner to Java EE applications. There are several differences to standard Java EE assembly and deployment though. First of all, while the ".eba" archive (enterprise bundle archive) may contain all the application's modules and dependencies within it, as a Java EE EAR typically does, it may also refer (through application-metadata) to some or all of the application content as explicit dependencies and omit those from the archive. Of course, these have to be provisioned from somewhere, which is where the WAS configured OSGi bundle repository comes in. Application modules and common libraries that need to be shared between applications can be installed (through WAS admin) into one of the configured OSGi bundle repositories and these repositories are used by WAS admin during application deployment to ensure that all an application's dependencies are resolved. For example, one of the Alpha samples uses a JSON library that can be installed into the integrated WAS bundle repository and shared between the sample application and other applications - the WAS Admin view on the bundle repository is shown below:

WAS can be configured to use existing repositories instead of or as well as the integrated internal repository. At the application level, it is not necessary in the application metadata to describe a transitively closed set of dependencies - WAS works this out during deployment and produces deployment metadata that describes precisely which modules the application consists of. If deployment metadata already exists then it can be used during application deployment  - this is useful if an application has been tested in a QA deployment and is ready to be rolled out to a production system - you now want the application you tested to be deployed rather than a newly resolved version of it.

If you have many applications using common libraries then having a single copy of those modules shared between applications is better then deploying a copy of the common library in each EAR. Having the dependencies resolved at deployment time ensures that applications cannot be started unless all their dependencies are present, eliminating hard-to-debug ClassNotFoundExceptions that can occur in more loosely-managed shared-library installations. Since OSGi modules are versioned, different applications can easily move to new versions of a common library at their own pace, independent of other applications. And horrible second-order dependency clashes are avoided by module-versioning so that if an application has two libraries, A and B, which need both a third library C - but at different versions - then the application will deploy successfully with both versions of C.

Once the application is installed, it is ready to be started just like any other WebSphere applications. Starting the application is what causes the bundles to be "installed" in the application-level OSGi framework (and started). This is "install" in the OSGi lifecycle sense - the applications have already been installed in the WebSphere sense to the target WAS servers.

An installed OSGi application can be managed at the bundle level - if later versions of bundles are added to the configured OSGi bundle repository after the application has been installed these will not affect the applicaiton but will be available in the WAS Admin console if the application is to be updated to such later levels.

By way of illustration, the WAS Alpha sample mentioned above delivers 3 bundles, one of which is a web application which has a dependency on a common JSON library. From a management perspective, the application consistents of the set of four libraries, one of which is denoted as being shared. If a later version of the JSON library were to be be deployed to the configured bundle repository then it would show up in the drop-down list of available versions in the view shown below. Selecting that version would cause a re-resolve of the application which, if successful, would offer the administrator the opportunity to save the configuration and update the application.

I've mentioned web applications a few times. The migration step to convert an existing Java EE enterprise web application, consisting of one of more web archives (WARs), into an OSGi application involves renaming the archive from .ear to .eba prior to deploying to WAS. For most web apps its as simple as that. WAS introspects any WARs within a .eba archive and generates the OSGi metadata required to convert this to a web application bundle.

One final note - one of the innovative technologies included in the WAS V7 OSGi Application Alpha is an integrated OSGi Blueprint container. This is a dependency injection container whose heritage is derived from the Spring framework; it enables business logic to be built from simple POJO components whose lifecycle and dependencies - including references to other components and to resources such as JDBC and JMS providers -  are described in an XML "blueprint" and managed by the Blueprint container.This and other features of the WebSphere OSGi Application support are being developed as open source components of the Apache Aries project and integrated into WAS.

Thats all for now - do take a look at the Alpha and let us know what you think.

OSGi 4.2 Published

My previous post mentioned early drafts of the OSGi 4.2 specifications which define part of the enterprise OSGi programming model that the new Apache Aries project is implementing. Since then the OSGi Service Platform V4.2 have been finalized and published by the OSGi Alliance. The platform is defined in two specifications - the "core" and "compendium" specifications. The latter includes the new Blueprint container specification mentioned in the previous post, an important part of the enterprise OSGi programming model we're implementing in Aries.

OSGi in the Enterprise – the Apache Aries incubator

There have been an increasing numbers of discussions recently - these two on TheServerSide are pretty representative - over the role of OSGi technology in enterprise Java applications. On the one hand it can be an asset in enabling a more modular approach to building enterprise applications: not only is a significant amount of enterprise Java middleware built on OSGi for this reason but so are some significant applications such as LinkedIn and the Jazz Team Server. On the other hand is the question of just how OSGi features in the programming model for enterprise applications. What is the web component model? The persistence model? How does the vast landscape of existing Java EE components begin to take some advantage from OSGi?

These are the questions the OSGi Alliance Enterprise Expert Group (EEG) are addressing through a set of specifications related to how existing, familiar Java EE technologies are exploited in an OSGi environment. For example, the EEG's Web Application specification (RFC 66) describes how an OSGi web container manages the lifecycle of application components written to the Servlet and JSP specifications and how existing WAR files are transformed to a web application bundle whose web components are then managed by that container. Other EEG specifications follow a similar pattern, describing how JPA, JTA, JNDI and other technologies in common use in Java EE applications should be catered for in an OSGi environment. And the Spring framework is relevant here too as the inspiration for the OSGi Blueprint container specification. This defines a standard dependency injection container including the application configuration XML (the application "blueprint") used by the container to manage, wire and configure simple Java components and optionally publish/consume these as services in the OSGi service registry. A public draft roll-up of these specifications was published earlier this year by the OSGi Alliance, ahead of finalization.

The broad adoption of OSGi as part of the enterprise Java application programming model depends not only on the EEG specifications - to encourage consistency of behaviour across enterprise OSGi platforms, to ensure application portability and avoid vendor lock-in - but also on their widespread implementation. This is the primary motivation of the Aries incubator, which aims to deliver implementation of the EEG specifications that are part of the enterprise OSGi programming model. Aries sets out to provide enterprise OSGi componentry that can be integrated into application or integration server runtimes - such as Geronimo and ServiceMix - without being tied to any one of these. Some of the work - for example the Blueprint container implementation - actually started inside Geronimo but, as it evolved, it seemed better to move it into a new incubator to help develop a community with a focus on enterprise OSGi that was independent of any specific target runtime.

Want to help develop Aries? Have a look at the proposal and discussion and get involved.