General Description

The Mobile World

To understand what is meant by the term Mobile World it is important to know all the various components that the Mobile World is composed of. After having read this chapter, it should be possible to imagine all the possibilities and all the challenges, which can be found in today's mobile infrastructures.

Understanding the contents of this chapter is essential, cause it illustrates reasons for Java™ middleware like iChilli™ or dtF/AF.

Mobile Device Differences

The following figure illustrates today's mobile device diversity. Although for simplicity only devices that will be targeted by the iChilli™ or dtF/AF systems, will be explained in detail.

Figure 2.1. Different mobile device classes and their approximate^[4]market shares.

Different mobile device classes and their approximate The market shares shown in this figure are based on a news entry found on computerworld.ch, which summarized data of a recent Gartner Dataquest research. market shares.

According to the previous figure, mobile devices could be separated into four major categories to provide a fundamental classification of current mobile devices.

Palm sized devices, running PalmOS, or at least an OS that can be compared to PalmOS, and a Java™ VM that implements the MIDP specification.
Highend Handhelds, running some flavor of Windows CE, Linux®, SymbianOS or some similar OS. Those devices are expected to run a PersonalJava or Personal Profile compliant Java™ VM.
Smart Phones, running SymbianOS or a proprietary OS. Smart Phones are expected to run a MIDP compliant Java™ VM.
Other devices - Those devices are not in the scope of this diploma thesis. Possible devices might be embedded devices (automation processors), set-top boxes or automotive navigation systems.

The following table finally tries to establish a relationship between some real-world devices to provide an imagination on how current mobile devices differ from each other.

Table 2.1. Mobile Device Comparison

Device Name	Manufacturer	CPU Type / CPU Speed	Memory Size	Available Connectivity	Display Type	Display Size (Pixels)	Battery Durability	Operation System	Available Java™ VM
Palm Zire™	Palm, Inc.	Motorola Dragonball EZ 16MHz Processor	2MByte	Standard Mini USB Connector, IrDA	Monochrome Display	160 x 160	5 hours during permanent operation	Palm OS® v4.1 software	MIDP compliant
Palm Tungsten™	Palm, Inc.	Texas Instruments OMAP1510 144 MHz Processor	16MByte	Standard Mini USB Connector, IrDA, Bluetooth™, GPS etc. through Palm Universal Connector	High Resolution Display with 64k Colors	320 x 320	3 hours during permanent operation	Palm OS® v5.0 software	MIDP compliant
Sharp Zaurus SL-C700	Sharp Cooportation	Intel® XScale™ (PXA250, 400 MHz)	64MByte max.	USB, IrDA, Ethernet and WLAN etc. via CF card	65k color transmissive System LCD	640 x 480	3 hours during permanent operation	Linux® (Embedix™)	PersonalJava compliant, jdk1.3.1
Sony Ericsson P800/P802	Sony Ericsson Mobile Communications AB	ARM 9, 200 MHz	16MByte	GSM, GPRS, HSCSD, IrDA, Bluetooth	4k color TFT Display	640 x 480	talk time up to 13 hours	Symbian OS™ V7.0	PersonalJava™ or MIDP compliant
Siemens S55	Siemens AG	?	200K (100K available to Java™ VM)	GSM, GPRS, HSCSD, IrDA, Bluetooth	Color, 7 lines	101 x 80	up to 360 min	proprietary OS	MIDP compliant

Having previously made a distinction between available mobile devices makes it easy to associate the devices mentioned in the above table with an actual device class.

Class I Palm Zire™, Palm Tungston™

Class II Sharp Zaurus SL-C700

Class III Sony Ericsson P800/P802, Siemens S55

The above table additionally illustrates that contrary to Sun's marketing campaign write once run anywhere™, it isn't possible to run one application on almost any mobile device. This is at least true if someone tries to run an application on a low computing device with limited resources, that was originally developed for a 'fat client'. One good example is a mobile application that access a Stock Ticker Web Service using some SOAP API. If that application was initially developed for the Desktop, the application is supposed to use Java™ APIs that are having a huge memory footprint, because an economical usage of resources isn't as important on the Desktop as on small sized devices with limited resources. The following example illustrates how much resources will be used by the previously mentioned Stock Ticker application after optimizing the applications for a mobile device.

The SOAP Java™ archive by itself will consume about 50 KByte (including a XML parser) - Additionally the application logic might consume additional 50 - 100 KByte of storage space. Although the application bytecode and the needed APIs might fit onto a mobile device, memory usage during runtime could remain a problem. Usually applications that are parsing some sort of a XML file, are a general problem on most cellular phones and on some PDAs, because the XML parsing process consumes to much memory. Having mentioned this problem makes clear that the usual memory limit of 100 KByte could be easily reached on small devices, which requires in turn additional optimization efforts during development time.

Wireless Communication Protocols

The figure below illustrates currently available mobile communication protocols over their transfer rates. Usually they could be categorized into circuit-switched and packet-switched (TCP/IP based).

Figure 2.2. Overview of current Wireless Communication Protocols.

The above figure makes a distinction between outdoor and indoor protocols, which identifies the area of usual usage. Generally there are four different types of mobile communication protocols.

Older 2G protocols like GSM and HSCSD, which are circuit-switched protocols.
Hybrids, so-called 2.5G protocols like GPRS, which are still using GSM based technologies. Although GPRS is a packet-switched protocol.
New or upcoming 3G protocols that are completely new implementations. An example for a 3G protocols is the highly mentioned UMTS protocol, which is packet-switched and provides high transfer rates. Although UMTS is currently unavailable to the public.
Non-Cellular protocols that were introduced to provide wireless connectivity to the internet. Such a protocol is WLAN, also known as Wi-Fi or 802.x networks. Another protocol that fits into this category is Bluetooth, which provides lower transfer rates compared to WLAN.

For the sake of completeness the above figure also includes wired terminals that are considered to be non-mobile devices.

Within the scope of this diploma thesis all of the above protocols are considered as unreliable protocols. That unreliability has to be covered by this diploma thesis and the resulting iChilli™ system architecture. Below are listed some important reasons why we consider these protocols/technologies as unreliable.

Weak or missing wireless network coverage.
Limited wireless radio signal range.
Some materials are interfering or even shielding the wireless radio signal. This could happen for example, if someone is driving through a tunnel or someone resides at the bottom of a valley. Although other radio signals are potentially supposed to interfere wireless radio signals.
Network error. Usually wireless network technologies are more vulnerable to common network problems than traditional network technologies.

Another problem that comes along with wireless network protocols, are expensive uplinks to the network of the wireless network provider. That means every time a person wants to transfer data and needs to connect to a wireless network using a mobile device, that person has to pay money for the time beeing connected or at least for the amount of data that was transmitted.

Summarizing the above figure and its explanations, it could be said that there are currently up to five different wireless communication protocol. Each of those protocols are considered as unreliable and TCP/IP-based. The latter provides the possibility to completely disregard the necessity of directly dealing with the actual network layer implementation, because TCP/IP networking will be addressed accordingly by every Java™ development kit, which is a core technology leveraged by this diploma thesis. Although the remaining spontaneous disconnects are an issue that has to be addressed by the iChilli™ architecture.

Mobile Operating Systems

As illustrated by Baumgarten todays operating systems for mobile devices could be summarized by the following four representative operating system types. [[baumgarten, LUCA02]] Although those should be considered less secure, according to Baumgarten, there isn't currently an operating system that provides real security for mobile devices. What is meant by the term real security will be described within a short example later on.

Table 2.2. Current mobile operation systems (1).

Palm OS®

Symbian OS

Manufacturer - Palm Inc., available since 1996.
Current form factor supports PDA sized mobile devices.
Operating system includes a handwriting recogition software.
Communication Layers: TCP/IP, IrDA, RS-232
Virtual Memory isn't supported, no MMU available.

=> No memory protection mechanisms available.
Few expansion possibilities (for example, memory expansions etc.).
Developer Tools are available for free.
Interfaces and APIs are well documented an freely available.

Manufacturer - Symbian Ltd., a cooperation of several companies.
Current form factor supports a variety of mobile devices such as cell phones, PDAs, subnotebooks etc.
Virtual Memory will be supported; MMU does exists

=> Memory protection exists.
Scheduling is based on Threads (RT are possible).
Operating system is almost implemented in C++.
Various developer APIs such as C/C++ and Java™ are available.

The system could be programmed using various programming languages.
Free access to sources is limited.
Developer tools are available for free.

Table 2.3. Current mobile operation systems (2).

Windows CE and PocketPC®

Linux

Manufacturer - Microsoft®.
Current form factor supports almost any mobile device.
Source code is partitially available.
Programming interfaces are modelling a subset of the Win32 programming API.
Basic memory protection mechanisms are available.
Scheduling is implemented using Threads (RT are possible)
Limited amount of 3rd party applications is available.
A PKI^[a] is available.

Developer Tools are freely available (open source).
Source Codes are freely available (open source).
Programming interfaces are open.
Up to 98% of the whole system is implemented in C.
Memory protection mechanisms are differentiated into user processes and system processes.
Various communication protocols are available.

Scheduling is realized using processes (RT are possible).
Runs on many target platforms.

^[a] Public Key Infrastructure

The previously described operating systems could be put into a ranking order according the following aspects.

Available/Supported communication layers.
Available/Supported internet services (for example, HTTP, Samba, FTP etc.).
Type of memory protection mechanisms.
Available/Supported expansion possibilities.
Available documentation (API etc.)

To implement a Java™ midleware like iChilli™ or dtF/AF within a situable time frame, requires a specific type of operating system. For example, porting an already existing EJB container to a mobile device requires a specific amount of storage space and memory. Also safe memory access and safe thread handling are subjects that have to be considered while programming an EJB container for a mobile device. Palm OS® for instance makes an EJB port nearly impossible because of its memory handling implementation. On Linux® based mobile devices in contrast, it was very easy to get a first version of an EJB container up and running, because the Blackdown project provides a Java™ development kit version 1.3.1 for Strong ARM processors, which is supported by many of todays EJB containers. Although executing an EJB container on a mobile device that was initially developed for a server platform is still a problem because of performance issues. The following short table illustrates some data collected while executing the OpenEJB and Jboss™ containers on a Sharp Zaurus Linux® PocketPC.

Table 2.4. Performance Data Resulting From different EJB container systems running on a mobile device.

	OpenEJB	Jboss™
Consumed space on storage medium	appr. 9 MByte	appr. 25 MByte
Startup time	appr. 5 minutes	appr. 30 minutes
Consumed memory space	appr. 10 MByte	appr. 50 MByte
Operating systems remains stable while running the container	yes	no (memory limit exceeded)

Having made the above experiences while trying to run a standard EJB container on a mobile device, it was finally possible to put the previously mentioned operating systems into a ranking according to the above listed criteria. The list is sorted from most preferable to least preferable.

Linux®
Symbian OS
Windows CE/PocketPC
Palm OS®

The above ranking was mainly driven by the fact that Linux® provides a nearly fully capable OS in the sense of current Desktop operating systems.

Although knowing that running a standard but small footprint EJB container on a Linux handheld could be made possible within a hurry, it wasn't an option to just stick with jdk1.3.1, because almost any mobile device doesn't support those kind of Java™ VMs.

Secure Mobile Operating Systems

The previous section only covered semi-secure mobile operation systems. Although security has to be a subject within mobile computing environments, especially if a mobile device is supposed to run an enterprise system like iChilli™ or dtF/AF. Because enterprise application almost operate on confidential data, protecting that data is not only desirable - it has to be guaranteed. For example if a mobile device and the data contained within that device could be accessed by everyone, that device has to be considered a serious source of vulnerability. The previous example becomes an additional relevance because mobile devices are items that are getting lost on a regular basis - just like keys.

Addressing various security issues that could occur in conjunction with mobile computing wouldn't be within the scope of this diploma thesis. Instead it would be interesting to introduce an already existing solution that addresses various security issues at a very low level, preferably at the operating system level. Baumgarten and Ackert are describing an operating system [[baumgarten and eckert, 2001]], called LucaOS - A next generation secure mobile operating system, that provides security for mobile devices. The following picture illustrates the current architecture of LucaOS.

Figure 2.3. The LucaOS system architecture.

LucaOS is currently available as a Linux® based prototype, although LucaOS isn't supposed to be bound to just one specific operating system. Speaking on a very simple level - LucaOS turns an ordinary mobile device into a so-called trusted device. One integral part of LucaOS is a system database, which contains several security policies. By using these policies, the management kernel of the LucaOS system is able to decide whether some data should be encrypted or not. Additionally this security architecture makes it possible to decide which user is allowed to view and use what kind of data.

Even LucaOS is still a prototype, it nevertheless illustrates how certain security threats could be identified and classified and how those threats could be addressed within a secure mobile operating system.

J2ME Profile Overview

If refered by people, J2ME has been sometimes misunderstood as beeing an implementation specification for a Java™ VM that runs on mobile devices, which is not true. J2ME in fact is a umbrella term for many different specifications, each specification targeting a specific mobile device. J2ME currently provides Java™ VM implementations for mobile devices such as cellular phones, PDAs, handhelds, set-top boxes and even JavaCards. The below figure illustrates currently available J2ME profiles and how they relate to each other.

Figure 2.4. Overview of the J2ME Profiles and how they relate to each other.

In the above picture there are two vertical segments included for the sake of completeness - J2SE and J2EE. Both are specifications for the Desktop or Server platform. According to the above picture, there are two main standard configuration profiles in the J2ME world: the Connected Device Configuration (CDC) and the Connected Limited Device Configuration (CLDC). A Configuration Profile in this special context should be understood as a specification for a Java™ runtime environment - it doesn't necessarily provides APIs like a GUI programing interface. Additionally there is a configuration profile for JavaCards but because this diploma thesis isn't targeting such devices, this specific aspect won't be covered in detail.

The CDC profile is targeted toward powerfull mobile devices. According section 'Mobile Device Differences' such a device could be the Sharp Zaurus PocketPC. Other devices could be set-top boxes, multimedia devices and so on. Refering to the CDC whitepaper the CDC profile provides the full Java™ 2 Platform virtual machine, the CVM virtual machine, and the minimal class libraries and APIs to get the system up and running. The last sentence contains most notably one phrase the full Java™ VM which means that the CDC profile is compliant to the J2SE virtual machine specification.

The CLDC profile is targeted towards mobile devices having limited resource constraints. Quoting Mahmoud the CLDC was first distributed in October 1999 with the idea of creating a "lowest common denominator" [[mahmoud, 2002]]. In general that means the CLDC profile is meant for devices such as the Siemens cell phone mentioned in section 'Mobile Device Differences', which only provides about 100 KByte RAM to the Java™ VM.

The Foundation Profile (FP) could be described according to the CDC whitepaper as a set of Java APIs that, together with the CDC, provides a complete, J2ME application runtime environment targeted at consumer electronics and embedded devices. The CVM in the CDC is the engine for the Foundation Profile libraries. The Foundation Profiles contains commonly know Java™ packages such as java.lang, java.util, java.io, java.text and java.security. Although the Foundation Profile is missing a GUI API.

The Personal Basis Profile (PBP) provides, according to the PBP Programmer Guide, a Java™ 2 Platform, Micro Edition (J2ME Platform) application environment for network-connected devices supporting a basic level of graphical presentation. It provides a platform for the development of Java™ applications for consumer electronics devices. Although it should be mentioned, that the GUI presentation layer couldn't be compared to the richness of the AWT API - The PBP GUI layer should be expected to be lightweight and device specific.

The Personal Profile (PP) provides, according to the PP Programmer Guide, a Java™ 2 Platform, Micro Edition (J2ME Platform) application environment for network-connected devices. It provides full Abstract Window Toolkit (AWT) support (relative to JDK 1.1 AWT) and includes a number of feature improvements introduced by J2SE. Personal Profile provides a platform for the development of Java applications for consumer electronics devices. Personal Profile provides much of the functionality of the PersonalJava environment, but in a next-generation J2ME profile. That means that the PP is supposed to be the successor of PersonalJava, a previous profile that can be compared to PP.

The Mobile Information Device Profile (MIDP) is designed to be used with the CLDC and provides a set of APIs, optimized for small footprint devices, such as a cell phone. The MIDP notably provides persistence storage classes, some networking facilities and a lightweight GUI layer that could be compared to the one of the PBP. Recently the new MIDP 2.0 specification was released - The below table contains important changes compared to MIDP 1.0. Although MIDP 2.0 still supports applications that were initially developed for MIDP 1.0.

Table 2.5. New Features Introduced With the Occurence of MIDP 2.0.

	MIDP 1.0	Comments
Connections to RS-232 interfaces		-
HTTP/HTTPS Connections		HTTPS Connections are missing in MIDP 1.0
Secure Connections		-
Server Sockets		-
Socket Connections		-
UDP Datagram Connections		-
LCD UI		In MIDP 2.0 various additional GUI components and an improved LayoutManager were introduced.
LCD CustomItem GUI Component		Allowes to place a completly customized component on a Form
Game API		-
Media API		-
PKI Support		-
Push Functionality		Allowes a MIDLet to be launched on the event of incomming messages.
	Not applicable. Feature will be supported.

Reading through the above table, it should be realized that substantial network funktionalities were introduced in MIDP 2.0, additionally previous security issues were targeted by providing classes that could be used within a PKI. All of these just mentioned additions, which were made to MIDP 2.0, could ease the task of providing at least a small footprint pseudo- EJB container for MIDP devices. The meaning of the term pseudo indicates that MIDP devices won't be able to run a real EJB container - Instead they are supossed a very lean implementation of a container that is able to execute application logic. How this task could be accomplished will be described in section 'The PersonalChilli Concept'.

The PDA Profile (PDAP) targets handheld personal digital assistants. The PDA profile also includes the Mobile Information Devices Profile (MIDP) in its implementations to re-use many of the APIs already defined in that profile for small, mobile devices. The PDAP is supposed to support a subset of the AWT GUI toolkit. Currently there is no reference implementation (RI) of the PDAP available.

Summary

While showing the current stakes of The Mobile World during the previous sections, it could be made clear that current mobile computing environments aren't homogeneous entities. Rather current mobile computing environments are suffering from device diversities as shown in section Mobile Device Differences, varying Java™ VM implementations according to section J2ME Profile Overview, different communication facilities and nearly a dozen operating systems as explained in section Mobile Operating Systems.

The situation just described enforces a Java™ middleware like iChilli™ or dtF/AF to address that actual situation. Because iChilli™ aims to provide an EJB runtime environments, it was necessary to decide which J2ME profile is situable to serve as an underlying Java™ VM implementation. Additionally it was necessary to distinguish whether that actual J2ME profile provides proper Java™ APIs for a mobile EJB container. Finally the weaknesses and strengths of the hosting operating system were also taken into considerations.

Although it was possible to run an already existing EJB container without much efforts on a mobile device, using a jdk 1.3.1 implementation, it was not necessary to revise the initial decision to provide an EJB container implementation that runs on top of some sort of a J2ME profile. Although during the previous analysis of todays Mobile World, it was possible to fine-grain the requirements for a J2ME compliant EJB container.

One element of the revised requirements is the fact that a mobile EJB container would be only implemented for devices of the device class II, mentioned in section Mobile Device Differences. Additionally it was possible to clarify, that MIDP will need a different lightweight application container that isn't EJB compliant - thus this container will be a proprietary implementation. Even if section J2ME Profile Overview illustrates that devices of the classes I & III may be equipped with an updated version of MIDP (MIDP 2.0), it is still not possible to provide an EJB compliant container on such devices, because of capacity constraints. So as a result of the described boundaries it was decided to provide two versions of a mobile EJB container - one that is compliant to the EJB spec and one that is not. The architecture how those two different containers should be implemented is described in section The PersonalChilli Concept

The iChilli™ Vision

This section describes the Vision that forms the basis of the iChilli™ mobile J2EE platform. The intention of this section is to give an overall overview of all the various components that are assembling the iChilli™ system. Although it should be absolutly clear that completly finishing the development of every single iChilli™ software component isn't within the scope of this diploma thesis.

As analyzed in section The Mobile World, a Java™ middleware that is targeting mobile devices needs to address specific subjects, which are predominant in the field of mobile computing. To address those subjects the iChilli™ system will be composed of several subsystems. Basicly the iChilli overall system architecture could be distinguished into a J2EE server subsystem and a client substystem that runs on a mobile device.

Because the server subsystem already runs a J2EE environment and Java™ application development on mobile devices is time consuming and has a low learning curve, it would be desirable to reuse the application logic that is running on the mobile EJB server. That means in turn having an EJB container on the mobile device is a must, but would be time-saving and wouldn't require to learn how to use a different technology. Thus running an EJB container on a mobile device could increase acceptance of mobile applications and improves availability of mobile applications, which results in a faster Time To Market factor. The most pressing argument for having an EJB container on a mobile device is that application logic that was once developed and tested on the server could be seamlessly transfered to the client, which reduces the overall system to be failure-prone.

Although the client peer running on the mobile device isn't isolated from its server peer. In fact the client peer has the ability to replicate enterprise data from the server onto the data storage facility of the mobile device. Additionally after having changed the data partition that was once transfered to the mobile client, the client peer needs the ability to synchronize its current changes with the server peer. This behaviour is required because the overall system has to remain in a consistent state. Replication of data will be provided by a Java™ middleware called Lime which will be described in section The Distributed Object Layer. Data synchronization and secure mobile transactions will be provided by the dtF/AF Java™ middleware which will be described later on. Data persistency will be profided in the form of a relational database system, a XML based object database, a MIDP Record Store or even by an ordinary file. What kind of persistence mechanism will be used on the mobile device really depends on the sort of resource infrastructure that will be provided by the mobile devices. Mobile devices with a high computing capacity could be expected to persist their object states via a JDO or ODMG compliant persistence layer.

Reaching this section, it should have been understood that running a mobile application server not only needs its own data storage facility to operate on, because the EJB spec requires such a behaviour, it should be further understood that the mobile application server needs its own data storage facility because the server needs to operate in a completly autarkic manner. The requirement for the previously mentioned autarky directly results from the unreliable mobile network infrastructures described in section Wireless Communication Protocols. This requirement differentiates the idea behind iChilli™ from so called thin clients because those clients aren't able to remain functional while beeing off-line.

An additional component of the iChilli™ infrastructure is focusing on mobile application management. An application in the context of iChilli™ has to be considered to be implemented as an Enterprise Java™ Bean. Because within enterprise environment applications not just only needs to be developed and installed but also requires additional support, it was necessary to define every single management and support process that exists during the lifecycle of a mobile application. The following table illustrates each mobile application management & support process that could be identified.

Table 2.6. Application Management & Support Processes

#	Process Name	Stage in Application Lifecycle
1	Mobile application requirement analysis	Design/Planing
2	Mobile application implementation specification	Design/Planing
3	Mobile application development	Development
4	Mobile application packaging and deployment^[a]	Deployment
5	Mobile application execution	Runtime
6	Mobile application monitoring and maintenance	Runtime
7	Mobile application update provisioning	Deployment/Redeployment
Not applicable. Feature will be supported.
^[a] Mobile applications for devices of class II will be packaged according to the J2EE specs, mobile applications for devices of class I or III will be packaged according to the J2EE Client Provisioning Specification.

After having outlined the processes that should be covered by the iChilli™ mobile J2EE platform, it is necessary to specify which process will be covered by what kind of iChilli™ component. Additionally while talking about a Vision it should be clear that not every aspect of that Vision could be within the scope of this diploma thesis. Components that were not developed during this diploma thesis are labeled accordingly.

Table 2.7. Application Management & Support Processes and its Corresponding iChilli™ components

Process #	Component Name	Within the Scope of This Thesis?
4	ChilliRepository server
5	PersonalChilli / iChilli™ J2EE server
6	PersonalChilli / ChilliRepository Server	/
7	PersonalChilli / ChilliRepository Server	/
Within scope. Not within scope.

Finally to complete the overview of the iChilli™ system architekture it would be feasible to explain the previously mentioned software components by using some figures. Although a complete illustration of the iChilli™ system doesn't make any sense at this time, which is the reason why the figure of the complet iChilli™ system architekure is contained within Appendix A - iChilli System Overview.

Figure 2.5. Overview of the iChilli™ Server Peer

The iChilli™ server subsystem provides a complete J2EE runtime environment. The components necessary to provide J2EE compliancy are descriped in the J2EE Platform Specification, which is the reason why the components of the iChilli™ server substystem are just briefly described in the list below.

Web Container - Provides a runtime environment for Servlets and Java™ Server Pages.
EJB Container - Provides a runtime environment for Enterprise Java™ Beans
Application Client Container - Provides a runtime environment that is able to execute EJB clients.
Applet Container - Provides a runtime environment that is able to execute Java™ applets.

Finally it is important to understand that the iChilli™ server subsystem is built on top of a standard Java™ virtual machine, as described in [[lindholm and yellin, 1999]].

Additionally to J2EE compliancy, the iChilli™ server subsystem will be able to replicate data to mobile client devices using a distributed Java™ middleware called Lime.

Figure 2.6. Overview of the iChilli™ Client Peer

The iChilli™ client subsystem provides an EJB runtime environment for mobile devices. Actually this client subsystem is called PersonalChilli and will provide the following services as required by the Enterprise JavaBeans Specification.

BMP - Bean Managed persistence, which allowes an Enterprise Bean Provider to control how an Entity Bean should handle object persistence as described in Chapter 12 - Enterprise JavaBeans Specification (version 2.1).
CMP - Container Managed Persistence, which allowes an Enterprise Bean Provider to delegate persistency control to the underlying persistence layer of the container which executes the actual bean. The just described behaviour is described in detail in Chapter 10 - Enterprise JavaBeans Specification (version 2.1).
MDB - Message-driven Bean Component Contract, which allows an enterprise bean to be invoked asynchronously to handle the processing of some sort of incoming messages. Basicly as of version 2.1 of the Enterprise JavaBeans Specification, Message-driven Beans are able to handle any type of asynchronous messages. That means not only JMS messages will be supported but also for example HTTP protocol based requests. Although the Enterprise Bean Provider doesn't need to care about the actual implementation of the Message-driven Bean container, he just needs to send some sort of a message to a message-driven bean - which will be consumed accordingly by some business logic running on the server. Why Message-driven Beans might be usefull on a mobile device is described in section The Enterprise JavaBeans Specification, v2.1.
Web Service EP - Web Service Endpoint, which allowes an Enterprise Bean Provider to expose the application logic of an stateless session bean as a Web Service Endpoint. Accessing an Enterprise Bean asynchronously by some sort of a platform-independent protocol was one requirement for PersonalChilli to be used within dtF/AF. The Web Service Endpoint for example, allows a dtF/AF application to access the application logic of the PersonalChilli container by using protocols like XML-RPC, without even knowing the actuall implementation of the application logic. Since version 2.1 of the The Enterprise JavaBeans Specification, v2.1, asynchronous XML-RPC messages could also be handled, but implementing a XML-RPC server using Message-driven Beans seems to be somehow redundant, because there are already independent Web Service solutions available. Additionally companies like Sun® don't seem to undertake such an effort.

In addition to a pure EJB runtime environment, PersonalChilli has a Transaction Coordinator and Transaction Manager attached, which will both control the proper execution of distributed transactions. Currently transactions will be covered by a different research work, done by Ulmer [[ulmer, 2003]].

Figure 2.7. Overview of the iChilli™ Application Repository Server

As described previously, the iChilli™ system needs to be able to manage different mobile applications and different versions of the same mobile application. This requires the iChilli™ system to register each mobile application and its corresponding version while it is getting rolled out onto a mobile client device. Because of having registered every rolled out application and its corresponding version, it would be possible to manage those applications and update them to a newer version as necessary. Additionally it would be possible to generate some specific statistics about cuurently rolled out mobile applications by querying the database that holds the data of installed mobile applications.

The described mobile application management behaviours are subject to the ChilliRepository server, which allows to register and query rolled out applications using a UDDI based server. Additonally the ChilliRepository server provides a mechanism to provide OTA provisioning^[5] of mobile applications.

UDDI and its relation to the iChilli™ system will be described in section Universal, Description, Discovery, and Integration (UDDI), the way how mobile applications could be provisioned onto mobile devices is described in section Application Deployment.

What is dtF/AF?

This section gives an overview about the dtF/AF framework, currently developed by the company sLAB. Additionally this section gives a brief understanding about how dtF/AF differs from iChilli™ and how it would be possible to leverage some specific iChilli™ system components.

Figure 2.8. Overview of the dtF/AF system architecture

dtF/AF is an application framework for mobile environments, which is nearly convergent to iChilli™. Although dtF/AF differs regarding the implementation of some importing system components. Those components that couldn't be found in the iChilli™ section will be described in this section. Components that are nearly identical, will be mentioned but not described any further.

Basicly dtF/AF is devided into two different subsystems - a server subsystem and a mobile client subsystem, just like iChilli™.

Applications on the mobile client will be executed as so-called Mobile Data Objects. Those Mobile Data Objects are supposed to be implemented as Enterprise Java™ Beans. Thus it could be assumed that the mobile device runs a container system that represents a lightweight EJB container, optimized for mobile devices. Additionally to an EJB runtime environment, the mobile dtF/AF subsystem also provides a transaction logging system that logs every transaction during runtime. Those logged transactions will be needed to synchronize the application state of the mobile client with that of a dtF/AF server. Additionally to just providing a mobile runtime system that allows someone to execute application logic, dtF/AF also provides a Generative GUI Framework that is required to provide generic user interfaces that are optimized for small sized displays of mobile devices. Both the transaction logging system and the generative GUI framework that reside on the mobile device will be described later on.

The server of the dtF/AF system in turn consists of two differnt types of server systems - one subsystem that is solely meant to execute tarnsaction logs that were previously recorded on the mobile device and a Conflict Resolution Engine that is need to resolve prossible conflicts that might occure during executing of recorded transaction logs, the second subsystem is required to provide an execution environment for some kind of business logic. The latter (second) subsystem is supposed to be J2EE compliant. The first server subsystem that executes recorded transaction logs and resolves possible conflicts will be described later on.

The following code snippet illustrates how the dtF/AF Generative GUI Framework composes user interfaces out of plain XML files. This XML file only describes the visual Look & Feel of a user interface, the actual data is contained within another XML file which will be accessed by reference from within the XML file shown below.

  1| <DIALOGVIEW ID="AddrDialog" Layout="Border"> 
  2|  <VIEWINFO Lang="en" Titel="Main Dialog"
  3|          Description="A Test Dialog"/>
  4|  <GROUPVIEW ID="Content" Layout="Grid"
  5|            ModelRef="sp1:selection"> 
  6|      <BORDERLAYOUTINFO ID="Layout_Comp" Pos="Center"/>
  7|      <TEXTVIEW ID="sp1:Name"> 
  8|          <VIEWINFO Lang="en" Title="Name"
  9|                    Description="Address Name"/>
 10|          <GRIDLAYOUTINFO ID="Layout_Label" x="0" y="0"
 11|                     width="1" height="1"/>
 12|          <GRIDLAYOUTINFO ID="Layout_Comp" x="0" y="0"
 13|                     width="1" height="1"/>
 14|      </TEXTVIEW>
 15|      <TEXTVIEW ID="sp1:Street"> 
 16|          <VIEWINFO Lang="en" Title="Street"
 17|                    Description="Street Name"/>
 18|          <GRIDLAYOUTINFO ID="Layout_Label" x="0" y="0"
 19|                    width="1" height="1"/>
 20|          <GRIDLAYOUTINFO ID="Layout_Comp" x="0" y="0"
 21|                    width="1" height="1"/>
 22|      </TEXTVIEW>
 23|      <TEXTVIEW ID="sp1:Town"> 
 24|          <VIEWINFO Lang="en" Title="Town"
 25|                    Description="Town Name"/>
 26|          <GRIDLAYOUTINFO ID="Layout_Label" x="0" y="0"
 27|                    width="1" height="1"/>
 28|          <GRIDLAYOUTINFO ID="Layout_Comp" x="0" y="0"
 29|                    width="1" height="1"/>
 30|      </TEXTVIEW>
 31|  </GROUPVIEW>
 32| </DIALOGVIEW>
 33|

Explanation

	Defines an application window (e.g. a visual application dialog).
	Defines an usually invisible group that serves as a container element for other elements. A model that will be attached to this group will be also referenced by this element.
	Defines a textfield for a address name.
	Defines a textfield for a street name.
	Defines a textfield for a town name.

The resulting (Swing) dialog is illustrated in the following figure.

Figure 2.9. An Example of a Generated User Interface using dtF/AF.

At the moment the dtF/AF framework is able to generate the following user interface types.

AWT
Swing
LCD UI (MIDP)

Because it is very easy to implement new view types for different user interfaces, the dtF/AF generative GUI framework is also situable for the following types of GUI APIs.

SWT
WAP/HTML
Thinlets
LwVCL

The idea in dtF/AF of logging every transaction at the site of the mobile client is heavily influnced by an IBM research paper called Gold Rush: Mobile Transaction Middleware with Java-Object Replication [[butrico, chang, cocchi, shea and smith, 1997]], which in turn borrows most ideas from the CODA distributed filesystem. Both CODA and dtF/AF have some commonness allways found in mobile computing environments. The following figure illustrates the elements that are common to mobile computing environments if they aim to provide autarky to the mobile device.

Figure 2.10. Venus States and Transitions

According to Kistler's Ph.D. thesis [[kistler, 1993]] Venus is the Cache Manager that runs at the mobile Coda client site. At a basic level Venus can be compared with the Synchronization Manager and the Transaction Manager that are running on the mobile dtF/AF client. Although Coda clients are not designed for small footprint clients like a PocketPC - they rather could be found on laptops.

During Hoarding state, Venus is collecting usefull data in the anticipation of disconnection. Basicly while oparating in on-line mode, dtF/AF is also collecting and interchanging data with various server peers. After getting disconnected, Venus operates in Emulation mode. While remaining in this mode Venus acts as a so-called pseudo server, but most importantly Venus records sufficient information to replay update activity when it reintegrates into a network. Actually every log entry goes into a replay log. Having just described the Emulation mode, it should have become clear that dtF/AF acts in a much similar way. Business logic gets executed using a local server and every action gets logged into a transaction log to be replayed after getting reintegrated. While reaching the Reintegration state the Coda client remains in a transitory state. During Reintegration Venus propagates changes made during Emulation, and updates its chache to reflect current server state. While replaying the recorded logs during Emulation state, the Coda system is able to resolve several conflicts that may occure during a replay cycle. The final Reintegration state will be also covered by the dtF/AF system. Possible conflicts could be detected and resolved using the dtF/AF Conflict Manager.

The main focus of this section was to become familiar with the dtF/AF system and its basic concept. It should have also become clear that dtF/AF adapts several already existing distributed computing strategies to be situable for mobile computing.

dtF/AF Enhancements

At the time the dtF/AF system doesn't provide neither a client server system that is able to execute application logic nor a server system that is able to execute some sort of application logic. Additionally dtF/AF isn't able to execute EJBs at all. So just having mentioned these boundary conditions, it seems feasible that dtF/AF could borrow system components from iChilli™. Especially the PersonalChilli system component that in fact is a lean EJB container could be used within the dtF/AF mobile client. Finally providing a mobile EJB container due to leveraging the PersonalChilli server was one reason for getting support for this diploma thesis by the company sLAB. Additionally sLAB had a reasonable interest in collecting research knowledge on how it would be possible to run server components on mid to small sized mobile devices.

User Characteristics

During this diploma thesis we will distinguish between normal users and users who administer the iChilli™ system. While a standard user will be considered to just interact with a running application, a user that got administrative rights is supposed to know iChilli™ system internals, which he needs to operate and administer the system. Additionally all user roles described in the J2EE Platform Specification, the Enterprise JavaBeans Specification and the J2EE Client Provisioning Specification are appropriate. The previously made user distinctions might become apparent on some functionalities of the resulting iChilli™ prototype.

General Considerations

Since this project is carried out inside the framework of a diploma thesis, the main goal is only to fulfill all the must-have requirements and not specifically to integrate as many of the optional features as possible. However, some of those will still be considered achievable. The software as well as the coding- and documentation language to be used will be (American) English.

Assumptions and Dependencies

Since this project will be developed around the existing dtF/AF system, the programming language and environment to be used will be J2SE and J2ME, respectively. Since Java can generally be used in a platform-independent way, the extension to the existing dtF/AF system (the subject of this project) is not allowed to use platform specific features.

2