Relatório Final de TFC Licenciatura em Engenharia ...premio-vidigal.inesc.pt/pdf/ChristopheConceicaoTFC.pdf · Licenciatura em Engenharia Informática e de Computadores (LEIC) Ano

Departamento

de Engenharia

Informática

Relatório Final de TFC

do curso de

Licenciatura em Engenharia

Informática

e de Computadores

(LEIC)

Ano Lectivo 2005/06

N.o da Proposta: 22

Título: Ajax Technology

Professor Orientador:

António Paulo Teles de Menezes de Correia Leitão

Co-Orientador:

Tiago Augusto Duarte Gavinhos

Aluno:

50972, Christophe Pereira da Conceição

Ajax Technology 24-07-2006

Acknowledgments

I would like to express to my adviser, Prof. António Leitão, my heartfeltthanks. His trust, �exibility and great support helped me to accomplish thiswork with success. All the discussions contributed to the creation of betterand more creative solutions.

To Eng. Tiago Gavinhos and all the VILT team, I would like to expressmy thanks for their support and feedback along the development of thisproject.

I thank Eng. João Pimentel, who was the �rst person to develop ap-plications with the Kiron platform, his feedback helped me to solve manyproblems.

To Eng. Virgílio Gaspar, I would like to thank all his support along thedevelopment of this project and review of this document.

I would like to thank the Fénix team, for their feedback during the pre-sentation of the work in progress.

And �nally my special thanks to Eng. Rui Figueira who introduced methe Ajax concept. Without him, this work would probably have never started.

Christophe Pereira da Conceição iii


Summary and keywords

The development of web applications has been experiencing several techno-logical revolutions. Each of them provided new features and higher levels ofabstraction to ease development. One of the major problems of current web-applications is its synchronous data request model, which blocks user activityupon each request, transforming the web-browser into a kind of �slide-show�projector with a successive passage of static screens to the user. To overcomethis, a new web development concept appears under the name of Ajax. Thismodel enables the web-browser to ask for data asynchronously, breaking thestart-stop model of current web-applications into a continuous interactionmodel. With this new approach some tools and frameworks came up to easeand support the development of this kind of applications. Many of these newtools have a low level of abstraction, making di�cult for a programmer todevelop complex rich Internet applications.

This work wants to go further, enabling the development of web appli-cations with the same model used for desktop and distributed applicationsdevelopment. The web-browser will not only present the user interface ren-dered by the server, but will also do some processing, including control ofthe application and rendering of data components.

Keywords: Ajax, distributed applications, rich Internet applications, webapplication development

Christophe Pereira da Conceição v


Contents

List of Figures xi

List of Tables xiii

Acronyms xiv

1 Introduction 11.1 Prologue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.2 Web presentation . . . . . . . . . . . . . . . . . . . . . 51.2.3 Web 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.4 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Solution design 92.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Main goals . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.2 Presentation and user interaction . . . . . . . . . . . . 10

2.2 Web Operating System approach . . . . . . . . . . . . . . . . 102.3 Kiron approach . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Development methodology 133.1 Development roadmap . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1 Interaction with server objects . . . . . . . . . . . . . . 153.1.2 Data communication abstraction . . . . . . . . . . . . 173.1.3 Peer to peer approach . . . . . . . . . . . . . . . . . . 183.1.4 Web-browser application development . . . . . . . . . . 18

4 Kiron 214.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.1 Global architecture . . . . . . . . . . . . . . . . . . . . 214.1.2 Peer architecture . . . . . . . . . . . . . . . . . . . . . 22

Christophe Pereira da Conceição vii

24-07-2006 Ajax Technology

4.2 Kiron Virtual Network . . . . . . . . . . . . . . . . . . . . . . 23

4.2.1 KVN nodes . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2.2 KVN link layer . . . . . . . . . . . . . . . . . . . . . . 25

4.2.3 Transport layer . . . . . . . . . . . . . . . . . . . . . . 26

4.2.4 KSockets application layer . . . . . . . . . . . . . . . . 26

4.3 Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3.1 Kiron Remoting Architecture . . . . . . . . . . . . . . 30

4.3.2 RMIServer . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3.3 RMIClient . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3.4 Remote Reference Layer . . . . . . . . . . . . . . . . . 32

4.3.5 Transport Layer . . . . . . . . . . . . . . . . . . . . . . 32

4.3.6 Proxy dynamic loading . . . . . . . . . . . . . . . . . . 33

4.3.7 Asynchronous vs. synchronous . . . . . . . . . . . . . . 33

4.3.8 Distributed Garbage Collection . . . . . . . . . . . . . 34

4.3.9 Method noti�cation . . . . . . . . . . . . . . . . . . . . 35

4.3.10 Concurrency . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.11 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.12 Sample code . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.13 Remoting patterns . . . . . . . . . . . . . . . . . . . . 38

4.4 Kiron.ECMAScript . . . . . . . . . . . . . . . . . . . . . . . . 39

4.4.1 KVN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.4.2 Remoting . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.4.3 User Interface . . . . . . . . . . . . . . . . . . . . . . . 40

4.4.4 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.4.5 JavaScript language improvements . . . . . . . . . . . 42

4.5 Kiron.JVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.5.1 KVN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.5.2 Remoting . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.5.3 Lease manager . . . . . . . . . . . . . . . . . . . . . . 47

4.6 Kiron.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.7 KRouter.JVM and KRouter.NET . . . . . . . . . . . . . . . . 48

4.8 Application development patterns . . . . . . . . . . . . . . . . 48

4.8.1 Client/server applications . . . . . . . . . . . . . . . . 48

4.8.2 Server centric applications . . . . . . . . . . . . . . . . 48

4.8.3 Peer to peer applications . . . . . . . . . . . . . . . . . 49

4.8.4 Standalone applications . . . . . . . . . . . . . . . . . 49

4.8.5 Kiron with legacy systems . . . . . . . . . . . . . . . . 49

viii Christophe Pereira da Conceição


5 Results 515.1 Planing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2 Comparison with other Ajax solutions . . . . . . . . . . . . . 51

5.2.1 Backbase . . . . . . . . . . . . . . . . . . . . . . . . . 535.2.2 GWT . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.2.3 DWR . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.2.4 WebORB . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.3 Kiron unique features . . . . . . . . . . . . . . . . . . . . . . . 55

6 Future Work 576.1 Core enhancements . . . . . . . . . . . . . . . . . . . . . . . . 57

6.1.1 Circular references and objects serialization . . . . . . 576.1.2 Concurrency . . . . . . . . . . . . . . . . . . . . . . . . 576.1.3 Transactional support . . . . . . . . . . . . . . . . . . 58

6.2 Middleware extension . . . . . . . . . . . . . . . . . . . . . . . 586.2.1 Kiron.Ruby . . . . . . . . . . . . . . . . . . . . . . . . 586.2.2 Kiron.GWT . . . . . . . . . . . . . . . . . . . . . . . . 586.2.3 Security improvement . . . . . . . . . . . . . . . . . . . 59

6.3 Peer extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 596.3.1 K-XGUI . . . . . . . . . . . . . . . . . . . . . . . . . . 596.3.2 Integration with qooxdoo toolkit . . . . . . . . . . . . 59

6.4 Development tools . . . . . . . . . . . . . . . . . . . . . . . . 596.4.1 K-DEV . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.5 Concrete applications . . . . . . . . . . . . . . . . . . . . . . . 606.5.1 WebOS . . . . . . . . . . . . . . . . . . . . . . . . . . 606.5.2 Dynamic documentation system . . . . . . . . . . . . . 61

7 Conclusions 63

Appendixes 65

Bibliography 91

Christophe Pereira da Conceição ix


List of Figures

1.1 Traditional web application model vs. Ajax model . . . . . . . 31.2 User activity with Ajax . . . . . . . . . . . . . . . . . . . . . . 4

2.1 WebOS architecture . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Cross-platform WebOS . . . . . . . . . . . . . . . . . . . . . . 11

4.1 Kiron middleware . . . . . . . . . . . . . . . . . . . . . . . . . 224.2 Kiron peer architecture . . . . . . . . . . . . . . . . . . . . . . 234.3 KVN - Kiron Virtual Network . . . . . . . . . . . . . . . . . . 244.4 KVN Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.5 Communication with external applications . . . . . . . . . . . 264.6 Kiron Instant Messaging . . . . . . . . . . . . . . . . . . . . . 294.7 Kiron remoting architecture . . . . . . . . . . . . . . . . . . . 304.8 RMIServer and RMIClient . . . . . . . . . . . . . . . . . . . . 314.9 Kiron Rich User Interface . . . . . . . . . . . . . . . . . . . . 414.10 On browser web-application debugging . . . . . . . . . . . . . 42

6.1 Kiron.ECMASCript with qooxdoo . . . . . . . . . . . . . . . . 606.2 File system explorer and �le viewer . . . . . . . . . . . . . . . 61

7.1 JSLog logging panel . . . . . . . . . . . . . . . . . . . . . . . . 667.2 ActiveWidgets data grid . . . . . . . . . . . . . . . . . . . . . 697.3 Javeline Framework Architecture . . . . . . . . . . . . . . . . 797.4 TIBCO General Interface Architecture . . . . . . . . . . . . . 827.5 Backbase Presentation Client . . . . . . . . . . . . . . . . . . 837.6 Backbase eXtensible Markup Language . . . . . . . . . . . . . 847.7 Backbase JSF Runtime . . . . . . . . . . . . . . . . . . . . . . 847.8 Direct Web Remoting . . . . . . . . . . . . . . . . . . . . . . . 857.9 WebORB architecture . . . . . . . . . . . . . . . . . . . . . . 88

Christophe Pereira da Conceição xi


List of Tables

5.1 Feature comparison table . . . . . . . . . . . . . . . . . . . . . 53

Christophe Pereira da Conceição xiii


Acronyms

API Aplication Programming Interface

AWT Abstract Window Toolkit

AJAH Asynchronous JavaScript and HTML

AJAJ Asynchronous JavaScript and JSON

AJAX Asynchronous JavaScript And XML

ASP Active Server Pages

CSS Cascading Style Sheet

DHTML Dynamic HTML

DGC Distributed Garbage Collection

DOM Document Object Model

DWR Direct Web Remoting

GUI Graphical User Interface

GWT Google Web Toolkit

I/O Input Output (entradas e saídas)

KML Kiron Markup Language

KVN Kiron Virtual Network

JVM Java Virtual Machine

JSON JavaScript Object Notation

Christophe Pereira da Conceição xv


JSF Java Server Faces

JSP Java Server Pages

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

RIA Rich Internet Applications

PHP PHP: Hypertext Preprocessor

POJO POJO: Plain Old Java Objects

RMI Remote Method Invocation

RPC Remote Procedure Call

SWT The Standard Widget Toolkit

VOS Virtual Operating System

webOS web Operating System

XML eXtensible Markup Language

XSLT XML Stylesheet Language for Transformations

XHTML eXtensible HyperText Markup Language

xvi Christophe Pereira da Conceição


Chapter 1

Introduction

1.1 Prologue

Software development is a complex process and di�erent kinds of softwareapplications result from this process. Each one has its own features, chal-lenges, and complexities, but all of them in one way or other manipulate data,and some of them need user interfaces to present and accept this data. Theimplementation of these user interfaces depends on the type of applicationsand the involved technology. An interface for an adventure computer gameis certainly di�erent from an interface for a billing system. Web applications,for example, have their interfaces rendered in a web browser. This kind ofapplication has the advantage of being accessed by anybody, anywhere wherean access point to the Internet is available.

Distributed applications are built by an aggregate of distributed nodes.These nodes communicate between them and cooperate to produce the de-sired computations of the application. Web applications and enterprise ap-plications [1] are examples of distributed applications: they are built withindependent and distributed components. A minimal web application has atleast two components, a web-server and a web-browser, but most of themcontain even more components. Enterprise applications, for example, aredesigned with independent tiers to implement the persistence of the appli-cation, its business rules, and presentation of the data. The persistence tiertypically connects to a relational database which can be running in a di�erentcomputer. Each of these web-application components can be distributed overa network to balance load and enhance performance of the whole application.

The web presentation tier is responsible for the presentation of the datafrom the web-application. Fowler [1] de�nes di�erent patterns to implementthis part of the application, but all of them rely on server-side processing.

Christophe Pereira da Conceição 1


In this work we will discuss and investigate some new techniques of webpresentations with client-side processing and rendering. The browser willnot only present the user interface rendered by the server, but will also dosome processing, including control of the application and rendering of datacomponents.

1.2 Context

In this section we introduce some important concepts to give context to theproblem and its motivation. Ajax, web 2.0 applications, and web presentationconcepts are discussed. Given its fundamental role in Ajax web-applications,the JavaScript language is presented here too.

1.2.1 Ajax

Ajax, or Asynchronous Javascript And XML, stands for a new hype in web-application development [2]. This technique consolidates various technologiesenabling the development of richer and more attractive web-applications.The main feature of Ajax is the XMLHttpRequest object which provides theability to make asynchronous requests from any web-browser to the web-server. There are various tools, toolkits and frameworks related to Ajax,each one with their own particular features and purposes.

Ajax incorporates the following technologies:

• XHTML and CSS - standards-based presentation

• DOM - dynamic display and interaction using the Document ObjectModel

• XML and XSLT - data interchange and manipulation

• Asynchronous data retrieval using XMLHttpRequest

• JavaScript for application logic

In classic web applications, user actions trigger HTTP requests to theweb-server. The server processes the request and responds back to the clientwith HTML. With Ajax, the web-browser has a component responsible forhandling asynchronous requests to the web-server and then to transform theretrieved data (see �gure 1.1).

Ajax brings a new concept of user interaction with web-applications. Intraditional web-applications the user activity is interrupted with requests to

2 Christophe Pereira da Conceição


Figure 1.1: Traditional web application model vs. Ajax model

the web-server, with Ajax these requests are made asynchronously keeping acontinuous user activity with the web-application (see �gure 1.2). With thisapproach web-pages don't need to be fully loaded anymore. Only portionsof the web-page and the necessary data are sent to the web-browser. Theinterface is rendered incrementally instead of full page refreshes.

Advantages

There are several advantages in the Ajax model. Interaction with the web-application is more �uid and attractive, there is no page �ickering or longwaits between user actions. Ajax can be used for various purposes such asupdating or deleting records; expanding web forms; returning simple searchqueries; or editing category trees, all without the requirement to fetch a fullpage of HTML each time a change is made. Generally, only small requestsare required to be sent to the server, and relatively short responses are sentback. This allows the development of more interactive applications featuring



Figure 1.2: User activity with Ajax

more responsive user interfaces due to the use of DHTML techniques.

Problems

The new user interaction style of Ajax application can easily break the ex-pected behavior of the browser's back button. Users generally expect thatclicking the back button in web applications will present the previously loadedpage but, in Ajax applications, this might not be the case. Ajax applicationsare typically single page web-applications and the back button will exit therunning application to the last visited page, which is not what the user ex-



pected. Solutions exist (using IFrames) to populate the history of visitedpages used by a browser's back button. The dynamic web pages updatesare also a problem for bookmarks. This can be solved serializing the stateof the application in text format and appending it to the application URL.However, it is not easy to serialize the state of the whole application in textformat.

Another problem of Ajax is that it requires users to have JavaScriptenabled in their web-browsers. JavaScript can also be a problem in termsof browser compatibility and can be di�cult to handle by inexperiencedprogrammers.

Ajax siblings

Ajax stands for Asynchronous JavaScript And XML. The XML part refers tothe use of XML to transport data that is transformed using XSLT templates.Other variants of Ajax appeared to solve other speci�c problems. AJAH orAsynchronous JavaScript and HTML for example, requests small portions ofrendered HTML to the web-server for incremental interface rendering. Theonly thing that the web-browser needs to do is to update regions of the web-page with the provided HTML. Another approach is AJAJ, or AsynchronousJavaScript and JSON, which use JSON, the JavaScript Object Notation,to transport data between the web-server and the web-browser. JSON is atextual representation of JavaScript objects that, when evaluated by a web-browser, it is automatically mapped into a native JavaScript object whichcan be handled easily and transparently. JSON is useful to transport andhandle data, especially for data manipulation in the web-browser.

1.2.2 Web presentation

Web presentation is responsible for presenting the data of the applicationin a graphical form, visible to the user. Di�erent patterns and techniquesexist to build this part of the web-application, some of them are easier toimplement but less �exible and others are more �exible but more complex andharder to implement. All of these techniques rely in one principle: all dataaccess, manipulation and transformation is done in the server, and the clientonly needs to present the processed data. With the actual model of web-applications, each user action entails one request to the web-server, even if theaction represents just a small change in the user interface. The response sentback to the client contains the whole page with the new screen of the interface.Current Ajax applications send requests to the web server and upon receivingeach response update only sections of the user interface, allowing it to be built



has needed. This approach reduces bandwidth and enhances the interactionwith the web-application. New web-applications that are now being builtwith Ajax use these concepts, updating sections of the interface and doingsome data validation asynchronously. These applications are known by thecommunity as Web 2.0 applications. Web 2.0 is not a standard, it's onlya new acronym that appeared in the community to identify this kind ofapplications.

This work wants to go further, enabling a new paradigm shift in thedevelopment of web applications. One of the main goals is to develop web-applications in the same way that desktop applications are developed. Thebrowser will not only serve to present HTML to the user, but will also behaveas an active component of the application. Ajax technologies will be the toolsto develop this type of web applications since Ajax and the XMLHttpRequestare currently the only way for the web browser to access the web serverasynchronously.

1.2.3 Web 2.0

With its allusion to the version numbers that commonly designate softwareupgrades, Web 2.0 was a trendy way to indicate an improved form of theWorld Wide Web. Web 2.0 usually refers to a second generation of servicesavailable on the World Wide Web that let people collaborate and share in-formation online. In contrast to the �rst generation, Web 2.0 gives usersan experience closer to desktop applications than the traditional static Webpages. The term was popularized by O'Reilly Media and MediaLive Interna-tional as the name for a series of web development conferences that startedin October 2004. Web 2.0 applications often use a combination of techniquesdevised in the late 1990s, including public web service APIs, Ajax, and websyndication. To some extent, Web 2.0 is a buzzword, incorporating whateveris newly popular on the Web and its meaning is not clearly de�ned.

1.2.4 JavaScript

JavaScript is a lightweight, interpreted programming language with objectoriented capabilities. JavaScript follows the ECMAScript 262 [3] languagespeci�cation and became popular for web programming because many browserscontain an implementation of this language. This scripting language allowsexecutable content to be included in web pages. A web page needs no longerbe static HTML, but can include programs that interact with the user, controlthe browser, and dynamically create HTML content. However, ECMAScript



262 speci�cation lacks a packaging and inheritance system. The next EC-MAScript speci�cation will include packaging and inheritance mechanisms,but these features that are essential for code reuse and ease of developmentaren't available at this moment. To solve this, a modular code loading andclass system were implemented.



Chapter 2

Solution design

After exploring the technologies related to Ajax and identifying their capa-bilities and limitations, the next phase of this work was to establish the goalsand requirements of the project.

With the Ajax hype, a huge number of tools and libraries were devel-oped. Many of them were designed to support speci�c domains, such as userinterface design or XMLHttpRequest wrappers. Others, to simplify the de-velopment of web 2.0 applications. This hype also contributed to the rebornof the JavaScript language.

At the beginning of this project, none of those tools were capable enoughto create web-applications in the way that desktop applications were devel-oped. One of the major goals was to create a framework or platform to enablethe development of web-applications with the same work-�ow and e�ort asdesktop applications are developed. To achieve this, many solutions andarchitectures were studied, designed and adapted to �t these requirements.

2.1 Goals

This section contains an enumeration of the main goals to achieve in thisproject. They serve as guidelines to design the �nal solution described laterin this document.

2.1.1 Main goals

• Develop web-applications the same way as desktop applications.

• Modular platform.

• Independent modules can be used in di�erent contexts.



• Integration with legacy systems.

• Client implementation independent from the server.Both must implement and respect the de�ned communication pro-

tocol.

• Transparent interaction with server objects.

• Entity changes can be noti�ed to the client.

• Presentation and application control can be done by the client.

• GUI system based on SWT, Swing and JFace.

2.1.2 Presentation and user interaction

• Single-page web-application. One page is loaded and incrementallyupdated.

• Maintain browser behavior.Back, forward and bookmarks must be operational to maintain

behavior.

• Simulate continuations locally.Application work-�ow can be controlled by the client, it should

be possible to go back in the history, make some modi�cations andcontinue the application with the new data. Checkout is a typicalexample of this feature.

• Component rendering can be done with XML templates to be more"web-designer friendly".

2.2 Web Operating System approach

To develop web-applications the same way as desktop applications, the �rstapproach was to create a virtual operating system integrating the server andclient in one component to deliver a common programming interface (see�gure 2.1).

Applications are developed to run over this virtual operating system. Theclient application is responsible for the presentation and control of data, theserver contains business logic and other private processing not accessible tothe client.



Figure 2.1: WebOS architectureThe WebOS provides an API to develop web-applications as they wererunning in only one computer. The WebOS is implemented over a vir-tual kernel from the web-server and the web-client. These virtual kernelsemulate services provided from real operating systems.

The concept of virtual operating system �ts well to dissimulate a conven-tional web-browser in a virtual computer with the capacity to run complexapplications.

The communication is done over a common protocol to enable cross-platform development. Each application node can run over di�erent plat-forms and still communicate between them with this protocol.

The API provided does not depend on the browser where it's running(see �gure 2.2). Applications developed to run over the WebOS should runon any browser with JavaScript enabled.

Figure 2.2: Cross-platform WebOSApplications run over the Web Operating System. The web-browser We-bOS implementation contains a cross-platform layer to run on di�erentweb-browsers.



2.3 Kiron approach

The virtual operating system approach has the problem of being restrictiveto the domain of complex web-applications. In some cases it's useful to havea more �exible platform with similar features to develop simpler applicationseasily. Basically, the virtual operating system approach does not match therequirements of a modular platform, where its modules can be used in dif-ferent contexts. It is also di�cult to add features to old web-applicationswith this approach. To solve these problems, a new architecture was de-signed to accomplish all the de�ned requirements of the project. This newarchitecture, named Kiron, splits the virtual operating system approach intoseparate and independent modules. A WebOS can be implemented over theKiron platform as a Kiron web-application.

The Kiron platform is the �nal solution of this work and is discussed inthe following chapters of this document.



Chapter 3

Development methodology

The �rst phase of this work was spent researching the current technology andsolutions related to Ajax and rich Internet application development. Regularmeetings with the adviser professor were made to discuss solutions and ideas.This work was developed in enterprise context giving a great feedback to theprogress of the project.

After analyzing the state of the art, many solutions were sketched andexperimented. With the desktop application development model in mind,the �rst attempt was to design a virtual web operating system to providethe necessary base to develop rich Internet applications. After some discus-sion and observations in the enterprise environment this solution proved tobe too complex and hard to integrate with other applications. With thisinformation, the solution was redesigned to support these requirements. Thenew solution consists of a modular platform providing the necessary servicesand features to develop web-applications with the �exibility of desktop ap-plications and the power of distributed applications but without the extradevelopment e�ort.

When the functional prototype was completed, it was presented to theVILT team to discuss the solution and possible problems. One problempointed by the team was the di�culty to handle JavaScript and developlarge applications using this language. The lack of packaging and inher-itance system was a hindrance to the development of reusable JavaScriptapplications. This was the main motivation to create an alternative to theprototype language approach of JavaScript [4] and to create a wrapper forClasses and inheritance around the JavaScript prototypes. Some time laterthe work in progress was presented to the INESC-ID Software Engineeringgroup. After the discussion with the team, the transactional support waspointed as a problem to be solved for concurrent applications with sharedobjects and partial web-page rendering.



The project proceeded with three days of work per week with VILT aswell as bi-weekly meetings with the adviser professor. All of these meetingscontributed to the design and implementation of the �nal solution. As newAjax tools were emerging, a lot of time was spent reading and learning thesetools.

3.1 Development roadmap

In the development of this work, a wide range of topics and technologies wereinvolved, including: web-application development, networks, distributed ap-plications, programming language design, and graphical user interfaces de-velopment.

This section starts with an enumeration of problems related to the projectrequirements and references to their solutions.

The development roadmap is divided in four main subsections: (1) In-teraction with server objects, (2) Data communication abstraction, (3) Peerto peer approach, and �nally, (4) the Web-browser application developmentsubsection.

To develop web-applications with the same model of desktop applications,it is essential to have a mechanism to interact easily with server objects fromthe web-browser. The subsection entitled �Interaction with server objects�describes problems and solutions related to remote method invocations andRPC between the web-browser and web-server.

After solving problems related to server objects interaction, the need fortransparent data communication was obvious. Subsection �Data communi-cation abstraction�, enumerate problems related to data communication be-tween the web-browser and web-server using Ajax technology. The solutionfor this problem passed through the development of a virtual network.

With transparent data communication and remoting capabilities betweenthe web-browser and web-server, the next challenge was to bring functionaluniformity between the web-browser and the web-server. That is, give clientand server functionalities for the web-browser and web-server. Network nodeswhich behave like clients and servers at the same time are known as peers.Subsection �Peer to peer approach� discusses problems and solutions relatedto this approach.

The last subsection, Web-browser application development, describes prob-lems and solutions related to JavaScript application development.



3.1.1 Interaction with server objects

The ability to interact with web-server objects as if they were local to theweb-browser can result as a great improvement in web-application develop-ment. With this approach the web-browser wouldn't act as a HTML rendereranymore, it would act as an active component of the application, handlingapplication logic and control of the web-application. Complex data handling,validation and control can be done with this solution.

To achieve this, the �rst thing to do was to create a remote method in-vocation system using the XMLHttpRequest object. The very �rst solutionused XML to transport data between the web-browser and server. Serverimplementation was made in Java with marshaling and unmarshaling of sim-ple primitive data. Remote objects were kept in a table with an associationbetween their remote and local references. JavaScript invocations build therequest with XML that is interpreted by the web-server which make the cor-rect method invocation to the referenced remote object. Unfortunately, han-dling XML for data manipulation can be very painful for the web-server andweb-browser. To solve this problem the JSON format was adopted, whichis a cleaner and easier way to interchange data between two endpoints. Formore details about this choice see 4.2.4 Data Representation section.

Object serialization

After choosing JSON to transport data between the web-server and browser,the next phase was to increase the functionalities of the remoting system. Toachieve this, data objects returned from method invocations were serializedinto JSON for web-browser handling. Classes marked as serializable aretransformed into JSON, in Java their slots are obtained using the gettermethods of the class. This process is done in the response marshaling phase.

Remote proxies

Automatic object serialization is a powerful mechanism to interchange struc-tured data between the web-server and web-browser transparently. But thisapproach can be problematic if data objects are big, and worse, if more dataobjects are included with them. A simple remote method invocation couldsend a huge amount of data that is mostly irrelevant for the actual call.

To solve this problem, a remote proxy [5] approach was implemented.When remote method invocations return an unserializable object, this objectis kept in a remote object table with its remote and local reference. The datasent to the web-browser contains information about the remote object andhow to access it.



With this approach the client requests for data as it needs it, avoidinguseless data transfers. Suppose, for example, a large collection of items thatis mapped into a table on the user interface. With this approach data canbe sent only when the user scrolls the table up and down.

For more detail about the implemented remoting solution see section 4.3.

Dynamic proxy representation generation

The remote proxies for remote object access bring another problem that mustbe solved: To build a remote proxy, the web-browser, or the client of theremote object, needs a class representation with its method signatures. Toavoid manual stub generation, a dynamic proxy generation was implemented.If the web-browser does not contain the representation of the remote objectit asks the remote object owner to provide it. The representation is built andloaded dynamically on the client. With this approach if a remote methodinvocation returns an object that the browser cannot handle, the browserasks the remote object owner for its representation to be able to handle it.

For more details about dynamic proxy generation see section 4.3.6.

Repetitive HTTP Requests

Successive remote method invocations are translated into lots of HTTP re-quests that can overload the network and web-server. Since many remoteinvocations can be made in a short period of time, these invocations are keptin a con�gurable temporal bu�er that holds the requests and dispatch themall at once when the timeout expires. For critical data retrieving it is possibleto �ush the requests immediately.

Freeing up Memory

Remote objects that are kept on the server spend memory. When objectsare not referenced or used by anybody they must be freed up to avoid mem-ory leaks. For details about memory management and distributed garbagecollecting go to section 4.3.8.

Shared objects and method noti�cation

Remote objects that are shared by multiple remote proxies must be awareof concurrent modi�cation. To achieve this, a simple object locking andmethod invocation noti�cation system was implemented. These mechanismsare useful to track user activity on shared objects.

For further details see section 4.3.9 and 4.3.10.



3.1.2 Data communication abstraction

At the very beginning of this work, remote method invocations were madedirectly over the XMLHttpRequest object. For data interchange and com-munication without using remoting capabilities it was required to use theXMLHttpRequest directly. Using XMLHttpRequest directly can be painfulbecause the programmer must be aware of the state of the request, dispatch-ing and handling request response in di�erent contexts. To solve this problema socket emulation layer was implemented over the XMLHttpRequest object.With this layer it is possible to interchange data over simulated independentchannels.

For more details go to section 4.2 and 4.2.4.

Multiple client handling and dispatching

The creation of a socket emulation layer brings new challenges and problems.It is necessary to create a virtual network to connect endpoints together usingvirtual sockets. Data must be sent in packets and dispatched over the networkto the correct destinations. To do this, a common format to interchange datawas designed and a virtual routing system to dispatch the data packets wasimplemented.

This is discussed in more detail in section 4.2 and 4.2.1.

Building a virtual network

A virtual network means in the simplest approach having a link, transport,and application layers. This three-layer approach is based on a simpli�cationof the OSI network model [6]. The link layer is discussed in section 4.2.2,transport layer in 4.2.3 and application layer in 4.2.4.

Communication with external processes and computers

To enable a web-browser to communicate with external processes they mustbe available and reachable in the virtual network. To do this, the externalprocess must use the socket emulation layer to be able to act as an endpointin the virtual network. Go to section 4.2.1 for details about the solution tothis problem.

Handling client disconnections

When a client connects to an endpoint, the server must handle the connec-tion, consuming memory and processing power. Clients can orderly close



their connection, thereby allowing the server to release its own end of theconnection, thus freeing the used resources. Unfortunately this approach isnot su�cient if the client crashes or does not close the connection properly.To solve this problem, a lease system is used on each connection.

For more details about this topic, go to the Connection leasing subsectionin section 4.2.4.

Communication optimization

Most of the time, one endpoint sends a collection of packets at-once. Sinceeach packet contains source and destination information, redundant data issent over the network. To solve this problem a data compression layer isimplemented at a lower level which is responsible for compacting the datawith a common source and destination, avoiding redundant data replication.

For more details about this topic see Packets subsection in section 4.2.4.

3.1.3 Peer to peer approach

The client-server remoting approach brings a powerful development modelto create web-applications. An additional improvement could be made ifany endpoint of the virtual network could act as a client and a server at thesame time. This approach would increase the uniformity of the whole systemgiving equivalent functionalities to any endpoint of the web-application.

This was the next step of the project development: to bring functionaluniformity to all virtual network endpoints. At the lowest level, the web-browser must implement KServerSocket funcionalities to be able to act as aserver (see sections 4.2.4 and 4.4.1). To expose its objects to other peers thenext thing to be implemented on the web-browser is the RMIServer, which isresponsible for exposing objects to RMIClients (see sections 4.3.2 and 4.4.2).

3.1.4 Web-browser application development

The web-browser is the access point for web-applications. The only wayto develop applications to run on a web-browser without plugins is withJavaScript. JavaScript lacks a packaging and inheritance system. On theother hand, HTML alone is not expressive enough to create rich user inter-faces similar to desktop applications with windows, menus and other widgets.

These problems and their solutions are discussed in the next subsections.



Developer friendly JavaScript

As application logic complexity grows in the web-browser, code reuse andsharing is a must. Unfortunately, JavaScript lacks a packaging system andits prototype approach is not easy to use for the purposes of code reuse.

To solve this problem a JavaScript dynamic module loading and classwrapper were implemented. Go to section 4.4.5 for more detailed informationabout this topic.

Rich User Interfaces

In order to allow creating rich interfaces with look and feel similar to desktopapplications, it was necessary to implement a graphical user interface systemto run in the web-browser. The solution was to implement a graphical userinterface system in JavaScript and a markup language to ease the construc-tion of these interfaces. For more details about this solution go to section4.4.3.



Chapter 4

Kiron

Kiron is a development platform for next generation web applications. Thisplatform enables the development of rich Internet applications and Ajax ap-plications with minimal e�ort, using the same concepts used for desktopapplication development.

4.1 Architecture

This section describes the architecture of the Kiron platform (more detailedexplanations can be found in the subsequent topics). Initially, the architec-ture is presented at a global level and then more speci�cally at peer level.

4.1.1 Global architecture

Kiron represents a middleware [7] layer to develop distributed web applica-tions (see �gure 4.1). The middleware provides di�erent technological speci�cimplementations to glue applications together with common communicationprotocols. Kiron middleware is placed bellow applications and over operatingsystems, virtual machines or other speci�c technology. The Kiron platformprovides a high level of abstraction enabling the developer to build applica-tions as if they were desktop applications.

One of the most powerful features of this middleware approach is the pos-sibility to develop applications with speci�c technologies. For example, anapplication with access to the MSN instant messaging protocol can automat-ically share this feature to other applications. Kiron.ECMAScript, whichruns in a conventional web browser, could access MSN instant messagingeasily and transparently.



Figure 4.1: Kiron middlewareKiron middleware is situated between operating systems or virtual ma-chines and applications. It is built with various technological speci�c peers.Applications can be implemented over this peers.

4.1.2 Peer architecture

Applications developed with the Kiron platform are composed by peers thatcooperate between them to produce the desired computations. Kiron wasdesigned with platform independence in mind: peers are glued togetherwith independent communication protocols. Peers can be implemented inany language as long as they respect the designed protocols. One of theimplementation is Kiron.ECMAScript, which corresponds to a peer imple-mentation in JavaScript intended to run on a conventional web-browser.Kiron.ECMAScript can communicate with others peers using the power andlanguage features provided from them.

Peers under Kiron represent units of execution in a distributed environ-ment: they behave like servers and clients at the same time (see �gure 4.2).For communication purposes, peers can exchange data over a virtual networkwith independent channels or at a higher level, sharing objects using remot-ing capabilities. In the next sections the virtual network and remoting arediscussed in more detail.

Currently, the Kiron platform contains peers implementations under theJava Virtual Machine, .NET Framework and ECMAScript.



Figure 4.2: Kiron peer architectureEvery peer support two main features: The KVN, or Kiron Virtual Net-work, for communication purposes, and remoting to ease the developmentof distributed applications. The KVN is implemented with two layers.The transport layer exchange data over HTTP or directly over TCP/IP.KSockets are implemented over the transport layer and exchange datawith JSON. The remoting functionality is built with one RMIServer. TheRMIServer can contain RMIClients. RMIClients can connect to otherpeers RMIServer. Communication between RMIClient and RMIServer isdone over the KVN with JSON.

4.2 Kiron Virtual Network

The Kiron platform provides a virtual network for communication purpose.This solution enables bi-directional communication over independent chan-nels. A socket emulation layer provides this channel independence, with thesame concepts of real sockets over IP networks.

The virtual network topology is de�ned with one or more KRouters, whichare responsible to dispatch packets over the network (see �gure 4.3). Eachendpoint has an attributed network address managed by one KRouter. Thisaddress corresponds to 32 bits of data and their meaning is de�ned with thepacket routing rules of each KRouter.

Endpoints under the KVN, or Kiron Virtual Network, can communicatewith applications outside the virtual network if one of the endpoints acts as a



Figure 4.3: KVN - Kiron Virtual NetworkThe KVN support communication between Kiron peers. KRouters are re-sponsible to dispatch data packets to their destinations. Kiron peers mustbe connected to a KRouter to be available to the network. Data can besent between any peer over the network, regardless of their implementa-tion. Communication can be done over HTTP or directly over TCP/IP ifpossible.

bridge to other networks. For example, an endpoint can act as Telnet bridgeto the KVN enabling any endpoint to access other services via telnet.

This approach can be very powerful because all implementation speci�cendpoints can be integrated in the virtual network. Any new applicationdeveloped under a speci�c language or technology can connect to the virtualnetwork, sharing its features to other applications. Taking the telnet bridgeexample, with this endpoint connected to the virtual network it is possible toaccess telnet services from a web-browser connected to the virtual network.

4.2.1 KVN nodes

The Kiron Virtual Network is built with network nodes. These nodes can beKiron peers or KRouters and both can be implemented over any speci�c tech-nology (see �gure 4.4). Nodes implemented with di�erent technologies can



communicate with each other using independent communication protocols.

Figure 4.4: KVN NodesA KVN node represents an endpoint in the virtual network. A KVN nodecan be a Kiron peer or a KRouter. Kiron peers and KRouters are imple-mented over speci�c technologies.

Kiron peer

A Kiron peer acts like a client and server at the same time. It provides abase of platform independent features to connect applications together (See�gure 4.2).

KRouter

To create and manage one Kiron Virtual Network there must be at least oneKRouter to connect Kiron peers together. The KRouter is responsible fordelivering packets over the KVN to their correct destinations. It acts likea node over the virtual network where other KRouters can be connected.(Figure 4.3). Packets are dispatched between them following the de�nedrouting rules. This is useful to balance load over large systems.

Connections to the KRouter can be done over HTTP, TCP/IP or withdirect local connection. Connections over TCP/IP are used when peers aredistributed over di�erent computers. Direct local connection is used whenpeers and the KRouter are running on the same computer.

External applications can connect to the KRouter and communicate withother nodes over the KVN. Figure 4.5 shows an example of a terminal sendingdata directly to the web-browser.

4.2.2 KVN link layer

In IP networks the physical layer de�nes the cable or physical medium itself,connecting network nodes together. The virtual network does not have anycable or physical medium. The KVN runs over IP network which acts as a



Figure 4.5: Communication with external applicationsIn this picture we see an external application sending data directly to theweb-browser.

support for the KVN virtual link layer. Endpoints in the KVN are connectedover IP networks.

4.2.3 Transport layer

The transport layer is responsible for delivering data between peers; it canbe implemented over HTTP/S or directly over TCP/IP, depending on theinvolved peers. For example, Kiron.ECMAScript peer might be running inthe browser and communicate with Kiron.JVM and Kiron.NET with HTTP.Kiron.JVM can communicate with other Kiron.JVM and Kiron.NET peersdirectly with TCP/IP. Basically, the transport layer depends on the peer im-plementation. Kiron.ECMAScript has its transport layer implemented withHTTP because it's the only way to transfer data to/from a web browser. Fordirect communication between peers the transport layers must be compati-ble, Kiron.JVM and Kiron.NET are implemented over HTTP and TCP/IPenabling direct communication with Kiron.ECMAScript.

4.2.4 KSockets application layer

The Application layer is closest to the end user. It provides a way for theuser to access information on the virtual network through an application.This layer is the main interface for the user to interact with the application



and therefore the network.To exchange data over the virtual network the solution was to implement

a system similar to sockets over IP networks. The Kiron Sockets, or KSock-ets, have a similar behavior to common sockets. A KServerSocket listens forKSocket connection requests and creates a new KSocket for each new con-nection. Data can be sent between KSockets in any direction simulating adedicated communication channel.

Data representation

In order to interchange data between peers with di�erent implementations thebest solution is to use plain text for data representation. Kiron.ECMAScriptpeer represents one of the most important components in Kiron and in�u-ences the choice for data representation format. This peer uses XMLHttpRe-quest to transport data over HTTP and can handle data in plain text or inXML. In order to exchange structured data in text format the most widelyused format is XML, but its manipulation can be very painful. Anotherway to exchange structured data in text format is to use JSON. JSON, orJavaScript Object Notation is a very lightweight format for data interchange.It has the advantage to be very easy to handle, especially with JavaScriptwhere the structured data can be mapped directly into a JavaScript object.Many implementations of JSON already exist for di�erent languages: Ac-tionScript, C, C++, C#, ColdFusion, Delphi, E, Erlang, Java, JavaScript,Common Lisp, Lua, Objective C, CAML, OpenLaszlo, Perl, PHP, Python,Rebol, Ruby and Squeak.

Due to the fact that current browsers only support JavaScript, it is al-ways necessary to provide a Kiron implementation in JavaScript, namelyKiron.ECMAScript. As a result, JSON is a good choice for data representa-tion. Moreover, JSON can be translated to XML very easily.

Packets

Data is transmitted between peers in a packet format which contains theorigin, destination and body of the message. Packets are transmitted overKSockets where the origin and destination of each packet contains the hostand port of the respective KSocket. Packet representation is done usingJSON format for ease of manipulation and uniformity with the rest of thesystem. Internally, all packets contain their source and destination, but foroptimization purposes collection of packets with common sources and desti-nations have their message body associated with only one source and desti-nation, avoiding data replication. This compression is handled automatically



by the communication layer and is transparent to the programmer. At theapplication level, every packet has one source and one destination.

Connection leasing

KSockets are connected to other peers KSocket's. When one peer is gone,it must notify the other to release its KSocket. This noti�cation can bedone when the peers still exist in the network or when it does not need itanymore, but if it crashes no noti�cation is sent and the KSocket lives foreveron the other peer. To solve this problem, a leasing approach was adopted.Each created KSocket connection is leased and the client must renew thelease of the other peer KSocket. If the lease is not renewed the KSocket isautomatically closed and removed, solving the problem of client crashes.

Sample code - ChatServer

The example presented as Program 1 illustrates the use of KSockets over theKVN. It's a simple broadcasting server where all received message are repliedto all connected clients. KSockets are leased resources, the entity responsiblefor handling connected sockets must be aware when they are closed or nolonger used.

Program 1 ChatServer in Java

public class ChatServer implements IConnectionListener, ISocketListener, ILeaseListener {

private ArrayList connectedClients = new ArrayList();

public ChatServer(int port) {

KServerSocket socket = new KServerSocket(port);

socket.setConnectionListenner(this);

}

public void accept(KSocket socket) {

connectedClients.add(socket);

socket.addSocketListener(this);

socket.addLeaseListener(this);

}

public void dataReceived(KSocket socket) {

Iterator it = connectedClients.iterator();

while(it.hasNext()){

KSocket destination = (KSocket)it.next();

destination.send(socket.getReceivedMessage());

}

}

public void resourceExpired(LeasedResource resource) {

connectedClients.remove(resource);

}

}



Program 2 ChatClient in JavaScript

var chatSocket = new KSocket(host, port, function(data_received){

print(data_received);

})

buttonHandler = function(){

chatSocket.send(getMsg());

}

button.addActionListener(buttonHandler);

Figure 4.6: Kiron Instant MessagingIn this picture we see chat clients running in two web-browsers. Messageare dispatched between them trough the Kiron Virtual Network.

Figure 4.6 represents a chat application demo running on a WebOS.

4.3 Remoting

The Kiron remoting elevates network programming to a higher level. Aprimary goal for Kiron remoting was to allow programmers to develop dis-tributed programs with the semantics used for non-distributed programs. Todo this, a remote proxy [5] approach was adopted. Clients can have a proxyof any server object to interact with it. Proxies can be sent between peers,when needed each peer resolves the proxy and connects to the owner of theobject. Peers implemented in languages with introspective capabilities cangenerate and load proxy representation dynamically. Another approach toaccess server objects without remote proxies is to send the serialized object



to the client. With this solution, the client has access to all the data and theserver does not need to handle remote references.

4.3.1 Kiron Remoting Architecture

This section describes the Kiron remoting architecture. The Kiron remotingimplementation is essentially built from three abstraction layers. The �rstis the RMIClient and RMIServer layer, which lies beneath the view of thedeveloper. This layer intercepts method calls made by the client to theremote proxy and redirects these calls to a remote object.

The next layer is the Remote Reference Layer. This layer manages refer-ences made from remote proxies to remote objects. Remote proxy referenceresolving is done in this layer (go to section 4.3.4 for more details).

The transport layer is based on the virtual network and provides basicconnectivity.

Figure 4.7: Kiron remoting architectureKiron remoting is built from three abstraction layers. The RMIClientRMIServer layer are used by remote proxies that make requests to remoteobjects. The Remote Reference layer manages references for remote proxyresolving. The Transport layer runs over the virtual network and providespeer connectivity.

RMIClients connect to RMIServers to access server objects. RMIClientsare contained in RMIServers for proxy resolving purposes (�gure 4.8).

Suppose, for example, that on a remote method invocation the RMIServerneeds to resolve a proxy, it must access the correct RMIClient to access theremote object. New RMIClients are created only if they are not already inthe RMIServer's collection. RMIClient and RMIServer are discussed in moredetail on the next sections.

Like communication protocol, remoting protocol is platform independent.



Figure 4.8: RMIServer and RMIClientRMIServer exposes peer objects to other peers RMIClients. RMIServercan contain various RMIClients for remote proxy resolving. This occurswhen a remote method invocation contains a remote proxy of another peer.

4.3.2 RMIServer

The RMIServer is responsible to provide access to peer objects. Only oneRMIServer exists per peer. Unmarhsaling and marshaling of data, objecthandling and method invocation is done by the RMIServer. RMIServer con-tains one component to handle remote objects and another to count objectreference and handle object noti�cations.

Entity Manager

The entity manager has the responsibility to handle remote object referenceover the distributed system. One entity manager is created and associatedto each RMIClient, containing the remote object reference handled by thisclient. Basically it acts like a table with objects mapped with their remotereference. The connection is handled with one KSocket. When the KSocket isclosed, the respective entity manager is freed up, removing all remote objectreferences handled by the respective client.



Reference Counter and shared objects

As described earlier, RMIServer contains one entity manager for each con-nected RMIClient. In some situations the same object can be used by di�er-ent clients and references must be counted to know when the object is notused by anybody. To achieve this, RMIServer contains one reference counterto track shared objects. When one object is referenced by one new clientthe counter is incremented and when it is not used anymore the counter isdecremented. When the counter reaches zero it is secure the remove and freeup the remote object.

It is possible to be noti�ed when methods of shared objects are invoked:this is done with the shared objects manager who keeps track of the regis-tered method observers for further noti�cation. More detailed explanation isdiscussed in the Method noti�cation section.

4.3.3 RMIClient

This component connects to RMIServers to access entities from other peers.Marshaling and unmarshaling of data is done here too. The provided inter-face is used by object proxies. RMIClients are contained in RMIServer forobject resolve purposes. When an RMIServer receives a proxy of an objectfrom another peer a new RMIClient is created and connected to it to accessthe remote object.

4.3.4 Remote Reference Layer

Every proxy contains information about the owner, class name and referenceof the remote object. This data can be serialized and sent to other peers.When needed this information is su�cient to resolve and access the remoteobject. This procedure is done automatically by the remoting system whichautomatically creates one RMIClient and connects it to the remote objectowner.

4.3.5 Transport Layer

The Transport Layer provides connectivity support. RMIServer is imple-mented over a KServerSocket to listen for client connections and communi-cate with them using KSockets. RMIClients create one KSocket connectionto the KServerSocket from the RMIServer.



4.3.6 Proxy dynamic loading

One peer can request another one to provide a representation of one of hisclasses. When a client needs a class representation to access a remote object,the RMIClient asks for the class representation and loads a remote proxyautomatically. This feature is useful when a remote method invocation re-turns objects as proxies and the client does not know the returned objectsrepresentation. Suppose, for example, that a client requests a collection ofbooks. Books are returned as remote proxies, and the client does not knowtheir class representation. In such situations, the RMIClient automaticallyasks the server for the Book class representation and loads the books remoteproxies dynamically.

Peer implemented over dynamic languages can load proxies dynamically,in opposition to static languages that must load them o�ine or with a just-in-time compiler and linker.

Publish and subscribe with broker

Consider a group of publishers responsible to publish contents to a brokerand another group who subscribes to speci�c contents. Contents are objectscreated by publishers who own the object. When they publish the contentthey are stored as proxies in the broker. When the subscriber receives thecontent proxy, it must connect to the owner of the content to access it. Thisis done automatically by the Kiron remoting mechanism.

4.3.7 Asynchronous vs. synchronous

Remote method invocations between peers can be done synchronously orasynchronously. Synchronous access locks the peer that made a request toanother maintaining a similar development behavior of local applications.Waiting for the response of another peer can be problematic, especially ifpeer implementation does not support threading. The solution is to makeasynchronous calls to peers with an associated handler for further execution.This approach is especially useful with the Kiron.ECMAScript peer, since itis not yet possible to have multithreading in a browser application.

In order to implement remoting with asynchronous calls, the system cre-ates an object with a slot that will be �lled with the future value and anhandler that is responsible to process the received value.



4.3.8 Distributed Garbage Collection

In order to free up memory used by applications, objects must be deletedto release space for others. On local applications this can be done manu-ally or automatically with a garbage collector that frees up unused objects.Garbage collectors use di�erent strategies, but all of them rely in one prin-ciple: objects are garbage collected only if they are not referenced in therunning application. Knowing if an object is not referenced in a local ap-plication can be easy, but in a distributed scope this can be a very complextask. Using the reference counter approach, an object can count its referencefrom distributed applications, but what happens if the application owningthe reference crashes? The object would never be garbage collected.

To solve the problem of distributed garbage collection a lease approachwas adopted. Each created object gets a lease with a limited time period.The owners of references to the object are responsible for renewing this lease ifthey want to continue using the object. Periodically, the distributed garbagecollector checks the leases of each distributed object and if it has expired theobject is deleted. Network latency must be considered to avoid situations ofleases that are not renewed in time and the object continues to be referencedby another application. This approach solves the client crash problem.

In some situations it is possible that objects have references to each otherforming circular references. Circular references in distributed applicationsare not as common as in local applications. The lease approach does notsolve this problem and objects can live forever if they have circular references.However, if one of the endpoints is disconnected, the lease will not be renewedand the objects in the circular reference will be garbage collected. We canmake this assumption because web-browser clients are volatile endpoints andsituations with circular references are not common.

Besides automatic garbage collection it is also possible to manually no-tify that an object is not in use. This is useful in clients which are imple-mented with languages that does not have object �nalization capabilities.Kiron.ECMAScript is an example where object �nalization is not availableand objects are released manually or with distributed garbage collection onclient disconnection.



4.3.9 Method noti�cation

The remoting protocol has a noti�cation system at the method scope of anyshared object, enabling one endpoint to listen for method invocations of aspeci�c object. This noti�cation system is based on the observer pattern[8] and every proxy can attach an observer to a speci�c method. When themethod is invoked, the update method of all registered observers is calledwith the passed method parameters and the caller address. This mechanismis useful for concurrent and collaborative applications to monitor and actwhen shared objects are manipulated.

4.3.10 Concurrency

Every remote object can be locked for restrictive access to one peer. Thelock is temporary and must also be renewed to avoid endless object locks.This is a very simple mechanism for temporary ownership over one sharedobject and more work can be done at this level. This is discussed in FutureWork section.

4.3.11 Security

To make an object available to other peers that permission should be ex-plicitly de�ned in a con�guration �le or by using language annotations, ex-pressing which classes and methods are remotely available. It is possible toturn o� all these restrictions which is particularly useful during the projectdevelopment stage.

4.3.12 Sample code

Program 3 illustrates how Kiron.ECMAScript can access Kiron.JVM objectsremotely. The Java program has a simple de�nition of a class hierarchy anda service provider. The JavaScript program accesses the service and gets acollection of remote objects.



Program 3 Vectorial shapes in Java

public abstract class Shape{

private Point position;

public Shape(Point position){

this.position = position;

}

public Position getPosition(){

return this.position;

}

}

public class Circle extends Shape{

private float radius;

public Circle(Point position, float radius){

super(position);

this.radius = radius;

}

public float getRadius(){

return this.radius;

}

}

public class VectorialPictureProvider{

public static Collection getShapes(String pictureName){

//Retrieve from file or DB the picture data

}

}

Program 4 JavaScript accessing Java objects (synchronous mode)

importProxy("VectorialPictureProvider"); //Request server to obtain class representation

shapes = remote.VectorialPictureProvider("ice_cream"); //Obtain shapes collection

it = shapes.iterator(); //Obtain collection iterator

while(it.hasNext()){ //Iterate over collection

shape = it.next();

writeln(shape.getPosition().toString()); //write the position of the shape

if(shape instanceof remote.Circle){ //Check if it is a circle

writeln(shape.getRadius()); //If it's a circle, write his radius

}

}

This simple example illustrates how to use remoting on the Kiron plat-form. Its �exibility to dynamically generate proxy representations enablesthe programmer to code between the server and the client easily and trans-parently. In this example all shapes sent to the client are treated as remoteobjects, the server must track all these objects and the client must make onerequest per slot access. This approach is �exible but ine�cient. Anothermore e�cient but less �exible approach is to send all the shapes serialized at



once. To do that in Java, the classes we want to be totally serialized mustimplement the interface com.kiron.rmi.Serializable (program 5).

Program 4 is in synchronous mode, so each request blocks the client untilthe response arrives. Typically this approach must be avoided and requestsmust be asynchronous. In order to do that, Kiron provides a mechanismto make asynchronous remote method invocations. Each remote invocationreturns an object containing a slot for the future value and an associatedhandler to execute when the response arrives (program 6).

Program 5 Vectorial shapes in Java with serializable shapes

import com.vilt.kiron.rmi.Serializable;

public abstract class Shape implements Serializable {

...

}


public static Shape[] getShapes(String pictureName){


}

}

Program 6 JavaScript accessing Java objects (asynchronous mode)

//Request server to obtain class representation

importProxy("VectorialPictureProvider");

//Obtain serialized shapes asynchronously

remote.VectorialPictureProvider("ice_cream").onResponse = function(shapes){

//Iterate over shapes (they are all on the client now!)

for(var i = 0; i < shapes.length; i++){

//Iterate over shape properties

for(var property in shapes[i]){

writeln(shapes[i][property]);

}

}

}

Note that in program 5 we return an array of Shapes and we lose all in-formation of the subclasses. To avoid that we must return a SerializableCol-lection to serialize a collection of di�erent objects (program 7).

Program 7 Vectorial shapes in Java with serializable collection


public static SerializableCollection getShapes(String pictureName){


}

}



4.3.13 Remoting patterns

Here we describe some patterns and good practices to be used with Kironremoting.

Service object

The Service object approach can be useful in a situation where a statelessservice is intended. To simulate RPC with Kiron, remote services can beimplemented with static methods. For example, in program 8 arithmeticoperations are provided as static methods.

Program 8 Calculator Service Object

public class Calculator {

public static double add(double a, double b){

return a+b;

}

public static double multiply(double a, double b){

return a*b;

}

public static double divide(double a, double b){

return a/b;

}

public static double pow(double base, double exp){

return Math.pow(base, exp);

}

public static double sqtr(double num){

return Math.sqrt(num);

}

}

Shared object

If the intention is to have a single point of access or an unique object sharedamong other clients, it is useful to use the singleton pattern [9]. One simpleexample to show this is the store case. Imagine a book store which providesa collection of books and there is only one store available. Program 9 showsthis situation.



Program 9 Shared Book store

public class BookStore {

private ArrayList books = new ArrayList();

private static BookStore instance;

private BookStore(){

/** Load books **/

}

public static BookStore getInstance(){

if(instance == null){

instance = new BookStore();

}

return instance;

}

public void addBook(Book book){

books.add(book);

}

public ArrayList getBooks(){

return books;

}

}

Data transfer object

When the intention is to send data between two end-points without keepingand handling state from the data owner it is useful to use a Data TransferObject with serialized data.

4.4 Kiron.ECMAScript

The peer implementation using ECMAScript and Ajax to run on a conven-tional web browser without any plugin is discussed in this section.

4.4.1 KVN

Kiron.ECMAScript contains KSocket and KServerSocket implementation tosupport the KVN communication protocol. The transport is done over HTTPusing the XMLHttpRequest object, the essence of Ajax applications. Foroptimization purposes, packets are kept in a temporal bu�er and dispatchedonly when the con�gurable timeout has expired. With this approach manypackets are sent together with only one HTTP request. Packets arriving fromthe server are dispatched to the respective KSockets for further processing.

The peer address is kept on a browser cookie to maintain connection onpage transitions and reloads.



4.4.2 Remoting

RMIServer and RMIClient are also implemented on the browser peer, en-abling remoting in both ways. It is possible to manipulate remote objectsfrom other browsers, servers or peers. Other peers can access browser objects.

Since JavaScript is a dynamic language, proxies can be generated andloaded dynamically (Program 4).

It is also possible to cache idempotent remote method invocations. Thisis useful in collection iterations or any idempotent invocation where succes-sive object method invocations do not change the object's state. By defaultremoting cache is disabled and must be used with care and only for opti-mization purposes.

4.4.3 User Interface

To create rich user interfaces for the web a user interface system was designedand implemented. The design was inspired from SWT and AWT [10, 11]and it is built with the composite pattern to ease the composition of graphiccomponents over the interface. The root object represent one simple graphiccomponent, all widgets and interface components are specializations of thisroot component. A container of components is also a specialization of theroot component to include other components and containers.

Figure 4.9 shows some widgets that are available in Kiron.ECMAScriptand Program 10 illustrates how to create a window component in JavaScript.

Program 10 Window with a button in JavaScript

importModule("UI.*");

var win = new UI.Window(UI.TITLE);

win.setTitle("Wapplication example");

win.setSize(300,200);

var button = new UI.Button(UI.PUSH, "push me");

win.add(button);

Dynamic Cascade Style Sheet loading

It is possible to load cascade style sheets dynamically any time in the exe-cution of the application. This is useful to change styles dynamically or toload applications with their own styles.

Kiron Markup Language - KML

The Kiron Markup Language, or KML, was created to create user inter-faces in a descriptive way. With this approach, web-designers can create



Figure 4.9: Kiron Rich User InterfaceIn this picture we see an example of some widgets that are available withKiron.ECMAScript.

user-friendly interfaces, separating application logic from the interface de-scription. This approach also provides a cleaner way to integrate HTMLwith the application.

Program 11 Window with a button in KML

This is done with XSLT templates that are responsible for the transfor-mation of XML data structure into equivalent JavaScript.



4.4.4 Debugging

Kiron.ECMAScript has a built-in console and remote object browser for de-bugging purposes. The console interprets JavaScript code and is useful totest and debug code. The remote object browser shows all remote objectsof the web-server. It is possible to explore the slots of each remote object tosee what is going on with a particular object.

Figure 4.10 shows the console and remote object browser.

Figure 4.10: On browser web-application debuggingIn this picture we see the in-browser console which can evaluate JavaScriptcode in run-time, and the remote object browser that can see, in run-time,who is connected to the server and what objects they are using. It isalso possible to inspect the contents of the remote objects with the remoteobject browser.

4.4.5 JavaScript language improvements

In this section we describe some useful JavaSript language improvements thatwere made to ease development and reuse code.



Modules

A module corresponds to a portion of code that can be reused. A moduleis implemented in one �le and modules hierarchy is mapped in the directorytree. Modules can be loaded dynamically and are loaded only once.

Program 12 Dynamic module loading

importModule("MyModule"); //arguments: module_name

We can de�ne module dependencies with this mechanism. Suppose thatMyModule depends on MyBase and MyComponent:

Program 13 Module dependency de�nition

/* File "MyModule.js" */

importModule("MyBase");

importModule("MyComponent");

Modules hierarchy is re�ected by the directory structure.``/MyApplication/MyMainModule/MySubModule.js'' can be imported

like this:

Program 14 Module hierarchy leaf loading

importModule("MyApplication.MyMainModule.MySubModule");

Contrarily to the Java packaging system and namespaces in C#, it isnot possible to automatically load multiple modules by importing the parentmodule.

For example:

Program 15 Module hierarchy group loading problem

importModule("MyApplication.MyMainModule");

This will not import the sub-modules of MyMainModule, it will import: ``/MyApplication/MyMainModule.js''.

One convention has been made to solve the problem of group moduleloading. Sub-module group loading can be done using the special character�*�. For this to work it is necessary that a module with the name of the parentmodule loads the modules contained in it.


``/MyApplication/MyMainModule/MySubModule.js''``/MyApplication/MyMainModule.js''``/MyApplication/MyMainModule.js''


Program 16 Module hierarchy group loading convention

importModule("MyApplication.MyMainModule.*");

This instruction import the module ``MyApplication/MyMainModule/MyMainModule.js'' and ``MyMainModule.js'' must import modules thatare contained in MyMainModule.

Program 17 MyMainModule.js de�nition

/*...*/

importModule("MyApplication.MyMainModule.MySubModule");

importModule("MyApplication.MyMainModule.MySubModule1");



/*...*/

It is also possible to override the modules mapping from the directorytree. The table kiron.moduleMapping contains overridden modules mapping andadding entries to that table will override the module loading location.

Program 18 Overriding module mapping

kiron.moduleMapping["MyModule"] = "/Somewhere/MyModuleWithAnotherName.js";

...

importModule("MyModule");

Class and inheritance system

In JavaScript every entity is an object, but there is no mechanism to de�neclasses and inheritance in an easy and proper way. The language is powerfulenough to simulate such mechanism and every programmer adopts a strategyto implement these features. For the sake of simplicity and code uniformity,Kiron.ECMAScript has one class and inheritance system.

Classes provide abstraction and encapsulation of data. To create a class,the only required things are its name and one closure to de�ne its methods.The �rst argument of the closure contains the scope of the class, methodsand shared variables are de�ned here (the scope is the prototype object propertyin JavaScript).


``MyApplication/MyMainModule/MyMainModule.js''``MyApplication/MyMainModule/MyMainModule.js''``MyMainModule.js''


Program 19 JavaScript class creation

Class("MyClass", function(publ){

publ.init = function(){

writeln("This method is invoked when object is created");

}

publ.myMethod = function(param){

writeln("My method invoked with: "+param);

}

})

...

myObject = new MyClass();

>>> "This method is invoked when object is created"

myObject.myMethod("hello");

>>> "My method invoked with: hello"

Variables that are de�ned in the scope of the class are shared amonginstances. Instance variables must be de�ned using the keyword this to beassociated only to the instances.

Program 20 Shared and instances variables

Class("MyClass", function(publ){

publ.init = function(){

publ.share = "shared variable";

this.a = "instance variable";

}

})

...

myObject1 = new MyClass();

myObject2 = new MyClass();

myObject1.a = "foo";

myObject1.a

>>> "foo"

myObject2.a

>>> "instance variable"

myObject2.share = "shared variable changed";

myObject1.share

>>> "shared variable changed"

It is also possible to pass parameters on object creation.



Program 21 Parameters on object construction

Class("ComplexNumber", function(publ){

publ.init = function(real, imaginary){

this.real = real;

this.imaginary = imaginary;

}

})

...

myNumber = new ComplexNumber(100, pi/2);

Kiron.ECMAScript provides a single inheritance mechanism to encouragereuse of code. To create an extended class it's necessary to provide the nameof the new class, the base class and a closure to de�ne its methods. The �rstargument of the closure represents the scope of the new class and the secondargument represents a wrapper to access methods of the base class. This isuseful to call base class methods when they are overridden.

Program 22 JavaScript inheritance

Class("Song", function(publ){

publ.init = function(name, artist, duration){

this.name = name;

this.artist = artist;

this.duration = duration;

}

publ.toString = function(){

return "Song: "+this.name+"--"+this.artist+" ("+this.duration+")";

}

})

Class("KaraokeSong", Song, function(publ,supr){

publ.init = function(name, artist, duration, lyrics){

supr(this).init(name, artist, duration);

this.lyrics = lyrics;

}

publ.toString = function(){

return "Karaoke"+supr(this).toString()+" ["+this.lyrics+"]";

}

})

...

song = new Song("Ah and such", "StinkyCat", 150);

>>> "Song: And and such--StinkyCat (150)"

karaokeSong = new KaraokeSong("My way", "Sinatra", 225, "And now, the ...");

>>> "KaraokeSong: My way--Sinatra (225) [And now, the ...]"

This mechanism respects the JavaScript object system as it is possible toknow in run-time if an object is an instance of a class.



Program 23 run-time object type checking

Class("Song", function(publ){

...

})

Class("KaraokeSong", Song, function(publ,supr){

...

})

Class("Person", function(publ){

...

})

...

song = new Song("Ah and such", "StinkyCat", 150);

karaokeSong = new KaraokeSong("My way", "Sinatra", 225, "And now, the ...");

karaokeSong instanceof KaraokeSong

>>> true

karaokeSong instanceof Song

>>> true

karaokeSong instanceof Person

>>> false

song instanceof Song

>>> true

song instanceof KaraokeSong

>>> false

4.5 Kiron.JVM

Kiron.JVM is a peer implementation to run over the Java Virtual Machine.

4.5.1 KVN

Kiron.JVM has access to the KVN and can be connected to the KRouter us-ing direct local connection if the KRouter is running together with Kiron.JVM.It is also possible to connect to the KRouter using TCP/IP.

4.5.2 Remoting

RMIServer and RMIClient are present in Kiron.JVM providing remotingfeatures to other peers and accessing other peers remote objects.

4.5.3

Documents

Relatório Final de TFC Licenciatura em Engenharia ...premio-vidigal.inesc.pt/pdf/ChristopheConceicaoTFC.pdf · Licenciatura em Engenharia Informática e de Computadores (LEIC) Ano