htdocs.pluggable.html Maven / Gradle / Ivy
The OpenEJB Container System -- Everything in OpenEJB is pluggable, even OpenEJB itself 
Main Welcome! Download Mailing Lists The Team
Users Quickstart Hello World! Deploy Startup Support Request Feature
Servers Local Server Remote Server
Adapters Tomcat
Integrators Why OpenEJB Overview Design Specification Presentation
Developers Release Plan Source Code SourceForge
The OpenEJB Container System
Everything in OpenEJB is pluggable, even OpenEJB itself
OpenEJB is whatever you want it to be
OpenEJB is a complete EJB Server platform, clients can access beans through the Local Server or the Remote Server. Both of these are focused on ordinary users who just want to create EJBs and need a an EJB Server to run them. This is great, but what if you want more control?
What if you want to customize part of the EJB Server? What if want to create a new enterprise bean type? What if you want to tear out things you don't need? What if you want to re-implement something or make very specific optimizations?
What if you want the EJB Server to directly and tightly use systems in your existing infrastructure, such as a security system or transaction system?
What if you are not looking to create EJBs at all, but rather, you want to create your own EJB Server or add EJB compliance to your existing application server?
If you need any of these things, then OpenEJB is for you.
OpenEJB is like a kernel
Just as Linux is actually the kernel for the operating system, OpenEJB is a kernel for an EJB platform. We refer to this EJB specific "kernel" as the container system. It is a framework by which EJB Containers can interoperate but not be dependent on each other. Where an EJB Server can provide remote access to beans in those EJB Containers without being dependent on any of the EJB Containers in the system.
Just like the Linux operating system, OpenEJB is divided into several independent pieces. Every piece can be ripped out and replaced independently of the others. Pieces can be added and combined in a number of different ways to create customized EJB platforms for specific needs. This idea is similar the concept of a Linux distribution. Each distribution is a full working operating system, each has a unique combination of pieces, but all share the same heart, the kernel.
Anyone can participate
The power of OpenEJB, as with Linux, is that many people can play in the same game. Anyone can add a piece. All pieces can play together.
For example, the open source project OpenORB, formerly of Exolab, integrated OpenEJB into OpenORB to provide OpenORB users with EJB functionality. Similarly, Apple Computer integrated OpenEJB into its WebObjects application server to provide WebObjects users with EJB functionality.
Vendors can play along
Vendors are already participating in this game. As mentioned above, Apple Computer put OpenEJB into WebObjects and has been shipping it world over since WebObjects version 5.1. This is great. Imagine the possibilities when more vendors participate.
Let's say Oracle decided to take the part of their application server that provides EntityBeans with lightning-fast Container-Managed Persistence to the Oracle Database and make it an OpenEJB-compatible EJB Container. They could sell that EJB Container separately or packaged with the Oracle Database to anyone using an OpenEJB-based platform. WebObjects users could purchase and plug-in the Oracle CMP Container, as could OpenORB users, and as could users of any other software that uses OpenEJB as its container system.
In the extreme case, IBM or BEA could convert their EJB Containers to OpenEJB-compatible EJB Containers and sell them separately, in combinations, or at different price levels. One container for stateless SessionBeans, one for stateful SessionBeans, one for bean-managed persistence EntityBeans, one for container-managed EntityBeans, and one for JMS MessageDrivenBeans. Along with selling one big platform for $20 grand, they could sell a base platform for $5, for example, and each of the containers for $5 grand. They could sell those containers to their existing customers or users of any other OpenEJB-based EJB platform.
Open Source can play along
Now if someday the developers of the PostgreSQL database server, or the MySQL database server decided to create an EJB Container that supported EntityBeans with container-managed persistence, the same rules apply. Anyone using an OpenEJB-based EJB platform could download, plug-in and use one or both of those those containers for their CMP EntityBeans. Those containers could be written to work as close to the database as possible, cutting out all middle-men like JDBC and providing container-managed persitence in the most performant way possible, taking full advantage of all the features of the database.
You can play along
Let's not forget, OpenEJB is open source and distributed with a business-friendly, non-restrictive, BSD-style license. Anyone can help themselves to as much of our code as they can stomach. You can even sell what you make from it!
Change the code as much as you want. If there is functionality you need, grab the existing piece and edit till your heart is content. We do this very same thing when there is functionality we need, you can too. In fact, all the containers in OpenEJB were created using our stateless SessionBean container as a template.
If you want to be the one to write that PostgreSQL CMP EntityBean Container, just grab our existing Castor CMP EntityBean Container and hack it up. We'll even let you use our CVS if you want to make it available to other OpenEJB users as well.
Perhaps you want to create a CMP EntityBean container that persists beans directly to your mainframe. Grab the code you need to get started, put a few developers on the task, then plug it into an OpenEJB system and put it to work.
Be creative and think outside the box, invent a new EnterpriseBean type! A NativeBean type, for example. Just create an OpenEJB EJB Container that executes your native code according to your specification, and start writing beans in C++.
Want to distribute beans via a special distributed object protocol? Grab the Remote Server code and change it to use another protocol, SOAP for example. Maybe you want to make it an extention to the Remote Server or maybe you want to write it as a brand new org.openejb.spi.ApplicationServer implementation. It's your time and your desicion.
Java, EJB, JDBC, JNDI, JTA, Sun, Sun Microsystems are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and in other countries. XML, XML Schema, XSLT and related standards are trademarks or registered trademarks of MIT, INRIA, Keio or others, and a product of the World Wide Web Consortium. All other product names mentioned herein are trademarks of their respective owners.