Recent Changes - Search:

WNaS @ UNIK

Master Thesis

Security and Mobility
UniK, Kjeller

edit SideBar

WP2 Proximity-based applications

see also:

Semesteroppgave Dec 2008: Ola Nordbryhn, "Personal Context Information Made Accessible in a Semantic Web Application" (.pdf)Δ

Description:

The WP2 will introduce innovative applications that will take advantage from the nowadays communication and home environments technologies.

These applications will introduce new models of group interaction and active applications.

Particular applications that are considered in this project are:

  • Active TV applications:
    • Local community-based applications
    • Betting, voting, real TV, TV shopping applications
  • Any new application from partners

Home environments

  • Broadband expected to reach 60 % of all households in some European Memberstates
  • Convergence of IT, Telecom and Consumer electronics
  • Multiple opportunities to enjoy applications (personal device, game console, PC, TV,...)
Suggestion: concentrate on "easy and personalised service access", example: connection to and streaming from set-top box

New models of group interation and active applications

  • Proximity is either "physically close" (to a person or a device), "intellectually close" (having the same spirit), or "currently not occupied" (like: available for communications)
    • "physically close" (to a person or a device): my EPG get's streamed to me
    • "intellectually close" (having the same spirit): My hiking friends
    • "currently not occupied" (like: available for communications): Example members of your working group (at distributed places) are in front of the coffee machine
  • Member of physical groups (soccer, kindergarden, school, interest groups)
    • need exchange of services for their groups
    • need seamless authentication to the services
  • Active applications - what is this?
Suggestion: concentrate on proximity services and one "group community", e.g. children soccer team

Reason: This listing opens for too many services. We should restrict to some 1-2 scenarios

UniK's role

  • lead the wp
  • contribute to easy pairing and device authentication
  • contribute group identity (in conjunction with Telenor's PATS lab "list functionality")

Description of the HTTP interface in WP3

This is just a brief description, as the web service is not yet 100% completed. Most of this is just cut from the document I'm writing for this fall's semester assignment which is going to conclude my work on the WellCom project. If you have any questions, feel free to contact me on email (ola.nordbryhn@gmail.com) or phone (+47 99 27 61 26).

Interface

The web service may be accessed, either via an XMPP client or directly via an HTTP call. The details of the XMPP call is described below. Messages sent through the OpenFire server that conform to the TN-Wellcom format are picked out by the plugin described previously, and posted as an HTTP request to the reasoner web service hosted on Axis2. This reasoner unwraps the request from the XMPP packet, finds out what kind of request it is and consolidates the ontology to find out how to act, if the request is well-formed it calls either the get(String userName, int parameter, String value) or the set(String userName, int parameter, String value) depending on whether the message is a get or set request. If the HTTP interface is used, the get() and set() methods may be called directly, these both output a string. For security purposes, the HTTP interface should be protected by an authentication scheme to ensure that users have right to access and modify data. The XMPP interface uses the native authentication scheme during sign-in to protect the web service against unlawful access.

On composite classes

Composite classes are classes which are not defined by a database value alone, but which has a value that depends on one or more other classes. These are made with the rdfs:definedBy: class annotations where a definition includes class name and one or two values with correct datatype for that class.

XMPP messages

The construction of XMPP packets is described in RFC3920, the TN-Wellcom message format is a modification to the standard Info-Query (IQ) packets. In short, they are formed in the following fashion: <iq to='user'><query/></iq>

The IQ tag may have more attributes, to, from, id, type, xml:lang and version to name some.

The message format used for the web service communication is a slightly modified version of this. The standard get/set/result/error types are used, but instead of a query tag, the <TN-Wellcom> tag follows directly after the iq tag. Within the TN-Wellcom tag, three parameters are specified, the user name, the universal name or parameter in the ontology of which to alter or inquire, and finally the value of the given parameter. This composition is callen an information capsule. A well formed message conforms to the following form:

<iq from='[login name]' id='[session id]' type='[message type]'>

<TN-Wellcom>[user name], [parameter], [value]</TN-Wellcom>

[Possible more capsules]

</iq>

where:

  • Login name is the user's login name with optional resource as specified by the XMPP core protocol
  • Session ID is automatically assigned by client
  • type is either get, set, result or error, as specified in the XMPP core protocol
  • User name is the user name of the user the request inquires
  • Parameter is an integer which corresponds to a universal name in the ontology and is the super key of the database schema
  • Value specifies the value of the parameter, this is an string value to be able to contain both characters, float and integer values, time values and boolean values.
  • More than one TN-Wellcom capsule may be sent within the same IQ, if they all are the same type, i.e. it is not possible to send both get and set request capsules within the same IQ message.

If the capsule is a set-type, both name, parameter and value must be specified in order for it to be a validly formed request. The databases will be updated with the new information given in this capsule. If the packet is a get-type, either name or value may be left blank, or all three values may be filled. If name is left blank, the system will return a list of User names that has the same value as in the capsule for the given parameter. If value is left blank, the value for the given User name and parameter is returned. If all three values are specified, the system will return a boolean value specifying whether or not those three values correspond to the current values in the database.

Contacts

Ola Nordbryhn, , m: 9927 6126
Josef Noll, , p: 6484 4745, m: 9083 8066
Jan Arild Audestad, mob 900 49 817

Edit - History - Print - Recent Changes - Search
Page last modified on December 18, 2008, at 05:49 AM EST