BAL: A language for component based distributed applications development

Panayiotis Alefragis Dept. of Telecommunication Systems & Networks

ΤΕΙ of Mesolonghi Nafpaktos, Greece alefrag@teimes.gr

Nikos Chondros Euroactive Consulting Ltd.

Athens, Greece Nikos.Chondros@euroactive.gr

Abstract—In this paper, a component based object oriented language for the creation of distributed applications is presented. The system design supports the client/server paradigm while the language compiler supports automatic partition of components to the client or server side. The evolution of the compiler creation, the partition algorithm logic and a concrete example are presented.

Keywords – component based software; object oriented programming language; distributed applications; partitioning

I. INTRODUCTION Data driven applications are almost as old as

computing. One of the challenges present since the beginning, is how to distribute them to as many users as possible in a resource friendly way. The current trend is the use of AJAX technologies in Web applications, in order to distribute the load between the client and the server. This however has resulted in increased complexity for both the design and the implementation, due to the multitude of technologies and programming paradigms that have to be integrated in order to achieve a high quality user experience. Such technologies include among other:

• An RDBMS for data definition and partial business logic implementation

• A programming language for the implementation of the majority of the business logic

• A GUI toolkit (be it the HTML or a language specific one) for the design of the user interface

• An application server and a web server • A scripting language (usually JavaScript) for

the implementation of UI automation functions (along with appropriate server side components in the case of AJAX)

Another important reason, not unrelated with the previous one, is the manual partitioning of the code across the tiers and the effort required to keep the state synchronized (caching logic) [1].

Because of all of the above, the cost of maintaining an application after the initial design is overwhelming as any required change usually requires modifications in almost all application layers and components. If, in addition, repartitioning logic in different tiers is also required, moving logic among tiers will most likely require reimplementation of the logic in different programming languages and environments, for example from declarative SQL, to imperative Java and scripting JavaScript.

Client

proxy Serverside

local

Asynchronous

DataBaseAccess

Data Scheme

BAL CompilerBALsource

Figure 1. BAL Generated Application Scheme Our research effort is aimed towards removing most of

this complexity by: 1. unifying all application definition constructs

in a single programming language 2. allowing the compiler of this language to

partition the application across tiers 3. allowing the same source code base to

produce different deployment layouts based on compiler options

We also challenge the ‘everything in the browser logic’ by allowing for a client side implementation of a new breed of generic thin client, specific to the function of running business applications remotely. While the browser is a universal medium for application delivery and especially useful for casual use, it can become cumbersome if it is enforced for a full day’s work with an application, both for the end user as well as for the network with the load it incurs. However, by including a different client implementation for the web browser, we also allow universal access from all existing devices with that capability. Figure 1 presents an application scheme generated from BAL source code. The database scheme, the client-side proxy components and the corresponding server side components are generated from the same BAL source code.

Another important aspect of the approach is strong typing enforced at compile time. Although the trend of the last decade is the increasing use of scripting languages, there are some quite important drawbacks involved in their use. One of the most important ones is the loss of compile time checks for proper type usage. We decided to enforce strong typing beginning from the database and spanning the complete language.

2009 35th Euromicro Conference on Software Engineering and Advanced Applications

978-0-7695-3784-9/09 $25.00 © 2009 IEEE

DOI 10.1109/SEAA.2009.82

486

2009 35th Euromicro Conference on Software Engineering and Advanced Applications

978-0-7695-3784-9/09 $26.00 © 2009 IEEE

DOI 10.1109/SEAA.2009.82

486

In this initial report, we are focusing on describing the architecture and the partitioning logic by imposing the following limitations:

1. Java is used across the board, both as an embedded source language as well as a target language.

2. Database functionality is simulated by Java classes that exist only on the server side. No queries are allowed other than full table loads.

3. The UI layer is not included in the initial language definition and direct Java code is used to simulate the user interaction.

II. RELATED WORK Cornell University developed the Jif [2] programming

language aiming to use replication and partitioning to build secure distributed systems. To that end, the Java language was enriched with annotations in order to define access rights on each variable declaration. The Jif compiler enforces the declared access rights for all uses of the annotated variables and a compiler partitions the code in two parts maintaining consistency by automatically introducing state sync messages while also enforcing the rights between the tiers.

The same team later introduced the SWIFT system [3], where server side tier is a web server while client side is implemented though a web browser. The system introduces an intermediate language, called WebIL, that allows the partitioning of the application to client and server while considering data placement constraints. The Google Web Toolkit [7] was used for the client while a servlet implementation provided for the server communications.

A different approach comes from INRIA where a new programming language called HOP [4] was introduced aiming to provide for interactive web applications. The approach is not aimed for database oriented applications but mostly deals with the user interface. Still, the target program is developed monolithically and the compiler splits it in a client and server part. The programming language is modeled closely to the HTML layout.

Another effort was made with the introduction of the programming language Links [5] at the University of Edinburgh. It follows the functional programming paradigm and integrates an SQL based database. OCaml was used to develop the compiler and the run time environment consists of JavaScript code for the browser and SQL commands at the server. The state is maintained completely on the client.

Recently, Hilda [6] was introduced. Here, as in Links, the language provides for data definition as well. The language is declarative and the notion of separating the user interface from the business logic is introduced.

III. LANGUAGE DESIGN We defined a new object oriented programming

language called BAL (Business Applications Language) supporting the usual constructs of class, property and method, with automatic memory management via garbage collection. It is enriched with domain specific commands in order to aid in the implementation of the partitioning logic by reducing the problem from its general form.

The ‘entity’ language construct supports the inclusion of the database schema in the language and provides the compiler with knowledge about the tables, fields and data types. An example follows:

entity Item table ITEMS property Code as integer property Desc as string primary key Code end entity The ‘process’ construct separates the user interface

from the business logic at the language level. The construct correlates table fields with the logic to process them and the application control flow. It is not possible in the ‘process’ construct to include any user interface related information, like the actual widgets that will implement the required fields, their position on the screen etc, making it a UI-less form in the menu/form/widget notion.

The process, while basically a class, also contains declarations of the elements it provides to the user, along with event binding instructions. These elements can be:

1. A ‘data source’ which is an adapter for the actual information stored in the database

2. A ‘field’, which binds to a ‘data source’ and allows read and write access to entity attributes

3. A ‘table’ and a ‘column’, also binding to a ‘data source’ and providing multi row access to it

4. A ‘service’ providing the means to invoke one of its methods.

With the above components, the complete business logic and flow of the application can be defined in a UI-less way. An example process is the following:

process pItemEdit property Source as dbinfrastructure.Recordset<Item> elements subscribe OnStart MyStart data source ds of Item field fCode bind ds.Code field fDesc bind ds.Desc validate validateDesc service sSave fire Save end elements method MyStart throws Exception ds.setSource(Source) ds.edit end method method Save throws Exception ds.update end method method validateDesc(value as string) throws Exception if value.length == 0 throw new Exception("Desc cannot be empty") end if end method end process Another language construct is the ‘form’ which focuses

in visualizing a specific ‘process’, however this construct and the related components are under development and thus are beyond the scope of this paper.

The last BAL specific notion is that of the ‘application’. Using this construct the menu of the application is defined, which maps user selectable options to defined processes. For example:

application test

487487

menu option ItemList process pItemList end menu end application Along with these enhancements some “syntactic sugar”

was introduced in order to reduce the complexity of the source code and also increase the compiler optimization possibilities. More specifically, properties get automatic access and assignment methods that the compiler can choose to inject code into. To improve the readability of the source code, a property access looks like a variable access but is treated as appropriate function calls eventually.

To support the above constructs, a component library was developed in Java and was tightly bound with the compiler. This library provides all the building blocks for:

• Database simulation and access • Event management • Menu handling • The ‘process’ infrastructure with data binding

logic • Application startup wrapper for application

initialization

IV. COMPILER EVOLUTION The BAL compiler was created in three phases, using

ANTLR [8] and its tree walking grammars. In the first phase, the compiler generates a monolithic application in Java that implements all the program logic. To circumvent the lack of user interface, we used a test case approach in which a class representing a test case was written directly in Java and controlled the application by using application specific reflection, like starting menu options by name, accessing processes and fields by name, etc.

In the next phase, the compiler was modified to partition the user accessible components of the application from the business logic and run them on different runtime environments. A Java/RMI based implementation was used to provide for the required network call infrastructure. To accommodate the generated code evolution, the runtime library was also modified to provide for a messaging infrastructure. In addition, proxy classes for important components that required automatic synchronization, like the ‘process’ infrastructure, were created. The logic used was that each event in the client environment was forwarded to the server for processing in a synchronous manner.

Although this scheme is fully distributed, it does come with a cost, which is the increased latency imposed by the synchronous network calls for each event (a trivial optimization was used to avoid network calls for fields without event listeners). However, an unbeatable advantage of this scheme is the increased security of the solution, as no code is sent to the client environment for execution, resulting in less possible vulnerabilities.

To improve the overall system performance, what was clearly needed was a way to push some components of the code to the client execution environment. So, in the final phase, the compiler was modified to place parts of the event-related code in the proxy classes for each ‘process’ (e.g. field validation or service invocation). This was achieved by the introduction of a partitioning algorithm

inside the compiler, presented in the next section. The partitioned code uses mostly asynchronous RPC techniques to reduce user perceived latency.

V. COMPONENT PARTITIONING An initial safe assumption is that, as the ‘form’

construct can only visualize and use a ‘process’, all code related to it can be executed on the client without the need to have any of its state synchronized with the server. Based on this, the partition algorithm only needs to focus on the components up to the process level.

The partitioning logic operates on the Abstract Syntax Tree (AST) of the application as it is generated during source parsing by the compiler. The goal is to select some of the methods of a process, along with dependent properties and methods, aggregate them in proxy classes and map the corresponding events to them. This way, the selected code will be able to run completely on the client side, avoiding synchronous network calls.

The approach on our prototype is a simple, iterative one, capitalizing on the compiler’s tight binds to the run time library. In a nutshell, the compiler begins by marking well known methods and classes as ‘unavailable on remote’, avoiding any code that would access a server resource, e.g. File or Database accesses. It then marks all methods bound to events as candidates for remote implementation and parses the AST trying to find prohibiting factors for that. The implemented algorithm is inspired by the backward consistency algorithm introduced in constrain logic programming languages [9]. If no conflicts are found, the current method’s dependencies are marked for analyzing at the next pass. The algorithm finishes when no more methods are marked for analyzing.

In our prototype we have disallowed client side code to create new objects, avoiding the required data flow analysis required to estimate their life time. Finally, all properties of a process, marked as being used by methods promoted to run on the client environment, get automatic definition and use of state synchronization messages in their accessing and modifying methods.

The result of this partitioning is two sets of Java classes. The first implements the application logic on the server while the second is the set of proxies that are sent to the client. When a server side class is instantiated, the proxy is automatically created and submitted to the client asynchronously. Both parts manage state synchronization automatically, by submitting asynchronous notification messages to the other side; these messages are again classes that are automatically created by the BAL compiler.

In fact, what the compiler eventually achieves is to automatically generate a subset of the application suitable to be executed in the client environment, as a proxy. This subset contains all processes, classes and their elements and properties that need to be accessed on the client environment because they were partitioned to be executed there. This is achieved by manipulating constructors and property access methods and injecting code there.

VI. EXAMPLE For the example process listed in Section 3, the second

evolution of the compiler that blindly forwarded the events

488488

to the server would generate the following Java snippet in the proxy class:

protected void initElements() { … fCode= new ClientFieldForward<Integer>(this,”fCode”); fDesc= new ClientFieldForward<String>(this,”fDesc”); … } In the final version however, the ‘Desc’ field’s

validation is marked to run on the server and the compiler generates:

protected void initElements() { … fCode= new ClientFieldForward<Integer>(this,”fCode”); fDesc = new ClientFieldDetached<String>(this, "fDesc"); fDesc.Validate.subscribe( new eventinfrastructure.EventHandler() { public void handleEvent(Object sender, EventParameters prm) { validateDesc(prm.value); } });

… } public void validateDesc(String value ) throws Exception { if( (value.length() == 0) ) { throw new Exception("Desc cannot be empty"); } } Note that the event subscription is directed to an event

handler on the proxy class and there is no synchronous network call involved. If the code changed any property, asynchronous notifications would be generated for state synchronization, automatically injected in the property’s setter.

VII. CONCLUSIONS & FUTURE WORK This research is aiming towards easing complexity for

state of the art database application development, while also reducing the perceived latency for the end user of such applications, who accesses them behind slow networks like the internet. For the first goal, the related research has already proved that this is feasible and BAL was designed with the best ideas that were found there; still BAL has some way to go to that end as described below. Regarding the second goal though, our experiments have indicated that the asynchronous nature of BAL partitioning does indeed improve the user experience.

Continuing this research, our next step will be to implement the ‘form’ construct in the language compiler. Our aim is to allow different concrete implementations to be generated depending on the required client platform. Considered platforms include Java/Swing for the BAL-specific thin client, Java/GWT [7] for web based clients and possibly a C++/QT or wxWidgets thin client.

Another required extension that must be implemented includes interfacing with an RDBMS by enabling embedded SQL commands directly in the language and managing the data definition via a central data dictionary. This would eliminate the need for the ‘entity’ construct, having the compiler access the data dictionary directly. It would also allow the compiler to automatically generate data caching code, while also permitting the partitioning algorithm to generate code to handle data locality as well. The clients will then include a low footprint RDBMS for caching (Sqlite, JavaDB), which will be automatically

managed by the BAL runtime libraries and compiler generated code.

REFERENCES [1] Fan Yang, Nitin Gupta, Nicholas Gerner, Xin Qi, Alan Demers,

Johannes Gehrke, Jayavel Shanmugasundaram, “A Unified Platform for Data Driven Web Applications with Automatic Client-Server Partitioning”, Proceedings of the Sixteenth International World Wide Web Conference (WWW2007), Banff, Alberta, Canada, May 2007.

[2] Lantian Zheng Stephen Chong Andrew C. Myers, “Using Replication and Partitioning to Build Secure Distributed Systems”. Proceedings of the IEEE Symposium on Security and Privacy, Oakland, California, p. 236–250, May 2003.

[3] Stephen Chong, Jed Liu, Andrew C. Myers, Xin Qi, K. Vikram, Lantian Zheng, Xin Zheng, Cornell University, “Secure Web Applications via Automatic Partitioning”, Proceedings of the 21st ACM Symposium on Operating Systems Principles (SOSP'07), p. 31–44, October 2007.

[4] Manuel Serrano, Erick Gallesio, Florian Loitsch, Inria, “Hop, a Language for Programming the Web 2.0”, Proceedings of OOPSLA '06: Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications, Portland, Oregon, USA, p.975-985, 1-59593-491-X, May 2006.

[5] Ezra Cooper, Sam Lindley, Philip Wadler, and Jeremy Yallop, “Links:Web Programming Without Tiers”, Proceedings of FMCO 2006, LNCS 4709, 2006.

[6] Fan Yang, Jayavel Shanmugasundaram, Mirek Riedewald, Johannes Gehrke,Alan Demers, “Hilda: A High-Level Language for Data-Driven Web Applications”, ICDE Conference, April 2006

[7] Google Web Toolkit, http://code.google.com/webtoolkit [8] Another Tool For Language Recognition, www.antlr.org [9] Pascal van Hentenryck, Helmut Simonis and Mehmet Dincbas,

“Constraint Satisfaction using Constraint Logic Programming”, Artificial Intelligence (58), p.113-159, 1992.

489489