HICSS'01: A Component-Based Architecture for the Development and ...

Proceedings of the 34th Hawaii International Conference on System Sciences - 2001

A Component-Based Architecture for the Development and Deployment of WAP-Compliant Transactional Services Mario Cannataro ISI-CNR, Via P. Bucci 41/c 87030 Rende, Italy [email protected]

Domenico Pascuzzi University of Calabria, Via P. Bucci 41/c 87030 Rende, Italy [email protected]

Tel: +39-0984-839047, Fax: +39-0984-839054

Tel: +39-0984-839047, Fax: +39-0984-839054

Abstract The Wireless Application Protocol (WAP) is an open, global specification that empowers mobile users with wireless devices (such as mobile phones) to easily access and interact with information and services on the Internet. Although some components of the WAP suite have been developed, it lacks a complete general architecture integrating software components of both the Internet and wireless contexts in a transparent way. This paper presents a general architectural framework to develop and deploy portable applications and services accessible by WAP-compliant mobile terminals, extending end-to-end services between terminal and business applications. Different implementation strategies for the application logic, allowing either fast prototyping or the realisation of robust portable complex applications and transactional services, are presented. Moreover, a technique to handle terminal disconnection is presented.

1. Introduction The Internet and cellular communications represent the more significant technological steps towards the globalisation of human activities, with significant impact on social behaviour. The present trend is defining and building converging mechanisms between Internet and wireless networks able to allow for the transparent access to web contents and applications using wireless terminals. Value Added Mobile Services (VAMS) [1] present more competitive characteristics in comparison to fixednetwork services, such as: • Mobile access; • Time and location-independent service access (anytime, anywhere); • Different possibilities to reach the user (asynchronous, synchronous);

• •

Different possibilities to access data (push, pull); Location-dependent services deployment, on the basis of user location. However, applications designed for the fixed network (wired) are not suitable to operate in mobile (wireless) systems, which are constrained by lower throughput, higher bit error rate and restricted terminal capabilities. New architectural designs and system platforms are necessary to cope with these problems and to facilitate the integration between the wired and wireless world. The Wireless Application Protocol (WAP) [2], an emerging standard for the deployment of data oriented applications for wireless networks, specifies an end-to-end communication protocol between a mobile terminal and a WAP gateway, a component that interfaces the wireless and the fixed networks (e.g. GSM and Internet). Although some components of the WAP suite have been developed, it lacks a complete general architecture integrating in a transparent way software components of both Internet and wireless domains. This paper presents a general architectural framework to develop and deploy applications accessible by WAPcompliant mobile terminals. It extends end-to-end services between terminal and business applications to allow the development of transactional services. Different implementation strategies for the application layer, allowing either fast prototyping, or the realisation of robust and portable applications and transactional services, are presented. In particular, the componentbased implementation of the application layer supports features such as portability, robustness and easy maintenance. Whereas a light-weight implementation of the same layer, based on the use of server-side scripting techniques, allows fast prototyping or the cost-effective implementation of simple WAP-compliant applications where time-to-market and costs are the primary requirements. The architecture employs a technique to handle client disconnection: it attempts to recover a consistent state

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

1

Proceedings of the 34th Hawaii International Conference on System Sciences - 2001

after a terminal disconnection and subsequent reconnection, reducing the number of communication between the terminal and the network, that is an important requirement of wireless communications. The rest of the paper is organised as follows. In Section 2, we present basic components of the WAP platform. In Section 3, we describe the classical approach to develop and deploy WAP applications and some design issues. In Section 4, we present a general architecture for the development of robust and reusable WAP applications, integrating WAP and Internet components. In Section 5, we detail the architecture implementation, based on a real prototype of the system, and we present two different design approaches. Section 6 contains conclusions.

•

2. The Wireless Application Protocol

3. Design choices for the development of WAP-compliant applications

The most promising technological platform to deploy advanced services over wireless terminals is the Wireless Application Protocol. This Section introduces WAP in general terms, and explains the role of the WAP-gateway in the overall platform outlining its duties and features. The WAP specifies an end-to-end communication protocol between a mobile terminal (client-side) and a WAP gateway (network-side), to allow access to Internet/Intranet contents from wireless networks [2]. WAP lets the phone act as a simple web browser, but optimises the mark-up language, scripting language (client-side), and the transmission protocols for wireless networks and terminals. Basic components of the WAP framework are: • a µ-browser hosted by the mobile terminal (WML user-agent); • a WAP gateway allowing the interworking operations between the wireless network and others kinds of data networks (e.g. TCP/IP networks); • a layered stack of (WAP) protocols specifically designed for wireless environments (see figure 3). Moreover, a highly interoperable application environment (Wireless Application Environment, WAE) is provided [2]. WAE defines an XML-compliant markup language named WML (Wireless Mark-up Language) [3], and the associated client-side scripting language WMLScript [4]. The µ-browser is a simplified web browser executed on a terminal able to display WML contents and to execute WMLScript code, which communicates with the WAP gateway using the Wireless Application Protocol, on different wireless transports. Interworking operations between GSM and TCP/IP (e.g. Internet) networks, are:

protocol conversion between the WAP layers (WSP, WTP, WTLS, WDP) and the WWW layers (HTTP + TCP/IP). • format conversion – i.e. the on-the-fly, dynamic translation of contents from HTML to WML (HTML transcoder module). The communication between the gateway and the mobile terminal (see Section 5.2) occurs through the following software modules: • Encoder – that encodes data using a particular compression technique to minimise the number and dimension of packets transmitted via the radio interface. • Decoder – that carries out the inverse decoding operation.

Classical approach in developing WAP-compliant applications comprises the following choices: • localisation of the application; • content format and content generation (static or dynamic); • access to pre-existing (legacy) applications. A WAP application may be localised either on the WAP gateway, or on the Application Server (i.e. a computer hosting the application logic and an HTTP server). In the first case, the WAP gateway acts as an Application Server: it realises the encoding/decoding functions and hosts the static and dynamic WML contents of the application. In the second case, the WAP gateway behaves as an HTTP proxy, which issues HTTP requests to fetch content from the Application Server on behalf of the µ-browser. Apart from the encoding/decoding operations, it realises protocol conversion (HTTP - WAP): requests from the µbrowser are translated into HTTP requests, and the results are compiled and transmitted back to the mobile phone. Application logic is accessed by a standard HTTP server, running on a host eventually connected to the Internet. The application content and output can be coded in HTML or WML: Table 1 shows possible content formats and their pros and cons. Table 1. Content formats for WAP applications Format Full HTML Reduced HTML WML

Pros Cons Unique content version Heavy conversion process; complex output for WAP browsers Good conversion Poor output for HTML process, performance browsers Best performance (no Content duplication conversion) (HTML, WML) mgmt

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

2

Proceedings of the 34th Hawaii International Conference on System Sciences - 2001

Using full HTML requires a complex HTML to WML conversion process, which could produce not suitable results. The advantage of this approach is maintaining a unique version of the web site for both web browser and µ-browser. Using a light version of HTML (i.e. optimised for the WML conversion) the conversion process is easy to implement; but unattractive graphical effects are frequent on traditional web browsers. Coding contents using WML gives better results on the µ-browser, but this requires the maintaining of two versions of the web site. A more flexible solution, which is adopted by our system, is to provide dynamic code generation (HTML or WML) with respect to the kind of client (WAP or HTML browser). Very often to access pre-existing (legacy) applications it is not sufficient to on-the-fly convert their output in WML. In fact the results could not be suitable for wireless terminals (e.g. very long output), nor a context-free filtering could be acceptable. A possible solution is to provide an application-dependent conversion layer within the architecture.

4. A layered architecture for WAP-compliant applications The main goal of our architecture is to extend basic functions of the WAP framework with more sophisticated services, such as support for transactions and state maintenance after a client disconnection. The proposed four-tier architecture (figure 1) integrates standard components of WAP and WWW domains and allows to realise the following aims: • end-to-end communication between mobile terminal (µ-browser) and application server (i.e. business logic); • remote access to databases; • support for transactions, integrating transactional services offered by DBMS; • optimised management of terminal disconnection. User layer (Client)

Network layer

Terminal

WAP Gateway

Browser

Application layer

Application Server

Protocol Conversion

WML

WAP WMLScript WTAI

Encoder/Decoder

Wireless (GSM) side

Data Server Stored

HTTP Content Conversion

Data layer

Business Logic

TCP/IP

Static Contents

Procedure

Content

Wired (Internet) side

Figure 1. WAP – Web integrated architecture.

The four layers are: User layer, i.e. a wireless terminal with a WML µbrowser. • Network layer, represented by the WAP gateway, which acts as an HTTP proxy. • Application layer composed by the Application Server implementing the business logic. • Data layer, composed by the DBMS servers and the hosted databases. The Data layer can also integrate different sources of data, such as legacy applications and semi-structured data (HTML, XML). The communication interfaces between adjacent levels are shown in Table 2. Table 2 – Interfaces between layers Interface Protocol Domain User - Network WAP Wireless network (GSM)

•

Network - Application HTTP Fixed network (Internet) Application - Data

TCP/IP

Fixed network (LAN)

In our design, the WAP gateway operates as proxy whereas the Application Server is executed on a different host. This design choice allows: • to separate the WAP-based connectivity operations by the application implementation; • to implement the Application Server using open standard technologies, such as the Enterprise JavaBeans component-based framework, that to date are not supported by commercial WAP gateways; • to provide an open and portable solution based on the use of standard APIs.

4.1. The management of terminal disconnection Initially designed to distribute information (hypertexts), the World Wide Web is evolving towards a middleware platform for the deployment of distributed transactional applications. The web interaction model does not deal with the user-session concept: logically related user interactions conducted using HTTP are not managed in an atomic way (e.g. selecting goods and purchasing them). This is due to the stateless nature of HTTP. To implement transactional (state-aware) applications we need to deal with the following concepts: • Session – a context in which client-server HTTP communications take place. • Application state – a set of information (within a session) shared by a client and the application server (e.g. the basket of a user in an e-commerce application, a service to be subscribed, etc.) In summary, the Session is an abstraction in order to provide logic continuity of the pairs HTTP_request-

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

3

Proceedings of the 34th Hawaii International Conference on System Sciences - 2001

HTTP_response and the Application state is a set of variables (state variables) that have to be made available to both client and server. Classical techniques used to manage sessions (Cookies, HTML Forms, URL rewriting, Java Servlet Session tracking) have a common limit: the mechanism to maintain a session is valid while the connection is alive. If a connection is interrupted because of network errors or client crashes, the session is invalidated and the state information is no longer addressable: the user must reconnect and resubmit previous requests. In a wired environment this does not cause serious problems, whereas in a wireless environment, where communications are less reliable and disconnections are more frequent, repeating an operation after a disconnection can be costly and unproductive. The model presented in the rest of the Section attempts to extend the lifetime of a client session to cope with disconnections, reducing repetition of user requests after reconnection. The mechanism for state maintenance against disconnections is based on a Static Session Identifier (SSI) used to identify a client and its current session. The Application Server uses SSI to address a workspace (primary or secondary storage) containing state variables. SSI has the following features: • uniqueness – it identifies a client in a not ambiguous manner; • temporal invariance – it does not change across subsequent HTTP transactions; • temporal validity – it also remains valid through disconnections. The proposed session and disconnection management mechanism is implemented within the Application Layer and comprises the following components: • an auxiliary database used to store information about sessions and state of the application (state variables); • a Session Manager (SM) process (e.g. a Java servlet) used to manage sessions and disconnections. The auxiliary database essentially comprises the following tables: Session and State. The Session table (SESSION) keeps track of user sessions, whereas the State table (STATE) stores state variables, related to a specific user session, according to the format . The removal of a session causes the cascading elimination of all the state information related to it. State and session information survive network and server crashes or shutdowns. The Session Manager process is independent of the application and offers a set of session/state management services accessible by APIs or class methods. Table 3 summarises Session Manager’s APIs to be invoked from application code in order to use SM services.

Table 3: Session Manager primitives Service Primitive Meaning NEW Creation of a new session GET, PUT Storing / Loading of state parameters BIND Binding of a session to a client CLOSE Removal of a session The basic function of the SM is to provide session management and state maintenance of an application. It manages lifecycle of a user session implementing the finite state automata shown in figure 2. To each arc is associated an event that determines state transition and the consequent action performed by SM. Lifecycle management is based on the use of two timers (Timer1, Timer2) with associated timeout (Timeout1, Timeout2). New

Operation

Close Destroy

ACTIVE

Reconnection && !Resume

Reconnection && Resume

Destroy

Recovery

Timeout1

Reconnection

Suspend

Notify removal

Timeout2 SUSPENDED

REMOVED Destroy

Figure 2: Session state transition diagram. After the authentication procedure, application asks the creation of a new (ACTIVE) session. During the connection, the user makes a sequence of operations during which SM stores (PUT primitive) and, in case of need, retrieves (GET primitive) state information from STATE table (normal mode operation), as specified by the application developer. When a user decides to terminate a session, application explicitly asks SM to remove all state information associated to the current session through the CLOSE service primitive: session state is now REMOVED. Let us define “event of disconnection” an event that causes an irreversible interruption of communication between mobile terminal and application running on the Application Server. Whenever an “event of disconnection” occurs (it is raised after a given timeout Timeout1 of inactivity), SM suspends the current session, which assumes the SUSPENDED state. The session suspension is transparent to application. Now, SM sets Timer2 and waits for either event: 1. If the user reconnects within the expiration of Timer2 (Timeout2), the Session Manager informs him of the existence of a SUSPENDED session and let him to choice its resuming or destroying. In case of resume, the Session Manager performs a recovery procedure

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

4

Proceedings of the 34th Hawaii International Conference on System Sciences - 2001

(see below); otherwise it releases old session information and creates a new one. In both cases the current session becomes ACTIVE. 2. If the user does not reconnect within Timeout2, the session becomes REMOVED and the SM explicitly removes it. 3. If the user reconnects after Timeout2 SM notifies him about session removal and creates a new ACTIVE session. If an event of disconnection occurred but the user reconnected before Timeout1 (i.e. the SM did not realise that event), the system will behave as in the first step. Services offered by the Session Manager provide a mean to guarantee the continuity of a user-session even in the case of intermittent communication. When a user reconnects to the system after a disconnection the SM starts a recovery procedure that attempts to reconstructs the last card before disconnection. This can require either to access static WML contents or, in the case of dynamic WML data, to re-execute the proper processes (e.g. Java servlets, CGI programs or server-side script programs) maintaining the consistency of data. A detailed description of the Session Manager is beyond the scope of this paper and can be found in [12].

5. Implementation This Section discusses some implementation techniques for the proposed architecture. In particular we attempt to trade-off the typical constraints of wireless environment (terminal and network) that impact the design of business logic and session management, and the main requirements of web-based applications.

5.1. User layer (Client) A WAP-compliant wireless terminal (cellular phone or PDA) represents the User layer. It is generally characterised by the following constraints: • Small, low resolution displays and limited user-input facilities. Displays have few lines of text and low resolution. Terminal lack of mouse and keyboard, thus requiring new User Interface different by typical GUI. Current I/O devices are touch-screen and voicemenu. • Limited computational resources (CPU, RAM), duration and power of batteries. • Many kinds of terminals. Wireless terminals are available in different models (handheld, laptop, communicator, smartphone) and architectures, which can cause interoperability problems. Moreover, the limitation of installed terminal software (e.g. µ-browser) should be considered when designing or

porting pre-existing applications to the wireless environment. The main software components of a WAP-compliant terminal are: • the client-side implementation of the WAP layers in order to accomplish peer-to-peer communication with WAP gateway (see figure 3); • a µ-browser running on top of the WAP stack. As said before, the µ-browser is a simplified web browser able to display WML contents and to execute WMLScript code. WML, a lightweight version of HTML, is an XMLcompliant mark-up language able to face the limited bandwidth of wireless networks and the terminal constraints that could prevent the effective support of HTML. WML defines a new WAP-specific User Interface model that is based on the Card & Deck metaphor. A WML document is a deck composed by a set of cards. A card is a unit of interaction between user and application (e.g. a menu, a form to input data or simply text), whereas a deck is a set of logically related cards and represents the smallest information sent by the Application layer to the terminal. Decks and cards are referred by URLs. Likewise HTML, anchors within an URL allow referring to specific cards within the current deck. WML supports local variables, whose runtime values are stored in a terminal memory location named browser context. These values can be accessed in any point of the WML/WMLScript code. The main advantage in having local variables is the possibility to realise efficient mechanisms to manage and maintain the state of application. In fact, using local variables limits the transmission of session variables between server and terminal reducing network traffic and resulting in better caching. The WML browser is equipped with a bytecode-based virtual machine, so it can also execute compiled scripts on behalf of the application server. Scripts are coded in WMLScript, a scripting language derived from JavaScript and optimised for small-memory and small-CPU devices. However, rather than embedding WMLScript in the WML decks, WML only contains references to WMLScript URLs. Another difference is that the WMLScript source code need to be compiled into the WMLScript bytecode before it can be run on a WAP terminal. WMLScript enhance µ-browser with procedural logic, so it is possible to perform action as field validation (check for formatting, input ranges, syntactical control, etc.) or small conversion operation, thus reducing network round-trips and enhancing functionality. A major limitation of the µ-browser is the difficulty to bring very long WML contents coming from legacy

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

5

Proceedings of the 34th Hawaii International Conference on System Sciences - 2001

applications or from HTML to WML conversion operations. This could be faced emulating frames in WML. To enhance the development of advanced WAP application, our architecture uses: • WMLScript and local variables to reduce traffic; • local variables and URL rewriting technique to allow end-to-end session management between terminal and application.

number, user name and password) of a PPP (Point-toPoint Protocol) connection. The IWF (Interworking function) block implements the gateway interworking functions between the GSM and the fixed network (PSTN). WAP Proxy/Server

Terminal

WAE

Apps on other servers

WAE WSP

5.2. Terminal-Network interface

WTP

Wireless terminals (User layer) communicate with the WAP gateway using WAP on different kind of wireless networks and bearers (low level transport mechanism). The main constraints of wireless networks are the following: • Low bandwidth. Current values range from 0,3 to 10Kbit/s, some order of magnitude lower than wired ones. • High latency. Latency depends by the type of medium being crossed, and by the cell load. • Unsteady connection. Main causes are the blank out period during handover, the limited duration of the battery and exiting from the covered area. • High Transmission Bit Error Rate. Error rates are greater than in wired networks (typical phenomena are fading and interference) and it is more difficult to guarantee Quality of Service. • Low predictable service availability. Wireless networks can suffer short or long periods of inaccessibility, due to congestions or faults. At present, WAP content delivery over GSM network uses various bearers: • CSD (Circuit Switched Data); • SMS (Short Message Service); • GPRS (General Packet Radio Service) and HSCSD (High Speed CSD) in the near future. The type of bearer has to be supported both by the terminal and the gateway in order to accomplish communication. Performances using SMS messaging are very poor, so it should be used only for short browsing requests and in order to receive short contents. Moreover, many commercially available gateways support only CSD connection. The description below discusses details for using a WAP gateway in a circuit switched data (CSD) environment. To allow the connection between terminal and WAP gateway it is necessary to configure the WAP terminal to make a data call into a RAS (Remote Access Server) dialup server (figure 3): i.e. the dial-up properties (phone

WSP

IWF

ISP/RAS

IP

IP

PPP CSD-RF

WTP UDP

UDP

IP

PPP CSD- PSTN RF Circuit

PSTN Subnetwork Circuit

Subnetwork

RAS - Remote Access Server IWF - InterWorking Function

Figure 3. Terminal-Network interface. Over the PPP connection, the terminal will send and receive packets using UDP as (connection-less) transport protocol. It is necessary to configure the IP address of the WAP gateway in mobile terminal. Some devices require configuring a port number, in addition to IP address. For the Motorola phones, 9200 and 9201 respectively are the port numbers for connection-less and connection-oriented services.

5.3. Network layer (WAP Gateway) The WAP Gateway, whose main functions have been presented in Section 2, implements the Network Layer. We used both commercially available software, such as the Nokia WAP gateway [13], and free software, such as the Kannel Open Source WAP gateway [14].

5.4. Network-Application interface Almost all the WAP gateways support HTTP connections that allow to separate the application implementation by the network and terminal details. Using HTTP between the Network and Application layers allows the easy integration of pre-existing webbased applications. On the other hand this could require additional logic to filter or adapt application outputs to WML (e.g. in the case of legacy applications their native access methods could be used instead of HTTP). The support of connection-oriented protocols, such as RMI (Remote Method Invocation) or IIOP (Internet InterObject Protocol), could simplify the implementation of transactional services. Future Application servers for the emerging UMTS services will in fact support CORBA-based interfaces.

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

6

Proceedings of the 34th Hawaii International Conference on System Sciences - 2001

5.5. Application layer (Application Server) The Application Server generally represents the middle-tier of a typical three-layer client/server architecture and hosts application/service business logic. Other than technical aspects, the implementation of the Application layer should also consider some important goals such as: • to reduce the application time-to-market; • to model the application business logic in a costeffective and efficient way, using approaches that can take into account the application complexity, ranging from simple applications showing database contents to complex ones offering transaction-based services; • to enhance the application portability and platform independence (hardware, operating system, middleware, etc.), when this is necessary; • to reduce the development, deployment and maintenance costs. It is clear that all the previous goals would be obtained, but the architecture should be able to trade-off some of them, with respect to some design, implementation and deployment requirements or constraints. An important goal when deploying services to mobile terminals is to support different kind of devices in a transparent way. Ideally, such an architecture should be device transparent: no modification to the mobile device software, and application transparent: no modifications at design time and avoidance of changes to the application code [15]. In order to obtain such goals, the problem of simultaneously generating output in different formats for different devices should be addressed at the Application layer. The characteristics of user terminals and the application logic should be kept separated. In [16] the terminal features, the data format, the transfer protocols are stored as XML documents, and application contents are dynamically rendered on the basis of these information (using XSL style sheets). The Java Border Service Architecture [17] uses a similar approach, but it also takes into account different kind of Graphical User Interfaces, such as push buttons, scrolling bars, text fields, etc. Although our architecture currently supports the generation of WML and HTML code, adding new code to the Application layer can easily extend it. In fact, the content generation is located in a servlet or a script, respectively in the component-based or script-based implementations (see below). The rest of the Section will depict a component-based, portable and reusable Application Server implementation, which main goal is to support the development of complex, long-term, multi-target applications (in terms of

kind of platforms, application providers, users), where portability, easy maintenance and robustness are primary requirements. For simpler applications (or for fast prototyping) where primary requirements are time-to-market, reduced cost and development time, a simplified version of the component-based Application Server implementation is presented. It is mainly based on the use of server-side scripting techniques and easy to implement database access. 5.5.1. Component-based implementation. The Application layer architecture employs a componentbased design, using the Enterprise JavaBeans (EJB) technology to implement and deploy object-oriented distributed applications. EJB is the core of a wider framework, Java 2 Enterprise Edition (J2EE), an advanced platform for the development and the execution of distributed transactional applications [11]. The Java 2 platform supports JDBC compliant drivers through which it is possible to access common DBMS. The EJB Application Programming Model (APM) has the following properties: • Clear separation between business logic and low-level services. The former is implemented by reusable components whereas the latter are offered by the EJB platform (network and data connections, multithreading, transactions, component persistence, distribution, security and life-cycle.). • Server-side reusable objects – the attribute-based declarative programming model offered by EJB allows to dynamically choose the runtime behaviour of a component. • Portability ensured by the Java language (Write Once Run Anywhere). • Support to distributed transactions involving multiple objects executed over different Virtual Machines. The Application Server is designed in a modular way and comprises the following specialised layers (figure 4): • Servlets: they manage the HTTP communication with the WAP gateway, which acts as a proxy for a mobile terminal, and care of the dynamic WML/HTML code generation. • Session beans: they represent a server-side proxy of the client and are used to model the client-application interaction (business rules). A session bean instance is bound to a single client. This layer manages the maintaining of the application state through state-less communications. • Entity beans: they encapsulate the data sources and offer an object-oriented interface to the data model. Each data source of an application (a table or a view on a relational database) is mapped to an entity bean

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

7

Proceedings of the 34th Hawaii International Conference on System Sciences - 2001

independently of client activity. Each column of a table is in relationship with a bean attribute and a table record is a bean instance. Entity beans are transactional-aware components. This layer accesses data via JDBC. In the case of object oriented databases entity beans directly map database objects. Web Container

Session Beans

1

J D B C

Entity Beans WML/HTML generation

According to the architecture proposed in Section 4, Table 4 shows the main steps necessary to develop a WAP application using a particular Application Server implementation.

EJB Container

Servlets

WML HTML Static Contents

as: Personal Home Page (PHP), Microsoft Active Server Pages (ASP), and Java Server Pages (JSP).

2

Session mgmt Data access

3

EJB low level services (HTTP, …)

4 Java Virtual Machine Operating System + supported hardware

5

Figure 4: Component-based Application layer. 5.5.2. Script-based implementation. Using serverside scripting techniques, the application code is directly interpreted by the Application Server modules (figure 5).

WML HTML Static Contents

WML + Script Programs Web Server Extension

A D O

O D B C

J D B C

Data access HTTP Server Operating System + supported hardware

Figure 5: Script-based Application layer. Common scripting techniques are: CGI: (scripts) programs written in different languages (Perl, C++, etc.) are executed by the Application Server operating systems; • Web Server Extension, i.e. a module that is connected to the HTTP server allowing to insert the script code directly in the WML pages. The Web Server Extension module directly interprets script programs when the WML pages are loaded. This approach can use different scripting techniques such •

6 7

Table 4: WAP application development. Component-based AS Script-based AS Data model definition Data model definition (e.g. Data Flows (e.g. Data Flows Diagrams, UML) Diagrams, UML) Discovery and definition Discovery and definition of the business rules of the business rules Mapping of the data Not required, data model using entity beans access embedded in the script programs Mapping of the business Business rules realised rules using session beans via the script programs (PHP, ASP, JSP) Definition of the servlets Not required, for dynamic WML/HTML code is (WML/HTML) code part of the page generation containing the script program Component compilation Not required Application Deployment Not required in the target Application Server

Using the component-based implementation, the developer can concentrate on business logic development (business rules and entities) thus avoiding to repeatedly design the server infrastructure. Implementation duration and complexity are reduced augmenting software quality and reliability. Binary portability of components over different EJB platforms does not require recompilation. Moreover, modular development of components makes it possible to re-use entire application portions. As an example, Entity Beans that map entities such as “Customer Registry”, “Price List”, “Account”, and Session Beans that model activities such as “Credit card validation” and “E-basket” can be easily re-used in different applications. On the other hand, script-based implementation reduces development time and overall costs, and simplifies installation and maintenance of the server software modules. Moreover, it can be used for costeffective fast prototyping.

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

8

Proceedings of the 34th Hawaii International Conference on System Sciences - 2001

5.6. Application-Data interface To access relational databases the Java DataBase Connectivity (JDBC), Open DataBase Connectivity or Active Data Object (ADO) “standards” can be used. JDBC allows an entity bean to connect to a database, to start query/transactions and to obtain results (ResultSet) avoiding DBMS related tricks and details. The connection to a database can be either long-term (it is maintained for the component lifetime) or short-term (it is acquired and released for each data access method invocation). The entity bean methods exporting the database access functions are named database routines. ODBC and ADO allow easy operation and development, so they are used especially with scrip-based server implementation. The Application-Data interface should also support access to different sources of data, such as semi-structured data (text, HTML, XML), datawarehouse or multi-dimensional database, legacy data. Moreover, the navigation of the metadata repository eventually offered by the Data layer should be supported.

5.7. Data layer The Data layer stores and manages the application data. Other than structured object/relational databases, the Data layer can support different data sources, such as: • Data generated by legacy applications that cannot directly be translated in WML format. These data sources could be managed mapping a legacy application as an entity bean or considering it as a particular stored procedure into an hypothetical database. • Data stored in multimedia databases or in multidimensional databases (datawarehouse). Some of the format-dependent “data access primitives”, such as images indexing or drill-in / drill-out OLAP primitives in datawarehouse could be offered at the Application and User layers. • Semi-structured data, such as HTML and XML, that can be retrieved by the Application Server accessing external web-sites (e.g. real-time offering of a price less than competing’s prices). A key aspect to manage those heterogeneous data sources is the availability of a metadata repository.

5.8. An example of VAMS implementation The proposed architecture has been successfully tested upon a specific case study: a system prototype for Sales Force Automation (SFA) has been implemented. It implements an Enterprise Mobile Intranet which can be remotely accessed by using WAP-compliant terminals.

Implemented prototype functions are: • Searching information about products (price-list, catalogue, storage); • Product reservation; • Listing, changing or undoing product reservation. To access enterprise database each salesman is authenticated using username and password. The system verifies the existence of an account for the specified user. The main design effort has been concentrated upon the Application layer that has been developed using both the Component-based (CB) and Script-based (SB) approaches. In the following, the CB and SB implementations according to the phases shown in Table 4 are discussed. The output of the phases 1÷2 are the database schema (Relational Model) and the Business Rules. In our prototype, the main entities (tables) are “Price-list”, “Warehouse”, “Reservation” and “Salesmen”. Domain constraints and referential-integrity constraints have been implemented by means of triggers. The main functions are “Authentication”, “Reading information” and “Product reservation”. The phases 3÷6 are different for the two approaches. In the SB approach data access and business rules are directly embedded in scripts (using PHP, ASP or JSP). Scripts are a mixture of static WML code and database routines. In CB approach, entity beans and session beans are respectively used to map the data model and the business rules. So we have an entity bean for each database table and a session bean for each business rule. Entity beans and session beans are server-side Java classes (components), running in the J2EE environment. Moreover, the servlets of phase 5 (web components in J2EE architecture) have to be implemented. A servlet must declare, among its attributes, the home interfaces (HIs) of the session beans that intends to invoke in its methods. In the same way, a session bean must declare, among its attributes, the home interfaces (HIs) of the entity beans that intends to invoke in its methods. HIs are used in order to obtain the beans' Remote Interfaces (RIs) and invoke methods. For instance, the following is the execution flow in the “Reading price-list” function: a) Salesman connects to the Mobile Intranet; b) Salesman chooses the function “Reading Price-List” from his WAP mobile terminal; c) “Reading Price-List” servlet activates and calls the “Reading Price-List” session bean methods in order to search for product information, according to manufacturer, price range and many other search keys. It is also possible to combine different search criteria in order to make more accurate product selection and minimise over-the-air traffic overhead.

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

9

Proceedings of the 34th Hawaii International Conference on System Sciences - 2001

d) “Reading Price-List” session bean reads product information stored in enterprise database by means of the “Price-List” entity bean methods, that encapsulate SQL statements (database routines). Database access is obtained via JDBC interface. e) “Reading Price-List” servlet collects results and dynamically generates WML output that will be returned to salesman’s WAP terminal and displayed. The last phase (7) is not necessary in SB approach. In CB approach, instead, compiled components (beans and servlets) must be deployed in a target Application Server (in our implementation J2EE server). During this phase, system administrator must specify many environment properties such as: JNDI (Java Naming and Directory Interface) names, i.e. the symbolic names of components that are resolved by J2EE server, database connection strings, IP address of the machine hosting enterprise database and so on. The possibility to specify these properties at deployment time makes it possible to deploy the same application (or a subset of it) on different platforms.

6. Conclusions Some recent works are addressing the development and deployment of applications for wireless environments. In [5] a WAP based system able to multiplex data flow at the transport level is presented. An architectural comparison between the SIM Toolkit and the WAP to support Mobile e-commerce applications is described in [6]. A system for the development of WAP-based applications, where the site development has been automated, is presented in [7]. Although it is similar to our system, it does not use any Application Server to implement business logic and only static file-based contents are provided. Other interesting projects are those of the “I.T. for Mobility” Esprit European programme [8] and in particular the FLIRT project. By using emerging standards as HDML, WML and WAP, that project describes mobile services in a form that can be delivered to handsets of varying capability [9]. Other important initiatives can be found in the ACTS programme [10]. Along those directions, this paper presented an integrated general architecture to develop and deploy portable applications and services for WAP-compliant mobile terminals. The architecture is component-based and follows a modular approach to the design of applications, thus allowing application portability and component reusability. The integration between WAP and WWW components allows end-to-end services between terminal and business applications for the development of transactional services. Moreover, the system implements a technique to handle terminal disconnection that optimises

the operations after re-connections due to intermittent communications. Different implementation strategies for the Application layer, allowing either fast prototyping or the realisation of robust and portable applications and transactional services, are presented. In particular, the componentbased implementation supports portability, easy maintenance and robustness, whereas the script-based one allows the cost-effective, timely implementation of simple WAP-compliant applications.

References [1] The demand for Mobile Value-Added Service – Nokia White Paper. [2] Wireless Application Protocol Architecture Specification – WAP Forum. http://www.wapforum.org/. [3] Wireless Markup Language – WAP Forum. http://www.wapforum.org/what/technical.htm. [4] Wireless Markup Language Script – WAP Forum. http://www.wapforum.org/what/technical.htm. [5] Thomas Enderes, Design and Implementation of a Multiplexing Framework for the Wireless Application Protocol, Tech. Rep., University of Karlsruhe-Institute for Communications Engineering, May 27, 1999. [6] Kyriacos Sabatakakis, Marcel Zumbuhl, Steffen Krotsch, Mobile eCommerce, Andersen Consulting, Zurich, Switzerland. [7] Juha Leppanen, Timo Laakko, Markuu Kylanpaa, Prototype development for the WAP application, VTT Information Technology, Finland. [8] IT for Mobility, http://www.cordis.lu/ esprit/src/mobility.htm. [9] FLIRT: Flexible Information and Recreation for Mobile Users, http://www.seagrp.co.uk/Flirt/flirt.html [10] The ACTS Information Window, http://www.infowin.org/ACTS/. [11] Sun Microsystems, J2EE Application Programming Model Available at http://java.sun.com/j2ee/apm/ [12] Cannataro M., Pascuzzi D., An Object-Based Architecture for WAP-Compliant Applications, MDDS‘2000, pp. 178-185, IEEE CS Press. [13] The Nokia WAP gateway, http://www.nokia.com. [14] The Kannel Open Source WAP and SMS gateway, http://www.kannel.org. [15] M. Satyanarayanan, Mobile information access, IEEE Personal Communications, 3 (1), Feb. 1996. [16] The Apache XML Project, http://xml.apache.org/cocoon/technologies.html [17] S. Müller-Wilken, F. Wienberg, and W. Lamersdorf, On Integrating Mobile Devices into a Workflow Management Scenario, MDDS‘2000, pp. 186-190, IEEE CS Press.

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

10