 | Level: Introductory Martin Brown, Developer and writer, Freelance
31 Jul 2007 Both mashups and Ajax are now firmly entrenched in the Web landscape. Put
them together and you have the makings for Rich Web applications. This article explains the Rich Web Application Backplane, currently a W3C Note, which is designed to bring standardization to the field, proving a set of common building blocks, or components, these applications tend to use.
Existing Web site deployment methods
Web site technology has been improved and extended over the years. Traditional Web sites were based around simple, static, HTML pages combined with the graphics and other elements to make up the individual Web pages. The bulk of the content was completely statically based, or was generated from a database as HTML pages that were served statically through a Web server.
The next phase of the Web environment was the dynamic Web site using technologies such
as the Common Gateway Interface, or server-side dynamic environments such as PHP and
JavaServer Pages™ technology. Although these solutions are common, they rely on
completely re-building a Web page and supplying it back to the client. This allows for
the dynamic element by rebuilding the page with each step with the custom content.
Figure 1 shows the basic outline of the traditional solution.
Figure 1. Traditional solution
Standard dynamic Web sites of this type work well, but have a number of different issues with their operation:
- The submission or acceptance of data relies on exchanging the request and reloading the entire page — even if only a tiny part of the page needs to be updated.
- State information about a user's visit within the Web application is stored somehow at
the server, rather than the client level. Often this is handled with a unique session ID
and a cookie in the client browser that holds the information. Supporting this requires
a number of server-side caching and session solutions, including proxying technology and dedicated session servers.
- The load of the server increases as the server deals with the whole request. This can imply multiple database queries and even multiple database sessions and templating solutions to build the new page.
- To work with multi-page and complex forms, especially if form and data entry choices
rely on the selection of other form information, can be incredibly difficult as the data must be stored between each page view.
- To get round many of these problems requires a different approach to the way pages and the components on those pages were loaded.
 |
Ajax, mashups, and dynamic page components
The use of Web browser technology, including Dynamic HTML (DHTML), CSS, XHTML and
JavaScript have changed how you can build Web pages. They remove the need to submit entire forms and reload the entire page to introduce new information in the browser.
In particular, Asynchronous JavaScript with XML (Ajax) technology enables the dynamic submission of information from a Web page, and for the response data to that information to be re-presented within the browser without the page having to be reloaded.
With Ajax, JavaScript is used to submit (through the XmlHttpRequest system) a request to a remote server, parse the
content, and choose how to display that on screen. You can use the Ajax solution to
display any data or information based on the contents of the Web page they are viewing. Form elements can be rebuilt — for example populating the content of a pop-up list — and even full forms can be added and extended.
The result is a complete change in the way you can submit and load pages and information. Figure 2 gives a rough overview of the sort of process and execution sequence.
Figure 2. The Ajax solution
You can see from the diagram in Figure 2 that the monolithic page load solution has changed. Instead, you get an initial page load containing the information you want. Further requests then load different fragments of the page for display.
Rich Web Application Backplane
The Ajax solution given in the previous example is not the only solution available for
the exchange and dynamic production of Web pages. A number of different solutions are
available, both in terms of the methods to submit information to the server, and to
receive and display that information.
The aim of the Rich Web Application Backplane is to pull together the different technologies that provide the building blocks that now form the basis of modern Web applications. The role of the Rich Web Application Backplane is therefore to define these different elements and provide a standardized method that allows these different components to work together.
The standard also aims to produce the standards that will enable these technologies to build Web applications without imposing restrictions and requirements on the Web developers that force them into using a specific solution.
This will enable developers to use the technology they prefer — such as Ajax,
XForms, or SVG — to build Web applications, and still allow them to work within an agreed standard development environment.
To achieve this level of standardization, the Rich Web Application Backplane will define a number of different standard systems that describe the different elements of a typical Web application. The standard currently defines three areas:
- Submission system: A standard way to submit information. The submission area will define the life cycle of events (valid for any language or environment) that will handle the submission process.
- Data Model: The model used to act as the format to exchange information between the user and the server that provides the information. The XML is different to that currently exchanged in that the XML represents both the data and the display information.
- Events and Life cycle: These mechanisms act on the data and submissions and translate the information between the user and the server system. This will include how events — including user level events such as clicking on a button — are translated into operations and processes. The event-driven model is designed to replace the more traditional JavaScript or hand-coded translation from the XML returned by the server-side of the application so that specific XML events handle the display of specific information.
In essence, the Rich Web Application Backplane is the standardization of the tools and
technologies already in frequent use into a suite of standards that build Web-based applications.
Figure 3 shows the Rich Web Application Backplane in action in the same format as the
traditional (Figure 1) and Ajax (Figure 2) overviews.
Figure 3. Rich Web Application Backplane in action
From the diagram in Figure 3, you can see that the submission system
acts as the final interface between the server and the original page. The real power is
in the XML Data Model and the bindings that enable the event parser to translate between the original page and the new elements. It is the binding that responds to user interface queries and exchanges those selections through the submission model to the server. With the response, it is also the binding that converts the response back into the XHTML, SVG or other viewable element within the original document. It is the event and data binding system that provides that glue between the different components and the power of the Rich Web Application Backplane.
Look at these different areas in more detail.
Submission
The submission system is the element of the user interface and supporting logic that allows for the exchange of information between the Web browser and server components of the Web application.
Traditional models used the re-loading POST or GET system within a form submission to provide the information. For
greater interaction, use JavaScript to process the elements of the form and submit the component.
Other existing dynamic elements include the REST and similar interfaces combined with the XMLHttpRequest object within JavaScript to submit requests and return bare XML or indeed any other type of data that can then be post-processed and displayed.
The Rich Web Application Backplane wants to standardize these elements with a number of improvements:
- Improved mapping between the submission object and the Document Object Model (DOM)
API. This will include some basic improvements to the way that data and requests are
exchanged, and how this works in connection with the rest of the page and the
application. The current note talks about the use of standardized toolkits like Dojo to
provide a simpler method to request the information, and better ties between the page
components, the methods for loading and updating the data, and structures being used by those components.
- Improved notification events. During its course, a typical submission exchange will
assemble the submission (serialization), transmit the request, wait for a response,
receive the response, and de-serialize the response into a local object. For example,
when you use XmlHttpRequest, you rely on the state change function call, and the ready
state of the requests to determine what to do when the request reaches a particular point. These states need to be expanded and more transparent, yet accessible, to improve the experience and responsiveness of the application, and improve the communication and updateable state of the page as the submission itself is processed.
- Event synchronization to allow the submission system to work independently and allow
for the event notification to work across multiple events. For example, the application
might raise an event when it receives data from the original request to process while
the data is received. However, only when all the data is received (event a) and
processed (event b) will the system then update the visual display of that information.
Overall, the main aim is to standardize on the submission model, expand the events to enable to handle the submission process, and provide a more extensive event model to be able to support complex interactions.
Data model
Data within the Rich Web Application Backplane forms the connection between the user and the back-end application. The role of the data is both as the source of the information and also as the key for the events that trigger specific operations.
The data model largely follows the typical object model used in standard application
development environments. The data model will specify the information and the rules that
you can use to operate on that data. The result is an object that can both represent the data to the user and communicate with the back-end application to update the data contents.
This can be represented very simply, as seen here in Figure 4.
Figure 4. Data model in the Rich Web Application Backplane
For the Rich Web Application Backplane, you will use an XML data model, where the model
consists of the core data, validation system, constraints, and actions:
- Data instances: These hold the real information and you should be able to store the data in a particular instance of the model.
- Validation: In the data model, include the routines that can validate the data that
forms the instance of the data object. By placing the validation in the data instance,
the model should validate itself rather than rely on the server to validate the information.
- Constraints: Because you can use the data within an environment where direct access to
the server might be controlled, limited, or simply unavailable, the data model should
contain the rules that define the constraints of the object. For example, this might
include business rules that restrict the size and scope of specific elements, or prevent
the specification of different combinations of elements in the same instance. Like the
validation component to the data model, this will help enforce that objects on the
system are valid before they are exchanged and used with other components of the system,
both internally in terms of the user interface, and also externally when exchanged
through the submission system to other objects. Also, keep in mind that the data model
can define many of the User Interface (UI) elements used in the application. Validation
and constraint information will help to drive the UI and make the application easier to
use, as the application might change the available choices and UI elements based on user input.
- Actions: These handlers deal with the events associated with the object. In terms of
the UI, it is the actions that specify what happens at the selection of a particular
component of the model, submission,or action button.
Declarative language programmers will be familiar with much of the structure of the data model as an object instance, albeit one with very specific rules and roles within the overall application model.
Because the data model provides the user interaction, you can use it to validate the
data input at the point of interaction. The data model will define the object structure
plus layout and valid values. This eliminates the issue with traditional models where the validation must occur on the server end.
Events and life cycle
The events life cycle and the data binding that work on the core XML data provide the
main method to process different elements within the Rich Web Application Backplane.
Events and event handlers are already a common part of many Web applications, including
some of the existing methods for processing XML, and event systems within JavaScript and
CSS events, all of which provide methods to act upon and respond to existing events.
As part of the standardization of these different technologies, the Rich Web
Application Backplane will unify the methods that specify and respond to the different events within a system.
The current draft of the standard already identifies the main topics of the event
system that you must handle as part of the standardization process, including:
- Device independence: Make the events system, triggers and responses work independently
on a range of devices. From a user perspective, this means separating specific
operations that can happen from user operations. Existing examples of these include
scrolling down, which is an operation, and the act of scrolling down, which is a user
operation. The first is an example of an operation that might be application led, the latter is an example of something that a user requests, the result of which is the first operation.
- Accessible eventing: Do not hide the event system, or make it so complex that it is impossible to use.
- Standard events: Make the event system specify a number of standard events that occur for frequent behavior and requirements.
- XML-generic markup for handlers: Keep event handlers easy to define against XML, even
from different base architectures, with a strict standard on how to define and apply those handlers. Currently different XML standards (XHTML, DOM) have different systems.
- Scripted and declarative handlers: The Rich Web Application Backplane is designed to
be usable and applied with any language. Don't limit the system to specify language types and environments. This should help prevent developer preferences from halting the use of the standard.
- Methods for binding events and handlers: Dynamically append events and handlers to existing structures.
- Security issues when binding cross-documents: Limitations in the current dynamic/Ajax
solutions prevent cross-site scripting. It can be difficult to work with security issues across documents event on the same site.
- Cross-namespace issues in compound documents: You should able to work with a variety of components across different XML namespaces within the same displayed document.
- Integrating event approaches: Ensure that eEvent solutions across different systems are compatible.
|
Comparing the Rich Web Application Backplane to standalone applications
Possibly the most interesting aspect of the Rich Application Backplane is that the process is largely designed to improve the current Web application infrastructure so that it more closely matches the traditional standalone application environment.
The role of the XML data binding and events, and the process of adding life cycle
methodologies to the deployment and execution of a Web application is very similar to
the object-oriented approach and the Model-View-Controller (MVC) pattern. MVC components
are designed for use in environments where a lot of user interface elements are displayed, and where the data handling interface and the viewable interface to that information can be developed without the two relying directly on each other. Instead the controller component is responsible for view to model updates, and often for updating the view based on the model data.
Figure 5 shows the typical MVC diagram.
Figure 5. MVC diagram
Within the Rich Web Application Backplane, the View is the XHTML, SVG or other display component; the data is the XML data model, and the controller is the data binding/event handlers that process the information. The submission object in this system has a role to play as the supplier of the MVC component and the interface between the user-side of the system and the server component.
In many cases these tools and abilities are available in standalone environments. The
creators of the Rich Web Application Backplane hope to produce the standards that make this functionality available to Web applications.
Although Figure 5 shows an MVC-like model as an example, you can
apply the basic principles of the Rich Web Application Backplane to any model and page
design methodology. The aim is to standardize on the methods available to build the page, not specific elements of how your application should work.
Summary
The purpose of the Rich Web Application Backplane is to provide and support the
standards that will make it easier to develop Web applications in a way that more
closely resembles existing standalone native applications. It will provide a more compatible
and usable method to exchange information between the components.
When you define the roles of:
- The submission system (which controls interaction between Web client and Web server)
- The data model (which holds information and provides methods for display)
- The events (which control the interaction between the UI components, the data model components and the submission system)
you should be able to develop Web applications in any language and environment you chose and support the ready exchange of information between different components, irrespective of their source.
Resources Learn
-
Rich
Web Application Backplane: Find and review the full text and details of this W3C standard.
-
The
ultimate mashup -- Web services and the semantic Web (Nicholas Chase, developerWorks, August - October 2006): See this six-part series that chronicles the creation of the ultimate mashup, an application that not only stores data from different mashups but uses semantic technology to enable users to create their own mashups by swapping services.
-
Programmable Web: Stay up to date with the latest on mashups and the new Web 2.0 APIs.
-
Ajax page: Visit this page sponsored
by the Mozilla Development Center for Ajax-centered information .
-
Considering Ajax, Part 1: Cut through the hype (Chris Laffra, developerWorks, May 2006): Consider this set of discussion points for every developer before you use Ajax techniques for a Web site.
-
Introduction to XML (Doug Tidwell, developerWorks, August 2002): Take this tutorial for a good grounding in XML.
-
Understanding DOM (Nicholas Chase, developerWorks, July 2003): Get a better understanding of dealing with XML as an object in this tutorial.
-
Second Generation Web Services: On XML.com, find coverage of the REST architecture.
-
developerWorks XML Zone: Find a wide range of technical articles and tips, tutorials, standards, and IBM Redbooks.
-
developerWorks technical events and webcasts: Stay current with technology in these sessions.
-
IBM XML certification: Find out how you can become an IBM-Certified Developer in XML and related technologies.
Get products and technologies
-
IBM
trial software: Build your next development project with software available for download directly from developerWorks.
Discuss
About the author | 
| | Martin Brown has been a professional writer for over eight years. He is the author of numerous books and articles across a range of topics. His expertise spans myriad development languages and platforms -- Perl, Python, Java, JavaScript, Basic, Pascal, Modula-2, C, C++, Rebol, Gawk, Shellscript, Windows, Solaris, Linux, BeOS, Mac OS/X and more -- as well as Web programming, systems management and integration. Martin is a regular contributor to ServerWatch.com, LinuxToday.com and IBM developerWorks, and a regular blogger at Computerworld, The Apple Blog and other sites, as well as a Subject Matter Expert (SME) for Microsoft. He can be contacted through his Web site at http://www.mcslp.com. |
Rate this page
| |
