Skip to end of metadata
Go to start of metadata

Articulates a "business model" that should be understandable by all stakeholders; focuses on purpose, scope, operational objectives, policies, enterprise objects, etc.

Service Oriented Architecture

A Service Oriented Architecture (SOA) is a 3-tier architecture where the data used by an application is separated by a service layer.  The abstraction provided by the service tier decouples the data and the application so that each tier becomes scalable.  There may be many services deployed that can service any number of applications in a consistent manner, especially if the services tier provides standards-based interface.
MapBuilder fits in the Application layer of an SOA.  It provides the framework to build applications that interact with web services.  For maximum extensibility, it provides a client implementation for standards-based services, but is not limited to those.  Almost any piece of information available through an Internet URL can be used in a MapBuilder application.

Modern web applications use the principals of something called Web 2.0.   This includes concepts such as  the Web as a platform , harnessing  the collective intelligence of communities with participatory applications (wikis, blogs, etc.), use of web services, and providing a rich user experience with programming techinques such as AJAX and DHTML .

MapBuilder implements many of the same concepts.  When designing your application you should think in terms of  accessing discrete bits of distributed information (through a web service), providing one or more representations of that information and the tools to control what happens in response to user actions.

For further reading:

Design Drivers

The following principles are used when making design decisions:

Client is a Web Browser
MapBuilder applications should be easy for users to run. Users should not have to download and install new software. Instead all MapBuilder clients should run inside the commonly used web browsers. In particular, Internet Explorer 6+ and Mozilla browsers based on Mozilla 1.3+.

Minimal Server-Side Requirements
MapBuilder should keep deployment requirements to a minimum in order to maximise the user base. Hence:

  1. Where possible, clients should not require server side scripts.
  2. If server side scripts are required, the server environments currently supported include: PHP and J2EE/JSP. Contributions for equivalent functionality in other server environments is encouraged.

Easy to incorporate libraries into a web page
MapBuilder widgets are to be incorporated into HTML web pages. Incorporating widgets should be kept simple so that someone with basic HTML and JavaScript knowledge can build a MapBuilder Web Page.

Keep bandwidth to a minimum
All client functionality and information content needs to be downloaded, so it is important to keep it to a minimum. Files that are downloaded should also be static which means that browsers will cache them locally.

Use Javascript/XML/XSL/DHTML
Mapbuilder stores state data internally in XML files. Converting XML to HTML is done using XSL. XSL has the advantage that it can be used both in the client and server.  DHTML and JavaScript techniques shall be used to manipulate MapBuilder objects in the browser.

Modular Design
A modular design has many benefits:

  1. A client need only include the module it requires, hence reducing the size of the client.
  2. A modular design is easier to understand, maintain and extend.
  3. Extra functionality can be easily added and removed.
  4. It is easier to break development up between multiple developers.

Open Source
MapBuilder software is open source. Open source was chosen because:

  1. Part of our target audience are community groups who often cannot justify buying software.
  2. Developers are more likely to extend open source software.
  3. It's fun developing open source software.
    Any libraries that MapBuilder uses or extends should not introduce an incompatible or closed license.

Model-View-Controller Design Pattern

MapBuilder implements the Model-View-Controller (MVC) design pattern.  It is a very useful design pattern for web applications because it provides good separation between the information content, the presentation of that information and the application state.
A Model represents the information of the application, typically in the form of an XML document retreived from a web service or in the the form of a static file at a URL. Models provide "get" methods to retrieve particular pieces of information or state and "set" methods to update the information and state of the model. When set methods are used, views are notified of the change by calling listeners that can be registered with the model.

A View is a representation of the information in a model. Views can register themselves with a model to be notified of changes in the model that may affect the view. This is typically using "listener" callback methods which are called for various event types. Views may also provide means to send user gestures (e.g. mouse clicks) to a controller. In MapBuilder, views are called widgets.

A Controller translates interactions with the view into actions to be performed by the model. Controllers modify the information and state of a model.  In MapBuilder, controllers are called tools.

The separation of model and view allows multiple views to use the same model. Consequently, model components are easier to implement, test, and maintain, since all access to the model goes through these components. This also makes it easy to extend because you can simply write a view and some controller logic and wire them into the existing application.


The use of standards greatly enhances the configurability and re-use of components in MapBuilder. Mainstream web standards (HTML, CSS, XML, XSL, etc.) are employed throughout. Web service standards are also used for accessing the content of the application, notably the geomatics standards developed by the Open Geospatial Consortium (OGC). These include:

  • Web Map Service (WMS) which renders geographic information as a picture.
  • Web Feature Service (WFS) which provides access to geographic data as vectors allowing manipulation and rendering of individual features
  • Web Map Context (WMC) which encodes a completed "map" composed of geographic information from several sources.
  • SLD

Other mainstream or defacto standards may also be supported such as Geo-tagged RSS (GeoRSS) for encoding geography in RSS feeds.  Work is ongoing to support mass-market and tiled data sources (Google maps, KaMap, etc.) WSDL/SOAP is not yet implemented but will be supported in the future.

Further details on the standards employed in MapBuilder are available in the Information Viewpoint.

  • No labels