From MemberWiki

NOTE: This wiki page holds part of the early draft specification for OpenAjax Hub 1.1. It contains all of the finalized and approved content from the OpenAjax Hub 1.0 Specification, plus draft text for the new features in OpenAjax Hub 1.1. Text repeated from the Hub 1.0 spec isidentified by the string [HUB10]. The draft text for the features that are new to Hub 1.1 is identified by the string [HUB11]. At this point, the new features are very early in development and have received little or no review by the Interoperability Working Group. All of the new features should be treated by the community as a work in progress that is not yet ready for use by the community.

Contents 1 5 Managed Hub Overview 1.1 Mashups Overview 1.1.1 Ways that mashups are created 1.1.2 User-built mashups 1.1.2.1 Discovery and cataloging of useful widgets, feeds, and other data 1.1.2.2 Assembling widgets onto the mashup canvas 1.1.2.3 Running the mashup 1.2 Widgets Overview 1.3 Mashup industry challenges 1.3.1 Interoperability 1.3.2 Security 1.4 Managed Hub Conceptual Overview 1.5 Sample source code 1.5.1 Mashup container application source code 1.5.2 Widget source code 1.6 Providers overview 1.6.1 The smash provider 1.6.2 The inline provider 1.6.3 Other providers 1.7 Security characteristics of the smash and inline providers

5 Managed Hub Overview

[HUB11]: Everything in this chapter describes new features found in OpenAjax Hub 1.1.

Mashups Overview

The primary target application scenario for the Managed Hub features in OpenAjax Hub 1.1 are mashups.

Within this specification, the term "mashup" refers to an application that uses the "Web Runtime" (i.e., the browser engine that runs HTML/Ajax applications) and combines data from more than one source into a composite application. The classic mashup example has one part of the screen showing a mapping widget (e.g., Google Maps) and another part of the screen show showing a table of real-estate data retrieved from a data feed (e.g., Craigslist), thereby creating a new and distinct web application that "remixes" and connects two independent web services in ways that were not originally provided by either source. Widgets and feeds (described below), along with simple web services, are the most popular building blocks for mashups.

Mashups represent a new technique for Web application development that leverages the industry's move towards SOA (service-oriented architecture), where back-end data is exposed as web services via APIs that can be invoked from client browsers (e.g., via XMLHttpRequest). Mashups allow easy remixing of data exposed via SOA and represent a revolutionary new technique that allows rapid application assembly by non-programmers, thereby broadening the base of people who can build applications, drastically reducing development time, and unleashing the innovation of end users to remix information sources to gain insights and improve productivity.

Large amounts of useful information has become available in the form of re-usable web services that can be queried by web applications running in the browser, often (but not always) using XMLHttpRequest. Some of the web services are compatible with the WS* set of standards (e.g., WSDL, WS-Security, WS-I, etc.) and/or SOAP; others use lighterweight protocols such as simple XML, JSON (JavaScript Object Notation), or one of the industry standards for simple syndication feeds (i.e., RSS or Atom). Countless Web services across a wide spectrum of categories have become available on the public Web. Within individual enterprises behind firewalls, companies have created web service APIs that allows internal Web applications to gain secure access to internal company databases.

A key industry phenomenon is the rapid rise of "web widgets" (aka, '"widgets"' or "gadgets"), which represent a portable chunk of code that can be installed and executed within other HTML-based web pages. Within this specification, the term "widget" will be used as a shorthand for "web widget".

Ways that mashups are created

There are a number of ways that mashups can be created. This specification will highlight two categories of mashups:

• Programmer-built mashups - Many Web applications built by individual Web developers fall into the mashup category. In this scenario, a programmer uses Ajax technologies (e.g., HTML and JavaScript) to code up a Web page that combines 3rd-party web services, widgets and feeds as components within a Web page.
• User-built mashups - In this scenario, a non-programmer creates the mashup using mashup designer tools, typically running in the browser. The mashup tools often allow the user to discover feeds and widgets from various sources, and then assemble those feeds and widgets onto a mashup canvas, sometimes using drag-and-drop gestures to pull from a widget palette onto the mashup canvas.

This chapter will focus primarily on user-built mashups, but note that the underlying OpenAjax Hub 1.1 technologies are also applicable to programmer-built mashups because the two workflows share the same interoperability and security issues.

User-built mashups

The section provides a quick overview of a common workflow for user-built mashups.

Discovery and cataloging of useful widgets, feeds, and other data

Often, the first step in creating a user-built mashup is discovering the various data sources and widgets that provide the information and visualization features that is required in the mashup. Data sources typically consists of data feeds (often RSS or Atom), already-built widgets, and other miscellaneous forms of data (e.g., company spreadsheets). Various tools exists (in the picture below, a "Discovery and cataloging tool") to help the user search for appropriate data sources and widgets, transform the data sources (e.g., applying filters and joins to data feeds), and builds a catalog of mashup components. For the purposes of this discussion, it is assumed that all data sources (including feeds) and visual components are available in the form of widgets within a "widget catalog".

Assembling widgets onto the mashup canvas

Once the catalog contains the components needed by the mashup, the user runs a (perhaps different) mashup tool to assembly widgets onto the canvas, as shown below. Mashup tools often display a widget catalog from which the user drags widgets onto the canvas.

Often in a subsequent step, somehow or other the widgets needs to communicate with each other so that changes in one widget can trigger corresponding updates in other widgets. Sometimes the mashup tool is able to link widgets together automatically, but other times the mashup user needs to manually link widgets with each other.

When a mashup tool includes OpenAjax Hub 1.1 inside, then widgets are linked together via the Hub's publish/subscribe engine. Whenever a widget needs to notify other widgets of a change in state, the widget publishes an event by calling one of the OpenAjax Hub's publish() methods. Other widgets subscribe to the given event topic. When the event is published, the Hub notifies subscribers, who are able to perform appropriate update actions in response to the event.

Running the mashup

Mashup tools that run in the browser typically have instant deployment, meaning that upon completing the build and linking process on the mashup canvas, the mashup is available for immediate use both by the user who created the mashup and by other users who can access the URL at which the mashup was saved. To run the mashup, users simply navigate to the URL at which the mashup is stored.

In the picture below, note that upon deployment any design-time user interface, such as the widget gallery, does not appear.

Also, observe that when the mashup executes, some of the widgets in the mashup communicate in the background with particular Web servers. This opens up the possibility of severe security vulnerabilities if the mashup does not have an appropriate mechanism for isolating widgets to prevent unauthorized information flow. For example, the company server probably in the picture may have granted read/write access to the data on the server to the mashup's web page, which means if Widget-E or Widget-A were malicious, they could attempt to gather company confidential information or trigger malicious transactions. The Managed Hub feature in OpenAjax Hub 1.1 addresses the security issues raised by mashups. The sections below describe how the Managed Hub feature provides a mechanism to isolate 3rd party widgets and includes a security manager mechanism such that the mashup container application can mediate the dispatching of messages that are passed among the widgets.

Widgets Overview

As mentioned previously, within this specification, the term "widget" refers to Web widgets, which represent a portable chunk of HTML/Ajax code that can be installed and executed within other HTML-based web pages. Widgets typically are placed within a rectangular area of the mashup canvas and present a user interface for viewing information and interacting with that information. Widgets often talk to a back-end web service in the background as they execute.

There are a significant number of proprietary widget formats used in the industry today. Some of the most popular proprietary widget formats support Ajax content (i.e., HTML+JavaScript+...) and use the browser engine to render that content. The main difference between these widget formats that support Ajax content is with the supplemental metadata file(s) that accompany the Ajax content. The metadata is often contained in a single XML file that provides information such as widget name, description, the URL for the server with which the widget needs to communicate, and the list of messaging topic names that the widget might communicate with other widgets.

OpenAjax Alliance is attempting to bring the widget industry together with a single standard for Web widgets that might be incorporated into mashups or loaded into an Ajax IDE:

• OpenAjax Metadata - With its OpenAjax Metadata Specification, the alliance is defining an industry standard for widgets around which the industry can consolidate.
• Open source transcoders - The alliance is also developing open source transcoders for some existing proprietary widget formats into the format defined by the OpenAjax Metadata Specification.

The open source reference implementation of OpenAjax Hub 1.1 directly supports widgets that conform to the OpenAjax Metadata Specification and can be adapted to support proprietary widgets via a transcoder. A separate open source effort within the OpenAjax Alliance project area demonstrates how to integrate the open source transcoders with the open source for Hub 1.1.

Mashup industry challenges

Two key challenges in the world of mashups are interoperability and security.

Interoperability

The industry has seen a rapid rise in the available of widgets, but these widgets are expressed in several different widgets formats, which hinders interoperability, and thus goes against the remixability promise. OpenAjax Alliance is working to help the industry move towards greater widget interoperability, particularly due to its OpenAjax Metadata Specification, which among other things defines an industry standard for Ajax-powered widgets.

Security

OpenAjax Hub 1.1 places a primary focus on the security challenges inherent with mashups. The full potential of mashups occurs when arbitrary users, without approval from a centralized authority such as a company's IT department, can import arbitrary widgets into their own mashup. However, the security techniques used in today's popular Web browsers did not anticipate the unique requirements of mashups, where 3rd party widgets co-exist with each other within the same Web page. A naively constructed mashup very well could allow malicious widgets to send the user's personal information to a malicious server, send company-private information to a malicious server, or trigger sensitive web transactions (e.g., an eCommerce transaction) using user credentials stored within cookies.

A key thrust for OpenAjax Hub 1.1 is to prevent such attacks from malicious widgets. OpenAjax Hub 1.1 extends the (typically intra-frame) publish/subscribe features found in OpenAjax Hub 1.0 (the "Unmanaged Hub") by adding the ability to set up a managed hub (typically inter-frame) that allows incorporation of untrusted widgets from third parties. Untrusted widgets are isolated from the rest of the mashup (often using IFRAMEs) such that all information exchange to and from each untrusted widget occurs over a secure, mediated message bus.

Managed Hub Conceptual Overview

If the mashup container application and the widgets use OpenAjax Hub 1.1, then Hub 1.1 manages inter-widget communications under the hood via the OpenAjax Hub 1.1's Managed Hub mechanisms. The following pictures provides a conceptual overview for how widget-to-widget communications works in Hub 1.1. (Note: the picture below is a conceptual overview. Actual implementation details differ slightly.)

The picture above assumes that the user clicked on something within Widget-C, which causes Widget-C to broadcast an event to the other widgets. The picture also assumes that Widget-A is interested in this event, and therefore has subscribed to this event (and identified a callback function). Finally, let's assume that the security manager for the mashup allows the given message to travel from Widget-C to Widget-A. Here are the steps:

1. The mashup container application loads the JavaScript files for OpenAjax Hub 1.1 and all communications providers that it will be using. In this example, two providers are used, the inline provider and the smash provider. (The sections below will provide an explanation of what providers are and will discuss the inline and smash providers.) Once the JavaScript files have been loaded, the mashup container application creates an instance of "Managed Hub" using the OpenAjax.hub.createManagedHub(...) method.
2. The mashup container application then loads all of the widgets that are in the mashup by telling the appropriate provider to load a given widget. In this example, the mashup container application will ask the inline provider to load Widget-C and the smash provider to load Widget-F and Widget-A. As part of the loading process, the mashup container side of the provider passes information to the widget to tell it which client-side provider it should load and use. Once the widget loads its provider, the widget establishes a connection to that provider, and therefore to the mashup container application, by calling the OpenAjax.hub.connect(...) method, which returns a connection handle object (a connHandle).
3. As part of its initialization logic, Widget-A wants to listen for a particular event, so it calls connHandle.subscribe() to register a callback function that will be invoked whenever that event is received.
4. The mashup is now ready for the user to run. During the course of operating the mashup, the user makes a selection in Widget-C, which causes the logic within Widget-C to invokes connHandle.publish() to notify other widgets about the event.
5. The Hub 1.1 logic that is embedded in Widget-C passes the published message to the provider that was loaded with the widget (in this case, the inline provider).
6. The Widget-C side of the inline provider passes the message to the mashup container side of the inline provider.
7. The inline provider within the mashup container application passes the message to the Managed Hub.
8. The Managed Hub passes the message to the security manager, which decides which subscribers (if any) are allowed to receive the message.
9. The Managed Hub dispatches the message to all widgets that have subscribed to the given event and that are allowed to receive the message. (In this example, the event is dispatched only to Widget-A.) Note that the event is channeled first through the provider that corresponds to a given widget. (For Widget-A, it is the smash provider.)
10. The smash provider logic within the mashup container application then passes the message to the smash provider logic within Widget-A. (With the smash provider, this will be cross-frame message passing.)
11. The smash provider within Widget-A passes the message to the Hub 1.1 logic in Widget-A.
12. The Hub 1.1 logic in Widget-A invokes the callback function that was registered in step 3.

Sample source code

The following sections outline how the source code might look for the scenarios pictured above.

Mashup container application source code

The following source code depicts how the mashup container application's HTML and JavaScript might look to produce the scenario pictured above. (The code below is for illustrative purposes only. An actual mashup container application probably would be programmed differently. For example, instead of hardcoding the loading of the 3 widgets, the mashup container application probably would use a more dynamic approach.)

<html>
<head>
  <title>Mashup Container Application</title>
  <!-- Load the JavaScript files for OpenAjax Hub 1.1 -->
  <script type="text/javascript" src="Hub11/OpenAjax.js"></script>
  <script type="text/javascript" src="Hub11/OpenAjax-mashup.js"></script>
  <!-- Load the providers that will be used -->
  <script type="text/javascript" src="Hub11/providers/smash.js"></script>
  <script type="text/javascript" src="Hub11/providers/inline.js"></script>
  <script type="text/javascript">
    function loadEventHandler() {
      /* Create a Managed Hub instance */
      managedHub = OpenAjax.hub.createManagedHub(...);
      /* Load Widget-C with the inline provider */
      inline.load(...); 
      /* Load Widget-F and Widget-A with the smash provider */
      smash.load(...);
      smash.load(...);
    }
  </script>
  <body onload="loadEventHandler()">
    <!-- body contents not shown -->
  </body>
</html>

Widget source code

For illustrative purposes, we will assume that the widget either conforms to the widget XML format in the OpenAjax Metadata Specification or can be transcoded into that format. The following illustrates how Widget-F might look:

<widget xmlns="http://ns.openajax.org/widgets" name="Widget-F">
  <description>Widget that presents information that is pulled down 
               dynamically from a public web server</description>
  <content>
    <![CDATA[
      <div id="...">
        <!-- user interface elements would go here -->
      </div>
    ]]>
  </content>
  <pubsub>
    <subscribesTo topic="..."/>
  </pubsub>
</widget>

One of the obvious things missing from the above sample source code are the JavaScript files for OpenAjax Hub 1.1 and the smash provider. The assumption in the above source code is that the mashup container application will provide wrapper logic around the simple widget XML that is shown above. This wrapper logic will load OpenAjax.js, OpenAjax-mashup.js, the smash provider's JavaScript, establish a connection to the mashup container applications's managed hub, and calls connHandle.subscribe() on behalf of the widget to subscribe to the topic listed in the <subscribesTo> element. (Note: wrapper logic examples can be found in the OpenAjax Alliance open source project.)

Providers overview

OpenAjax Hub 1.1 has an architecture that allows plug-in message passing "providers" to receive messages from and pass messages to the widgets in the mashup. Hub 1.1 ships with two standard providers (the smash provider and the inline provider) and allows the use of other custom providers.

The smash provider

The smash provider allows for secure inclusion of untrusted widgets within a mashup. This provider implements the SMash techniques (see the SMash research paper) which uses the following approach:

• Widgets are placed into IFRAMEs that have a different subdomain than the mashup container application and the other widgets. This technique leverages the same-domain policy that is implemented in today's popular browsers whereby the browser disallows JavaScript or DOM bridging between different-domain IFRAMEs.
• Inter-widget communication happens through a particular mechanism (the window.location fragment identifier, aka "IFrame Proxy" technique) that can be shared among the IFRAMEs. Note that the SMash techniques sets up the IFRAMEs such that all communication via IFrame proxies is mediated by the mashup container application, which prevents widgets from listening in on the SMash communication channel.

The inline provider

The mashup container application might choose to use the inline provider for widgets that were developed by a trusted supplier (e.g., yourself or your company), where it is advantageous to place the widget inline (e.g., better performance characteristics). The inline provider places the widget's Ajax content within a DIV in the same frame as the mashup container application. Note that the inline provider does not isolate its widgets, so it should be used with extreme caution.

Other providers

The Hub 1.1 architecture allows for plugin providers. The alliance will investigate other providers that might ship with future version of OpenAjax Hub. For example, in the future, the alliance might develop a 3rd standard provider that leverages some of the features that have been proposed for HTML5.

Third parties are welcome to develop other providers, but developers should be sure about the trustworthiness of 3rd party providers. In the Hub 1.1 architecture, providers are able to participate in "kernel activities" with the Hub, and therefore malicious providers will have broad access to any information available to any of the widgets.

Security characteristics of the smash and inline providers

The following table lists some of the key security issues associated with mashups and how the two providers work to address those issues:

Security issue	Description	smash	inline
Authentication	?	?	?
Integrity	?	?	?
Confidentiality	?	?	?
Pshishing	?	?	?
Man-in-the-middle	?	?	?
Cross-site scripting (XSS)	?	?	?
Cross-site request forgery (CSRF)	?	?	?