There was no open-source effort ... devoted to [the EJB] spec, so I quit Sun ... and started EJBoss. — Marc Fleury The EJB and J2EE are sold at outrageous prices [so] only corporate IT can afford to play with it. But we believe it is mainstream technology. — Marc Fleury Our biggest success is in attracting a good crowd of talented developers. — Marc Fleury We are the only group in the J2EE space with the GPL license, [which is] the only "major" license that requires the server and all it's derivative to be open. — Marc Fleury The sky's the limit with EJBoss.... Java itself is such a moving and lively field, our principal interest is in being on top of it! — Marc Fleury We are here to have fun and learn so we use the latest and greatest technology, with disregard for focus groups. — Marc Fleury Any enhancement that is made to the server should be brought back to the community. It's that simple. — Rickard Öberg I realized almost at once how forward thinking Rickard's ideas were, such as adding the "one" RMI (remote method invocation) object trick. — Marc Fleury I named the container "NextGen," believing it was really a revolutionary design for the industry. — Marc Fleury Most EJB servers that are available today are implementing the EJB specification literally.... This may lead to scalability problems. — Rickard Öberg

EJBoss: An Open Source EJB Server A Conversation with Marc Fleury and Rickard Öberg by Lori Houston Following Sun Microsystems release of the Enterprise Java Beans, or EJB, specification; a host of new applications for EJB began cropping up as part of Java's evolution into distributed enterprise computing. One of those was EJBoss, an EJB server started by a former Sun developer and intended to spur EJB infrastructure development in the open-source arena. First released under the GNU General Public License in March 1999, EJBoss has attracted some three hundred developers. The project has become a leading open-source effort for an EJB container with Java 2 Enterprise Edition platform extensions. Marc Fleury, EJBoss's creator, and Rickard Öberg, the project's lead developer, will present a session on EJBoss architecture at the O'Reilly Conference on Java, March 27-30. O'Reilly Web reporter Lori Houston asked Fleury and Öberg to lay some of the groundwork for their presentation. Houston: What is the background of each of your roles with EJBoss? Fleury: I was first exposed to the EJB spec at Sun, and I wanted to learn it in detail. There was no open-source effort at the time devoted to this spec, so I quit Sun to avoid legal issues and started EJBoss. In September 1999, a business partner and I founded a company, Telkel, to provide services around this platform. EJBoss is part of the Web operating system along with other APIs from JavaSoft (or other Java divisions). It is part of the underlying infrastructure that needs to happen for Web applications to work on GPL. Öberg: I have been working with EJB since the beginning. I wrote an EJB server for a proprietary project when I was working as a consultant a couple of years ago, back when all commercial EJB servers were still in beta. This got me started in the applications server business. Since then I have done another app-server on my own, called XS, which laid the foundation for the ideas that will be used in EJBoss 2, primarily the componentization of the server. In the Open Source business I worked on OSAS (Open Source Application Server) last year, but when that project was cancelled (and the source became XS) I joined EJBoss. I am very interested in building distributed component servers. I am also very interested in the Open Source concept for various reasons. Since EJBoss is a distributed component server using an open development process, it was a natural move for me. Houston: Why did you want to get involved in this? Fleury: As a new piece of infrastructure, the EJB and J2EE are sold at outrageous prices right now: for example, $50,000 per CPU for WebLogic. What the *#@$!? Initially it's been a rich man's technology; only corporate IT can afford to play with it. But we believe it is mainstream technology—or at least it should be. Öberg: My primary reason for working with open-development projects is the highly effective teach/learn side effects. If you want to learn a particular area, you will want to talk to as many other people in that area as possible. Explaining things to others is the best way to learn. And the more people are involved, the greater the chance that you will be able to pick up words of wisdom from others. It's a bit like "do unto others as you would have them do unto you." If you apply that principle in practice, you'll notice that it is a very efficient way to evolve and grow as an individual, while at the same time accelerating the growth of the group. It's a very philosophical idea in one sense, but at the same time a very pragmatic approach. Want to learn more about Java? Check out The O'Reilly Conference on Java, March 27-30, in Santa Clara, CA. Houston: Are there other Open Source server efforts for the J2EE platform? Fleury: Sure, Enhydra is one example. They will be presenting at the the O'Reilly Conference on Java with us. But they are not really J2EE. Apache also has Jakarta, which does the higher layers of J2EE (Servlet and JSP), with IBM and Sun contributing code and people to the effort. The only other "real" project out there in the EJB space like EJBoss is BullSoft with JOnAS. There are also many other smaller projects. The field is growing. Houston: What differentiates EJBoss? Fleury: There are three major differences that I see. One is the people involved. As the first open-source J2EE implementation, EJBoss caught the attention of all the people interested in the J2EE spec. Our biggest success is in attracting a good crowd of talented developers in the field. Talent attracts talent. There are also many little startups that need a real EJB container for their applications, so they contribute highly motivated and skilled people to the project. I'm fully aware that EJBoss's efficiency comes from the quality of its people and I've done everything to make them happy and excited about the project. Since my company benefits a lot from the work performed in EJBoss, I've felt it was fair to offer stock options to the most dedicated contributors. Most the people working on this stuff are pretty passionate. Can your day job do that? Secondly, use of the GPL license: We are the only group in the J2EE space with the GPL license. This presents a lot of advantages to our current spectrum of contributors. The individual developer likes GPL on average, because GPL is the only "major" license that requires the server and all it's derivative to be open. If you use it you have to contribute back the code you add. Free software doesn't mean free developers; it's more of a two-way street. For startup developers, the GPL is interesting because the viral nature of the license doesn't propagate to the beans running on top of GPL. This means they can still ship proprietary applications on top of EJBoss, but at the same time it assures them that the core server will always be open in ALL its features. That prevents other groups from adding high-end "load balancing/fail-over" features on top of your stuff and making money off it, while you get nothing in return—certainly not the code. GPL is an insurance policy. We have had excellent response on this choice. And third, the sky's the limit with EJBoss. We don't do this with legacy in mind. I am always very open to the wildest ideas. Java itself is such a moving and lively field, our principal interest is in being on top of it! For example, we standardized on the 1.3 Virtual Machine still beta in SUN. Another example is our deployment facility: it's the simplest you can find. Period. We are here to have fun and learn so we use the latest and greatest technology, with disregard for focus groups. Houston: Why did you choose the GPL as the Open Source license to release EJBoss under, as opposed to other Open Source licenses? Fleury: As I mentioned, the other licenses don't protect the interest of the individual developer or the startup developer looking to ship applications running on EJBoss. They protect (and I am thinking of BSD and its 13,784 "cute" derivatives) the interests of a particular breed of commercial server developer, the one that wants to sell only the server. It's as if somebody took your writing, added a few sentences and stylistic touches and re-packaged it as their own, while you never made a dime. That category of people is non-existent in EJBoss. We don't want leeches. We only have either individuals that want a payback in form of code or companies selling applications with EJBoss that want the best possible embedded server with high-end features for the best possible price: free. Öberg: Yes, the primary purpose of using GPL is that it is more community based than other open source licenses, which are more interested in providing loopholes for commercial uses. The idea is that any enhancement that is made to the server should be brought back to the community. It's that simple. However, there is no problem with using EJBoss with a proprietary application. The beans that run on EJBoss do not have to be GPL. It's a bit like a GPL editor: the editor may be GPL, but any documents that are edited with it don't have to be GPL. Houston: What will you cover in your session on EJBoss at the O'Reilly Conference on Java? Fleury: I plan on covering two aspects: deployment and scalability built in the server. We use two fundamental hacks, one from JDK1.3, one from JDK1.2.2. Once these are understood, we believe EJBoss's "NextGen" will become a blueprint for many people in the industry. For example, if you want to deploy a bean with BEA Systems' EJB server, WebLogic, you need to preprocess, post process, run a compiler on it, and so on. With EJBoss, you drop your bean in the deploy directory and off you go. That is very important since the EJB specification speaks to the needs of the deployer. EJBoss really goes the extra mile to deliver on it and make the deployer's life easy. Other EJB servers pay lip service to the needs of the assembler and deployer. However, their true focus is only on the developer. Scalability is another big issue. This is where the EJBoss container architecture will shine. The invocation layer and the bean passivation mechanisms are pretty advanced, and built in from the ground up (unlike Bull, for example). This is very important because on the Web, these servers will need to scale in production. If you find the information in this interview of interest, check out the authors' presentation at the O'Reilly Conference on Java. Houston: Could you tell us more about "NextGen?" Fleury: NextGen is the code name for EJBoss1.0. When Rickard submitted the core ideas behind EJBoss1.0 (the Proxy and Remote Serialized features), I had been working on the EJB spec for months. Like the rest of the industry, I relied heavily on classic compilation and non-dynamic stub and proxies for the EJBoss implementation. But also like everybody else, I was banging my head on the limitation of the "classic," almost "naive" approach to EJB container implementation that the industry seems to focus on today. This is why I realized almost at once how forward thinking Rickard's ideas were, such as adding the "one" RMI (remote method invocation) object trick. I named the container "NextGen," believing it was really a revolutionary design for the industry--maybe even a blueprint of what is to come in commercial containers, once everyone gets it, as Rickard says. "NextGen" is the next generation of containers, the first of its kind. EJBoss2.0 will blow everyone out of the water. Öberg: Most EJB servers that are available today are implementing the EJB specification literally. That is, for each logical EJBObject there is one physical EJBObject that receives requests. This may lead to scalability problems if there are many EJBObjects alive at any one time, and gives a rather complex structure to the EJB container. In "NextGen" we have only one physical EJBObject that serves all logical EJBObjects. Because of this, we can scale the server much better, and the core architecture is much simpler, which in turn gives less bugs and better performance. Also, we use a concept called Dynamic Proxies (which is available in JDK1.3), which allows us to deploy beans without generating a lot of extra classes, as all other servers do. So, "NextGen" is the name of the current EJBoss 1.0, but in some sense it is also a name for the next generation of EJB servers. Houston: What are your plans and goals for EJBoss? Where is this going? Öberg: The goal, for me, technically, is to provide a solid implementation of EJB. The primary goal of EJBoss2, which I am currently working on, is to allow parts of the server to be replaced with other implementations. For example, if you want to provide your own persistence mechanism or use another transaction monitor, then you will be able to replace those almost on the fly. Since different applications have very different requirements this "plugability" factor is very important. There are a ton of cool features in EJBoss2 that are not available in other servers, and these features will make it super easy to use and integrate with other software. Fleury: Have fun, grow, code. Commoditize J2EE.