In this section, a complete example of a subsystem and a service registration and discovery is presented, based on the implementation done for the Semantic Subsystem and Service Repository of the ACCUS ICP. More specifically, using an example, the whole registration and discovery procedures will be shown, both for subsystems and services focusing on the input and output data formats, with the advantage of using specific data. Finally, validation done for evaluating the implementation will be also displayed.
4.1. Description of a Use Case Example
The proposed scenario involves a traffic control urban subsystem, which provides a traffic lights control service for managing the traffic lights cycles, along with information about the traffic density in several road intersections of a city. A smart mobility application uses the information provided by the traffic control subsystem in order to adapt traffic lights cycles to reduce and avoid traffic jams in the city.
Information provided by the traffic control subsystem is obtained by means of a Wireless Sensor Network, whose nodes will be deployed in road intersections of the city. The measurements taken by the sensors are sent via radio from the mesh network to the gateway, which comes with a special wireless node performing the base station role. This gateway is in charge of gathering data from the sensors and storing data until it is sent to the server and acts as an interface between ACCUS ICP and the Wireless Sensor Network. Then, the server, where all the data provided from the different sensors is collected and permanently stored, serves the data to the ACCUS ICP per request.
Both smart mobility application and traffic control subsystems are connected to the ACCUS ICP, which facilitates the communication between them with the services the platform provides. In order to enable this communication, traffic control subsystem must be registered in the ACCUS ICP first, so that it can be discovered and used by the smart mobility application.
Once the traffic control subsystem is connected, it sends a registration request, along with information about the subsystem, to the ACCUS ICP by means of its Subsystem Adaptor, using the corresponding method provided by the Application Interface. This method uses the Ontology Connector service to adapt the subsystem data sent in the request to an ACCUS ICP compliant format. Then, the Enterprise Service Bus locates and sends the request to the Semantic Subsystem and Service Repository, which registers the subsystem information received in a semantic repository, assigns an ID to the subsystem and returns it to the subsystem.
After subsystem registration, the traffic lights control service the subsystem provides is registered following the abovementioned procedure. When the service registration is completed, a smart mobility application can discover both the registered subsystem and service by querying Semantic Subsystem and Service Repository with SPARQL queries. In that case, information about the registered subsystem and service is returned to the smart mobility application in XML format.
Figure 14 shows the use case example, the whole registration and discovery processes as well as the interactions among the subsystem, the smart mobility application and the ACCUS ICP components involved in these processes.
4.2. Example of Subsystem and Service Registration and Discovery
Following the use case example presented in the previous section, and assuming that a) there is a traffic control subsystem that provides a traffic lights control service that b) has been just connected to the ACCUS ICP, two actions are carried out. As shown in
Figure 15, first, the subsystem is discovered by the ICP and secondly, the subsystem sends a registration request to the ICP with information about it.
Table 1 shows the information sent by the subsystem as well as the semantic annotations that the Semantic Subsystem and Service Repository will use to store that information.
Again, this information can be sent in some machine readable format as, for example, in XML or JSON. ACCUS ICP receives this data via a REST interface, and Semantic Subsystem and Service Repository converts the input data into semantically annotated data formatted in RDF. To do so, Jena API methods are used in order to obtain the classes defined in the ontology graph and stored in an .owl file, as well as to instantiate them with the values of the input data. Finally, the data is stored in a triple store database provided by Jena, called Jena TDB, and a unique ID is assigned to the subsystem and returned to it through the REST interface. This interface is also used whenever a subsystem, service or application connected to the ACCUS ICP wants to discover another subsystem, service or application registered in the ICP.
Once the traffic control subsystem has been registered, the traffic lights control service it provides is registered and, for that purpose, it sends a registration request to the ACCUS ICP with the information about it.
Table 2 shows the information sent by the service as well as the semantic annotations that the Semantic Subsystem and Service Repository will use to store that information.
Then, when the ACCUS ICP receives the data, Semantic Subsystem and Service Repository registers the service, following the same procedure as for the subsystem, and finally an ID is assigned to the subsystem’s service.
As soon as the subsystem and the service it provides have been registered, they can be discovered by any subsystem, service or application connected to the ACCUS ICP, thus obtaining information about them. To do so, they can query the Semantic Subsystem and Service Repository, using one of the methods that this service API provides. The results will be output in a document XML.
For example, if the smart mobility application wants to discover the traffic control subsystem previously registered, it can call listAllSubsystems method, which returns a list of all registered subsystems, or also it can call subsystemInfo method, which returns the information about the subsystem whose ID matches the one passed as an input parameter.
Therefore, calling, for example, the latter method using the traffic control subsystem ID, the following SPARQL query is executed:
PREFIX ns: <http://www.semanticweb.org/ACCUS/1.1#>
SELECT ?subsystemID ?subsystemFunctionality ?subsystemHealthState ?subsystemGeolocation
?subsystemProvider ?subsystemOwner ?subsystemCost ?subsystemPolicies
WHERE {ns:@[email protected] ns:isSSIDOf ?subsystem.
?subsystem ns:hasSSID ?subsystemID.
?subsystem ns:hasSSHealthState ?subsystemHealthState.
?subsystem ns:hasSSContext ?subsystemContext.
?subsystemContext ns:hasSSGeoLocation ?subsystemGeolocation.
?subsystem ns:hasSSProfile ?subsystemProfile.
?subsystemProfile ns:hasSSFunctions ?subsystemFunctionality.
?subsystemProfile ns:hasSSCost ?subsystemCost.
?subsystemProfile ns:hasSSPolicies ?subsystemPolicies.
?subsystemProfile ns:hasSSOwner ?subsystemOwner.
?subsystemProfile ns:hasSSProvider ?subsystemProvider.}
And the following output will be returned:
<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
<head>
<variable name="subsystemID"/>
<variable name="subsystemFunctionality"/>
<variable name="subsystemHealthState"/>
<variable name="subsystemGeolocation"/>
<variable name="subsystemProvider"/>
<variable name="subsystemOwner"/>
<variable name="subsystemCost"/>
<variable name="subsystemPolicies"/>
</head>
<results>
<result>
<binding name="subsystemID">
<uri>http://www.semanticweb.org/ACCUS/1.1#3309</uri>
</binding>
<binding name="subsystemFunctionality">
<uri>
http://www.semanticweb.org/ACCUS/1.1#Traffic Control Subsystem
</uri>
</binding>
<binding name="subsystemHealthState">
<uri>http://www.semanticweb.org/ACCUS/1.1#Active</uri>
</binding>
<binding name="subsystemGeolocation">
<uri>
http://www.semanticweb.org/ACCUS/1.1#Latitude: 54.3521 Longitude:
18.64637
</uri>
</binding>
<binding name="subsystemProvider">
<uri>http://www.semanticweb.org/ACCUS/1.1#ACCUS</uri>
</binding>
<binding name="subsystemOwner">
<uri>http://www.semanticweb.org/ACCUS/1.1#Company1</uri>
</binding>
<binding name="subsystemCost">
<uri>http://www.semanticweb.org/ACCUS/1.1#Free</uri>
</binding>
<binding name="subsystemPolicies">
<uri>http://www.semanticweb.org/ACCUS/1.1#Policy1, Policy2</uri>
</binding>
</result>
</results>
</sparql>
Similarly, if an application, subsystem or service wants to discover the traffic lights control service previously registered, it can call, the listAllServices method which returns a list of all registered services, or also the serviceInfo method, which returns information about the service whose ID matches the one passed as an input parameter. In the first case, the SPARQL query executed for listing all the registered services is the following:
PREFIX ns: <http://www.semanticweb.org/ACCUS/1.1#>
SELECT ?serviceID ?serviceFunctionality ?serviceType ?serviceHealthState ?serviceKind ?serviceCost ?securityProfile
WHERE {?Resource ns:hasSServiceType ?serviceType.
?Resource ns:hasSCost ?serviceCost.
?Resource ns:hasSHealthstate ?serviceHealthState.
?Resource ns:hasSProfile ?serviceProfile.
?serviceProfile ns:hasSID ?serviceID.
?serviceProfile ns:hasServiceFunctionality ?serviceFunctionality.
?serviceProfile ns:hasSKind ?serviceKind.
?serviceProfile ns:hasSecurityProfile ?securityProfile.}
and the information returned will be the following:
<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
<head>
<variable name="serviceID"/>
<variable name="serviceFunctionality"/>
<variable name="serviceType"/>
<variable name="serviceHealthState"/>
<variable name="serviceKind"/>
<variable name="serviceCost"/>
<variable name="securityProfile"/>
</head>
<results>
<result>
<binding name="serviceID">
<uri>http://www.semanticweb.org/ACCUS/1.1#4713</uri>
</binding>
<binding name="serviceFunctionality">
<uri>http://www.semanticweb.org/ACCUS/1.1#Subsystem and Service
Repository: an ontology translator for ACCUS ICP data treatment,
whenever the nSSOO ontology is required, that will be storing semantic information related with subsystems and services connected to the ICP.
</uri>
</binding>
<binding name="serviceType">
<uri>http://www.semanticweb.org/ACCUS/1.1#ACCUS ICP service</uri>
</binding>
<binding name="serviceHealthState">
<uri>http://www.semanticweb.org/ACCUS/1.1#Active</uri>
</binding>
<binding name="serviceKind">
<uri>http://www.semanticweb.org/ACCUS/1.1#ACCUS compliant</uri>
</binding>
<binding name="serviceCost">
<uri>http://www.semanticweb.org/ACCUS/1.1#Free</uri>
</binding>
<binding name="securityProfile">
<uri>http://www.semanticweb.org/ACCUS/1.1#ACCUS security profile</uri>
</binding>
</result>
<result>
<binding name="serviceID">
<uri>http://www.semanticweb.org/ACCUS/1.1#8647</uri>
</binding>
<binding name="serviceFunctionality">
<uri>http://www.semanticweb.org/ACCUS/1.1#Traffic lights control </uri>
</binding>
<binding name="serviceType">
<uri>http://www.semanticweb.org/ACCUS/1.1#Subsystem service</uri>
</binding>
<binding name="serviceHealthState">
<uri>http://www.semanticweb.org/ACCUS/1.1#Active</uri>
</binding>
<binding name="serviceKind">
<uri>http://www.semanticweb.org/ACCUS/1.1#Not ACCUS compliant</uri>
</binding>
<binding name="serviceCost">
<uri>http://www.semanticweb.org/ACCUS/1.1#Free</uri>
</binding>
<binding name="securityProfile">
<uri>http://www.semanticweb.org/ACCUS/1.1#securityProfile1</uri>
</binding>
</result>
</result>......</result>
</result>......</result>
</results>
</sparql>
Note that, when listing all services, information about Semantic Subsystem and Service Repository is also shown because internal ACCUS ICP active services are also registered in the semantic repository once the ICP is up.
4.3. Validation
In order to validate the practical performance of the Semantic Subsystem and Service Repository implementation, both the response time and the registration rate of the service have been tested. In order to test the response time, the timespan used for the different operations that the service provides to be executed has been measured. For each measurement, three samples have been taken in order to obtain an average value of the response time. On the other hand, the registration rate refers to the percentage of subsystems and services registered with regards to a certain number of registry requests done.
Tests have been done using an Intel(R) Core(TM)2 Quad CPU Q6600 processor @ 2.40 GHz equipped with 2.39 GHz and a RAM memory of 4 GB in a machine operating under the 64-bit Windows 7 Professional operating system.
4.3.1. Response Time
When a request is done to the Semantic Subsystem and Service Repository for the first time, this service must be initialized, so it takes more time than usual to execute the request. So, to begin with, the response time required when a request is done to the semantic repository for the first time has been measured. Results obtained are shown in
Table 3.
Now, considering that the service has been initialized, the response time of the semantic repository operations has been measured in three different cases: when the repository has 100, 500 and 1000 of subsystems and services registered. The purpose is to test the normal operation of the semantic repository for different amounts of registered data. The results obtained are shown in
Table 4,
Table 5 and
Table 6.
Analyzing the results obtained, several conclusions can be drawn. Besides the fact that the response time is higher when the first request is done due to the initialization of the semantic repository, it can also be appreciated that the response time increases with the amount of subsystems and services stored.
Comparing the time response between the different operations, it can be seen that the time response of listAll operation is considerably higher than in the other operations due to the higher amount of data that must be retrieved, which are all the subsystems and services stored in the semantic repository, while, for example, in listAllSubsystems and listAllServices only operation subsystems in the first case, and services in the second case are shown. Regarding the last two operations mentioned, the time response of listAllSubsystems is higher than the time response of listAllServices because in the first operation more information is shown than in the second operation. For the same reason, time response in registerService and getServiceInfo operations is higher than in registerSubsystem and getSubsystemInfo. Finally, it can be appreciated that the time response of registerSubsystem, registerService, getSubsystemInfo, getServiceInfo does not change significantly with the amount of data registered, because in these operations just one subsystem or service is registered or queried so they are not affected by the amount of data registered.
4.3.2. Registration Rate
For testing the registration rate, 5000 subsystem and service registry requests were done towards the Semantic Subsystem and Service Repository, and all the requests were successfully executed, registering the 100% of subsystems and services that requested registration.