‹header›
‹date/time›
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
‹footer›
‹#›
Introduction to the Rich Web Application Backplane
By John Boyer
Senior Technical Staff Member, IBM Corporation
•One way to look at the markup used to deliver today’s web application functionality is as a black box. 
•We have existing technologies like HTML, CSS, JS that web app authors use to deliver functionality on the client-side, and control over the generation and delivery of that markup rests with the web app author’s servlet, portlet, etc.
•But let’s think for a bit about the growth of requirements over the last 15 or so years.
•More complex layout and higher precision rendition of text, images, and user interaction controls.  But not just requirements on static content have increased.
•Users expect more dynamic behaviors like the ability to calculate the total cost of that insurance policy I’m trying to buy ore renew online, and to adjust values as I select and change types and amounts of coverage.
•Users expect to be told when they’ve made a datatype error, such as a wrong date, a non-numeric value or a missed credit card digit.
•They also expect the user experience to be unencumbered by non-applicable steps of the overall process flow, like not having to step through the ‘senior citizen’ or ‘Minor’ sections of the web app if the given birthdate suggests that the user is not in those categories.
•We further expect to be able to seamlessly integrate data available from the web into the user experience, such as selecting from a list of doctors provided by a query made after some data has been provided by the user, such as desired appointment date/time, region, required specialization, etc.
•Ad despite all the dynamism, we need all this content to be accessible to persons with disabilities.  It’s philosophically interesting that this particular issue so sharpens our focus on being able to determine the intent of markup.
•So when you take this growth of requirements into account and you look inside the box based on the current state of the  art…
Javascript/AJAX ad hoccinni in a tomato tag soup sauce with a sprinkle of herbs and CSS spices.
Persisting this “assembly language of the web” programming model breaks the future of the web.
To keep up, we need an upgraded methodology that can take us from mash-up to hook-up of componentized web applications
To begin to address this need for a methodological upgrade, we propose a layer called the “Rich Web Application Backplane” to set a foundation for commonly required capabilities and simplify fully-functional component integration.
This has the potential to…
•Create a consistent model for mixed markup authoring and reliable component hook-up
•Reduce duplication and non-interoperability of the same functionality in many markups
•Maximize information flow  among components to address interactivity and responsiveness requirements. This essentially happens by systematizing the interaction contract between a component and its environment so that components that are supposed to work together never get out of synch with each other.
•Address accessibility needs of dynamic web content, in part by being able to harvest accessibility information from the interaction contract for the component
Before we dig into the details, we should start with the “Hello, world!” of the Backplane.
•On the upper left side of the display we have a basic application built with XHTML and XForms that allows the user to specify his address and a radius of concern from that location.
•When the user hits a search button, results are obtained, in this case, how many sushi restaurants there are within range.
•The user expects this data to seamlessly be integrated into the user experience of the currently running web application.
•But the returned search list is one-dimensional, so presenting it like a set of Google or Yahoo search results does not produce the richest user experience.  Since we know the list includes geographic information appropriate for two-dimensional display against the backdrop of a map, it makes sense to involve another component for that purpose.
•In this case, the master controller for the application is perhaps expressed in SCXML, and it detects the availability of the restaurant list, and changes the application state to include a map component.
•In this state, the map component shows the list of search results as bubble points against the backdrop of a map of the region specified by the user.
•The user may then choose a particular bubble point, which drives further behavior in either a third component or as part of the first to present restaurant details such as its address or a link to its menu and prices.
One important observation to be made about this application is that data obtained from the web is used within the application to create a dynamic, rich user experience. The application is not replaced by another application containing the additional data.  In other words, the application avoids the unwieldy user experience of a page refresh that is characteristic of older web applications.
The key idea of this slide, though, is this: although this application is simple enough to stitch together by hand, i.e. by directly mashing up the components using detailed knowledge of the data schemas of each, it is also possible to begin envisioning a less ad hoc approach in which the components’ contracts with the outside world are specified and less dependent on the internal workings of other specific components.  This makes solutions that are less brittle and more reusable in other applications.
 
Perhaps the first fundamental common capability that the rich web application backplane could provide is a data object.  It could expose XML serialization and addressing of data as XML based on XPath, but it could also offer other serializations and addressing schemes. Access to the data can be provided by access binding so that views and controllers can obtain and manipulate the data.  Based on bindings, mutations of data could result in direct notification events to bound objects such as view controls. Components may also learn about and respond to data mutations based on events that flow along the ancestor path between the data and the document root. This diagram shows controllers on the left and view components on the right, both of which can consume data and data mutations and even produce data mutations by either method.  Controllers can be components like a submission object, perhaps wrapping a web service, that changes the data based on results of the submission.  Or the SCXML (state chart XML) component, which could control application transitions based on data mutations. Views are objects that expose data or the ability to mutate data to the presentation layer.  Simple examples are input and select controls as well as an output only control. The XAC component, or XML application component, is a recursion on the overall architectural depiction.  In other words, all or any part of the overall diagram can appear again within an XAC.  More about that in the next talk of this session.
Controllers like SCXML may trigger changes to presentational views and XACs based on data changes
Controllers like web service submissions may trigger massive changes to data, which then trigger changes to presentational views, XACs and even other controllers like SCXML
A good example of a common capability that could be built into the backplane, aside from the basic data object already described, is a model property broker.
As depicted, the model property broker surrounds the data, but it could attach in some other way.  It’s purpose is to annotate the data with useful properties. 
A good example property is data validity on a datum by datum basis.  The validity can be based on an assigned schema datatype or pattern, or by some boolean formula that decides validity based on comparison to other data.  An example is ordering an old journal paper photocopy from an interlibrary loan service.  You specify the lower page number then the upper page number, and the constraint would indicate that the upper page number must be at least as great as the lower page number.
Another useful property is here called relevance, which seeks to indicate data that may sometimes be needed in a process but is perhaps not needed currently due to some conditions in the data provided so far.  For example, while applying for some kind of insurance policy or perhaps a tax refund, a given birthdate specified by the user might make portions of the data corresponding to being a minor or a senior citizen non-relevant to that user.
Yet another model property could be a mutation lock that prevents the associated data node from being mutated by a data object binding, or perhaps even by script commands that access the data object.  This is a version of ‘readonly’ directly for the data.
The model properties are inherently useful to different kinds of components.  For example, a view component that binds to non-relevant data could become unavailable to the presentation layer in some way and also deactivate event handlers for which it is the target.  A submission object may be configured to omit non-relevant data from the data it serializes for submission.
Finally, note that the maintenance and update of these properties could be regarded as a separate module, thus avoiding the whole issue of whether they are better managed by declarative expressions or procedural scripts invoked by event handlers.  The real answer is that they will be handled by whatever means that the application architect finds easiest to develop and maintain, and the issue of the utility of a model property broker is orthogonal to the issue of how they are maintained.
As yet another important example of a commonly required capability that could be baked into the foundation provided by the rich web application backplane, we consider data submission.  This module is especially interesting because the advent of AJAX support in browsers allows a means of implementing a submission object like the one described below in today’s browsers. Combined with the other rich web application backplane components discussed so far, this reflects the growing trend in “emerging platforms” i.e. platforms that are provided outside of the web browser maker bottleneck.
Here are some of the most important properties of a general submission object:
•Ability to send XML data to a service that expects structure according to some schema.  While the actual send can be done with today’s XmlHttpRequest, this point is as much about the send and receive as it is about the predefined interaction of the submission object with other components of the backplane.  There would be no preprocessing code needed to collect data to submit around the document because it is already in a data object.  And the results of a submission can be put back into another data object without the submission module having detailed knowledge of other components in the application.  The submission puts the result data into a backplane data object, and other components bound to that data or listening for mutations of it respond accordingly.  This type of “loose coupling” results in applications that are less brittle easier to maintain and enhance over time.
•Ability to select a portion of the data being manipulated by the web application
•Ability for data model annotations or properties to affect submission, e.g. data constraint conformance/validity
•Ability for data to affect the destination URI and other parts of HTTP submission like verb and headers.  This allows the submission to interact with more of the Web 2.0 server-side processes.  There is an increasing trend toward making smarter server tier components, and by empowering backplane-based applications to communicate directly with these components from the client tier, the need for middle tier glue code is mitigated.
•Ability to use XML result to replace data content within the current application
•Ability to send non-XML, receive non-XML, and even place the result within XML data.
Returning to the Italian theme with which this talk began…
•The top layer includes presentational markups like XHTML, SVG and VoiceXML as well as markups aimed at helping to provide underlying interactions and behaviors, like XForms and XBL2.
•The bottom layer is the platform technologies on which we rely, such as a DOM parser, DOM events, an XPath engine for addressing XML, and JS/AJAX for helping to provide the consistent new functionality in existing web browsers
•The Rich Web Application Backplane, then, would be a middle layer that provides
•meaning for mixed markup through a compound document framework
•a basis for managing XML data that components can bind to and interact with
•an ability to synchronize component behaviors based on XML events and handlers
•the capacity to annotate data with properties accessible to all components
•a powerful capacity to interact with server side modules and data sources
•A systematic means of controlling the availability and interactions of components within a large web application
•And the ability to recurse all of the above via an XML application component model (XAC model)
This final slide is perhaps a bit of a good news story for the W3C since all but one of the blocks are either covered in some form or another by a W3C Recommendation Track document or by a technology considered to be foundational by the W3C.  In some cases, there are direct technical reports covering the topic, such as XML Events or SCXML.  In other cases, such as the model property broker or submission object, there is a technical report that contains at least some version of the technology, making it easier to draw from both the architectural and practical implementation experience within the W3C to help achieve the rich web application backplane.
The only component not yet on the W3C Rec track is the application component (XAC) model.  Not only is that likely to change soon, but it is also the subject of the next talk in this session.