mBlog

Now comes part 3 of my excerpt from capsFramework.

capsFramework

Introduction
The necessity of capsFramework constitutes with the request to have a framework that allows the user as well as the developer to create or use apps for vehicles with comparably small effort. Though, the developers shall be able to access sensor data straightforward with the use of APIs. The user shall have a simple to use platform in order to manage and access the different apps. The framework shall also follow
the idea of the web of things. The vehicle, and so all its data, shall be available for the vehicles owner and also for everyone or everything that are allowed to access it. capsFramework shall offer all the previously mentioned goals by utilizing proven and standardised protocols, applications and programming languages.
The following technologies are used: JBoss Application Server, Apache HTTP Server, DatabaseManagement System PostgresSQL,GWT,HTML, SOAP, REST and Java.
Figure 1 visualizes the interaction of the components in the capsFramework.

As you can see in figure 1 there are three main blocks: Server block including the two servers JBoss AS and Apache HTTP Server as well as the Sensoric Reader, Postgres database, caps and apps. The Simulation block includes CarSim which can produce sensor data and broadcast it. Finally the Sensor API block has got the elements capsWS and capsREST which can initiate a communication to the database. The Sensoric Reader consumes sensor data, for example from CarSim and sends this data to the database which stores it. caps has got an amount of apps and it can access the database. Every app can use the elements inside the Sensor API block in order to retrieve (sensor) data from the database. The previously named elements of capsFramework are described in the next sections.

JBoss AS
JBoss AS is an open source application server developed by the company Red Hat which is published under the LGPL license [JBo]. The current version is 6.0.0.M2.
Version 5.1.0 has been used in this work. JBoss AS allows it to host Java Enterprise Edition, abbreviated Java EE , projects and to make them accessible to the clients. Beside Java EE projects it is also possible to host web projects on the JBoss AS. Beside Servlets, Java Server Pages or Java Server Faces, JBoss can also interpret pure HTML combined with JavaScript.
One of the reasons to use JBoss AS is the fact that the applications of capsFramework, consisting of HTML and JavaScript, can be completely interpreted by it.
Another reason why JBoss AS was chosen, is the possibility to automatically deploy applications. The automatically deployment of applications means, that an application can be passed to the application server while the server is running. The server recognizes that a new application was deployed and initiates further actions so that this program can be accessed by the users shortly.
The capsFramework is designed to increase its amount of apps in the course of time so that the automatic deployment is one big factor in the architectural decisions. With JBoss AS it is now possible to deploy the app to a point in time when the user wants the app to show up and not when the system wants it. So the system does not need to be restarted in order to provide new applications to the user.

Apache HTTP Server
The Apache HTTP Server is a web server which deploys and interprets websites and makes them accessible to the user [Apa]. The Apache HTTP Server is an open source project of the Apache Software Foundation and is available for several operating systems like UNIX and Windows.
The reason why it was decided that another server in the capsFramework is necessary, was the fact that the possibility had to be created to access data which was not available to the time when the application was published. Such data, like pictures, videos, music etc., is often created or generated by user interactions. Since the data is created by the user at runtime of an app, it can not be inside the published web archive (*.war) because the data was not known at that time. So the data is not available for the JBoss AS and can not be simply deployed to it. The reason for it is, that only projects can be deployed to it which means that a so called deployment descriptor is needed. So, if the data is transferred to a directory of the application server a new deployment descriptor has to be generated every time so that JBoss knows about all its resources to perform the necessary actions to use them. This effort, mainly regarding the loss of time which comes along with the deployment procedure is too huge and not acceptable for such a system. Figure 2 demonstrates the described behaviour.

Therefore, it was decided to use a local web server, Apache HTTP Server, to which the additional data is transferred. The server does not need any descriptors and the data can be accessed without loosing performance.
The generation of data copies which are transferred to the web server is necessary because JavaScript runs in a sandbox-mode inside the browser. Sandbox-mode means, that one can not access data from the file system because of security aspects.
So, pictures, music, videos, etc. can not be reached by the applications which run on the capsFramework. But if the data is copied to the web server it is possible to reach it. This is because it is not tried to access the data via the file system but via a ”remote” web server which is allowed by the sandbox-mode. Figure 3 shows this scenario presented as a sequence diagram.

Sensoric Reader
This section describes the tool Sensoric Reader which can receive and persist sensor data.
The Sensoric Reader is a tool which is implemented in Java. It does not have a graphical user interface(GUI) but it works invisible in the background. The tool is constructed to receive data which the sensors inside the car transmit and to store them into a database (here: PostgresSQL). To receive the data, the Sensoric Reader uses the EIToolkit. EIToolkit provides methods to receive data in form of UDP, abbreviation for User Datagram Protocol , -packages.
In order to inspect the UDP sensor data packets a specification was defined: Every sensor dataset which is send via UDP consists of a field which contains the name of the sensor and another field which contains the actual sensor value. If the Sensoric Reader recognizes a UDP package, it checks whether it is a sensor data package and whether it accords to the specification. The contents of the package, sensor name and sensor value, is read out and passed to the next method inside the Sensoric Reader if it fits the specification. In next step, the actions to persist the data into the PostgresSQL database are executed. First of all, it is checked whether
the particular sensor is known to the database or whether it is a newly attached one. A new table is created if it is a new sensor. The new table will collect the sensor data from that time onwards. After that step the same procedure happens in both case (existing sensor, new sensor): The sensor value, which was extracted from the UDP package, is stored in the particular table of the database. Beside the sensor value, a timestamp, which symbolizes the time of recognizing the sensor value by the system, is stored with the value. From now on, the sensor data which was send by the car is available for the capsFramework and can be requested at any time.

EIToolkit
The EIToolkit is a generic platform which can be extended by different technologies respectively methods with the help of stubs [EITb]. Among other things, TCP and UDP are provided for the communication. It has been already successfully used in projects like CARS [Ker08][EITa].
capsFramework uses EIToolkit in order to start a so called PacketObserver which listens to incoming UDP packages. Therefore, a class which extends the PacketObserver class is implemented . This class starts a UDP client which listen and analyses UDP packages. With the help of the class Paket, which is also contained in the EIToolkit, it is possible to access the contents of a UDP package.

Sensor API
This section describes the interfaces which are provided by the capsFramework.
These interfaces are represented by two Application Programming Interfaces, abbreviated API . The first API allows the access to the sensor data via the implemented SOAP web services. This API is called capsWS. The second API provides the same services like capsWS but it uses REST to access the sensor data.
The reasons why an API is provided to access the sensor data and not a direct access to the PostgresSQL database are the following: simplification and security. The access to the data was simplified in the way that several services are offered to execute certain tasks directly. It is not necessary to do any arrangements to get a connection to the database and to form any SQL(Structured Query Language)
statements. There also arrangements like including the appropriate JDBC (Java Database Connectivity) driver to initiate a communication between Java and PostgresSQL. The access to the persistent data is managed by the server and the result is delivered to the clients which use the API. The engagement with the database and its structure is not applicable.
The other reason is security. If a direct communication from an application to the database would be allowed, the user-password relation of the database has to be published. So, every application developer would have access to the complete database. Intended or unintended changes of the database state can be a result of this. It could lead to a loss, insertion or overriding of data sets. By providing an interface like the API, the developer can only send requests to it and wait for its response. The server will manage the access to the database so that the operations on data sets are safe and will not be manipulated. Figure 4 shows a general
interaction of application, sensor API and database.

capsWS
capsWS is an abbreviation for Car ApPlication System – Web Service. capsWS provides an API and hence an interface for accessing the persistent sensor data via SOAP.

capsRest

capsREST is an API which is based on REST and offers the possibility to access sensor data in the capsFramework. capsREST is an one-to-one implementation of the SOAP methods in capsWS converted to REST. So, the user does not have to relearn this API if he had used capsWS before, because the methods have the same names and parameters.

caps
caps represents a minimalistic operating system to manage and execute apps written with GWT. It can be roughly divided into two parts: desktop and kernel. First of all a graphic about caps’ architecture is shown in figure 5  which illustrates the layout of the caps’ desktop.