Reference Guide

allows us to do any pre/post processing when the binding/unbinding takes place - useful when
using optional services.
The name for the methods to bind/unbind follows a standard defined by OSGi [5]. The name is
composed by the prefix bind/unbind plus the name of the variable in camel case format. Since
the variable is called alertService, the method to bind must be called bindAlertService (“bind” plus
the name of the variable with the first letter upper case). The annotation @Reference offers an
attribute “name” that allows changing the suffix for the bind/unbind methods. Check the OSGi [5]
[33] reference for more details.
In order to verify the service is actually consuming SystemInformationService use the Virgo Admin
Console again as described in Verifying Published Services Using Virgo Admin Console on page
161 . When everything works as expected SwitchService can be seen as a published Service. If
SwitchService is published it means it is consuming SystemInformationService because a
mandatory relation was specified; if SystemInformationService was not available then
SwitchService wouldn’t be published.
Creating a REST API
In the following information RESTful Web Services (or REST API) is created to expose to the outside
world functionality provided by the sample application.
REST follows a client-server architecture to achieve separation of concern between the client and
the server. The client is not concerned about the internal representation and state diagram of the
server, and the server is not concerned about the client logics and states. Instead, the client and
the server communicate via a simple uniform interface that is devoid of state information (Stateless)
[1].
For HTTP, the client is typically a web browser, but can also be a variety of other software, such as
Curl [17], a mobile app, or a desktop app. The server is typically a web container such as a Java
Servlet container (Our case), IIS, or Python WSGI container.
The communication between the client and the server must be stateless. That is, a request from a
client should not depend on a previous request, as the server does not store client state
information. This implies that each client request must contain all the information the server needs
to process it.
Creating Domain Service Resource (REST Interface of Business Logic Service)
Table 9 describes the REST API implemented to expose the SwitchService functionality from the
sample application.
Table 9 Switch REST API
Request
Description
GET /sdn/hm/v1.0/switches/
Lists all switches managed by the application.
GET /sdn/hm/v1.0/switches/{id}
Gets the switch with the given id.
POST /sdn/hm/v1.0/switches/
Adds a switch. The request’s data must contain the switch
data in JSON format.
DELETE /sdn/hm/v1.0/switches/{id}
Deletes the switch with the given identity.
169