JAX London 2014: A retrospective
Interview with Holly Cummins

Apache Aries is all about Enterprise OSGi.

Jessica Thornsby
Apache-Aries-is-all-about-Enterprise-OSGi
  • Holly Cummins

    Holly is a software engineer at IBM’s Hursley labs. She is a popular speaker and has spoken at a variety of industry events including Devoxx, JavaZone, The ServerSide Java Symposium, The Great Indian Developer Summit, and WebSphere User Groups. She has also authored several developerWorks articles. She contributes to the Apache Aries project and to WebSphere feature packs. Holly has been with IBM for nine years. Before joining IBM, she completed a doctorate in quantum computation at the University of Oxford.

In September 2010, IBM software engineer Holly Cummins will deliver two sessions at JAX London Autumn Edition 2010. JAXenter.com caught up with her to find out more about the focus of her JAX London sessions: Apache Aries and fixing application performance issues.

JAXenter: You are a contributor to the Apache Aries project. What exactly is Apache Aries?

Holly Cummins: Apache Aries is all about enterprise OSGi – it provides implementations of many of the components of the Enterprise OSGi specification published earlier this year. For example, it provides a Blueprint container implementation which provides dependency injection and a declarative mechanism for interacting with OSGi services. Blueprint is a standardization of the conventions established in Spring dynamic modules, and it’s getting a lot of support as a standard. Another major component is the assembly model which enables collections of bundles to be assembled as a coherent enterprise application. What enterprise OSGi, and Aries in particular, enables is for applications to take advantage of the Java EE programming model along with the modularity benefits of OSGi and then more on top. So, you can have a really modular loosely-coupled OSGi application, but it’s also taking advantage of JEE features like JPA and JTA because they’re exposed as OSGi services. Then we can go one better than that and provide container-management of JPA and JTA using blueprint dependency injection. Everything’s hooked into JMX and JNDI as well. All of this is described in the Enterprise OSGi specification, and what Aries is providing is an implementation of the specification.

JAXenter: In the project proposal it states that the Apache Aries project aims to deliver open source implementations of the application-focused specifications defined by the OSGi Alliance Enterprise Expert Group. However, the project also aims to expand on these specifications. Can you tell us how the project plans to expand on the OSGi specifications?

Holly Cummins: There are some capabilities we included in our first release of Aries that go beyond the specifications – our intention here is to get implementation and usage experience to see what works properly and then to contribute these ideas and experience back to the EEG. For example, the Aries Blueprint container has namespace handlers for processing container-managed transactions and container-managed persistence contexts. We’ve also got a prototype for using annotations to drive the dependency injection, but that’s still being refined. The assembly of collections of bundles into a coherent application is an important feature of Aries and relates to ongoing EEG work around provisioning “subsystems” of bundles. Then there are some other areas where we haven’t started work yet but would like to go, like message driven blueprint endpoints and asynchronous services.

Of course, open standards and standardization are a really valuable thing, so we’re hoping that at least some of these innovations will be included in some form in the next version of the specification.

JAXenter: Apache Aries is independent of both the OSGi framework and the enterprise runtime environment in which application components are hosted, how does this independence benefit the project?

Holly Cummins: The Blueprint container work started off in a Geronimo sandbox but wasn’t tied to Geronimo as a component. We could see how we might get interest and contributions from other communities as well if we started a new project with an enterprise OSGi focus and contributed the Blueprint code to that project – and we have. Geronimo now consumes Blueprint from Aries but so do other projects too like ServiceMix and commercial products like WebSphere. Independence of OSGi framework is importat too. Consumers of Aires may run on top of any OSGi framework and we don’t want to narrow the appeal. ServiceMix runs on Felix, WebSphere runs on Equinox and Geronimo runs on both, while all use Aries. What this really underlines is the broader benefits of open standards and modular implementation in terms of portability and flexibility.

JAXenter: You are delivering a session on Apache Aries at JAX London Autumn Edition 2010. What can session attendees expect?

Holly Cummins: The session is going to be a practical introduction to Aries. I’m hoping attendees will gain an understanding of what’s in Aries and how it might work for them to solve some of the challenges they’re facing in terms of building enterprise applications. I’ll also demonstrate writing an Enterpise OSGi application from scratch; we start from nothing and end up with a working web application with a database back end.

JAXenter: You are also delivering a session on the tools and techniques that can improve application performance. Can you share any of these with us?

Holly Cummins: One of the most important things when improving application performance is to be systematic. I think there’s sometimes a tendency to just start changing things around in an application when we hit a performance problem. This isn’t a very effective strategy, and it can actually make things worse. Fixing a performance problem should really be a cycle of pretty simple steps – find the bottleneck, fix it, find the next bottleneck, fix it, and repeat. There are a few tools everyone should have in their toolkit to help them zoom in on bottlenecks. The first is a garbage collection analysis tool, for memory-related bottlenecks. The second is a good method profiler, for CPU bottlenecks. If you can use one that profiles the whole codebase without destroying performance, like IBM’s Health Center, that’s best. Profiling everything means you don’t have to guess what the problem codepaths are in advance, because of course if you guess, you might get it wrong. It’s also wise to investigate what’s going on in terms of disk I/O and network I/O, because those can really throttle an application. Finally, synchronization can become a major drag in multi-core systems, so have a look at how hot your locks are.

Author
Comments
comments powered by Disqus