Version 1 (modified by, 14 years ago) (diff)


Topic 8 GENI I&M Interfaces and Protocols (APIs): GUIs

Team members:

Jeremy Reed - Univ Kentucky (no)
Zongming Fei - Univ Kentucky (no)
Guilherme Fernandes* – Univ Delaware (yes)
Puneet Sharma - HP Labs (yes)
*Agreed to organize team

This section will lay out requirements and recommendations for GUIs that allow GENI users to manage (control, configure, access), visualize and discover I&M services, including the GUI themselves, and related data. The portals used by GENI experimenters to request the deployment of an I&M system or the instantiation of a sliver in an I&M component are not covered in the present draft. Requirements are defined to ensure GUIs and other services adhere to general GENI principles that must be enforced (e.g. privacy), and will tend to evolve from recommendations deemed essential by GENI I&M community. On the other hand, recommendations try to capture best practices in the field and general principles to increase the usability and effectiveness of these GUIs.

Note: This draft does not currently define any requirements or recommendations, but rather describes current practices, possible use cases and general thoughts that can hopefully inform the future definition of these requirements and recommendations by the GENI I&M WG.

Many design principles must be taken into consideration when developing GUIs for I&M architectures. As usual in Computer Science, these principles can be in sharp contrast with each other and trade-offs are made depending on the overall objective of the GUI. Following the general methodology of GENI, we identify GUIs developed for other I&M frameworks and services in order to capitalize on their strengths. A discussion of some of these design principles follows.

  • Centralized/Remote vs Distributed/Local vs Hybrid - These principles can be seen as part of a spectrum, with GUIs that provide a visual interface to services and data residing locally on the same machine on one end (e.g. pS-Performance Toolkit web interface), and GUIs that centralize management and distributed access to remote data and services on the other (e.g. MRTG+Cacti, CACTISonar). A centralized interface is the preferred approach on many use cases, such as health and status monitoring, as it increases the effectiveness and facilitates the access by providing a single, unified location for network management. However, collecting the data on a centralized location tends to increase the network overhead generated by network management. In contrast, GUIs with local scope tend to be faster in accessing data, create little or no network overhead and are generally simpler to build. Between these two extremes we can find hybrid GUIs. For example, a centralized visualization interface might cache only common queries and request others on demand (e.g. Periscope).
  • Flexibility vs Usability - GENI users should be able to have as much control as possible over the configuration of I&M services dedicated to their slice. In several instances it might be hard (or impossible) to identify a single set of parameters that satisfies all experimenters. GUIs can be designed to provide great flexibility (e.g. by permitting users to select what is to be displayed, how it should be displayed, or providing an interface to all sorts of configuration parameters). Expert users certainly appreciate having great flexibility, but even experts expect sensible defaults to be defined. On the other hand, non-expert users might be overwhelmed with too many options, reducing the GUI’s usability and users’ overall experience. Having different views (e.g. normal and advanced) with varying levels of complexity can be a conciliatory bridge between flexibility and usability.
  • Common graphical layouts and visualization aids - [There are established ways of presenting some types of data (e.g. utilization as line/area graphs with out and in directions overlayed, one- and two-way latency tests as scatter plots, measurement meshes results in 2D matrices). GUI developers should recognize de facto standards and try to follow them. Visualization aids are commonly provided through geographical maps, network topology diagrams, etc.]
  • Documentation?

The GENI I&M Architecture draft includes a Measurement Analysis and Presentation (MAP) Service. Many of the GUIs discussed in this section fall into this category. In contrast, network monitoring frameworks that take a middleware approach (e.g. perfSONAR) tend to view this type of service as users of the framework, sitting in a higher (external) layer. There are clear benefits of including this type of service in the architecture definition (e.g. it enables the main purpose of this section, namely to identify requirements and guide user expectations regarding GUIs). However, careful attention must be paid to the place of these services within the framework and the issues that arise.

One possible concern regards the substitutability of API functionality of other components through GUIs. For example, the API for a Measurement Point Service might define Start/Stop methods through a Web Services interface. If a GENI I&M system provides a GUI that allows the user to Start/Stop the MP, must the MP implement the same functionality (through the Web Services interface) to be considered compliant? Consider now the more complex example of GUIs that are the sole interface to a given dataset. Data might be pushed or pulled into a local (or remote) database which is then accessed by the GUI to display the data to the user (e.g. MRTG+Cacti). The data is clearly available to the experimenter through the GUI, but must it also be available through the defined MDA interface? Would it suffice for the GUI to be able to export the raw data in a give format (e.g. through HTTP file download)?

The access of GUIs to data raises very important issues regarding authentication and authorization in GENI. All of the GENI facilities must employ security mechanisms to ensure privacy and policy constraints are met. If a GUI has direct access to data, the GUI must likely employ the similar (same?) mechanisms as required on an equivalent MDA. On the other hand, if the GUI accesses other I&M services on demand to retrieve the d ata to be displayed, the GUI should allow the user to authenticate itself. In this case, should the user authenticate itself with the GUI, which is then trusted by the other services [this might make sense when the GUI is deployed as part of the I&M system]? Or should the GUI relay the authentication to the services by asking the user for its certificate (and password)? Both cases raise trust issues with the GUI themselves.

Finally, we address the discovery of and access to the GUI themselves. Some GUIs will likely act as services of the I&M systems (i.e. deployed within the system, maybe with direct access to data), and as such should likely be discoverable as any other service of I&M system (e.g. by registering to a Lookup Service). Open issues include determining the necessary information to register in order to meaningfully describe the GUI and its capabilities. Also, it is expected that many GUIs will be developed through the years by GENI users. GENI should likely provide an archive/repository to make these GUIs available and easily discoverable by the larger GENI community. Is this repository a centralized location (maintained by GENI) or just a Lookup Service pointing to the remote locations where the GUIs can be found?