Thin-Client Applications

Developing Java-AWT Thin-Client Applications for Limited Devices Developing software for personal wireless devices (PWDs) requires new methods and tools that address the restrictions introduced by these devices’ mobile nature. The Thin-Client Applications for Limited Devices (TCPTE) framework supports the development of thin-client applications for mobile devices with limited resources. Using TCPTE, we can execute Java applications on a server and display their AWT interfaces on a remote client. TCPTE combines the advantages of thin-client computing with the richness of client-server graphical interfaces and lets programmers develop applications for PWDs using the same processes and tools they typically use for desktop applications.

T

he rapid growth in popularity of personal wireless devices (PWDs), such as PDAs, smart phones, and 3G cell phones, has raised the need for specific software development methods and tools. Most applications for these devices are either Web- or Java-based,1 although platforms such as Microsoft .NET Compact Framework (http://msdn.microsoft. com/mobility/prodtechinfo/devtools/net cf/), the Symbian software developer’s kit (www.symbian.com/developer/sdks.asp), and the Palm OS Developer Suite (www. palmos.com/dev/dl/dl_tools/dl_pods) are becoming more widely used. Developers of PWD software must address several key issues: terminal heterogeneity, limited processing power,

IEEE INTERNET COMPUTING

storage capacity, display size and resolution, and wireless networks’ low bandwidth and high latency. Tools for designing GUIs using a platform-independent model could help tackle the heterogeneity and limited display size. These tools typically generate an XML description of the user interface that XSLT transformations can successively transform into platform-specific GUIs, customized according to device profiles.2 However, for existing GUI-based applications, such as the Java abstract windowing toolkit (AWT) applications, the problem is reverse engineering the original platform-dependent GUI to its abstract model. To execute resource-intensive appli-

1089-7801/05/$20.00 © 2005 IEEE

Published by the IEEE Computer Society

Gerardo Canfora, Giuseppe Di Santo, and Eugenio Zimeo Research Center on Software Technology, University of Sannio, Italy

SEPTEMBER • OCTOBER 2005

55

Thin-Client Applications

Thin-Client Models oftware architectures based on the thin-client model belong to two main classes: distributed and remote presentation. In distributed-presentation architectures, only a thin part of the presentation layer runs on the client.The bulk of this layer, as well as the application and data layers, run on the server. In remote-presentation architectures, the client handles more of the presentation logic, reducing the number of roundtrips to the server. Researchers have released many protocols for implementing distributed presentation; X Window System,1 Microsoft Remote Desktop Protocol,2 Citrix Independent Computing Architecture,3 and Virtual Network Computing (VNC)4 are the best-known examples. All these protocols result in significant network traffic due to communicating keystrokes, mouse movements, or bitmap alterations. Remote-presentation architectures limit the number of interactions between client and server, making them well-suited for wireless communications. They also support PWDs’ reduced screen size by mapping logical user interface components onto the native components that are more suitable for the presentation. Remote-pre-

S

sentation architectures require specifically designed client applications, which has helped limit the approach’s popularity. However, academic and industrial researchers are defining frameworks for porting the existing Java abstract windowing toolkit (AWT) into thin-client environments using remote presentation. The Ultra-Light Client (ULC)5 is a Java presentation engine that transparently handles the application’s distribution using half-objects — that is, hardware-dependent objects on the client side and faceless proxies on the server side, all of which communicate through the ULC infrastructure. Classic Blend for Java (www.appliedreasoning.com) lets developers apply both HTML and Java-based widgets on a Web application’s client side by transparently distributing each widget to the client using HTTP and providing a proxy through which widgets communicate with the server. Despite the object distribution transparency, the framework needs a property file on the server to connect widgets to the server’s application logic. The Thin-Client Framework (TCF, www.alphaworks.ibm.com/tech/tcf) is both a framework and a set of interfaces and

cations on devices with limited processing power and storage, developers can decompose applications into two groups of components and transparently distribute them between a PWD and one or more servers accessed through a network. Although many existing programming models and middleware platforms support the development of distributed applications in client-server environments, they often require nontrivial refactoring of desktop applications, which becomes more complex in environments where resources are limited. Software architectures based on the thin-client model represent a viable solution to this problem because they can transform a monolithic application into a client-server one without overly burdening the programmer (see the “Thin-Client Models” sidebar). Thin-Client Applications for Limited Devices (TCPTE; http://tcpte.rcost.unisannio.it/) is a frame-

56

SEPTEMBER • OCTOBER 2005

www.computer.org/internet/

abstract classes for developing client– server-specific applications. The Remote AWT (RAWT; www.alphaworks.ibm.com/ tech/remoteawtforjava/) is an implementation of Java AWT and Swing that allows the remote presentation of all Java applications using Sun’s Java Runtime Environment. Like ULC, RAWT uses the half-object design pattern. Moreover, with RAWT, developers don’t have to modify existing widget-based Java applications to use them as thin-client applications. They do, however, have to adopt the same JRE version on both server and client. References 1. N. Mansfield, The Joy of X:An Overview of the X Window Systems, Addison-Wesley, 1993. 2. Microsoft Corp., “Remote Desktop Protocol (RDP) Features and Performance,” white paper, 2000; www.microsoft.com/windows2000/tech info/howitworks/terminal/rdpfandp.asp. 3. J.P. Kanter, Understanding Thin-Client-Server Computing, Microsoft Press, 1998. 4. T. Richardson et al.,“Virtual Network Computing,” IEEE Internet Computing, vol. 2, no. 1, 1998, pp. 33–38. 5. Canoo Engineering AG,“Ultra Light Client:Technology White Paper,” white paper, 2001; www. canoo.com/ulc/home/whitepaper.html.

work for developing thin-client Java-AWT applications for PWDs. TCPTE supports effortless migration of Java desktop applications to limitedresource devices by reducing client-side computation, using a remote-presentation architecture that decouples the server- and client-side portions of the graphical framework through a specific design pattern, which hides the heterogeneity, and a communication protocol optimized for wireless communication. The current release of TCPTE (1.0) doesn’t tackle the problem of reduced screen size and resolution.

Application Development, Deployment, and Execution Typical TCPTE applications are database- and investment-management tools, remote control of home devices, remote work for business agents, and video games with limited interactivity but intensive computations (such as chess). We can logically

IEEE INTERNET COMPUTING

Developing Java-AWT

(b) Deployment Java .awt

Application 0101001010100 1001010010101 0010101001001 0100101010010 1000010010010 1000010100111 011010

Application 0101001010100 1001010010101 0010101001001 0100101010010 1000010010010 1000010100111 011010

3 Deploy

2 Compile Library

Unicast connection (pull) 4

Java.AWT

Database

TCPTE client

Application logic tcpte.awt

Application 0101001010100 1001010010101 0010101001001 0100101010010 1000010010010 1000010100111 011010

TCPTE server

XML

Retrieve applications list 5 Application request 6

1 Develop

Middleware

IP network Application usage 7

Middleware

Application developer

User interface

(a) Development

(c) Execution

Figure 1. The Thin-Client Applications for Limited Devices (TCPTE) processes. In the (a) application development phase, we compile a new or existing Java abstract windowing toolkit (AWT) application and test complex GUIs to verify the need for refactoring. During the (b) deployment phase, we move the application and its XML description to the TCPTE server, which links the application to the AWTServer. During the (c) execution phase, the user connects to the server and requests an application. divide these applications into two macrocomponents: user interface and application logic. To transparently support this division in a distributed client-server environment, TCPTE offers the AWTServer, a limited version of the java.awt package containing most of the graphical components of Sun’s package and preserving the same naming and interfaces, but with a limited set of methods for some classes. The package’s implementation interposes a middleware layer between a user interface’s abstract components and its graphical representation, thus moving the representation to the client device. TCPTE performs the division, which is transparent to developers and end users, at runtime. Figure 1 summarizes the development, deployment, and execution processes. In the first phase (1 and 2 in Figure 1a), the developer reuses existing Java AWT applications or develops new ones and compiles them independently of the device that will display them. The developer tests complex GUIs

IEEE INTERNET COMPUTING

with the AWTServer to verify the need for refactoring by adapting the application to the new environment. In the deployment phase, the developer moves the application and its XML description to a TCPTE server (3 in Figure 1b), where the application is dynamically linked to the AWTServer. Finally, in the execution phase, using a client written ad hoc for the specific device, the user connects to the server (4 in Figure 1c), which sends the client the list of deployed applications (5 in Figure 1c). The user selects an application and asks the server for its execution (6 in Figure 1c). The server then creates a process for executing the requested application and its user interface, which appears incrementally on the client (7 in Figure 1c).

Architecture and Design Figure 2 (next page) shows the TCPTE architecture. The server side’s top layer represents the application to be run on the server and displayed on a

www.computer.org/internet/

SEPTEMBER • OCTOBER 2005

57

Thin-Client Applications

Server side

Client side

User interface

Application logic

Dialog Name Separator Name:

OK

Option Option Option

Cancel

Choose from one of the following: Options Separator Name: Check one of the following: Option 5 Option Value

Option Option Option

Help

Platform-specific graphical library

AWTServer

AWTClient

Object communication layer

Object communication layer

Session layer

Session layer TCPTE libraries

Transport layer

Transport layer

Figure 2. TCPTE architecture. The current implementation uses personal Java and the Java 2 Micro Edition platform, but we could also adopt .NET for Windows or native libraries for the Palm OS. remote device. The application layer uses the components defined by the AWTServer layer. When the application logic invokes a method on an AWTServer component, the object communication layer lets the server invoke the method on the device’s corresponding AWTClient component. The current implementation of these components uses Personal Java and the Java 2 Micro Edition platform. (We tested the framework using J2ME with the Mobile Information Device Profile 1.0 and Connected Limited Device Configuration 1.0, but it should also work with MIDP 2.0 and CLDC 1.1.) However, because we use a platformindependent object communication protocol, we could also adopt .NET for Windows CE or native libraries for the Palm OS. TCPTE AWT Layer In Java AWT, an application can change the user interface state by invoking one or more methods on the graphical components, which triggers the invocation of the appropriate methods on the related peers. These peers, in turn, invoke specific native methods to project the changes of the user interface onto the device’s screen. The application uses listener objects to propagate an input event sent to a GUI component through its corresponding logical component. Because the TCPTE architecture separates the

58

SEPTEMBER • OCTOBER 2005

www.computer.org/internet/

application and presentation logics, we need two address spaces in which the two logics can execute independently. In the remote-presentation approach, it’s important to distribute application components between the two address spaces appropriately so the user can interact with the application through a separated device, leaving the application unchanged. For TCPTE, we modified the internal Java AWT implementation and used the half-object design pattern3 to distribute the graphical components between client and server. Because we use the halfobject pattern, we must split each component into two objects: one half in the application address space (AAS), the other half in the user interface address space (UIAS). The two half-objects communicate through the TCPTE object-communication protocol. Figure 3 shows the deployment of a subset of the TCPTE class hierarchy. In the AAS, we deploy the classes related to the application logic. In the UIAS, however, we identify three components: • half-object interfaces (HOIs) — interfaces for the half objects; • platform-specific half-object implementations (PSHIs) — platform-dependent implementations of the HOIs; and • platform-dependent GUI components (PDC) — GUI objects available on the UIAS. Each logical component has a remote reference to an HOI implementation. When the application invokes a method on a logical component, the component invokes the corresponding method on the related PSHI. In the UIAS, the PSHI maps each method invocation on the PSHI onto a corresponding method invocation on the PDC. The abstract factory pattern implemented by a specific toolkit creates the PSHI. Object Communication and Session Layer The communication layer handles the ad hoc serialization and deserialization techniques of objects transferred over the network, avoiding the Java runtime type information (RTTI) used by the serialization’s default implementation in J2SE and J2EE platforms but often not implemented in J2ME platforms. This layer makes the TCPTE communication mechanisms independent of the platform. To improve the communication layer’s performance, we serialize the objects transferred between client and server in a binary format. However, we

IEEE INTERNET COMPUTING

Developing Java-AWT

base communication between objects on asynchronous interactions built on a lightweight transport protocol to tolerate the wireless networks’ high latencies. Even if asynchrony requires a specific middleware for interactions between client and server, we can use asynchronous communication for void method invocations by avoiding acknowledgment replies (one-way invocations). To ensure both the “at most once” invocation semantic (instead of the “maybe” semantic of some objectoriented middleware for void invocations) and consistency when performing several one-way invocations, we use the underlying transport protocol’s reliability and first-in, first-out delivery order properties. Moreover, we use flow control to reduce the number of losses and, consequently, retransmissions, which are costly in wireless networks. So, although the User Datagram Protocol (UDP) could improve the system’s reactivity, TCP is the best choice (among the existing and diffused protocols) because it natively provides the desired properties and mechanisms. However, to improve reactivity, we release some of the TCP optimizations oriented to streaming communication. In particular, we disable the Nagle algorithm so TCP can send segments as they arrive in the sending buffers. Starting from these design considerations, the TCPTE object communication layer implements a one-way scheme for void method invocations and a synchronous two-way scheme for nonvoid method invocations. Unfortunately, simply substituting TCPTE remote method invocation (RMI) middleware with an existing asynchronous middleware (such as the one Caromel and colleagues propose4) isn’t easy with PWDs. Restrictions posed by some client platforms prevent these middleware, which are typically designed for desktop computers, from being used on PWDs without significant modifications. The session layer deals with the client-server connection setup and maintenance. Under some circumstances, such as an out-of-range device in wireless communication, the client and server could temporarily lose connectivity. In TCPTE 1.0, when a connection error occurs, the client freezes the user interface and tries to connect to the server.

TCPTE Evaluation TCPTE’s main benefit is that it lets developers build applications independent of PWD heterogeneity.

IEEE INTERNET COMPUTING

User interface

Application logic

Native components

Dialog Name Separator Name:

OK

Option

Cancel

Option Option Choose from one of the following: Separator Name: Check one of the following: Option

5

Option

Value

Options

Dialog Name Option Option Separator Name: Option Option

OK Cancel

Option Option Choose from one of the following:

Options

Separator Name: Check one of the following: Option

5

Option

Value

Option Option Option

Half-objects 1 java.awt component Application address space

1 Half-object interface

Platform-dependent GUI components N 1 Platform-specific half-object implementation

User interface address space

Figure 3. Deployment of a subset of the TCPTE class hierarchy. We use the half-object design pattern, which splits each component into two objects: the application address space (AAS) and the user interface address space (UIAS). Currently, we can seamlessly distribute applications between a server and heterogeneous clients, but can’t automatically adapt user interfaces to devices with limited screen sizes. To assess the impact of this limitation, we evaluated the framework by porting two applications developed for PCs and characterized by user interfaces of different complexity. Figure 4 (next page) shows the first application,
Engine, an open-source workflow engine that executes distributed processes modeled using the XML Processing Description Language over both LANs and the Internet. Our second application, Bloof,5 is a Java library for analytically processing version-control data. Bloof helps developers, project managers, and software engineering researchers comprehend a software system’s evolution. Table 1 (next page) shows the effort required from a single developer to port the two applications onto PWDs. Porting
Engine took only a few hours because of its simple user interface. We slightly modified the user interface layout to adapt the visualization of some graphical components to devices with limited screen size. Porting Bloof required more effort (six days by one developer) because its user interface, the Bloof-Browser, is too large and complex to fit on a PWD without changes. In particular, we needed to analyze the application’s structure and the graphical interface characteristics in order to adjust the user interface to a 160
160-pixel display resolution. Finally, we modified the source code to convert the Swing application (http://java.sun. com/j2se/1.4.2/docs/api/javax/swing/package -summary.html) into a TCPTE AWT application. Reorganizing the user interface entailed redefin-

www.computer.org/internet/

SEPTEMBER • OCTOBER 2005

59

Thin-Client Applications
Engine in desktop environment

Process definition

Workflow enactment service

Interface

Interface

Workflow client application

Invoked applications

Interface


Engine on a Pocket PC

Administration and monitoring tools

Interface

TCPTE server

Interface Workflow API and interface Workflow engines

Workflow engines Other workflow enactment service

Figure 4. The WfMC-compliant Engine. We evaluated the TCPTE framework by considering the porting of this and one other application initially developed for PCs and characterized by user interfaces of different complexity.

Table 1. Comparison between
Engine and Bloof porting times. Application

GUI/application analysis

Code analysis Components


Engine Bloof

2 hours 1.5 days

Pocket PC - Intel PXA255 - 57 MBytes of RAM - Personal Java VM

Testing

Total

0.5 hours 1 day

0 1 day

1 hour 1 day

4 hours 6 days

0.5 hours 0.5 day

HP workstation - Intel P4, 1.8GHz - 128 MBytes of RAM - Linux Fedora core 2

Ethernet, Wi-Fi, Bluetooth, GPRS

USB cable

Component adaptation

Layout

0 1 day

Measurement station - Intel P4, 1.8GHz TCPTE and - 650 MBytes of RAM VNC client - Windows 2000

Layout implementation

VNC server TCPTE server

Network shaper Network analyzer

Figure 5. Testbed used in the TCPTE performance evaluation. A USB cable connects a Pocket PC to a measurement station. We connected the measurement station to a server using wired and wireless channels. ing the layout to adapt it to smaller displays. To this end, we removed the toolbar and updated the

60

SEPTEMBER • OCTOBER 2005

www.computer.org/internet/

menus to offer all the original application’s functionalities. Moreover, we replaced right-button clicks with specific buttons, handling the main user interface’s three areas via a JTabbedPane (http://java.sun.com/j2se/1.4.2/docs/api/javax/ swing/JTabbedPane.html). To assess TCPTE’s effectiveness and efficiency and to validate our design choices, we compared TCPTE to existing technologies using several performance measurements. Among these technologies, we focused on Virtual Network Computing (VNC) because • a personal device version exists, • it’s an example of a distributed presentation approach, and • it performs better than other frameworks in its class.6

IEEE INTERNET COMPUTING

Developing Java-AWT

647

700

3.0 2.5

500 Seconds

Milliseconds

600 400 300

0.2

3.1

Ethernet

Seconds

4.0

Wi-Fi

Bluetooth

GPRS

(b)

5.0

3.0 2.0

4.0 3.0

Ethernet

Wi-Fi

Bluetooth

GPRS

VNC TCPTE synchronous TCPTE-synchronous-No Nagle TCPTE asynchronous TCPTE-asynchronous-No Nagle

2.0

1.0

1.0 0.0

0.0 (c)

0.0

6.0

VNC TCPTE TCPTE-No Nagle Seconds

5.0

1.5

0.5

40.8

0 (a)

2.0

1.0

200 100

VNC TCPTE TCPTE-No Nagle

Ethernet

Wi-Fi

Bluetooth

GPRS

(d)

Ethernet

Wi-Fi

Bluetooth

GPRS

Figure 6. Performance evaluation results. We tested the (a) network latency for wired and wireless networks, (b) reactivity, (c) visualization latency for small-to-medium user interfaces, and (d) bootstrap and visualization latency for medium-tolarge user interfaces. We performed all the measurements using the testbed depicted in Figure 5. We connected a Pocket PC to a measurement station using a USB cable, and connected the measurement station to a server using wired and wireless channels ranging from Ethernet to General Packet Radio Service (GPRS). Our first analysis aimed to establish how TCPTE and VNC depend on network bandwidth. We installed a network shaper on the measurement station to throttle the available bandwidth in the 14-Kbps to 1-Mbps range. We also installed a fast Ethernet network between the station and the server. Both TCPTE and VNC proved dependent on the bandwidth only at small values. When the available bandwidth grew to more than 33.6 Kbps, the performance of both technologies remained unchanged. Consequently, we performed other experiments, varying the network latencies by changing the network between the measurement station and the server. Notably, the results obtained in the first experiment validated the testbed for all other measurements. In fact, even if the USB connection between the PDA and the measurement station was a bottleneck when we used a network with high bandwidth to connect the station to the server,

IEEE INTERNET COMPUTING

bandwidth becomes a real bottleneck only for values under 33.6 Kbps, which is lower than the USB connection’s bandwidth. Our second experiment therefore compared TCPTE and VNC using three applications in scenarios characterized by different wired and wireless networks: fast Ethernet, Wi-Fi (11 Mbps), Bluetooth, and GPRS. Figure 6a reports the latencies measured using the ping command. We used the Bluetooth Networking Encapsulation Protocol (BNEP)7 to emulate an Ethernet network on top of Bluetooth’s Logical Link Control and Adaptation Protocol layer.8 Our test applications (available at the TCPTE Web site) were • ColorApps, for measuring reactivity (Figure 6b); •
Engine, for measuring the visualization latency with small-to-medium user interfaces (Figure 6c); and • Bloof, for measuring the bootstrap and visualization latency with medium-to-large user interfaces (Figure 6d). The reactivity measure is the average of the sample times between the PDA’s request and the receipt of the response whose content changes the

www.computer.org/internet/

SEPTEMBER • OCTOBER 2005

61

Thin-Client Applications 5,000

TCPTE test execution results Bytes: 14,260

Bytes

Bytes

5,000

2,500

0

10

20

30 Seconds

40

VNC test execution results Bytes: 162,258 2,500

50

0

10

20

30 Seconds

40

50

Figure 7. Transferred data comparison. VNC uses a raster approach to transfers the user interface image through a continuous data flow from the server to the client; TCPTE is a component-based approach in which each component requires an interaction between client and server. user interface background’s color. The visualization latency measure is the average of the sample times from the command request for the workflow diagram’s visualization and the last acknowledgment sent by the client after this visualization. The bootstrap and visualization time measure is the average of the sample times from the request for the application’s execution and the last acknowledgment sent by the client after the user interface’s visualization. The variance measured in every experiment was very low. Figure 6b compares VNC response times with two TCPTE configurations based on a TCP layer — one adopts the Nagle algorithm, the other disables it. In the first configuration, TCPTE performances are comparable with those of VNC for Ethernet and Wi-Fi networks; for higher latency networks, TCPTE response times are better. Disabling the Nagle algorithm reduces TCPTE response times because it eliminates delays (about 200 milliseconds for each acknowledgment) imposed by TCP’s delayed acknowledgment mechanism. Figures 6c and 6d show analogous behavior for the bootstrap and visualization of both medium and large user interfaces. With Bloof, VNC requires about 2.3 seconds to show the user interface, whereas TCPTE shows the user interface in 1.2 seconds over a Bluetooth network. However, Figure 7 highlights a significant difference in data exchanged between client and server, whereas the performance ensured by TCPTE is less exciting. This difference is because VNC uses a raster approach to transfer the user interface image through a continuous data flow from the server to the client; TCPTE is a component-based approach

62

SEPTEMBER • OCTOBER 2005

www.computer.org/internet/

in which each component requires an interaction between client and server. If this interaction is synchronous (nonvoid methods), the framework suffers from network latencies, as we discussed earlier. So, to evaluate the best possible performance using an asynchronous RMI middleware, we explicitly transformed, at the application level, each two-way method call in an asynchronous one-way invocation with a callback to return the value. This way, asynchrony ensures excellent TCPTE performance (as Figure 6d shows), whereas VNC performances remain unchanged. Moreover, Figures 6b–d show that on networks characterized by high latency (such as GPRS), adopting the Nagle algorithm improves TCPTE performance. Finally, we compared TCPTE’s usability with VNC, and generally with other existing solutions for PWDs, using a distributed-presentation approach. Following this approach, each action on the user interface throws an interaction between client and server. Some actions, such as scrolling a text area or changing a panel in a tabbed pane, require a sensible delay to visualize information. In general, this delay is acceptable if the client is connected to the server over a fast network, but is unacceptable over a slow network. With very slow networks, such as GPRS, the distributed-presentation approach also raises significant delays for clicks on a menu. With the remote-presentation approach, scrolling a text area or changing a panel or a menu require no interaction with the server because the information needed to update the user interface is already present on the client. Client-server interactions occur only when the user fires an event for the application logic to process.

IEEE INTERNET COMPUTING

Developing Java-AWT

T

o understand TCPTE’s future impact, we must analyze how the wireless world will evolve in the near future. If the available bandwidth increases and devices stay simple, the winning solution will be to offer services through thin clients. If, on the other hand, the devices become more powerful, the client-server model will likely predominate. TCPTE supports the development of applications that can run either way. As communication bandwidth grows, most content providers are offering multimedia services for sending images and real-time video and audio streams to wireless users. Following this trend, we’ll enhance the TCPTE AWTServer and AWTClient with multimedia components to play video and audio on mobile devices. We’ll also extend the session layer to support application wake-up and push messages to notify clients of events from the TCPTE server, such as applications’ availability, and session hand-off for starting an application on a device, freezing it at any instant, and resuming it on another device. As our evaluation showed, we can enhance the framework at the communication layer by implementing a middleware for asynchronous RMI to tolerate high network latencies by overlapping computation and communication. In this middleware, we’ll implement both void and nonvoid methods through asynchronous, nonblocking communication. For nonvoid methods, we’ll implement a transparent synchronization mechanism based on future variables. Moreover, to reduce response times, we’ll implement a mechanism that enables or disables the Nagle algorithm on the basis of the network latency. Acknowledgments We thank Giancarlo Tretola and Angelo Scarnata for their contribution to TCPTE’s development phases; Nicola Barbiero, Carlo Carrabs, Alessandro Craviolatti, Roberto De Pascalis, and Franca Perrina for their contribution in
Engine’s development; and Gabriele Venturi for the interesting discussions that animated this work.

References 1. K. Read and F. Maurer, “Developing Mobile Wireless Applications,” IEEE Internet Computing, vol. 7, no. 1, 2003, pp. 81–86. 2. J.C. Grundy and B. Yang, “An Environment for Developing Adaptive, Multidevice User Interfaces,” Proc. 4th Australasian User Interface Conf., Australian Computer Soc., vol. 18, 2003, pp. 47–56. 3. G. Meszaros, “Pattern: Half-Object + Protocol,” Pattern

IEEE INTERNET COMPUTING

4.

5.

6.

7. 8.

Languages of Program Design, J.O. Coplienand and D.C. Schmidt, eds., Addison-Wesley, 1995. D. Caromel, W. Klauser, and J. Vayssiere, “Towards Seamless Computing and Metacomputing in Java,” Concurrency Practice and Experience, G.C. Fox, ed., John Wiley & Sons, 1998, pp. 1043–1061. G. Canfora, G. Di Santo, and E. Zimeo, “Toward Seamless Migration of Java AWT-based Applications to Personal Wireless Devices,” Proc. 11th IEEE Working Conf. Reverse Eng., IEEE CS Press, 2004, pp. 38–47. S.J. Yang et al., “The Performance of Remote Display Mechanisms for Thin-Client Computing,” Proc. 2002 Usenix Ann. Technical Conf., Usenix Assoc., 2002, pp. 131–146. Bluetooth SIG, Bluetooth Network Encapsulation Protocol (BNEP) Specification, v. 1.0, tech. specification, Feb. 2003. Bluetooth SIG, Specification of the Bluetooth System, v. 1.1, tech. specification, Feb. 2001.

Gerardo Canfora is a full professor of computer science in the School of Engineering and the director of the Research Center on Software Technology (RCOST) at the University of Sannio. His research interests include software maintenance and reverse engineering, service-oriented software engineering, metrics, and experimental software engineering. Canfora has a Laurea degree in electronic engineering from the University of Naples Federico II. He currently serves on the Journal of Software Maintenance and Evolution editorial board. He is a member of the IEEE Computer Society. Contact him at gerardo.canfora@ unisannio.it. Giuseppe Di Santo is a PhD student in the Department of Engineering at the University of Sannio, Italy. His research interests include wireless networks, mobile computing, mobile ad hoc and sensor networks, and software architectures for distributed systems. Di Santo has an MS in computer science from the University of Salerno, Italy, and a master’s degree in software technology from the University of Sannio. Contact him at giuseppe.disanto@ unisannio.it. Eugenio Zimeo is an assistant professor of computer science in the School of Engineering and member of the Research Center on Software Technology (RCOST) at the University of Sannio. His primary research interests are software architectures and frameworks for distributed systems, highperformance middleware, agent-oriented programming, mobile and ubiquitous computing, wireless and sensor networks, parallel and distributed systems, and grid and service computing. Zimeo has a PhD in computer science from the University of Naples. He is a member of the IEEE Computer Society. Contact him at [email protected].

www.computer.org/internet/

SEPTEMBER • OCTOBER 2005

63