Research efforts at webinos never cease to push boundaries and cross final frontiers. Thus, with the following series of interviews “Face 2 Face with webinos”, which kicks off right now, we aim to go back to basics and give you a heads up on the basic development of the project. A milestone for our Open Source code to be spread is the adoption of our APIs by developers worldwide. By the way, do you know what APIs are available at webinos? Are you aware of their functions and status? To find the answer to those and other important questions, we had a chat with Louay Bassbouss from Fraunhofer FOKUS who gave us an overview of the APIs as well as detailed functions and explanation of their functionality.
Louay Bassbouss studied Computer Engineering at the Technical University of Berlin (TUB). He received his diploma in October 2008 with the completion of his thesis about Automatic Service Composition in user-centric mobile networks. Since that time, he started working as research engineer at the group of Open Communication Systems (OKS) at the Technical University of Berlin and the Competence Center Future Applications and Media (FAME) of the Fraunhofer Institute for Open Communications Systems in Berlin. His main research activities focuses on service composition, collaboration and interaction within the area of service oriented architectures as well as Web 2.0. Louay Bassbouss has been involved in multiple national (DOCAMPUS, Government Mashups) and international projects (BIONETS, uMash, Padgets, Open Cities, COSMOS) within the area of service oriented architectures, Web Mashups, mobile computing, and technologies for future Web applications.
webinos: Can you provide an introduction to webinos APIs?
Louay Bassbouss: webinos APIs are a set of common and well specified programming interfaces to deliver desired functionality such as access to hardware and software resources of the underling system available to webinos applications. From developer view, it is important to know how these APIs are specified but not necessary to know how these APIs are implemented. The procedure from identifying until implementing an API in webinos is the following:
- Identify needed APIs based on requirements
- Identify needed APIs based on webinos architecture
- Investigate existing APIs (e.g. from W3C and WAC) if they can be used in webinos with or without modification
- Specify new or extend the specification of existing APIs
- Create API stubs and demonstrations to test API applicability for developer
A key feature of webinos is the ability to discover services on remote devices and access them using the same APIs specified to access services on the local device. The APIs specified in webinos can be classified in the following categories:
- Webinos base and generic APIs
- APIs for service discovery and remote access
- APIs for access hardware resources (e.g. sensor API)
- APIs for read/write application data (e.g. contact API)
- APIs for communication with other applications in the same or another devices
- APIs allowing webinos applications to launch other webinos and native applications
- APIs for access user profile and user context
- APIs related to webinos security and privacy model
A description of all APIs specified in webinos and referred APIs used by webinos can be found in the specifications directory
What stage are they at?
The specification of the identified webinos APIs and Webinos architecture is more or less completed. But the current API can be extended in the future to cover other domains and new device types which are not considered yet in the current version of the API specification. Regarding to the implementation, there is a prototype available for Windows, Linux and Mac. This prototype can be seen as a test and demo environment of webinos functionalities. The implementation of webinos for other platforms (Android, iOS, etc.) and other device types (desktop PCs, smartphones, tablets, cars, TVs, Set-Top-Boxes, etc.) is work in progress.
Which APIs are you working on personally and how do you see them being used?
I worked mainly with the generic sensor and actuator APIs. Regarding to the sensor API, I used the existing specification to implement new different types of (soft) sensors and demonstrated the usage of the API in a demo applications. In general, the webinos generic sensor API provides web applications with an interface to access data from sensors in the device, connected to the device or in another device. The API should be used in combination with the general webinos service discovery methods findServices() and bind() to find and address sensors from a specific type and fulfilling certain criteria. Each sensor type can be identified by a feature URI such as the Temperature Sensor API: http://webinos.org/api/sensors.temperature for identifying temperature sensors. The measured values of a sensor are specified as a set of floating-point numbers. The size of this set and the range of each value field are specific for each sensor type. For temperature sensors, the value array consists of two fields, the first one represents the measured ambient temperature in degrees Celsius and the second field represents the normalized value between 0 and 1. From the usage view of the API, webinos applications are able to access the last measured value if available or to subscribe to a specific sensor and receive asynchronous updates in periodical intervals.
Back to the actuator API, my work was here at the specification level. Before starting with the technical specification, it is important to study the different kinds of actuators and to identify common features between all actuator types. The technical specification of each API module in webinos is defined in one Web IDL file. The Web Interface Description Language Web IDL can be used to describe interfaces that are intended to be implemented in web browsers. The specification of the generic actuator API can be seen as a complement specification of the sensor API. In contrast to the sensor API, the actuator API provides an interface for changing the value of each input pin of the actuator. Therefore, the actuator input values are specified as a set of floating-point numbers for each pin. Furthermore, the actuator API specifies the range of each input value as an interval or as a set of valid values. Similar to the sensor API, the type of an actuator can be identified by a feature URI such as The Thermostat API: http://webinos.org/api/actuators.thermostat for thermostat actuators. This actuator type consists of only one input pin which represents the desired set point temperature in degree Celsius. The min and max valid temperature values can be defined as a range interval such as [10°C, 27°C]. Switch is another type of actuators defined in webinos and can be identified by the feature URI: http://webinos.org/api/actuators.switch. Switch actuators consist also of one input pin which represents the state of the actuator ON or OFF. Therefore the range of switch actuators is one of the values {0, 1} where 0 represents the OFF state and 1 the ON state.
Which comparable APIs are in the same domain (from other companies)?
Based on webinos requirements, use cases and architecture needed APIs are identified. Potential existing APIs from W3C, WAC and elsewhere are investigated and analyzed. If no existing APIs that could fulfill the webinos requirement is found, high level requirements on a new API to be specified within webinos are stated. Let us take the sensor API as an example: there is currently a set of APIs tailored for specific sensor data. Examples are the W3C Geo location API, the W3C DeviceOrientation Event (accelerometer etc.) and the W3C HTML Media Capture API (camera, microphone). However, there is also a need for a generic and extensible API to get access to sensors. This is important as new types of sensors are frequently introduced. A candidate API was here the W3C system information API which is a high-level API to system information and sensors. A disadvantage of this API is that for each additional sensor a new property has to be defined. Furthermore, only one single value for each sensor property is supported. That is why a new sensor API is specified in webinos.
For developers reading this, what’s cool about the webinos APIs? Why should they use them?
From my point of view, I think there are several reasons why application developers should use webinos APIs. First of all, webinos provides a standard interface for service discovery and access of resources on local and remote devices in the same way. Furthermore, webinos specifies APIs not only to access functionality for a specific domain or platform but provides a wide range of platform-independent APIs to access functionality on different devices in different domains such as the webinos TV API for TV control/management and the vehicle API which provides access to specific vehicle data. Using webinos APIs, developers are able to access functionality on different devices in the same application. Furthermore, webinos provides a common interface for event handling by means of exchange data in terms of events among addressable entities (e.g., applications, services), either locally or remotely. By using this API, it is easier for developers to distribute their applications on different devices where each application component can interact with other components using application specific events. For all device APIs introduced in webinos there is a common policy management component to control the access to certain resources against a defined set of rules which can be evaluated taking into account context information to obtain a more flexible control system.
