Introduction to Bishop

This paper presents an architecture for server side web applications. The architecture is based upon the smalltalk MVC (Model, View, Controller) architecture which is used to build GUI applications.

Introduction

The architecture of web applications has evolved from pure client-server based (with various thin/smart/fat/dumb clients) to something that more and more resembles the MVC pattern. Of course the web is still client-server, it is the server that is implemented with a MVC architecture. A webserver serving static html pages to a browser is an example of a classic client-server architecture, a slightly more advanced example is a cgi application that generates dynamic html pages on a per request basis. This server model doesn't do a good job when it comes to handle the complex requirements of today's web applications.

The MVC architecture is an architecture well suited for gui based applications. One benefit of the MVC architecture is that since the application is divided into distinct parts, maintenance and upgrades are (relatively) easy to implement. The conventional MVC architecture is (obviously) not very well suited for developing server side web applications, due to the fact that they are ust server side. Something slightly different is needed.

Existing "MVC" architectures for web applications

Many have tried, few have succeeded. There has been several attempts to implement the MVC pattern for web applications. Some of them have been fairly successful and been used to build large websites, while others barely made it to freshmeat.net's new developer's tools announcement page. One common problem for many of these "MVC" implementations are that the don't implement a pure MVC architecture. A pure MVC implementation has a well defined model, view and controller and they are clearly separated.

One of the first MVC implementations that came around was Microsoft's ASP. ASP is a "server side scripting language" [3]. In ASP the view and the controller are implemented in the script code as html and javascript/vbscript respectively. The model can be implemented as COM objects but is, in practice, also implemented in the script code. This tight coupling between the model, view and controller makes an ASP application hard to maintain and understand. Example of similar technologies are JSP and PHP.

Another approach to implement the MVC pattern is the "template based architecture". In a template based architecture, the view is a separate html template (file) that are populated with dynamic data from the model and controller. Hence, the view is clearly separated from the model and controller. However, the controller is often implemented in the model, which makes both the model hard to use and the controller hard to understand. Examples of template based architectures are WebMacro [2] and TEA [5].

An organization tends to develop its own platform for web applications. Often is one of the above mentioned implementations used. This architecture leads to another problem, the hashmap. The hashmap is a global container for all variables used by the application. While this strategy might seem appealing for novice software engineers, the use of the hashmap has several drawbacks:

• Whenever a variable should be used in the application (model or controller) is has to be retrieved from /stored in the hashmap. There has to be code that validates if the value in the hashmap is of the correct type (a number can't have a string value, etc) and for null values. This code is error-prone and will be duplicated across the model and controller.
• It is difficult to understand what a method does based on it's signature. Most of the method only takes a HashMap as argument. It is the developer's responsibility to supply the necessary variables in the hashmap. The return value is also stored in the same map. Since the method sets the return value in the map, it is possible for a method to have several return values. This effectively voids years and years of programming languages research in favor of an untyped uncontrolled and ridiculously complex way of implementing software, where little or no help can be expected from the compiler.

Solving the problem, introducing Bishop

To effectively implement MVC in a server side web context we must describe the model, view and controller separately. While it might be possible to describe these using one language we suggest that three are used: Bishop, WebMacro and Java.
Bishop is a scripting language that acts as the controller, together with a template engine, such as WebMacro, and Java for the Model is it possible to implement a pure MVC architecture. The WebMacro templates are the view, the Bishop script is the controller and the business object described in Java are the model. The business object can be objects that maps directly to a database or more complex objects that contains domain specific logic.

The Bishop language can do the following:

• Translates HTTP request variables to real Java objects. (Future implementations could very well decode SOAP requests as well.)
• Create and manage objects that live for the entire user session.
• Invoke methods on model objects (i.e. execute methods on real Java business objects).
• Flow control for the controller (if/else support).
• Application wide error handling (exception handling).
• Define what view that should be used to display the current state of the model.

Bishop is an XML based language. It is easy to learn since it only has about 5 constructs. The following is an example of a login request for web application:

<bishop>
  <object name="authentication" type="webshop.Authentication"/>
  <invoke object="authentication" method="login">
     <in name="username" type="java.lang.String" default-value=""/>
     <in name="password" type="java.lang.String" default-value=""/>
     <out name="accessLevel"/>
  </invoke>

  <if object="accessLevel" value="-1">
     <view name="login_error.wm"/>
     <else>
        <object name="shoppingcart" type="webshop.Shoppingcart" static="true"/>
        <view name="main_shop.wm"/>
     </else>
  </if>
</bishop>
	    

When the script is interpreted the following happen:

1. An object named "authentication" is instantiated from the class "webshop.Authentication". This object lives throughout the request.
2. The method "login" is invoked on the authentication object. The login method takes 2 arguments, a username and a password. The values for these arguments are retrieved from the HTTP request variables named "username" and "password" respectively. If the request variables are not supplied from the client, the default values are used (both "" in this case). The login method returns an access level for the user or -1 if the user failed to be authenticated. The return value is saved in an object called "accessLevel". This variable is available in the view.
3. If the accesslevel was -1 (ie user not authenticated) the view is set to "login_error.wm", which is a template that displays a message to the user that the authentication failed.
4. Otherwise is a new object called "shoppingcart" created. This object has a property called static, which means that it will be available for other Bishop scripts during this session.

It is not possible, nor is it intended that any domain, or model, functionality is implemented in Bishop. While it is possible to abuse the usage of Bishop, it is not encouraged. Just as it is possible to abuse Java (hashmaps for instance) and WebMacro. Using Bishop, Java and WebMacro cleanly as intended it will provide you with an environment and architecture that reduces complexity and hence development and maintenance time and cost of web application projects.

The usage of a XML language for describing controllers makes some people think that there are disastrous impact on performance, imagine having to parse and validate XML documents for each request! This is however not an issue since pared and validated requests are cached for future use, which means that there is no reason why a Bishop solution should be any slower than a bare-bone servlet implementation.

Conclusion

Existing architectures for building web application are complex and error prone. A new way of implementing the MVC pattern in this context is necessary. The usage of a controller description language is necessary. This paper suggest the use of the triad of Bishop, WebMacro and Java for the foundation of Web MVC solutions.

Bishop is available for download from bishop.sourceforge.net

References