Because of the above mentioned Block/Service paradigm, it was necessary to wrap any server that should be run within the iChilli™ system into an Avalon Phoenix compliant block. After having evaluated several different design approach of how to start all the different servers, the final result contains a single iChilli™ server that will be initialized and started by the Avalon Phoenix system. The iChilli™ server in turn is responsible to initialize and start all the different servers listed at the beginning of this section. To initialize, start and manage a server (for example, a Servlet Conatiner or an OpenEJB Server as shown below) a so-called IchilliServerFactory is required, which is implemented using a singleton, a design pattern that ensures that there exists only one instance of that factory during runtime. Additionally each server can be managed using JMX^[10], a functionality provided by the Avalon Phoenix system.

Some iChilli™ server are required to support Hot Deployment of new application components. The iChilli™ block that wrapps the OpenEJB server, needs to be able to recognize if someone just copied a new Java™ Enterprise Bean into OpenEJB's bean directory while the EJB server is running. The iChilli™ EJB block needs such capabilities, because it is unpleasant to require the user to restart the whole iChilli™ server system after having deployed a new Java™ Enterprise Bean. So Hot Deployment basicly means to detect just deployed components while a server is running, to be able to integrate those components into an already running system.

Supporting Hot Deployment for all the different J2EE components requires in turn a hirarchical Classloader structure, because Servlets for example have to be loaded by a different Classloader as Java™ Enterprise Beans. This requirement is the reason why each iChilli™ server gets its own unique ClassLoader structure. How to configure a Classloader hirarchy will be described later on. The iChilli™ Classloader system is illustrated in the following example.

Basicly composing a Classloader structure is somehow similar to creating different iChilli™ server, because a IchilliClassLoaderFactory is responsible for instantiating all the different Classloader to put them finally into the appropriate hirarchy. A IchilliClassLoader implements two interfaces:

Every iChilli™ server that wants to recieve Hot Deployment notifications needs to implement the interface IchilliClassLoaderListner.

The below example of an iChilli™ Avalon Phoenix configuration file demonstrates how a Classloader structure will be defined.

  1| <config>
  2| <ichilli-server>
  3| <!-- Generic Configuration Parameters -->
  4| 
  5| <!-- Server Declarations --> 
  6| <servers>
  7|   <server>
  8|     <name>OpenEJB</name>
  9|   </server>
 10|   <server>
 11|     ´<name>JORAM</name>
 12|   </server>
 13|   <server>
 14|     <name>Tomcat</name>
 15|   </server>
 16| </servers>
 17| 
 18| <!-- Server Specific Configuration Parameters -->
 19| <openejb> 
 20|   <properties>
 21|     <openejb.home>${block.context}/openejb</openejb.home>
 22|   </properties>
 23|   <classloaders> 
 24|     <classloader>
 25|       <name>openejb</name>
 26|       <entry>${openejb.home}/lib/*.jar</entry> 
 27|       <monitored>false</monitored>
 28|     </classloader>
 29|     <classloader>
 30|       <name>openejb.beans</name>
 31|       <entry>${openejb.home}/beans/*.jar</entry> 
 32|       <monitored>true</monitored> 
 33|     </classloader>
 34|   </classloaders>
 35| </openejb>
 36| </ichilli-server>
 37| </config>
 38|                

The above figure finally recaptualizes the previously described iChilli™ server and Classloader infrastructure. Basicly Avalon Phoenix configures and initializes the IchilliService, which in turn configures and starts every server definded in the previously described configuration file using the IchilliClassLoaderFactory and IchilliServerFactory.

According to the section The iChilli Server Infrastructure at the begining of this chapter, the following servers were actually implemented at a very basic level.

The following services are supposed to be additionally services according to the iChilli™ core services (Servlets, JSP, EJB, JMS, SOAP/XML-RPC).

Basicly PersonalChilli doesn't provide a GUI layer, because it is a server system and no user application. Allthough under special circumstances it was necessary to start/stop the mobile EJB container from within a graphical user interface. As described in section Mobile Operating Systems Palm OS™ for example, isn't able to support background or even server processes that will be started during system startup (boot) time. Same applies to MIDP compliant devices. As a result it isn't possible to have an EJB container that runs in the background and additionally start a graphical client application that accesses the EJB container.

That finally means that an EJB container that runs on Palm OS™ has to be started by some kind of a library call from within an already running application. Allthough suspending or even shutting down the application also means terminating the EJB container that was just started with that specific application. This requires the graphical application to notify the EJB container before getting suspended or shut down. This behaviour finally gives the server a chance to finish pending transactions and persist changed data.

The subject of implementing an user interface layer that supports J2ME devices was completly discarded, hence it isn't within the scope of this thesis. Thus the objective was to use an allready existing GUI toolkits for mobile devices. While searching for situable GUI toolkits the following toolkits were taken into closer considerations.

Finally for the sake of simplicity, AWT were choosen because of beeing already familiar with that GUI toolkit.

The term application layer refers to a system component that is able to execute some kind of application logic. In the scope of this diploma thesis this will be in fact an EJB container. Thus business logic will be provided by Java™ Enterprise Beans. At a very early stage the people involved with this diploma thesis had a consensus that programming a new mobile EJB container just out of the void, would be very time consuming. As a result it was clear that the only alternativ would be to port an already existing EJB container to PersonalJava and possibly MIDP, respectively. After having evaluated several EJB containers it was finally possible to elect one EJB container for beeing a porting candidate. The final decission was to use OpenEJB because of the performance results found in section Mobile Operating Systems, the fact that OpenEJB can be run in embedded mode (will be explained later) and the fact that the author of this diploma thesis is a member of the OpenEJB project. Thus he knows that container very well.

As previously mentioned OpenEJB can be run in embedded mode. From the view of a Java™ developer this means that the OpenEJB runtime system can be instantiated just like a call to any other Java™ library. This in turn means that OpenEJB can be embedded into an user's mobile application. Embedding OpenEJB into an user's mobile application would solve for example, the previously mentioned problem that applications on Palm OS™ can't be run as a server application. The following figure illustrates the two contrary runtime modes of OpenEJB.

Allthough while beeing embeddable, OpenEJB won't eliminate the fact that J2ME profiles running on top of CLDC are missing most Java™ APIs needed to run an EJB container. Section The MIDP Feature Set Generative Transformation System illustrates an alternative approach of how Java™ Enterprise Beans could be brought to such devices.

Mode one at the left side is called IntraVM Mode, which basicly refers to the fact, that OpenEJB is running in the same Java™ virtual machine as the user's application does. EJB objects will be accessed using JNDI lookups during IntraVM mode.

Mode two at the right side is called Remote Server Mode and supplies a real distributed environment, because the EJB client does not need necessarily to run on the same machine as the remote server does. EJB objects in this mode will be accessed using some kind of RPC calls^[14].

To leverage the embeddable approach of OpenEJB a so called admin client was created, which fulfills the need of having a J2ME application that starts the OpenEJB runtime environment. Basicly this admin client is able to start an IntraVM server, or if necessary a Remote Server that resides at the same machine as the admin application. While developing and testing the just described application the Sharp Zaurus Linux™ PocketPC served as a mobile hosting environment.

The following figure illustrates how the admin application starts a Remote Server.

Basicly the above class diagram shows the composition of a AWT frame (e.g. an application window), which contains some menu items like start, stop, restart. Those menu items are causing the PersonalChilli Daemon to be started, stopped or restarted. The PersonalChilli Daemon in turn initializes the OpenEJB system by staticaly calling org.openejb.OpenEJB.init() and creates a server socket to recieve incoming OpenEJB protocol messages.

The more elegant way to use OpenEJB on a mobile device, would be in embedded mode. Running OpenEJB in embedded mode has the positive side-effect that no server needs to be instantiated that creates a server socket and other unnecessary stuff. The below code snippet illustrates a replacement for the PersonalChilliAdmin.startPersonalChilli method, which will start the OpenEJB system in embedded mode.

  1| import java.util.Properties;
  2| import javax.naming.Context;
  3| import javax.naming.InitialContext;
  4| import javax.rmi.PortableRemoteObject;
  5| import FooHome;
  6| 
  7| public class MyEjbApplication
  8| {
  9| public static void main( String args[])
 10| {
 11|   try
 12|   {    
 13|     Properties properties = new Properties();
 14|     
 15|     properties.put(
 16|       Context.INITIAL_CONTEXT_FACTORY, 
 17|       "org.openejb.client.LocalInitialContextFactory"); 
 18|     
 19|     InitialContext ctx = new InitialContext(properties);
 20|     
 21|     Object obj = ctx.lookup("my/bean/Foo"); 
 22|     
 23|     FooHome ejbHome = (FooHome)
 24|         PortableRemoteObject.narrow(obj,
 25|                                     FooHome.class);   
 26|   }
 27|   catch (Exception e)
 28|   {
 29|     e.printStackTRace();
 30|   }
 31| }
 32| }
 33|                

To illustrate what basiclly happens it would be necessary to introduce the below sequence diagram.

The above sequence diagram shows that while the client requests an initial JNDI context, the OpenEJB context factory returns such a context after having initialized the OpenEJB system.

The PersonalChilli distributed object layer provides the ability to operate in a nearly autarkic manner. That means while experiencing a disconnect, the mobile client is still able to execute some application logic. Additionally the distributed object layer provides a replication and sysnchronization facility.

While in theory it is possible to port an already existing EJB container to jdk1.1.8, it is completly impossible to undertake the same bold venture for a CLDC based J2ME profile. According to section J2ME Profile Overview MIDP got a completly reduced feature-set compared to jdk1.1.8 and doesn't provide a sufficient infrastructure to run an EJB container (even MIDP version 2.0 wouldn't support a real EJB container).

Because of this constraints a complete different approach has to be taken into consideration. Voelter for example has created an architectural concept for embedded systems which dynamically composes a container system [[voelter, kircher and marquardt, 2001]]. During development time a developer decides which Feature should be used by his application. Uppon that Feature specification a lightweight container system will be composed that only contains those infrastructural elements, that are required to support the Feature set defined by the developer.