When Chief Technology Officer Jeremy Boynes joined Gluecode Software, he brought first-hand knowledge of the possibilities that come with combining open source software and enterprise application development. He was Chief Architect for Bravanta and Netmosphere, where the use of open source software helped him reduce those companies' expenses, and his 20 years of enterprise computing experience also includes posts with Cisco, BT, Centrum Systems, and Sequent Computer Systems. He has a degree in electronic engineering and has participated in a number of large open source projects as contributor and committer, including OpenEJB, ObjectWeb, the Derby Java database, and, of course, the Apache Foundation's Geronimo J2EE server project.

IBM has announced that it is acquiring Gluecode Software, which is in line with its goals of fostering and participating in the open source community as well as encouraging the adoption of open standards. As with Eclipse, Derby, and the Apache HTTP server (httpd), IBM is bringing in Gluecode Software's Geronimo-based platform to provide an open source complement to its existing middleware lineup.

Our developerWorks staff asked Jeremy, as one of Geronimo's architects, to introduce us to Geronimo's design goals, its architecture, and how it stands apart, and perhaps give us a little insight as to how an open source project of this scale comes together.

developerWorks: Can you describe the Geronimo architecture? What are some of its main components?

Jeremy Boynes: When Geronimo started, the primary goal of the project was to produce an implementation of J2EE 1.4 by integrating many of the existing open source projects that supported portions of the specification. The architecture that emerged from that focused on two main areas: to provide a framework that facilitates that integration with zero impact on the other projects, and a set of system service modules that when assembled together would comprise the finished server.

The heart of the architecture is the Geronimo kernel and GBean framework. This provides the infrastructure that controls how other services are configured, activated, managed, and how dependencies between them are resolved. This core has been kept small, allowing Geronimo to scale down to the smallest devices.

There are actually two variations of this core. One is lightweight, designed for command-line tools or unmanaged servers; the other, designed for traditional servers, uses JMX so that all components can be managed and monitored.

Into this core we install a range of modules that provide the system services such as transactions, security, logging, naming, remoting -- the infrastructure that applications expect to have available.

Using this flexibility, we can assemble these services to form specific application environments. For example, the primary goal of the project has been to produce a J2EE 1.4 environment, and we achieve that by assembling the appropriate services together. The assembly model, though, can also be used for alternate configurations; we are actively working with the Spring community to produce an assembly that directly supports the Spring Framework.

This flexibility is extremely powerful but presents its own challenges in the form of configuration control and administration. To address those, we built a strong configuration management system into the kernel that allows modules to be combined together, signed and sealed, ready for installation into any Geronimo kernel. Which configurations a particular server is running can be controlled either by the server itself or, in an enterprise environment, by an external management service.

We actually extended this configuration management capability to end-user applications as well. This allows an organization to create a fully deployed application in an integration or test environment and then move that exact binary through the release process into production or for distribution to customers.

A fringe benefit is that we can actually reduce the overhead in a production server by performing all the deployment processing offline. It also allows us to perform extensive optimizations during deployment, potentially scanning byte code and optimizing code paths, without impacting online systems.

developerWorks: I understand that one of the project's key requirements is to be fully compliant with J2EE standards. Why does that matter?

JB: The basic truth is, it is important to our users. J2EE goes a very long way to defining a framework for applications that can be implemented independently by different organizations but behaves consistently across all of them (as verified by the Compatibility Test Suites). This provides enterprise users with the assurance that they can, if they choose, write applications in a way that does not lock them in to a single vendor's solution; or it means an application vendor can write an application once and have the assurance that it will run in any customer's environment.

Of course, in the real world the specification is incomplete and, even today, there are areas where knowledge of which implementation is being used is important. The key thing, though, is that users get to choose how locked in they are to a particular solution. Of course, with open source that lock is a lot less restrictive.

But certification is just one step along the way. To be successful, Geronimo needs to provide clear benefits to users over and above the base specifications. Our priorities in the project have been to focus on technology areas that have the largest impact for production deployment in enterprise environments. These are primarily features associated with management, configuration, reliability, scalability, and performance.

developerWorks: Which parts of the J2EE spec have made your life particularly difficult, and which parts have been easier to handle?

JB: For a while there was a running joke in the project about "88-itis" -- it seemed that everyone who worked on implementing the JSR-88 deployment specification started talking in tongues and rapidly became very cranky.

On a more serious note, some parts of the specification were fairly simple to handle because there were high-quality open source solutions out there we could integrate with. For example, for the Web container we integrate with either the Jetty server or Apache Tomcat, both of which have well-established pedigrees. Similarly, our JAXP [Java API for XML Processing] implementation uses Apache Xerces, our JMX [Java Management Extensions] implementation uses MX4J [an open source implementation of JMX], we provide an embedded database based on Apache Derby (formerly Cloudscape), and so forth.

The areas that have posed the greatest challenges are the same ones that have troubled all J2EE implementations: interoperability with other servers using Web services and IIOP.

developerWorks: There are a lot of quite competent commercial J2EE servers out there. Why is it important that Geronimo is open source?

JB: There are other open source J2EE servers out there as well, such as JOnAS from ObjectWeb. However, a project like Geronimo can only really succeed by being open source; moreover, to garner the support of commercial entities as well as individual developers, it has to be under a BSD-style license like the Apache License that allows solutions that are hybrids of open source and proprietary technology.

For example, the Geronimo J2EE server released by the Apache Software Foundation will be based on an assembly of other open source projects such as Apache Tomcat, Jetty, OpenEJB, and ActiveMQ.

Other assemblies may be provided by the project or by other organizations. For example, a system vendor could replace the transaction manager with one that uses proprietary software that hooks directly into OS-level journaling, or an enterprise user could replace the security policy provider with one that integrates with their compliance and audit infrastructure.

developerWorks: Have you found that the componentized nature of Geronimo lends itself to the open source development model?

JB: I would say that a modular approach like Geronimo has taken would be essential for any software project of this size, open source or internal to a single organization.

The key benefit for us, though, is that the development is driven by an open community where both individuals and companies can participate in and benefit from the work done by the project. Being based at the Apache Software Foundation with its emphasis on an open, meritocratic, and collaborative community ensures the long-term viability of the project and prevents it from being dominated by the agenda of a single individual or by the commercial motives of a single organization.

developerWorks: As a full J2EE server, Geronimo will no doubt feel right at home serving up large, distributed, transactional enterprise applications. But on the small end, where (if anywhere) does it stop making sense to use Geronimo?

JB: The componentized architecture allows Geronimo to scale from small footprint devices all the way up to large enterprise applications. We have paid particular attention to keeping the footprint of the kernel small so that it can be used on constrained devices such as set-top boxes. The user can then choose which services to configure into that framework as needed by the applications that are going to be run.

For example, a simple server appliance intended for use in a branch office could be configured with a Web container, security proxy, and perhaps a messaging client and then be used to run applications locally. The remote management and configuration capabilities would facilitate the administration of hundreds or thousands of these devices from a central location.

As Geronimo is really intended for server applications, it is probably not appropriate at this time to consider for deployment to handheld or cellular devices. However, as the capabilities of those devices increase, that may be an area to explore in the future.

developerWorks: Can you talk about some of the ways scalability is built into Geronimo?

JB: I'm glad you mentioned scalability rather than raw performance (although we have been fairly aggressive in that area too). In a era of commodity server hardware and zero license-cost software, it can often be more effective to scale an application across many machines rather than on ever-larger servers.

The ability to pre-configure applications and tailor the server configuration as needed allows a user to devote the resources of the server to application work rather than app-server overhead.

The traditional limiting factors for scalability are access to CPU, memory, and I/O. To manage CPU resources, we provide a set of thread pools that can be tuned to balance the resources available to inbound Web, EJB, and connector requests or for requests generated by the server itself, such as transaction rollback. In the future, we plan to combine the thread pools from different services together into a single work-management infrastructure that can be used to balance between these different workloads. We also introduced the core concept of a central transaction context that allows components to access per-transaction information without synchronizing on shared pools or caches.

To address memory scalability, we have been careful to control the amount allocated by the container as work is performed; unfortunately, we do not control the resources required by the application itself. This is an area that will still need to be tuned as we gain experience with real-world applications.

We have used the capabilities of NIO [Java new I/O], where practical, to improve I/O scalability. One area where we paid particular attention was in our transaction log, and here cooperation with ObjectWeb has resulted in the HOWL project, a very high-performance journaling subsystem.

In the end, it is still early days. The real information will come as Geronimo is stress tested in real-world situations. Problems in this area will certainly get the attention of the developers.

developerWorks: What have been the project's greatest challenges and greatest successes?

The biggest challenge has been the complexity of the project itself, the sheer size of platform that needed to be implemented. Doing this in an eco-system of cooperating-but-independent open source projects has also added to the excitement. This is also I think the greatest success -- that so many people have come together to make this happen.

developerWorks: How much of Geronimo was already built when the project began, and how much still needs to be written?

JB: None of the Geronimo kernel was actually built when the project began. However, many of the projects that could be integrated -- such as OpenEJB, MX4J, Jetty -- were already around and had been for quite a while. In most of them, some work needed to be done to bring them up to the J2EE 1.4 specification, which itself had yet to be finalized back when we started in August of 2003.

We are close to feature complete, but even when we are fully certified, there will be a ongoing effort in performance tuning, usability, internationalization, documentation, new features, and so forth.

Seriously, going forward there are areas we know need improvement and new ideas we wish to incorporate. There is a lot to be done and the community is open to everyone; come join in.

developerWorks: Do you have any pet projects outside of your day job?

JB: Apache Derby. I was very excited to see that come to open source. Actually, in one of my previous experiences we were using Cloudscape. To see a project like that come to Apache and be available was exciting to me and enabled me to bring out my database alter-ego.

developerWorks: Do you think open source has at last found a home in the enterprise?

JB: There is a greater acceptance of open source solutions in the enterprise than ever before, particularly in the last 12 to 18 months. The broad adoption of Linux for one the fundamentals of enterprise infrastructure, the operating system, has shown that organizations are becoming comfortable with the production readiness of open source technologies. We are now seeing that move up the stack with organizations starting to evaluate open source for databases and application infrastructure. These are mature markets with clearly defined specifications that are ripe for commoditization, and over the next three to five years I would expect open source solutions to become significant players in these spaces.

developerWorks: If there was some part of open source that needed fixing, what would that be?

JB: There are a lot of things to fix. The great thing is that with every open source community, there's something different that needs fixing. There really is no one open source movement; there's a whole variety of different communities and different forms of development going on, working on everything from the Linux operating system, projects at Apache such as httpd and Geronimo, to consortiums like Eclipse and ObjectWeb, or people's favorite desktop application in some SourceForge project. There's a huge variety there and they all have different issues, so I don't think there's one fix across the board.

Some of the challenges in open source remain communication, collaboration, trying to work together, understanding that all the commercial companies can play but still respecting the contributions that individuals can make... So the biggest challenges are cultural. Every single project addresses those in a different way.

developerWorks: What's the next big thing for Java?

JB: Geronimo [laughs]. The Java language is in an interesting phase where it has become seriously adopted for use in enterprise applications. We're entering a phase where people are comfortable using managed runtime environments and virtualization at the application-infrastructure level. So, I think we're going to see an exciting period of growth there.

We've seen the growth of independent movements, with things like Spring Framework giving users what they want. I think that diversity is good. There's also a huge role for standardization so that enterprises can actually have a reliance on how this technology evolves for the future. We're in an interesting time. There's a lot of innovation going on, there's a lot of new ideas coming on, a lot of new things being tried out, such as AOP [aspect-oriented programming] and some of the other lighter-weight frameworks. I think the excitement is there.

developerWorks: Do you have any other thoughts you'd like to share with developerWorks readers?

JB: The single most important thing from a technical perspective that I hope we've conveyed is not to think of Geronimo as just another J2EE server but as the start of a system framework that can be used to build a whole variety of tailored infrastructure services. The ways in which this framework can be used are limited only by our imaginations. Come join in and help build the future.

I'd also like to thank all the people, too numerous to mention, who have contributed directly or indirectly to Geronimo or to any of the projects involved.

Resources

Learn

• Learn how to use the new Eclipse WTP plug-in to develop and deploy Web applications to the Apache Geromimo server in "Create, deploy, and debug Apache Geronimo applications" (developerWorks, May 2005).
  
  
• Read the IBM press release about its acquisition of Gluecode Software.
  
  
• The Apache Software Foundation is the home for Geronimo, Derby, and a host of other open source projects.
  
  
• Learn more about Gluecode and Gluecode SE at the Gluecode Software home page.
  
  
• Visit the developerWorks developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
  
  

Get products and technologies

• Innovate your next open source development project with IBM trial software, available for download or on DVD.
  
  

Discuss

• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Resources
• About the author
• Comments

Next steps from IBM

Rational Application Developer features provide the comprehensive Integrated Development Environment (IDE) used to develop J2EE applications requiring Servlets and JavaServer Pages (JSPs).

---

• Try: Try the free Rational Application Developer, which helps developers quickly design, develop, test, analyze, and deploy high-quality Java, Javaserver pages, and J2EE applications.
• Article: Learn how you can deliver accurate, higher-quality J2EE apps with Rational Application Developer, open source JUnit and JUnitEE test frameworks.
• Tutorial: Build a Facebook application using PHP, the Spring framework, and J2EE.
• Demo: This demo shows how to use the new Java EE 5 Java Persistence API (JPA) framework.
• Buy: Rational Application Developer

Dig deeper into Open source on developerWorks

Discover knowledge paths

Skill-building guides for open source, Linux, cloud, Java, business analytics, and more.

Special offers