<?xml version="1.0"?>
<document url="http://openejb.sf.net/embedded.xml" toc="none">
<properties>
<title>The OpenEJB Container System</title>
<sub-title>Everything in OpenEJB is pluggable, even OpenEJB itself</sub-title>
</properties>
<body>
<sideimg src="images/diagram-container-system.gif" width="240" height="300"/>

<section title="OpenEJB is whatever you want it to be">

  <p>
OpenEJB is a complete EJB Server platform, clients can access beans through 
the <a href="embedded.html">Local Server</a> or the 
<a href="remote-server.html">Remote Server</a>.  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?  
 </p>
  <p>
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?   
 </p>
  <p>
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?
 </p>
  <p>
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?
 </p>
  <p>
If you need any of these things, then OpenEJB is for you.
 </p>
</section>

<section title="OpenEJB is like a kernel">

  <p>
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.
 </p>
 <p>
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.
 </p>
</section>

<section title="Anyone can participate">
 
 <p>
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.
 </p>

 <p>
For example, the open source project <a href="http://openorb.sf.net">OpenORB</a>, formerly 
of <a href="http://www.exolab.org">Exolab</a>, integrated OpenEJB into OpenORB to provide 
OpenORB users with EJB functionality.  Similarly,  Apple Computer integrated OpenEJB into its 
<a href="http://www.apple.com/webobjects/">WebObjects</a> application server to provide 
WebObjects users with EJB functionality.
 </p>
 

</section>

<section title="Vendors can play along">
 <p>
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.</p>
 <p>
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.
 </p>
 
 <p>
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.
 </p>

</section>
<section title="Open Source can play along">
 <p>
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.
 </p>
 
</section>

<section title="You can play along">
 
 <p>
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!
 </p>

 <p>
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.
 </p>

 <p>
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.
 </p>
 <p>
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.
 </p>

 <p>
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++.
 </p>

 <p>
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.
 </p>


 <p>
  
 </p>

</section>

</body>
</document>

