Thursday, March 15, 2012

Resource Classification for DSOA

Since 2010, we, Bruno and Marcelo, were determined to work with Ubiquitous Computing. Then we looked for professor Carla D. Castanho, who introduced us to Fabricio Buzeto, current project leader of Unbiquitous research group. After a few meetings, we agreed to develop a resource classification for DSOA architecture.


Bruno Pessanha Marcelo Valença

Firstly let us introduce ourselves. We both are undergraduate students of Computer Science here at Universidade de Brasilia. I, Bruno Pessanha de Carvalho, currently work as a Systems Analyst at Oak Soluções, focused on software-based enterprise solutions and used to work as a Software Developer at Autotrac, focused on embedded software development. My partner Marcelo Valença de Almeida used to work as a Software Developer at Autotrac and Sea Tecnologia focused on mobile development and web development, respectively.

The problem that our research group was facing was that without the classification it was hard for the developer to find resources at the environment. For example, imagine that the user needs a nice and big screen to project his graduation presentation that it’s stored at his cellphone and there are three resources available: Wide40InchesScreen, Nice27InchesScreen and Small14InchesScreen. So, if the developer would like to find that three kinds of screen at the environment, he should search for that three unrelated identifiers. The development of a resource classification would make that user capable of querying just a Screen and then he would receive all the options that are equivalents to that type of resource. We could specify a Screen as a root of one equivalence tree, and then extends to WideScreen and LetterBoxScreen, as shown above.

For this, we had to study how the current standards (UPnP, IEEE 1451,DLNA, USB, Bluetooth) dealt with service subtyping. After that research, we were able to set our own standards: audio, video, image, keyboard, pointer and connectivity. On this basis, it became possible to define a hierarchy of extensible interfaces, allowing the selection of equivalent resources in order to ease the search for resources, thus increasing the adaptability of services, the focus of this project.
For one or more interfaces be considered equivalent, the following criteria must be served:
  • the services must belong to the same resource;
  • the application must have at least the same services as their "father" and they must have the same identifiers;
  • they must have the same parameters.
Today the interface validation and the necessary modifications in DSOA are partially implemented and tested. Our focus now is on developing applications that serve as proof of concept to our implementation:
1 - Mouse composed of two buttons;
2 - Mouse composed of two buttons and scroll.
Thus, when some application request for resource (1), the resource (2) also maybe provided to meet the requesting application.