I recently interviewed Tim Ward of the IBM WebSphere software development team working from the Hursley lab in the United Kingdom. He is the design and development lead for the OSGi Feature Pack for WebSphere Application Server and has been actively working with OSGi for nearly five years. Tim is also an active committer in the Apache Aries project, which provides an OSGi application container. Based on my preparation work in November for the OSGi lab I co-hosted at Research Triangle Park's WebSphere User Group, I became familiar with Tim's fantastic talks at the 2010 Devoxx conference and Jax London's OSGi Community Event.
Tim, what is OSGi in two sentences?
Putting it most simply OSGi is a dynamic modularity framework for Java. Importantly OSGi also provides a set of tools and services that help developers and architects to build dynamic, modular composable systems on top of that framework.
Why do you believe OSGi helps to simplify Java application development?
Java has one of the largest, most diverse ecosystems for applications and libraries in both open and closed source - it is clear that Java is an extremely successful language for developing all kinds of applications. In some senses this success actually makes Java less usable and is the very reason that OSGi is needed. I have spent the last five years working on various parts of IBM's WebSphere Application Server, so I have a good feel for what a "large" Java application looks like. There are a huge number of connections between software components, open source libraries and systems. With Java's flat classpath any piece of code can depend on any other piece, even when that code is supposed to be private! This gets even worse when two pieces of code depend on different versions of the same class. Only one version of the class can be loaded by the classloader and that means that one of those two pieces of code will break at runtime!
One fix for this is to make extensive use of the private, protected and default visibilities for Java classes, but this forces your code into unpleasant shapes making it hard to reuse and follow. In OSGi this isn't necessary. Code within a bundle - a jar file with some extra metadata in its manifest - is by default private to that bundle. Any class within the bundle can use any other class in the same bundle (subject to normal Java access rules) but it cannot use a class from elsewhere unless the bundle explicitly marks it as imported. As well as marking imports from outside OSGi bundles are responsible for describing the Java packages that they expose to the outside world. These exports define the API of your OSGi bundle.
In addition to describing which packages are imported and exported the OSGi metadata also defines the version of exported packages and the range of versions that are acceptable for an import. By placing strict requirements on the versioning of bundles and packages OSGi is able to support multiple versions of the same class simultaneously - only allowing importers to see an export that matches their versioning requirement.
By using OSGi's modularity you can understand, constrain and dramatically simplify the dependencies between your modules. You can also concurrently support modules that need different versions of the same library without error at runtime. Best of all; when consuming a module produced by someone else, or when writing your own module; you can easily find other bundles to satisfy its requirements. This is so simple because both the requirements and the capabilities of bundles are explicitly defined by their metadata. In my view this makes OSGi an essential tool for writing today's Java applications.
Open source software is a key part of the solution. How did the Apache Aries project start and what are the main goals?
Obviously open source is an extremely powerful force in software development. Open source tools and libraries allow the entire Java community to share advances in technology and productivity without prohibitive cost and continual maintenance. When the OSGi Alliance began work on the OSGi 4.2 enterprise specifications release it was clear that open source implementations, and preferably more than one for each specification, would be a key driver for their evolution and adoption.
The Apache Aries incubator project was set up in September 2009 as a place where developers could design and build the core components of an Enterprise OSGi programming model – complemented by implementations from the Enterprise OSGi specifications. As a result Aries has its own implementations of several programming model focussed OSGi Enterprise specifications, as well as being a proving ground for new Enterprise OSGi technologies that can be fed back into future versions of the specification.
Apache Aries has been particularly successful in the last 15 months, has produced three releases, and is now used in a number of places including Apache projects like Geronimo and Karaf and commercial offerings like the IBM WebSphere Application Server OSGi Applications Feature Pack, WebSphere Application Server Community Edition and JBossOSGi. As a result of this success Aries recently graduated from incubation to establish itself as a new Top Level Project.
Why does IBM care about OSGi and why should java developers care about OSGi?
IBM cares about OSGi for several reasons. One of the most long-standing is that OSGi has been the basis for building a number of IBM products for many years. In fact WebSphere Application Server was the first Application Server to use OSGi technology. The modularity and dynamism of the OSGi framework is the ideal platform for developing software with the size and of complexity of an Application Server, which is why every Application Server vendor now uses OSGi to build their product.
Having reaped the rewards of OSGi, IBM realised that many of its customers were suffering with the same issues that had plagued the Application Server before it moved to OSGi. This formed the basis of IBM's work with the OSGi Alliance Enterprise Expert Group who built the first OSGi Enterprise specification. Using the new Enterprise OSGi standards IBM has built an Enterprise OSGi programming model into WebSphere Application Server (WAS). This is available as a Feature Pack for WAS Version 7, and is built into the latest beta releases of WAS Version 8.
The existence of the Enterprise OSGi specifications and IBM's commitment to OSGi represent why Java developers should be looking at what OSGi can do for them. OSGi has been used by all of the large middleware vendors for years to provide better modularity, lighter runtimes and dynamism. Java developers want these things for their applications too which is why OSGi is more important now than ever before.
How does Aries work together with other Java EE 6 components?
The Enterprise OSGi specifications define how a number of Java EE technologies can be integrated within an OSGi environment. Aries includes implementations of the JTA and JNDI services, allowing for familiar interfaces such as UserTransaction to be used transparently with OSGi. Aries also extends existing OSGi specifications such as the Blueprint Container and the JPA service to provide Enterprise qualities of service such as declarative transactions and container-managed JPA. When combined with OSGi Web Applications, which provide a slight variant of WAR packaging suitable for use in OSGi, a Java EE 6 developer should find that programming using Aries services is a natural extension to what is already available in Java EE.
How does developing with OSGi with Aries compare to OpenEJB or Eclipse Equinox?
Developing for OpenEJB is familiar to many developers who have used the EJB programming model before, which is one of the reasons for its popularity. The Enterprise OSGi programming model in Aries is built primarily around the Blueprint Container - a service that will also be familiar to the majority of Java EE developers even though most of them will never have used it before. The Blueprint Container specification was standardised by the OSGi Alliance primarily through the input of SpringSource (now VMware) who used it as an opportunity to standardise the OSGi-enabled version of the Spring framework. Now the Spring framework is used widely throughout Java EE applications, so many developers are familiar with its XML syntax. The Blueprint Container uses extremely similar syntax that will be familiar to anyone who has ever played with Spring.
Now Eclipse Equinox is an interesting case, in that really an Enterprise OSGi application using Aries is running on an OSGi framework. This means that in one sense Aries Applications are Equinox applications! The Aries project is very careful to avoid depending on any single implementation of the OSGi framework, meaning that applications can (and do) run just as well on Apache Felix or elsewhere. The primary difference between development for core Equinox and Aries is that Equinox provides the bare bones of a framework, whereas Aries provides the rich programming model. Another funny thing about Equinox is that it is the basis for the Eclipse IDE; Eclipse is then the basis for our free Enterprise OSGi tooling. This means that many developers are using Equinox to develop for Aries!
What is an example of IBM's contribution to OSGi?
Well IBM has been a big player in the OSGi Alliance for many years, working with the OSGi community to build better standards within OSGi. In addition IBM contributes significantly to the Eclipse Equinox project, which is the OSGi framework reference implementation. IBM is not only active with the core framework, but is one of several companies with Apache Aries committers. IBM also provided seed implementations of the Aries JNDI and JPA code to the Aries project, representing a real and continuing commitment to both OSGi and Open Source.
Where can we find more information on the web?
Information about Apache Aries is available from our website at http://incubator.apache.org/aries/
Where can people meet you (and the team) at upcoming events?
The Aries and IBM teams are pretty active and are often presenting at conferences. About a month ago I was at Devoxx, a couple of us were at the Autumn Jax London Conference and several have been at the last few OSGi Community Events and London Java User Groups; we also had a couple of Aries committers at ApacheCon this year. In the near future you can expect to see us back at the London OSGi Community Event, Jax London, EclipseCon, OSGi DevCon and a number of other venues! Last but not least there will be several OSGi talks at the IBM Impact conference in April.
What is your favorite development language and why?
My introduction to programming languages has been quite an interesting journey. At school I had some lessons in VBA, which taught me some of the basics of flow control, but also that it was very easy to write something that was incomprehensible the next day. At University I was a Physicist rather than a Computer Scientist, so pretty much all of my programming there was in FORTRAN. I briefly escaped FORTRAN by using C for my final year project, but I didn't play with an OO language until I started at IBM and began using Java. Java was something of a revelation, and I could see immediately why it was so popular - this isn't to say that I think Java is perfect, there are occasions where people in the office have heard my exasperation with the Java API, or an unpleasant limitation of the syntax. I do, however, strongly believe that there are few languages as generally useful as Java is. Java treads the fine line between ease of use, flexibility and performance in a way that no other language really does. Obviously there are times when another language will strike you with its beautiful solution to a particular problem but, despite its flaws, Java keeps me (and a huge number of others) coming back over and over again.
Let's switch gears and talk about what's coming next for Apache Aries?
As I mentioned earlier Apache Aries recently graduated as a new Top Level Apache Project. This represents a real step up for Aries and is a mark of its growth and adoption. We have another incubator release scheduled for early 2011, and are starting to put together a plan for our 1.0 release. Obviously I can't cover specifics for a plan that isn't final yet, but I would expect to see Aries prototypes using a number of the new services from the OSGi 4.3 draft specification over the next 3-6 months!
What are the current hot topics in the Java development community? And where is Java headed in 2011?
The Java Community has just been through something of an upheaval with the acquisition of Sun by Oracle. The future of the JCP and the Apache Source Foundation's decision to resign is obviously on a lot of people's minds. There is also a lot of talk about Java 7, and what will be in it. The one other topic that really seems to be growing within the Java community is OSGi and its place within Java. A number of large middleware vendors, including IBM, Oracle, Progress, TibCo and Paremus are all talking about how users can take advantage of OSGi with their products. Throughout 2010 there was an increasing level of interest in and discussion about OSGi. I only see that growing in the coming year.
And for a quick diversion - would you please tell us about your favorite hobby, tech related or not?
Whilst I love the range and depth of my technical responsibilities with Aries and IBM, I find it really important to relax doing something very different. One of my favourite hobbies is singing. I am a baritone, and a member of Southampton Choral Society. We put on about four concerts a year, the most recent of which was a performance of Handel's Messiah a couple of days ago. Despite heavy snow we still packed out our venue with nearly 400 people and had a great time. There's nothing quite like singing with a full Orchestra!
Thanks to Tim Ward for spending the time to discuss OSGi and Java development. I am excited to be able to share his insights about Java development. OSGi was definitely one of the most talked about Java development technologies in 2010.
Tim Ward is a design and development lead for IBM's OSGi Application Feature Pack for WebSphere Application Server, and has been actively working with OSGi for nearly five years. Tim is a regular participant in the OSGi Core Platform and Enterprise Expert Groups where he has lead specification development for a number technologies. As an EEG member he co-authored the JPA service specification, while in CPEG he has driven the design for bytecode weaving and classpath scanning support from the core framework. Tim is also an active committer in the Apache Aries project, which provides an OSGi application container based on implementations of the application-focused specifications defined by the EEG. Tim is also an experienced speaker, and has previously presented talks about OSGi, the Java Persistence API, Apache Aries, and WebSphere Application Server at EclipseCon, Jazoon, Devoxx, and Jax London.
Note: Originally published on the IBM Impact event blog for "App Infrastructure Tuesday."
