Despite all the movement toward Web 2.0, GeoWeb is still in the Web 1.0 age. In the quest to establish the Geospatial Web or GeoWeb 2.0, a rich spatial Flex Viewer has been created, and it’s free. All source code is included, and it can be extended via a simple widget programming model.

From GeoWeb 1.0 to 2.0

What is GeoWeb 1.0? It’s the HTML equivalent of publishing geospatial information on the Web—in Web 1.0 style. According ProgrammableWeb, a site that provides news on mashups, APIs, and the Web as

platform, more than half of the mashups of public Web APIs are map based. The demands for better ways to use geospatial information are obvious. However, if you spent some time with those mashups, even the good ones, you would find that almost all of them are doing just one thing, putting markers (lines or polygons) on the digital maps, regardless how fancy the user interface (UI) and the data may be. That’s why GeoWeb 1.0 is still in the HTML age.

Towards Web 2.0, GeoWeb 2.0 would need to be able to answer spatial questions and solve real-life problems in the spatial context—in addition to locating and visualizing data on maps. For example, it should be able to answer questions, like when the fire broke out, taking into account wind direction and speed, which area will be effected by the smoke and how many residents will be effected; or what critical infrastructure needs to be protected. It should also be able to pinpoint the nearest safe shelters for residents likely to be affected, the best evacuation routes; and the best way to setup road blocks so that the least number of U-turns will occur. Of course, the list of questions and problem-solving requirements could go on and on.

To provide such a service would require an efficient and geographically accurate mashup of intuitive data visualization, bilateral data integration, sophisticate geospatial processes and, of course, all in the context of accurate maps. Providing service is the essence of GeoWeb 2.0.

The Software Resources

The tools and software libraries for Flex Viewer include:

• Flex Viewer download - Free with source code and developer’s guide
• Flex Viewer live demo
• Flex Builder Professional (Flex SDK 3.1)
• ArcGIS API for Flex 1.0 - Geospatial programming made easier with free download
• ArcGIS Online - Free sample geospatial services and maps

Design Goals

When designing the Flex Viewer, I placed the viewer within a larger architecture context. As shown on the following diagram, the viewer alone is merely a good looking cool Flex application that cannot make up the GeoWeb 2.0. It’s the combination of various data channels and backend services that will make GeoWeb 2.0 a reality.

In summary, the design goals are:

• A Flex rich Internet Application (RIA) on ArcGIS API for Flex that can be deployed out-of-box
• Fully leveraging the power of geospatial services provided by ArcGIS server, ArcGIS Online or other server side solutions
• The ability to add more features via simple widget programming models
• Showcase the best practices for developing Web 2.0 style RIA for GeoWeb

Design Principle

The design principle I followed through the whole design and development process can be summarized in one word: SIMPLICITY. If I were asked for a tagline, I’d quote Albert Einstein, “Everything should be made as simple as possible, but not simpler.”

The viewer should be simple to deploy, configure and use and easy to extend. At the implementation level, the DRY (don’t repeat yourself) approach from the Ruby on Rails camp drives the development and constant refectory.

Is any framework used for the design? No, because using any existing framework could compromise the simplicity principle. However, from the source code you can trace the adoption of best practices in some of those lightweight Flex frameworks.

The Architecture

The viewer is designed to have the composite application architecture in high cohesion and low coupling. As shown in the diagram, the viewer’s core functions have been partitioned into a set of components.

Two major design patterns are used to minimize the friction among components and allow widget-based modularity, Event Bus and Dependency Injection (DI).

Event Bus

The viewer containing event bus is a global event dispatcher that is used to facilitate communication (messaging) between different components. The event bus is defined in the EventBus class as a set of static proxy methods defined inside the SiteContainer (SiteContainer.mxml) class to enable access to the EventBus transparently.

With EventBus, the components don’t have to be intertwined together by accessing each other’s methods (hence, creating high friction and complicated to maintain). Instead, the components communicate with each other using the publish/subscribe model via the event bus.

For example, the ConfigManager needs start loading configuration information only after the container is fully initialized. Sequentially, the other components need their share of configuration information provided by the ConfigManager. As shown on the diagram, this process is conducted via messaging using the event bus.

To do that, as shown in the following code snippets, the container need publish only the event without engaging directly to the receiving end components. Then, the ConfigManager can consume the message via listener. At last, the other components that need configuration data would just subscribe the CONFIG_LOADED event and retrieve the data from the AppEvent object.

//Container: notify initialized
SiteContainer.dispatch(SiteContainer.CONTAINER_INITIALIZED);

...

//ConfigManager: Container notify initialized            
SiteContainer.addEventListener(SiteContainer.CONTAINER_INITIALIZED, init);

...


//ConfigManager: publish configuration data to event bus
SiteContainer.dispatchEvent(new AppEvent(AppEvent.CONFIG_LOADED, false, false, configData));

...

//Other Components: consume configuration data to event bus
SiteContainer.addEventListener(AppEvent.CONFIG_LOADED, config);

The same messaging approach is used throughout the rest of the viewer. This makes modifying the viewer very simple and easy. As long as the messages are kept intact, a whole component can be replaced without going through extensive refectory.

Dependency Injection

Dependency Injection (DI) in computer programming refers to the process of supplying an external dependency to a software component. It is a specific form of inversion of control (IoC) where the concern being inverted is the process of obtaining the needed dependency.

The DI approach offers more flexibility and simplicity, because it makes it easier to create alternative implementations of a given service type, and then to specify which implementation is to be used via a configuration file, without any change to the objects that use the service. Within the Sample Flex Viewer, the alternative implementations are the widgets. DI is also used to create custom widget templates.

The following code shows how DI is used by WidgetManager to load widgets into the containers without knowing the specific implementations of the widgets.

private function widgetReadyHandler(event:ModuleEvent):void
{
 	var info:IModuleInfo = event.module;
 	moduleTable.add(info.url, info);
 	var id:Number = info.data.id;
 	var label:String = configData.configWidgets[id].label;
 	var icon:String = configData.configWidgets[id].icon;
 	var config:String = configData.configWidgets[id].config;       
 	var widget:IBaseWidget = info.factory.create() as IBaseWidget;
 	widget.setId(id);
 	widget.setTitle(label);
 	widget.setIcon(icon);
 	widget.setConfig(config);
 	widget.setConfigData(configData);
 	widget.setMap(map);
 	widgetTable.add(id, widget);
 	var widgetDO:DisplayObject = widget as DisplayObject;
 	addChild(widgetDO);
 	this.cursorManager.removeBusyCursor();  
}

In the above code, once the widget module is loaded, it will be cast into the IBaseWidget interface type. The BaseWidget extends IBaseWidget just for this DI usage. Once the widget is cast into IBaseWidget type, the WidgetManager doesn’t need to know what kind of widget it is or what it does. The WidgetManager only needs to call the methods defined in IBaseWidget to communicate with the loaded widget. Therefore, the implementation of a widget, regardless of how complicated it may be, is totally independent of the WidgetManager or the whole Flex Viewer container. The developer can freely develop a widget without being constrained by the Flex Viewer.

The Widget Programming Model

A compiled widget of the Flex Viewer is a standalone SWF (Flash) file that can be shared, moved and deployed into the Flex Viewer application.

Typically, a widget encapsulates an isolated and focused set of business logic that allows users to perform a task. In a service-oriented environment, a widget represents a service or an orchestration of services that enable users to clearly execute a business function.

A set of correlated widgets plus a clearly defined business workflow applicable to these widgets provide the business solution. The solution, furthermore, can be deployed to participate in an enterprise-wide business process.

The best way to describe this simple widget programming model is through a widget’s code. The following is the example code for a widget:

<?xml version="1.0" encoding="utf-8"?>
<BaseWidget xmlns="com.esri.solutions.flexviewer.*"
			xmlns:mx="http://www.adobe.com/2006/mxml">
	<WidgetTemplate>
	//you business logic code is here.
	</WidgetTemplate>                 
</BaseWidget>

As shown in the code above, the widget programming model has only two classes: BaseWidget and WidgetTemplate. A widget for this Flex viewer has to extend BaseWidget, which extends the Flex Module class to allow the widget to be compiled into a stand-alone SWF file.

The WidgetTemplate is actually optional. Using it will give the widget a built-in look-n-feel and behaviors.

After compiling the above code into a SWF file, the widget can be deployed by simply adding a widget entry into the configuration file, config.xml.

<widget label  = "My First Widget"
	Icon   = "myicon.png"
	menu   = "menuWidgets"
	config = "";>
    mywidgets/MyFirstWidget.swf
</widget>    
  

After refreshing the viewer, the widget will be added into the specified menu. Clicking the widget menu item will trigger the viewer to load the widget SWF file into the viewer’s container and display it. The will look like this:

The idea behind the widget model is that the application can be extended horizontally. This means you no longer have to continue to add/compile new features into the application; this leads to increasingly complicated and bulky program. Instead, you can indefinitely add new features and still keep the application lean, clean and simple. This is the beauty of the composite application architecture.

The Build-in Widgets

A set of built-in widgets are included with the new release. As matter of fact, every functional piece from the viewer is a widget. The built-in widgets are created to demonstrate the capabilities of a widget, such as the GeoRSS feed widget, the map services widget to display dynamic real time map feed and the locate widget to identify location on the map. The service area widget demonstrates leveraging the power of server-side geospatial processes. The print widget for printing the maps, etc. More widgets have already been developed by various types of developers and most of them will be shared.

What’s Next?

The current release is just a beginning. To fulfill the GeoWeb 2.0 vision, more analytical integration and collaboration capabilities will be introduced. Some examples are:

• Widgets to allow map editing by integrate with powerful GIS backend server
• Collaboration widgets to enable redlining and real-time sharing by using services, such as BlazeDS or alikes<
• Widget chain to allow workflow orchestration at the UI by chaining widgets together and streaming the session to generate data through the chain (There is a hidden feature even now. Try playing with the locate widget and service area widget and see what you can find.)
• Offline/desktop capability

Other improvements could include be adding more themes. The current release has two UI themes, darkangel and lighterside.

I’m looking forward to hearing feedback from you!

Read more from Moxie Zhang.