OpenAjax Hub 2.0 Specification Publish Subscribe Overview
From MemberWiki
NOTE: This wiki page holds part of the OpenAjax Hub 2.0 Specification.
Contents |
3 Publish/Subscribe Overview
Mashups (and Other Composite Applications) Overview
One of the primary target application scenarios for the OpenAjax Hub are composite applications such as 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 component (e.g., Google Maps) and another part of the screen showing a table of location-based 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 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 technique that allows rapid application assembly by non-programmers, thereby broadening the base of people who can build applications, 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 have 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 client-side 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 programmer-built mashup category. In this scenario, a programmer uses Ajax technologies (e.g., HTML and JavaScript) to implement a Web page that combines 3rd-party Web services, widgets and feeds as components within a Web page.
- End-user built mashups - In this scenario, a non-programmer creates the mashup using mashup assembly 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, possibly using drag-and-drop gestures to pull from a widget palette onto the mashup canvas.
The publish/subscribe features of the OpenAjax Hub target both programmer-built mashups and end-user built mashups.
Cross-component communication using the Hub
The primary features of the OpenAjax Hub are its publish/subscribe APIs that allow different components to send messages to each other. The pub/sub features in the Hub support the anonymous broadcast of messages within the mashup; publishers are typically unaware of how many subscribers there might be or who might be subscribing. The subscriber APIs allow the use of wildcards in order to subscribe to a range of topics.
- (Note: Although the Hub is centered on anonymous message passing, applications can add higher level logic to achieve advanced features such as point-to-point messaging, cross-component property management, and remote procedure calls.)
Topics and payloads
For both the Unmanaged Hub and the Managed Hub, components broadcast messages by invoking one of the Hub's publish(topic, data) functions. The topic parameter specifies a string name describing the published message; the data parameter holds the data payload of the message.
To illustrate using the Unmanaged Hub APIs, let's assume one component publishes a message whenever a new location.set event occurs:
var location_data = { lat:current_latitude, long:current_longitude };
OpenAjax.hub.publish("org.example.location.set",location);
and that a different component wants to be notified whenever the location.set event occurs, and therefore subscribes as follows:
function onDataCallback(topic, data) {
// Do something in response to the event and its data
}
OpenAjax.hub.subscribe("org.example.location.set",onDataCallback);
In the above example:
- The topic is "org.example.location.set"
- The data is a JavaScript object with two properties, 'lat' and 'long'
- There is a single callback function,
onDataCallback, that is called whenever someone publishes on the "org.example.location.set" topic
Here is the same example using the Managed Hub APIs. The publishing component invokes the HubClient APIs that are available to clients of the Managed Hub. (Note: the following examples assume that earlier logic initialized variable hubClient.)
var location_data = { lat:current_latitude, long:current_longitude };
hubClient.publish("org.example.location.set",location);
One of the subscribing components might have code that looks like this:
function onCompleteCallback(item, success, errCode) {
// Callback that receives notification whether the subscription request succeeded
}
function onDataCallback(topic, data) {
// Do something in response to the receiving the event and its data
}
var subID = hubClient.subscribe("org.example.location.set", onDataCallback, null, onCompleteCallback);
In the example above:
- The topic is "org.example.location.set"
- The data is a JavaScript object with two properties, 'lat' and 'long'
- There are two callback functions,
onCompleteCallbackandonDataCallback, where the first callback is invoked once immediately after the subscription request (perhaps asynchonously), and the second callback is invoked whenever the host application allows events on the "org.example.location.set" topic to be sent to this component
Refer to the "Best Practices" chapter for guidelines regarding topic names.
Unmanaged Hub and Managed Hub
The Hub supports both:
- A simple Unmanaged Hub that allows components within a single browser frame to communicate with each other via
publish()andsubscribe()APIs without any provisions for isolation or security - A more complex Managed Hub that includes the ability to isolate components into secure sandboxes, e.g., using IFRAMEs with different (sub-) domains.
The Unmanaged Hub
OpenAjax Hub 2.0's core, which includes the Unmanaged Hub, is small (<3K of JavaScript after compaction) and fast and well-suited to programmer-built mashups, where a JavaScript programmer is assembling various known and trusted Ajax components and web services into a composite web application and where he authors appropriate JavaScript logic to wire together the various components.
The following diagram illustrates typical usage of the Unmanaged Hub.
The Unmanaged Hub is described in the following chapter.
The Managed Hub
The Managed Hub feature set is significantly larger than that of the Unmanaged Hub. The ManagedHub is suitable both for developer-built mashups and for end-user built mashups, in which an end-user runs a mashup assembly application within a Web browser using a graphical user interface to assemble a custom application by placing widgets onto a canvas and wiring the widgets together. In this context, the ManagedHub's ability to isolate components into sandboxed containers helps the mash-up framework to provide a secure run-time.
The Managed Hub provides isolation mechanisms that ensure the following:
- Each sandboxed component cannot access the JavaScript environment or DOM of the host application or other components.
- The only mechanism by which the sandboxed component can communicate with the host application or other components is by using the Hub's
publish()andsubscribe()APIs. - Security manager callbacks by which the host application can apply a custom security policy that controls which components can publish and/or subscribe to which messages.
- The following security techniques must be implemented in conforming implementations (such as the OpenAjax Alliance open source reference implementation):
- Component loading and unloading techniques to ensure that the correct component is loaded and continues to run. A conformant implementation MUST include facilities that are designed to prevent malicious components from injecting themselves as replacements for the originally loaded components. (In other words, the Managed Hub must include anti-frame-phishing capabilities.)
- Messaging techniques that ensure private communication channels between the host application and each component, so as to prevent malicious components from monitoring messages directed to other components or forging messages towards other components.
- A means of preventing message forgery, i.e. each Hub component must verify the identity of the component that sent each message.
The following diagram illustrates typical usage of the Managed Hub.
The Managed Hub is described in a series of subsequent chapters.
Unmanaged Hub and Managed Hub comparison
The following table highlights the differences between the Unmanaged Hub and a Managed Hub:
| Unmanaged Hub | Managed Hub | |
|---|---|---|
| Design center | Programmer-built mashups | Programmer-built mashups and End-user built mashups (created using a mashup assembly application) |
| Key APIs | OpenAjax.hub.publish() OpenAjax.hub.subscribe() | hubClient.publish() hubClient.subscribe() |
| Core or optional | Core | Optional |
| Javascript code size | Small (<3K after compaction) | Larger |
| Component isolation | No | Yes (components can be isolated within secure sandboxes) |
| Security manager and message mediation | No (all messages are public within the current browser frame) | Yes (mashup assembly application includes a security manager which mediates all messages passed between widgets) |
| Types of components supported | "Components" in the loose sense (a component can be any snippet of HTML or JavaScript logic) | Components are frequently packaged as "widgets" using a popular industry widget format, such as the widget format found in the OpenAjax Metadata Specification. However, this is not a requirement; the ManagedHub can be used in isolation, without any widget framework at all. |
| How many hub instances | One (there is exactly one Unmanaged Hub per browser frame) | Any number (there can be muliple Managed Hub instances and, in some cases, multiple HubClient instances) |
| When introduced | OpenAjax Hub 1.0 | OpenAjax Hub 2.0 |
| Spec chapters | Unmanaged Hub Topic Names Best Practices | Managed Hub Overview Managed Hub APIs Managed Hub Containers Topic Names Best Practices |
