OZONE Platform

Developing Open Source Capabilities

What is it?

OZONE Widget Framework was originally designed to be a

method to enable composite views of many webapps, in

the model of iGoogle portal.

We refer to this as a 'single pane of glass'.

Widget Concept

A widget is nothing more than a web application, but designed for a simple task.

Think of a widget in the same model as a UNIX tool. One function, simple input and output, but able to be chained together for complex interactions.

Widgets currently require the use of the OZONE APIs.

Composite View / Dashboard

Dashboard Concept

The dashboard is designed to act as a container for other web applications, and is what provides the presentation mashup.

Dashboards, as a collection of 'things', are also an object represented in OWF that can be created, assigned, or shared with others.

How it works

In the previous example, you see three different web

applications presented in <iframe> elements in a

single presentation.

These web applications, either in cross domain or same

domain, have the capability to communicate with the

OZONE Inter-Widget Communication API.

Inter-Widget Communication (IWC)

In early 2009, we identified the need for web applications

to talk to each other directly at the client, instead of only

using server-side REST call brokering.

Since the W3C Web Messaging standard had not yet

been created, we developed a custom API to do exactly

the same thing, allowing customers to mashup web

capabilities from different vendors and across domains.

How IWC Works

The IWC is purely pub/sub eventing. Additionally, we have the capability to add additional APIs onto this message bus, or to link two elements directly together for RPC-style messaging.

Broadcast a message on a channel, anyone registered to that channel will receive the message.

Broadcast a RPC message onto a channel and define the receiving element, only the receiving element will get the message.

IWC Intents

Message Routing

In 2012 we introduced a community patch that was very similar to Google's Android Intents model. This allowed developers to add action-based routing to the messaging bus.

In the previous example, a user has selected a row from the grid in the upper left, which fires an Intent message with an action.

The container parses the action, and only shows tools registered to process that action.

Seems very simple.

It is, by design. We created a self-contained application

with communication APIs so that the user would be

able to drag and drop their favorite tools together into

a custom workflow.

Administration

Self-Contained System

The application is a Groovy on Grails application, and uses Spring Security and Hibernate to provide abstractions against authentication and persistence.

As a self-contained web application, we provide the ability to use your database and security infrastructure to administrate the use of OWF.

Why OZONE?

It's very easy to develop complex applications in a completely distributed model. As long as a few guidelines are standardized, specifically with messaging, each distributed team can build a portion of the presentation and integrate.

Since each piece is designed to be simple, pivoting changes to the presentation can be done quickly and a low cost to the overall experience.

What's Next?

OZONE Widget Framework was in dire need of a technical refresh. That's occurring now as a large refactoring effort.

Better User Interface

Better Support for REST

Active Open Source Development

Resources

Website: ozoneplatform.org

Google Groups: ozoneplatform-devs

Me: @in2rd on Twitter