Balisage Paper: The XML Expert's Path to Web Applications

Introduction

The core uses of XML technologies in document engineering are to encode structured, mostly text-based information (XML), to impose validity constraints on XML-encoded documents (DTD, XML Schema, Relax NG), to translate, often for presentation purposes, XML-encoded information into alternative formats (XSLT) and to query a data layer of XML-encoded information (XQuery). Typical applications are information systems for publishing and documentation.

This paper discusses how to repurpose XML technologies for Web applications. It turns out that current XML technologies provide a full stack of modeling and implementation languages and tools for Web applications that is stable, platform independent and based on open standards. Most importantly, it works right on top of HTTP. It is bare-bones in the sense that it requires little to no glue in the form of an application framework. This is a golden opportunity for domain experts who work with XML documents to leverage their domain expertise, their knowledge of document engineering principles and their skills in XML technology to build Web applications. This lets us pluck a handful of low-hanging fruits from the tree of XML technology for Web applications besides familiarity and accessability, such as platform and vendor independence, stability, reliance on open standards and end-to-end XML-based data encoding without costly impedence mismatches. Combining principles and proven practices from document and from software engineering, we examine and propose architectures, modeling techniques and implementation strategies that let end-user developers who are conversant with XML technologies create their own Web applications.

Our claim in this paper is not so much that we have invented something completely new. Rather, we review what is known, tailor it to the general domain of Web applications and package it as a consistent set of practices. We demonstrate our approach with the well-known casino game Blackjack, drawing on previous work, particularly on our browser game case study GameX [SKB14][BSK15].

A word about the state of this paper: The ideas that are presented in this paper have been at the heart of research and teaching in my group at TUM for a number of years. Pertinent aspects are summarized in previous papers at Balisage as cited above, in a recent PhD thesis [S16] and in recent Bachelor [O16] Master [T16] Theses. I intend this paper to connect previous results and to integrate them into a holistic set of practices. I continue to refine and validate these practices using the games Blackjack and Mancala in a lab course on XML technology at TUM that I teach in the current summer term 2016. At this stage of writing, I discuss principles and practices mostly in the abstract. The final version of the paper will draw on a fully worked example, the game Blackjack.

A Web application by definition follows the client-server architecture. In this paper, we consider thin-client Web applications. The core of the application runs in a server component that is accessed by client components through a Web server. The client components run in Web browsers; they display relevant information and offer interaction alternatives. A chosen interaction is translated into an HTTP request which is processed by the server component, resulting in an update of the relevant information to display, which is then returned to the client in the form of an HTTP response. This implies that the server component of a Web application is best viewed as an event-driven system which is ultimately triggered by HTTP requests.

In the further four sections of this paper, we address four aspects of XML-powered Web applications: First, we investigate how to implement an object-oriented, domain-driven design for the server component of a Web application with XML technologies, focusing on the principle of encapsulation. Second, we address the event-driven nature of the server component, employing statechart modeling encoded with SCXML. In particular, we define a stratification criterion that ensures that the behaviour that is expressed through the statechart can be executed in the framework of the request-response cycle of a Web application. Third, we put the server component on the Web, following the model-view-controler and XRX architectural styles. Fourth and finally, we discuss requirements and some solutions for multi-client Web applications that need to implement the observer pattern and server push interactions. We conclude with a reflection and with some final remarks.

Domain modeling and implementation of the server component

From a document engineering perspective, the server component of a Web application is typically seen as a repository of documents that is accessed through query and update functions. However, some types of Web applications have state in the server component beyond the state of a typical backend data layer. Specifically, they require several instances of the server component on one Web server that are dynamically instantiated and destroyed under user control. This is not the case with GameX, where all players share a single map to play on, but it is the case with Blackjack, where each table of Blackjack requires its own instance of a Blackjack game to be created in the server component, even in the most simple single-player scenario.

From a software engineering and particularly from an object-oriented perspective, the data of the server component are often naturally organized into a number of interrelated objects, with methods that locally operate on the data of an object, using methods on other objects as services. This is the principle of encapsulation, a form of abstraction that together with information hiding and inheritance facilitates software qualities such as ease of maintenance and extensibility.

More precisely, coming from an object-oriented modeling [BD] and domain-driven perspective [E04], an application is typically modeled in the object-oriented style by a number of classes, with a class corresponding to a type of domain entity and defining which data an instance of the class (that is, an object), holds and which methods can be performed on these data. This approach is particularly appropriate for Web applications that have state as described above.

We demonstrate how to model the data part of a class with a class schema in XML Schema. Objects are then implemented as XML elements that conform to their class schema. Methods are implemented as XQuery functions that have a reference to the object they are operating on as a "self" or "this" parameter. This approach mirrors directly common implementation practice for methods in object-oriented programming languages.

The most simple version of our case study Blackjack provides a game server to which eventually, due to this strategy of encapsulation, a number of clients can connect independently and asynchronously to play their own, separate one-person single-round games of Blackjack.

The domain model for Blackjack at this stage comprises the data of a single Blackjack game such as player hand, dealer hand and player bet. In addition, there are a number of top-level activities that operate on these data, such as placing a bet, executing a hit or stand command or tallying the game. There are also activities for creating and destroying a game and some helper activities that are invoked by top-level activities, for example instantiating and shuffling a deck of cards or drawing a card from the deck. The data model is defined by a UML class diagram which is then translated into XML Schema. The activities are implemented in an XQuery module, using the encapsulation technique described earlier.

The server component as an event-driven system

In the previous section, we have not yet addressed the overall behaviour of the server component. We view the server component as an event-driven system whose top-level activities are triggered by events, most commonly by user actions. Typically, there are constraints to the legal sequences of events, and the specific activity that is triggered may be dependent only on a specific pattern in the history of previous events. The classical tool to model the behaviour of an event-driven system is statecharts. Statecharts have been first introduced by Harel as documented in a book [HP98] he co-authored with Politi. They have later, in the object-oriented variant of state diagrams, become part of UML2; see [SSHK15] for a textbook introduction and [H99] for an extensive discussion of the use of statecharts in software engineering. Most recently, with SCXML [B15], an XML encoding language for statecharts has been standardized, bringing statecharts into the realm of XML technologies. A number of research papers discuss use of SCXML in particular, among them the Bachelor Thesis of Roxendal [R10], invited expert to the W3C committee that defined SCXML.

We complement our domain model of Blackjack with a UML statechart diagram that models the behaviour of the server component. The statechart is triggered by events that eventually originate from HTTP requests on behalf of a player who operates a Blackjack client component running in a Web browser. Execution of the statechart may result in computing data that are returned to the client component as a HTTP response. The statechart needs to be stratified in the sense that each execution of the statechart gives rise to an alternating sequence of events triggered by HTTP requests and returns of data in a HTTP response. The returned data specify which potential next actions on the part of the user will be accepted according to the statechart in its current state, following the principles of REST [F00].

The UML statechart diagram is manually translated into an SCXML encoding, following straightforward procedures, so in principle this translation can be automated. The SCXML statechart is then implemented in yet another XQuery module. Following the command pattern, ultimately each event results in a call to a query which operates on XML data representing the current state and on the SCXML data themselves.

Connececting the server component to Web clients

We are now ready to put the server component on the Web. We deploy the server component in an XML database system on the Web, currently we use eXist, but system dependencies are minimal. Browsers who wish to initiate a new Blackjack game connect to a dispatcher XQuery file on the server, which in turn instantiates a new Blackjack server component cum statechart object. From then on, communication between the browser and the server component is mediated by a controler query which translates HTTP requests from the browser into events for its statechart and translates data from the statechart into HTTP responses. The Blackjack client is implemented in XForms. It holds the information it is to display and the interactions it is to enable in its model, submitting requests AJAX-style and receiving responses in its model. The architecture is an instance of the model-view-controler architectural style named model-view-presenter with passive view and passive model [F02] and a one-to-one relationship between presenter and model.

Multi-client Web applications

It is straightforward to extend the Blackjack game to multiple players playing at multiple tables as long as all players at one table play through the same browser. The situation changes completely if we want to support a truly distributed game in which each player at a Blackjack table plays through their own browser. In that case, we have a number of controlers, one per player, who each are able to forward commands from their player to the server object and play back any data that the server component returns, possibly in reaction to commands issued by another controler. The latter destroys the ping-pong rhythm of request and response in the HTTP protocol. In this type of communication, which is actually a type of server broadcast, a server needs to be able to push responses to clients from whom there is no open request.

There are ways to emulate the server-push or server-broadcast communication pattern over HTTP by using so-called busy polling or long polling techniques in combination with AJAX-like requests. In fact, our browser game GameX uses busy polling to propagate changes in the map that were caused by one player to all other players. However, these solutions are not stable and do not scale. HTML5-based architectures go beyond the request-response cycle of the HTTP protocol towards server push solutions by supporting APIs such as Server-Sent Events and WebSockets [WSM13] in the client and with corresponding server-side implementations, for example in Node.js [HW12]. There does not seem to exist an XML-savvy implementation of these approaches, yet.

Conclusion

In this paper, we have laid out a coherent and coordinated set of practices for developing XML-powered Web applications. With Blackjack, this paper provides a worked example that illustrates these practices. The practices draw on previous work and are have been and are being bullet-proofed with further case studies.

One source of inspiration have been proven principles and practices from software engineering. We have demonstrated how the principle of encapsulation can be emulated with XML technology by mapping objects and methods operating on objects to XML elements and XQuery-encoded activities that are parameterized with the object-element they are supposed to operate on as a "self" or "this" parameter.

From data model to a model that also addresses actions: (1) defining a domain model. (2) data-behaviour-activities: modeling state with statemachine diagrams, encoded in SCXML. This facilitates model-driven code generation.

By systematically analysing the model-view-controler (MVC) architectural style and how it can be applied in the context of Web applications and the request-response cycle, we have worked out how a server component can be kept independent of its clients as long as there is a one-to-one relationship between a client and an instance object that the server component creates for the client to interact with.

The challenge is how to design an XML-driven solution for real multi-client applications or, more precisely, how to realize the observer pattern in the XML context. HTML5-based architectures go beyond the request-response cycle of the HTTP protocol towards server push solutions by supporting APIs such as Server-Sent Events and WebSockets in the client and with corresponding server-side implementations, for example in Node.js. If we wish to rely solely on XML technolgies, the only options seem to be emulations of server push through long pulling or busy pulling. It is a point for discussion and further development if we can fill this gap better with technologies in the XML stack.

The practices proposed in this paper are compatible with domain-driven design and model-driven solutions.