Helping ordinary people create extraordinary websites!
| |
Helping ordinary people create extraordinary websites! |
Use Continuations to Develop Complex Web ApplicationsBy Abhijit Belapurkar2005-04-22 
Problems in Conventional Web development
Model-View-Controller (MVC) is the universally adopted pattern for developing interactive applications, including those for the Web. This well-known pattern organizes an interactive application into three separate modules: one for the application model with its data representation and business logic, the second for views that provide data presentation and user input, and the third for a controller to dispatch requests and control flow. So what is this "flow" that the controller manages? A typical Web application consists of a well-defined sequence of interactions with the user in terms of loading pages and awaiting the return of filled forms. In that sense, a Web application is like an event-driven state machine. This event model is what is realized in a typical MVC architecture via the controller. For example, suppose that the user requests a certain page from the server, which contains a form to be filled. The user spends some time thinking about and filling in the answers, then submits the form. When this event arrives at the server (the controller module), the application moves into the next logical state, depending on the present state, the data submitted by the user, and the business logic. The outcome of this state transition, as visible to the user, is that the next page in the sequence or the earlier page, along with an error message, is displayed. This cycle is repeated as the state machine is propelled on its path from the begin state to the end state, at which point the Web application is deemed to have fulfilled the functionality required in that specific use case. The state diagram that controls the various possible flows from a "begin" state to an "end" state can either be implicitly implemented in the controller module (typically a servlet) or, as in the case of some Web development frameworks, can be externalized as metadata in configuration files. However the framework is implemented, the basic idea of a state machine is always there. A number of issues can pop up while developing Web applications based on this model, as described below: • Depending on the size of the state machine and the amount of data required to maintain a client's current state (as a Web application may be accessed by a large number of clients at any given time), the application logic could become unnecessarily cluttered and complex. • The client may choose to hit the back button on the browser at any time during the sequence of state transitions, or may clone the browser window to initiate a parallel sequence of actions. Either move could lead to multiple (sometimes even concurrent) submissions corresponding to states that had already been passed in the original interaction. As a result, the application would be forced to keep track of every individual transaction and provide the correct response to each of them. • A similar problem could arise in the case where a Web application was trying to gather information from the user in a series of forms spread over multiple pages. If the generation of a later form depended on the combination of responses the user had provided in the previous ones, then the application would be forced to keep track of the responses entered as part of each interaction and make sure that the correct page was returned in response to each one of them. Model 2 Web development frameworks do, in general, provide custom techniques for mediating one or more of the above mentioned problems. However, none is as intuitive and easy to develop as the continuations-based alternative, which resolves all of these issues in one go. Model 1 vs. Model 2 architectures Strictly speaking, only MVC's Model 2 architectures have a controller servlet. Model 1 architectures have decentralized control in which the browser directly interacts with servlets or JSP technology, which in turn access and work with the JavaBeans components representing the application model. In such architectures, the next page to display is determined by the user clicking a link on the current page or on the basis of parameters sent with a request. Most MVC-based Web applications today implement the Model 2 architecture. About event-driven programming The event-driven style of programming user interfaces dates back to the advent of client-server architectures. It is based around a central event processor and a number of event handlers that register with it. Each handler registers its interest in being notified when specific events occur. The user interaction state is maintained in the central module, which dispatches incoming events to the registered handlers depending on the current state held internally. Most Web-based interactions are a special case of event-driven programming, wherein the interface display is delegated to a Web browser rather than managed by a thick-client executable running on the user's workstation. Whereas a typical thick client would disallow user-driven functionality such as backward navigation and cloning, Web browsers support, and even encourage, it. Of course, resourceful programmers have found ways to customize the browser interface (using scripting code) to disallow such operations, but this introduces a dependency on the ever changing quirks of different browsers. While MVC's event-driven style of programming yields numerous advantages, it also leads to business functionality spread across multiple modules, making it fairly complex to develop, understand, and maintain any reasonably complex Web application. Even as numerous Web development frameworks (such as Struts, Spring, and JavaServer Faces) were developed to hide the complex plumbing beneath most MVC-style interfaces, some developers have begun to acknowledge the fact that other programming models deserve to be further explored. Tutorial Pages: » A Programming Paradigm to Simplify MVC for the Web » What is a Continuation, Anyway? » Problems in Conventional Web development » The Case for Continuations » User-Centered Navigation » You Make the Rules! » The Continuations Repository » An Example Application » Web Continuations in Apache Cocoon » The Application Sitemap » The Application Logic » Understanding the Application Logic » Resuming the Continuation » JavaScript vs. the Java language » Continuations in Java code » Pros and Cons of Continuations » Conclusion » Resources First published by IBM DeveloperWorks
|
 |