Data model

We abstract the data model from the application programming framework and provide some mechanisms to let it use both on the client side and the server side. Due to the limited memory size on the mobile devices, we cannot store all the data information on the client side.

The programmer should write some meta-data to point out which field must be stored on the client side. Therefore the data information can be invoked at local storage.

by us) which could be used both in the server components and client components. It let the providers have the common interface to use while retrieving the information. We cannot say for certain that we had totally brought up a complete solution in adopting data model on the client side, because we have not provided the synchronous mechanism from client to server.

But our design, separating out the data model, let the applications retrieve the data and store on the client’s storage. So users can still retrieve the information on the client side when network crashes. It is convenient and common using for the mobile applications.

Chapter 4 System Architecture

In order to automatically port the server side’s applications to the client side’s mobile applications and decrease the effort spent by the application providers, we design a system to attain our objectives.

The whole system architecture is shown as Figure 4-1. There are the three models classified from the abstract view of the programs at the above of the figure. The middle part is the components we provided for attaining our objectives. The middle left side of the figure is the file named “API Mapping Rules”, written in IM²L, which we talked about in section 3.2 and 3.3. And the below parts in the figure are the programs corresponding to the client and server visions. In the following sections, we will orderly introduce what components and mechanisms required in our system when they are operating.

Figure 4 – 1 System architecture

4.1 Interface Mapping Markup Language ( IM

L )

L

IM² is a XML-based language and its objective is to transform the APIs more generally. We use it to describe the rules about API mappings between different developing platforms. This language is defined by us (ART providers) and we consult the difference between different developing platforms in using the APIs and record the API mapping rules in order to transform the programs through diverse platforms. About the example of using the

L

IM² will be discussed further in section 4.2 and 4.3.

The merits of writing the API mappings through IM²L are as the following:

z It matches XML format so it have many available tools that can trace out the rules of mappings.

z It can be used in both Logic model and UI model.

z It can record many kinds of API mappings among different developing platforms.

z It is easy to modify while API revision is occurred. We can directly modify the API mapping rules when there is some change provided by one platform without rewriting a new code generator or altering the old one.

z It can be expanded easily. When one platform has new APIs, we just need to add the new mapping rules into our recorded file. Then our mapping scope will be expanded.

The file which named “API Mapping Rules”, mentioned in Figure 4-1, is written in L

IM² , and it is constructed by many of the API mapping rules. Figure 4-2 explains the concept of what the “API Mapping Rules” is. At the Figure 4-2, we can see that there is a source API which can be mapped to other APIs on different target platforms; this whole small

sketch is called an API mapping rules. The “API Mapping Rules” is the biggest graph at this figure, and it contains some API mapping rules in it.

Figure 4 – 2 drawing of API mapping rules

4.2 UI Model Transformation

In order to make User Interface, written by XUL, be shown on different kinds of developing platforms supported on the handheld devices, we use IM²L to define the transformations of API mappings.

XUL ART-UI MIDP WML

<window> Form Form <wml>+<card>

<canvas> Canvas Canvas <wml>+<card>+4 direction button+<img src=”…”>

<listbox> ChoiceGroup ChoiceGroup <select>

<button> Buttom Buttom <a href>

<textbox> TextField TextField <input>

Table 4-1

The capability of IM²L in User Interface is to record the API mapping rules of widgets which used in the XUL file and the API mapping rules will describe the usages of APIs on different developing platforms. For example, when we want to add a field of input a bunch of words to the display window on the client side, we have to write in different ways for different developing platforms, as Table 4-1.

In the original design, ART providers have to write different kinds of code generator in accordance with every developing platform. These code generators read the XUL file, and sequentially transform each widget in the file. There are some problems in this design:

z It is not easy to maintain the code generators.

The original way is to write the mapping rules in the code generator when there has any necessary transformations between source developing platform and target one. Besides, we have to write a specific generator corresponding to each developing platform. As mentioned above, if we want to modify the statement of transforming the widget, we should trace the programming codes of the code generator and find out the old mapping rules within it for the purpose of substituting the new API for the old one.

z We have to modify each code generator when a new mapping rule appears.

When we provide a new widget for UI designer’s usage, we must modify every generator in each kind of platform in order to update the new way of transforming the widget.

As a result, if we adopt IM²L to trace out the mapping rules, we can overcome the two problems mentioned above more flexibly. This set of mapping rules is provided by ART Framework. For program developer on ART, it needn’t take extra effort to understand the content of the document. Figure 4-3 shows a simple example how IM²L is used when

describing the mapping rules between different developing platform targeting at the specific UI widget. The elements used in Figure 4-3 are introduced as the following:

z InterfaceMapping

The element defines a set of widgets’ API mapping rules on each platform. The detailed mapping rules are illustrated in this section enclosed by the InterfaceMapping element.

z method

Here, we use method to represent each widget’s name defined in XUL. Our code generator will generate a concrete file of UI model according to the methods used in the XUL files designed by UI designers.

z params

params is an element of a nest shape. It contains lots of argument settings marked by params in its nest shape. It represents the arguments that the widget needs to set itself within the API usage.

z platform

We use this element to record transformation rules about the API usages among different developing platforms. There are two sets of platform elements, we have supported now, in Figure 4-3: wml and j2me. The value in the element is the record about how the API is used at the specific widget and the specific developing platform. We will process the API transformation according to the API usage record in this element.

<InterfaceMapping>

@@id1@@ = new TextField("@@label1@@", null, 30, TextField.ANY);

</platform>

</InterfaceMapping>

Figure 4 – 3 example of mapping rules in UI model

Thus, we know that using IM²L to describe API transformations can attain our objectives flexibly. The textbox in Figure 4-3 defines a widget in the XUL. We survey the APIs used for displaying the widget on different developing platforms, and record them in the element value of platforms. By setting some required parameters in the APIs, we can get the complete usage of APIs on all sorts of developing platforms. Then we can port the programming codes to different developing platform without any effort.

4.3 Logic Model Transformation

The architecture of implementing the transformation in logic model is shown as Figure 4-4; it includes two components developing by JavaCC and JDOM [11], which both are the available techniques written in Java. These two components will read the original programming codes, indicates “Program logical codes (server)” at the top left of the figure, run on the ART server and the API mapping rules, indicates “API mapping rules” at the top right, written in IM²L; after read these two files, “Code Generator”, marked in the middle, will use the “Transformer” to compare the statements with the mapping rules and to transform

the matched statements into the target statements. Finally, we will get the “Program logical codes (client)” which composed by the target statements and it can be executed on the client side.

Figure 4 – 4 architecture of code generator in logic model

The two available techniques, JavaCC and JDOM, we used in the logic model shall be examining how we exploited them to fulfill our requirement in the continuing paragraph.

We use JavaCC to generate a Java parser which can help us checking the programming blocks and the APIs’ name using in the applications. The Java parser contains many Java language grammars written in regular expressions. We can make use of it to build a parsing tree and note down the interested information into a temporary file. Such as the statements in the programming block and the APIs’ name and parameters used in the original application programming codes are inscribed in the temporary file. Then, the main component doing the compared and transformed task can easily get the marshaled information and have the better performance.

JDOM is a new API which can let programmers handle the XML documents as Java objects. It also improves the performance in accordance with Java. So, JDOM can handle a XML document as we with just like DOM and have the well performance as SAX. We use JDOM to trace out the mapping rules recorded in the API mapping rules written in IM²L. By using the mapping rules, we can find the corresponding APIs within the target developing platform and forward the information to the Code Generator which is responsible to the comparison.

L

IM² in the aspect of using in logic model is mainly in describing how the APIs, which is run in the application on the ART server, should be transformed into the APIs which can be run upon the runtime environments on the client side. As we mentioned in the section 3.3, the mobile applications run on the client side and the server side are both written in Java, so we do not need to modify the syntaxes and the semantics of the statements during transformations.

What we should do to port the program logical codes into different platforms is tracing out the APIs among the statements and transforming these to the target platforms according to the mapping rules written in IM²L. Figure 4-5 is an example for describing the API mapping rules written in IM²L using in the logic model. The explanations of what the elements do are as follows:

z InterfaceMapping

The element defines a set of API mapping rules within various developing platforms. The detailed mapping rules are illustrated in this section enclosed by the InterfaceMapping element.

z class

It records what class the API belongs to. In the Object-Oriented programming language, it is a common usage to specify the references of the APIs.

z method

The value of this element specifies the method’s name of the API. We will use the value of method and params, which will be talked later, to construct the mapping rules.

z progBlock

progBlock is abbreviate from the programming block. The value of this element can be “startApp”, “stopApp”, “listener” and “all” which is the default value. The functionality of using it is to promote the performance of the API transformations. The reason is that some APIs can just be used in some programming block or just be called during the life state of the applications in MIDP, so we do not have to compare these APIs in other programming blocks. This mechanism of adopting this element can make the performance well.

z params

params is an element of a nest shape. It can have lots of argument settings marked by parameters within. And it represents the argument that the API needs to set in itself.

z platform

This element is used in recording the API transformation rules corresponding to different developing platforms. There are two sets of platform elements in Figure 4-5 and it means that we support the API transformations between these two developing platforms. The first one in the name attribute of the platform is j2se and it records the usage of the specified API run on the j2se platform in its element value. Second is j2me and it also records the usage of the corresponding API in the j2me developing platform. By adding element of platform directly, we can easily extend our API transformations to a new developing platform, such as PJava [15].

<InterfaceMapping>

Figure 4 – 5 example of mapping rules in logic model

In the transformation of logical programming codes, we had defined the mapping rules from the APIs provided in ART to the APIs provided in MIDP completely. The mapping rule shown in Figure 4-5 describes the API usage of displaying a window on the ART platform can be transformed to the API of setting a window to the displayable object in the MIDP. Because we can only display a window on the monitor of handheld devices, we should select a suitable API to attain the same purpose on the client side. Here, we choose the API named setCurrent in MIDP and pick up a Displayable object as the parameter. In other mapping rules, we can also ensure that they will work well after transformed to the APIs run on the client side.

4.4 Data Model Design

In the implementation of data model, we provide two aspects of development tools. First, we provide some database API which can be used during application programming period both suitable on the server side and client side. Secondly, we define the data model schema used to specify what fields are the necessary data and should be provided on the client side during application executed. We shall now look more carefully into our consideration of the

design issue in data model.

4.4.1 Database API

A J2SE application typically stores state in local files that are easily and quickly accessible from the hard driver or transparently accessible over a fast local area network. The Mobile Information Device Profile provides a mechanism for MIDlets to persistently store data and later retrieve it. This persistent storage mechanism is modeled after a simple record oriented database and is called the “RMS” which is the abbreviation of “Record Management System”. These two runtime environments present the difference of using APIs between server side and client side. So on the server side, J2SE provides an API package named java.sql for accessing and processing data stored in a data source (usually a relational

database) using the Java^TM programming language. On the client side, the Mobile Information Device Profile provides an API package named javax.microedition.rms for MIDlets to persistently store data and later retrieve it.

In our way of solving different APIs between the server side and client side in the logic model and UI model mentioned above, we designed an IM²L to note down the mapping rules corresponding to different developing platforms. But because of the congenital usage of database APIs between J2SE and MIDP, the mechanism we adopted previously cannot work very well in the data model. So we try to design some APIs followed the javax.microedition.rms provided on MIDP as a model, shown as Table 4-2:

boolean addRecord (byte[] data)

boolean connectDB (String driver, String url, String dbname, String passwd)

boolean deleteRecord (int recordID)

int getRecordID (Object primaryKey)

byte[] queryRecords (Object primaryKey) boolean recordExist (Object primaryKey)

Table 4-2

We provide the common interface for the programmers to retrieve information both in the server-side and client-side applications. In the bottom layer, we still use the APIs supplied by the Java Community Process^SM respectively to implement our database APIs. We have adequate reasons of thinking that providing a common interface is a good way in the performance of transforming applications between various developing platforms because the job of transforming APIs is needless. In addition to this, the APIs are very simple and also convenient for the application providers to use.

4.4.2 Data Model Schema

We devise a data model schema of specifying which column of data should be shifted to the client side. So we ask the application providers to write a data model file which should follow our schema. Figure 4-6 is an example for describing the details of the columns using in the data model. The explanations of what the elements do are as follows:

<artdb>

<table ref="AddressBook">

<field ref="Name" />

</table>

</toRMS>

</artdb>

Figure 4 – 6 example of building a data model

z artdb

The element is the root of our data model. We will use the information inside to specify which column is essential and should be shifted into the storage on the client side.

z dbschema

This element can demonstrate how many tables are used in this data model. We can take advantage of the element’s value to build a database using Structured Query Language (SQL) [16].

z table

It manifests the table’s information inside. There is no standard database schema in W3C and still many groups devoted themselves to define a welcome schema. In order to simplify our data model, we define our database schema and take down below the table element. It can be changed into the standard one easily

z primarykey

We use this element to assign which field is the primary key of this table.

z field

This element is used to clearly show the columns in the table. The “name” and

“type” attributes are defined as #REQUIRED, so we cannot miss it. The attributes we defined to describe the field are not very completely corresponding to the relational database nowadays. For example, data length, allow nulls, default value, precision, scale and so forth, are the additional attributes provided by Microsoft SQL server. We simplify the designation and trace out the attributes which is necessary for building up the data model on both client and server side.

z toRMS

The element specifies which field is essential and should be transferred to the Record Management System on the client side. We use the type of “IDREF” at the

The element specifies which field is essential and should be transferred to the Record Management System on the client side. We use the type of “IDREF” at the