Reference Guide

Web Layer
Components in this layer are responsible for receiving and consuming appropriate external
representations (XML, JSON, binary...) suitable for communicating with various external entities
and, if applicable, for utilizing the APIs from the business logic layer to appropriately interact with
the business logic services to achieve the desired tasks and/or to obtain or process the desired
information.
User Interface End-Point (REST API) and end-point resources for handling inbound requests
providing control and data access capabilities to the administrative GUI.
External Interface End-Point (REST API) are end-point resources for handling inbound requests
providing control and data access capabilities to external applications, including other
orchestration and administrative tools (for example IMC, OpenStack , etc.)
Business Logic Layer
Components in this layer fall into two fundamental categories: model control services and
outbound communications services, and each of these are further subdivided into public APIs and
private implementations.
The public APIs are composed of interfaces and passive POJOs [19], which provide the domain
model and services, while the private implementations contain the modules that implement the
various domain model and service interfaces. All interactions between different components must
occur solely using the public API mechanisms.
Model API—Interfaces & objects comprising the domain model. For example: the devices, ports,
network topology and related information about the discovered network environment.
Control API—Interfaces to access the modeled entities, control their life-cycles and in general to
provide the basis for the product features to interact with each other.
Communications API—Interfaces which define the outbound forms of interactions to control,
monitor and discover the network environment.
Control Implementations—Implementations of the control API services and domain model.
Communications Implementations—Implementations of the outbound communications API
services. They are responsible for encoding / transmitting requests and receiving / decoding
responses.
Health Service API—Allows an application to report its health to the controller (via the
HealthMonitorable interface or proactively submitting health information to the HealthService
directly via the updateHealth method) and/or listen to health events from the controller and other
applications (via the HealthListener interface). There are 3 types of health statuses:
• OK – A healthy status to denote that an application is functioning as expected.
• WARN – An unhealthy status to denote that an application is not functioning as expected
and needs attention. This status is usually accompanied by a reason as to why the
application reports this status to provide clues to remedy the situation.
• CRITICAL – An unhealthy status to denote that some catastrophic event has happened to
the application that affects the controller’s functionality. When the controller receives a
CRITICAL event, it will assume that its functionality has been affected, and will proceed to
12