Unknown macro: {next_previous_links}
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

WSO2 Dashboard Server (DS) is a gadget container that allows users to create dashboards via the Dashboard Designer, which is a web application. The Dashboard Designer provides the capability to customize dashboard layouts, add pages to a dashboard, configure inter-gadget communication based on the Pub-Sub mechanism, add dashboard banners, and much more.

The WSO2 Dashboard Server also provides a programming model based on the OpenSocial specification that allows users to write customized gadgets, which are a sharable UI component, based on their own requirements. As DS allows the users to create each gadget as an isolated unit, gadgets can be developed in parallel.

When a dashboard editor creates or updates a dashboard via the Dashboard Designer, the data is stored in the original registry space that is allocated for the dashboard. However, when a dashboard viewer personalizes a dashboard, the data is stored in the space allocated to that particular user in the registry. Thereby, enabling per-user dashboard customization; while, also preserving the dashboard editors preferences.

The following diagram illustrates the high level architecture of DS:

At the core of WSO2 Dashboard Server lies the WSO2 Carbon Server, which is based on the WSO2 Carbon Kernel, and the WSO2 Carbon Dashboard platform, which is packaged with Jaggery and Apache Shindig to support the Dashboard Designer application. As the WSO2 Dashboard Server is based on the WSO2 Carbon Kernel, all the features provided by the Kernel (e.g., user management, resource management, etc.) are available in DS. In addition, DS also supports Single Sign-On, which can be enabled for internal or external identity providers, so that users can access the Dashboard Designer and also communicate with third party APIs, used by various gadgets, provided the third-party APIs have a mechanism to validate the OAuth token with DS.

The following diagram illustrates the low level architecture of DS:

The various components that make-up the Dashboard Server architecture are explained as follows:

APIs and Pages

The WSO2 Dashboard Server includes the following three routers: API router, page router and tenant router

The tenant router filters all the incoming requests to the Dashboard Designer, by analyzes the request URL context, and redirects those requests to either the API or page router, which are routers in DS used to differentiate the incoming API requests and page requests. 

Controllers

The WSO2 Dashboard Server maintains separate controllers for the API and Page requests. If the request is a page request, the controllers process the request and directs the user to the respective web page. When the request is an API request, the controllers carryout the corresponding process and return a result.

Modules

Modules contain the functionality that the WSO2 Dashboard Server uses to handle the registry transactions and to perform business logic related to user requests.

Store

The DS Store contains the dashboard layouts and gadgets, which the DS users use to create dashboards. The tenant needs to create a separate directory, based on their tenant name, inside the <DS_HOME>/repository/deployment/server/jaggeryapps/portal/store directory to maintain their customized gadgets and layouts.  

Theme

The DS theme, which is located within the <DS_HOME>/repository/deployment/server/jaggeryapps/portal directory, contains the following two directories: image and templates. The image directory contains the images that are used in the web pages, and the templates directory contains web views.

Jaggery

The Jaggery module in the server contains the Jaggery compiler and features.

Shindig

This is the server that the Dashboard Server uses to render gadgets based on the opensocial specification. For more information, go to https://shindig.apache.org/.

 

  • No labels