Nearchos Paspallis: My Blog

Conversion utilities in Java

2010-12-07T18:07:00.003+02:00

Since the beginning of 2010, I have been involved in AsTeRICS. This is an EU-funded project aiming to provide a software construction toolset for allowing prototyping of Assistive Technology (AT) applications. These applications should be adapted to the motor abilities of end-users.

My involvement in the project varies as a result of my main workload, which this semester includes teaching an introductory computer science course, and a postgraduate course in software engineering. Lately, a request was placed for a clear way for converting a primitive type (or string) in Java to a byte array, and back. This is required to enable a custom protocol that will allow the configuration and test module to connect remotely to the AsTeRICS middleware.

I had done something similar before, but only for integer primitive data types. After searching the web for an answer, I realized that there are some methods available but none is clear enough. I quickly realized that this functionality is "almost" built-in Java via the java.nio.ByteBuffer class. This class allows for converting primitive types such as short, int, and long to byte arrays. Scalar data types such as float and double can also be converted to byte arrays through an intermediate conversion to int and long respectively.

The resulting code is posted here, and is available for download as a Java class named ConversionUtils.

import java.nio.ByteBuffer;

public class ConversionUtils
{
    public static final byte FALSE_BITS = 0x00;
    public static final byte TRUE_BITS = 0x01;

    static public boolean booleanFromByte(final byte bits)
    {
        return bits != FALSE_BITS;
    }

    static public byte booleanToByte(final boolean b)
    {
        return b ? TRUE_BITS : FALSE_BITS;
    }

    static public short shortFromBytes(final byte [] bytes)
    {
        return ByteBuffer.wrap(bytes).getShort();
    }

    static public byte [] shortToBytes(final short s)
    {
        return new byte [] {
                (byte)(s >>> 8),
                (byte) s};
    }

    static public int intFromBytes(final byte [] bytes)
    {
        return ByteBuffer.wrap(bytes).getInt();
    }

    static public byte [] intToBytes(final int i)
    {
        return new byte [] {
                (byte)(i >>> 24),
                (byte)(i >>> 16),
                (byte)(i >>> 8),
                (byte) i};
    }

    static public long longFromBytes(final byte [] bytes)
    {
        return ByteBuffer.wrap(bytes).getLong();
    }

    static public byte [] longToBytes(final long l)
    {
        return new byte [] {
                (byte)(l >>> 56),
                (byte)(l >>> 48),
                (byte)(l >>> 40),
                (byte)(l >>> 32),
                (byte)(l >>> 24),
                (byte)(l >>> 16),
                (byte)(l >>> 8),
                (byte) l};
    }

    static public float floatFromBytes(byte [] bytes)
    {
        final int bits = intFromBytes(bytes);
        return Float.intBitsToFloat(bits);
    }

    static public byte [] floatToBytes(final float f)
    {
        int i = Float.floatToRawIntBits(f);
        return intToBytes(i);
    }

    static public byte [] doubleToBytes(final double d)
    {
        long l = Double.doubleToRawLongBits(d);
        return longToBytes(l);
    }

    static public double doubleFromBytes(byte [] bytes)
    {
        final long bits = longFromBytes(bytes);
        return Double.longBitsToDouble(bits);
    }

    static public byte [] stringToBytes(final String s)
    {
        return s.getBytes();
    }

    static public String stringFromBytes(byte [] bytes)
    {
  return new String(bytes);
    }
}

The above code can be tested using the following:

import java.nio.ByteBuffer;

public static String toString(final byte [] bits)
    {
        final StringBuffer stringBuffer = new StringBuffer(bits.length * 8);
        for(final byte b : bits)
        {
            stringBuffer.append(toString(b));
        }
        return stringBuffer.toString();
    }

    public static String toString(final byte bits)
    {
        final int displayMask = 1 << 7;
        final StringBuffer buf = new StringBuffer(8);

        byte value = bits;
        for(int c = 1; c <= 8; c++)
        {
            buf.append((value & displayMask) == 0 ? '0' : '1' );
            value <<= 1;
        }

        return buf.toString();
    }

    public static void main(String[] args)
    {
        {
            System.out.println("----------------------------------------");
            final boolean b_f = false;
            System.out.println("boolean false: " + b_f);
            final byte bits = booleanToByte(b_f);
            System.out.println("bits: " + toString(bits));
            final boolean new_b = booleanFromByte(bits);
            System.out.println("new boolean: " + new_b);
        }

        {
            System.out.println("----------------------------------------");
            final boolean b_t = true;
            System.out.println("boolean true: " + b_t);
            final byte bits = booleanToByte(b_t);
            System.out.println("bits: " + toString(bits));
            final boolean new_b = booleanFromByte(bits);
            System.out.println("new boolean: " + new_b);
        }

        {
            System.out.println("----------------------------------------");
            final short s = 123;
            System.out.println("short: " + s);
            final byte [] bytes = shortToBytes(s);
            System.out.println("byte array: " + toString(bytes));
            final short new_s = shortFromBytes(bytes);
            System.out.println("new short: " + new_s);
        }

        {
            System.out.println("----------------------------------------");
            final int i = 12345;
            System.out.println("int: " + i);
            final byte [] bytes = intToBytes(i);
            System.out.println("byte array: " + toString(bytes));
            final int new_i = intFromBytes(bytes);
            System.out.println("new int: " + new_i);
        }

        {
            System.out.println("----------------------------------------");
            final long l = 123456789012345L;
            System.out.println("long: " + l);
            final byte [] bytes = longToBytes(l);
            System.out.println("byte array: " + toString(bytes));
            final long new_l = longFromBytes(bytes);
            System.out.println("new long: " + new_l);
        }

        {
            System.out.println("----------------------------------------");
            final float f = 12345.6789e-2f;
            System.out.println("float: " + f);
            final byte [] bytes = floatToBytes(f);
            System.out.println("byte array: " + toString(bytes));
            final float new_f = floatFromBytes(bytes);
            System.out.println("new float: " + new_f);
        }

        {
            System.out.println("----------------------------------------");
            final double d = 123456789.0123456789e-7;
            System.out.println("double: " + d);
            final byte [] bytes = doubleToBytes(d);
            System.out.println("byte array: " + toString(bytes));
            final double new_d = doubleFromBytes(bytes);
            System.out.println("new double: " + new_d);
        }

        {
            System.out.println("----------------------------------------");
            final String s = "Hello World!";
            System.out.println("string: " + s);
            final byte [] bytes = stringToBytes(s);
            System.out.println("byte array: " + toString(bytes));
            final String new_s = stringFromBytes(bytes);
            System.out.println("new string: " + new_s);
        }
    }

Making "MUSIC"

2010-05-19T10:51:00.001+03:00

The Self-adapting applications for mobile users in ubiquitous Computing Environments (MUSIC) project I have been working on for the last 3.5 years is coming to an end (at least its EU-funded period). CORDIS has posted a nice review of the project, that I attach below. I am particularly proud to see a link to the context plug-ins repository which I prepared :-)

The project webpage is: http://ist-music.berlios.de/site.

I copy from ICT Results page (http://cordis.europa.eu/ictresults):

Adaptive software – a late bloomer

Adaptive software is the largely unfulfilled promise of mobile technology, but now a new platform developed by European researchers promises to finally deliver software that reconfigures itself depending on the context.
Adaptive software – software that can configure itself automatically to deliver the maximum functionality for a given context – is finally coming. One of the long-promised fruits of the mobile technology tree, adaptation has proven a late bloomer, in large part due to the number of extremely tough problems that dog the idea.

For starters, there are thousands of different potential devices, from mobile phones to media players to computers. Added to that are the even vaster number of applications.

“The MUSIC project wanted to create a platform for adaptive applications that could work on any device and with any software,” explains Geir Horn, researcher with SINTEF in Norway and coordinator of the project. “[It’s] because people often want software to work differently in different contexts.”

Faulty defaults

For example, most emailing software downloads each email with all attachments in the order they were received. On a slow internet connection, it can mean waiting an hour or more to retrieve all the emails a user has received, and the connection could even drop out before the important last mail has been downloaded.

But email clients have a ‘slow connection’ setting that lets users download just the basic information: the subject, the sender and the size of the file, and it can be very useful when roaming data feeds or when the bandwidth is limited.

And it is not just download options that can be optimised for particular contexts. Encryption, too, can be usefully adjusted for office use or when on the move, with simple or even no encryption for the office, but extremely strong encryption outside the office.

Functions like these are typically buried behind obscure menu items and several dialogue boxes, and there are literally hundreds of possible options for all the different software on one device, and even more options for other devices. Users would quickly become overwhelmed if they have to change settings manually.

“Of course, the email software developers could write their software so that it adapts when the internet connection is slow, or when the user is moving, or when the user is in a particular location, but there are possibly hundreds of different situations that they would need to think of, and it quickly gets prohibitively expensive,” stresses Horn. “And that is just for one application.”

MUSIC handles all these issues. It takes account of a user’s location, whether it is at home, the office, in a car or on public transport. It notes the device in use, whether a mobile phone, netbook or desktop, and it is aware of dozens of other variables, from the strength of the internet connection to the time of day, from light levels to the condition of the battery.

Good guesses

By combining all this information, the MUSIC middleware can make a very good guess of the users’ context, what the user will want to do at a particular time, in a specific location with a given device.

The MUSIC platform does not need to be configured by the user, it derives its possible settings from the high-level behaviour descriptions that are part of most software developed today. High-level behaviours describe functions such as displaying SMS messages via text or using audio.

These descriptions tell the MUSIC software what settings can be altered, and MUSIC then simply uses the most appropriate settings for a given context. In the SMS example, it would render the message in text when the user is in a restaurant, but render it in audio when he or she is in a car.

“The biggest challenge that the MUSIC consortium faced was trying to create software that would install on any device, whether it is a mobile phone, PDA, netbook or server,” Horn relates. “In the end, we decided to use Java, which we thought was the most appropriate cross-platform development language.”

The developers also used a plugin paradigm so the software can be extended in useful ways. For example, any software can take advantage of MUSIC functionality simply by developing a plugin for the platform. Similarly, the platform can expand its functionality via plugins too.

So while the base MUSIC configuration may take account of location via GPS and time via the device clock, plugins could expand the base configuration to take advantage of other sensors, such as a compass, accelerometer or light meter.

Mission accomplished

The MUSIC project achieved all its design goals and has created a robust prototype platform. The software is designated open source and is freely available. There is a fledgling development community coalescing around the platform and, while there is no formal commercialisation plan as such, it is very likely that MUSIC will slowly, almost surreptitiously, become part of the mobile landscape.

That is because the platform is tiny, just a few hundred kilobytes in its base configuration. “So if a company wants to offer services that depend on MUSIC, they can just bundle the software with the service,” Horn remarks.

He offers the example of a tourist office in, say, Turin. The tourism office can develop a package that will show users specific information at a precise location – say the history of a famous church – when the user is standing there.When the user subscribes to the service, the software can be downloaded to their phone directly. That makes the MUSIC functionality available to any other MUSIC-enabled software on the user’s phone.

By degrees and utility, then, MUSIC has a very strong chance of becoming a very common platform and then, finally, mobile technology will evolve to become truly ‘adaptive’.

The MUSIC project received funding from the ICT strand of the EU’s Sixth Framework Programme for research.

Check out the plugins repository on the MUSIC website.

Geosensing for your Windows 7

2010-03-04T10:15:00.000+02:00

If you enjoy your Windows 7 and you would like to add some geosensing capabilities (especially if you travel a lot), I suggest you read this article from lifehacker: How to Add Location Awareness to Your Windows 7 PC.

If you do choose to install the Geosense for Windows software, please make sure that you carefully read the installation guidelines (including the terms of use). You will be surprisingly amused :-)

Android LiveBlog

2010-01-05T20:22:00.000+02:00

I am following my first LiveBlog: Google Nexus One event on http://live.gizmodo.com/. Extremely entertaining and fun (even before the "actual event" had started). I am looking forward to more LiveBlogs in the future.

Capitalism meets Socialism

2009-12-17T14:57:00.003+02:00

Translating the sign on the window (from Greek): "Cooperative Bank for Banker Employees of Cyprus".

IntelliJ IDEA goes open-source

2009-10-16T08:15:00.003+03:00

As a long time Java fan and Java developer, I was excited to read this blog announcement this morning. IntelliJ IDEA goes open-source with its IntelliJ IDEA Community Edition.

I started using IntelliJ IDEA while at my first real job, Eternal Systems, Inc., back in 2002. At the time, IDEA was superb and much better than any other Java IDE (probably than any IDE). I have just started playing with the community edition (version 9.0-beta) and it seems that JetBrains has kept up the good work. If you are a Java developer, I highly recommend you test out this IDE. Have a look at this video for a quick glimpse.

While individuals will certainly benefit from this release, I think JetBrains will too. In particular, I believe that programming teachers will pick up this IDE as a recommended tool for their students who make their first steps in programming. With its constant and real-time code inspections, IDEA will be a great educational resource and students will not forget it after they graduate.

Time for Android!

2009-10-11T17:40:00.008+03:00

One of my main resolutions for after I would get done with my PhD thesis was to get deeper into the details of the architecture and the underlying mechanisms of Android. Now that my defense was completed successfully (with only a few minor improvements pending), I am ready for what I believe will be an exciting journey.

As a researcher in software engineering for context-aware systems, Android seems to be a unique opportunity. Here is what I believe makes the Android platform stand out from the rest of the mobile platforms:

It is open. This is a huge difference from its main competition, particularly the iPhone. While the latter is an excellent platform, and probably the state-of-the-art in the current arena of smart-phone hardware, its future is a bit uncertain. As a closed platform, the iPhone might face great challenges in attracting developers and end-users when other platforms (like the Android) catch-up with it.
Its architecture is well thought. With a layered structure that facilitates platform independence (i.e., the Linux kernel), powerful common libraries (e.g., realizing accelerated graphics and security protocols) and a runtime layer that allows development in Java (one of the most successful and widely mastered programming languages). With this, building for Android is a breeze and fun process!
It features reusable and replaceable components. This means that anyone can develop applications that feature web-browser and map views (among others) without having to develop them. It also means that any developer is free to enter an open market and compete with others (including Google itself) on providing the best core applications, like a phone manager or contacts manager.
It features an open market. While all registered applications must qualify a set of rules in order to be listed, these are much more relaxed and open in comparison to iPhone's market-place, which prohibits listing applications that compete with those from Apple.
It provides good developer tools. The Android SDK is of free to download and use (as expected), while the developers can also benefit from a great deal of online resources.
It is Google-backed. As the search giant is the core promoter in the Open Handset Alliance, the Android users can feel safe that the web-apps they are so accustomed to (like GMail, GCalendar, etc) will always be supported on their devices. Furthermore, building on their great legacy with organizing the world's information, the Android users can expect more innovative applications and functionality in their phones, assisting them to organize their own, mobile world.

I recommend the following three tutorials for anyone who needs to get a quick (but very intuitive) look into Android:

Part 1 of 3 - Architecture Overview

Part 2 of 3 - Application lifecycle

Part 3 of 3 - APIs

Update October 13, 2009: Just read this interesting post on Slashdot.

CSI Cyprus

2009-09-08T12:07:00.004+03:00

Crime Scene Investigation (CSI) is a quite popular TV series dealing with crimes (of course) and their forensic investigation. The series is quite popular and older seasons of the franchise are broadcasted (and assumingly are popular) in Cyprus too.

Interestingly, Cyprus also serves a central role in the drama's script in episode 25 of the latest season (season 6) in CSI: New York. If you cannot wait for season 6 episode 25 to be released, then try downloading the teaser video from iTunes. You will be amused!

This reminds me of another great moment from the US pop-cult industry. In season 16 of the Simpsons, Homer shouts to a Turk captain: "... you Cyprus-splitting jerks!". I was very proud to share that in my Greek blog back then.

Speaking of Homer, I also watched the teaser for season 21 (!) of the Simpsons (also available in iTunes for free), and it seems that these guys will never run out of ideas! His Odyssey will run a really long time!

Developing a complete context-aware application (CaMP) - Tutorial 10

2009-02-12T09:47:00.021+02:00

This tutorial continues the series started a few weeks back, with a comprehensive example: developing the Context-aware Media Player (CaMP). Here, we describe and apply a development methodology, which details the steps required to design and implement a context-aware application using the MUSIC middleware.

Development methodology

The following steps describe a structured method for designing and implementing context-aware applications using the MUSIC Context System. It is recommended that before you try to follow this methodology, you study the Tutorials on the MUSIC Context System here.

The methodology consists of the following 6 steps:

Identify the relevant context types; in case some context types are higher-level, identify other elementary context types to build on them
For each elementary context type identify a “context sensor” plug-in and for each high-level context type identify a “context reasoner”
For each context plug-in, reuse an existing implementation or proceed to construct a new one
Develop the functional aspects of your application
Register your application to the relevant context types and implement the code that adapts the application accordingly
Pack your application in JAR file as per OSGi's bundle packaging specification

Furthermore, step 3 is also analyzed into the following sub-steps:

Implement (or reuse) the corresponding context model
Define the MANIFEST and XML descriptor of the “context plug-in”
2.1. Define the standard properties like you would do for an OSGi component
2.2. Define the “provided” context types
2.3. Define the “required” context types [optional step for context reasoners]

Extend the abstract context sensor or context reasoner
Implement the “activate” and “deactivate” methods to start and stop the generation of context events respectively
Implement the “contextChanged” method to handle received context events [optional step for context reasoners]
Pack everything in a JAR file, as per the OSGi’s bundle packaging specification

Applying the development methodology to the Context-aware Media Player (CaMP)

The Context-aware Media Player is a simple application, which is defined as follows:

"CaMP is a simple media player, capable of playing audio or video media tracks, while exhibiting the following context-aware behavior:

When the user is detected as entering the room (where CaMP is deployed), then resume playback
When the user is detected as exiting the room, then pause playback"

We are going to develop an application that exhibits this kind of context-aware behavior using the proposed development methodology.

Step 1: Identify the relevant context types; in case some context types are higher level, identify other elementary context types to build on them

The first step is to analyze the relevant context types. In this case, the task it is easy because the application's verbal description is quite straight-forward. The main context type we are interested in is "whether the user is in the room". Thus we define the User-in-the-Room context type. This is a rather high-level context type, so we need to further refine it and decide how we can derive this context type.

While multiple approaches are possible, assume the following one: a user is assumed to have entered the room when his Bluetooth smart-phone is detected while at the same time some motion is detected by the web-camera on the deployment computer. Thus, we define two additional, elementary context types: Bluetooth devices and Motion. These two are combined to infer whether the user has entered (or exited) the room where CaMP is deployed.

The hierarchy of the context types is illustarted in the following figure:

Step 2: For each elementary context type identify a “context sensor” plug-in and for each high-level context type identify a “context reasoner”

The second step is to define a context plug-in for each context type. This comes naturally from the hierarchy of the context types, as illustrated in the figure above.

To detect the attached Bluetooth devices, we define a Bluetooth Sensor plug-in.
To detect motion in the room, we define the Motion Sensor plug-in
Finally, to detect whether the user has entered or exited the room, we define a context reasoner that takes input from the other two plug-ins; the User-in-the-Room Sensor plug-in

Notably, while the first two sensors have no context input (other than what is sensed from hardware, like the Bluetooth adaptor or the web-camera), the third one depends on input context types only. Thus, the first two can be constructed as context sensors and the third one as context reasoner.

Step 3: For each context plug-in, reuse an existing implementation or proceed to construct a new one

The next step is to reuse or develop a new plug-in for each one identified. As the construction of context sensors has already been covered extensively in Tutorial 8, we will here cover just the development of the User-in-the-Room context reasoner plug-in.

At this point, it should be noted that while a context plug-in is simply required to implement the IContextPlugin interface, it is usually more convenient to extend one of the helper abstract classes which provide default code for much of the required functionality. This functionality is illustrated in the following figure:

For instance, a class extending the AbstractContextPlugin can simply implement the activate() and deactivate() methods to start and stop generating events accordingly. The generated events are delegated to the context middleware via the fireContextChangedEvent() method.

On the other hand, a class extending the AbstractContextReasonerPlugin can simply implement the contextChanged() method to receive and handle context change events. The activate() and deactivate() methods are already implemented, and automatically register the context plug-in for notification of relevant context events (as defined in the XML service descriptor). (In case you need to overload the activate() and deactivate methods, make sure that you delegate the call to the super-class as well, i.e., super.activate() or super.deactivate()).

In both the cases of extending the AbstractContextPlugin and AbstractContextReasonerPlugin, the developers should define the provided (and optionally the required) context types as it is illustrated here:

<?xml version="1.0"?>

<component name="UserInTheRoom" immediate="true">

<implementation class="cy.ac.ucy.cs.osgi.context.user_in_the_room.plugin.UserInTheRoomSensor"/>

<service>
<provide interface="org.istmusic.mw.context.plugins.IContextPlugin"/>
</service>

<property name="PROVIDED_CONTEXT_TYPES" value="user-in-the-room"/>
<property name="PROVIDED_CONTEXT_TYPE_ENTITY[user-in-the-room]" value="#concepts.entities.environment|room"/>
<property name="PROVIDED_CONTEXT_TYPE_SCOPE[user-in-the-room]" value="#concepts.scopes.abstract.user_in_the_room"/>

<property name="REQUIRED_CONTEXT_TYPES" value="motion bluetooth"/>
<property name="REQUIRED_CONTEXT_TYPE_ENTITY[motion]" value="#concepts.entities.environment|room"/>
<property name="REQUIRED_CONTEXT_TYPE_SCOPE[motion]" value="#concepts.scopes.abstract.motion_detected"/>
<property name="REQUIRED_CONTEXT_TYPE_ENTITY[bluetooth]" value="#concepts.entities.device|this"/>
<property name="REQUIRED_CONTEXT_TYPE_SCOPE[bluetooth]" value="#concepts.scopes.resources.network.bluetooth"/>

</component>

In practice, you first define some aliases for each provided (or required) context type, and then you define the entity and the scope for each one of those accordingly.

Developing the User-in-the-Room Context Reasoner Plug-in

To develop the User-in-the-Room context reasoner plug-in, we also follow the steps defined in the methodology.

Step 3.1: Implement (or reuse) the corresponding context model

In this step, we need to define the model for the User-in-the-Room context type. As such, we first identify the required context values. In this case, we can simply abstract this type of information with a simple boolean. Following a process like the one described in Tutorial 7, we conclude to a model as illustrated in the following figure.

Step 3.2: Define the MANIFEST and XML descriptor of the Context Plug-in

The MANIFEST for the context reasoner plug-in is defined just like it is defined for any other OSGi component. In our case, the resulting file is illustrated in the following:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: User-in-the-room sensor context plugin
Bundle-SymbolicName: UserInTheRoomSensor
Bundle-Version: 1.0.0
Bundle-ClassPath: .
Import-Package: org.istmusic.mw.context.plugins,
org.istmusic.mw.context.events,
org.istmusic.mw.context.util.scheduler,
org.istmusic.mw.context.model.api,
org.istmusic.mw.context.model.impl,
org.istmusic.mw.context.model.impl.values,
org.istmusic.mw.context.ontologies,
cy.ac.ucy.cs.osgi.context.bluetooth.model,
cy.ac.ucy.cs.osgi.context.motion.model,
javax.swing
Export-Package: cy.ac.ucy.cs.osgi.context.user_in_the_room.model
Service-Component: OSGI-INF/UserInTheRoomSensor.xml

Next, the service descriptor is defined. As it was discuess in the previous paragraphs, this step requires that the provided and required context types are explicitly defined. In the case of the User-in-the-Room plug-in, the service descriptor was already illustrated in the previous paragraphs.

Step 3.3: Extend the abstract context sensor or context reasoner

As the User-in-the-Room has been identified as a context reasoner, we extend the AbstractContextReasonerPlugin class. The code of the UserInTheRoomSensor class is illustrated in the following:

package cy.ac.ucy.cs.osgi.context.user_in_the_room.plugin;

import org.istmusic.mw.context.plugins.AbstractContextReasonerPlugin;
import org.istmusic.mw.context.events.ContextChangedEvent;
import org.istmusic.mw.context.model.api.IContextElement;
import cy.ac.ucy.cs.osgi.context.motion.model.MotionContextElement;
import cy.ac.ucy.cs.osgi.context.bluetooth.model.BluetoothContextElement;
import cy.ac.ucy.cs.osgi.context.user_in_the_room.model.UserInTheRoomContextElement;

public class UserInTheRoomSensor extends AbstractContextReasonerPlugin
{
public static final String PLUGIN_ID = "User-in-the-room Sensor";

public static final double THRESHOLD = 0.12d;
public static final long MOTION_VALIDITY_PERIOD = 15000L; // 15 seconds

public UserInTheRoomSensor()
{
 super(PLUGIN_ID);
}

private boolean userInTheRoom = false;
private boolean userBluetoothDeviceAttached = false;

public void deactivate()
{
 userInTheRoom = false;
 userBluetoothDeviceAttached = false;
 super.deactivate();
}

private long lastMotionTimestamp = 0L;

public void contextChanged(ContextChangedEvent event)
{
 IContextElement [] contextElements = event.getContextDataset().getContextElements();

 for(int i = 0; i < contextElements.length; i++)
 {
     final IContextElement contextElement = contextElements[i];
     if(contextElement instanceof MotionContextElement)
     {
         lastMotionTimestamp = System.currentTimeMillis();
     }
     else if (contextElement instanceof BluetoothContextElement)
     {
         BluetoothContextElement bluetoothContextElement = (BluetoothContextElement) contextElement;
         userBluetoothDeviceAttached = bluetoothContextElement.contains(UserInTheRoomVisualComponent.DEFAULT_USER_DEVICE_ID);
     }
     // else ignore
 }

 final boolean motionDetectedRecently = lastMotionTimestamp + MOTION_VALIDITY_PERIOD > System.currentTimeMillis();
 if(motionDetectedRecently && userBluetoothDeviceAttached)
 {
     if(!userInTheRoom)
     {
         userInTheRoom = true;
         UserInTheRoomContextElement userInTheRoomContextElement = new UserInTheRoomContextElement(PLUGIN_ID, userInTheRoom);
         fireContextChangedEvent(this, userInTheRoomContextElement);
     }
 }
 else if(!userBluetoothDeviceAttached)
 {
     if(userInTheRoom)
     {
         userInTheRoom = false;
         UserInTheRoomContextElement userInTheRoomContextElement = new UserInTheRoomContextElement(PLUGIN_ID, userInTheRoom);
         fireContextChangedEvent(this, userInTheRoomContextElement);
     }
 }
}
}

The most interesting part of this class is the implementation of the contextChanged() method. More details about this code is provided in the following paragraphs.

Step 3.4: Implement the "activate" and "deactivate" methods to start and stop the generation of context events respectively

In this case, the two methods (activate and deactivate) are not very significant because the context plug-in is triggered by input context events arriving at the contextChanged() method (rather than timed events from a scheduler, like those defined Tutorial 8 for example).

The only noteworthy observation is that the deactivate() method is over-ridden (to initialize some local variables) but the delegation is forwarded to the super class anyway. This is important, as it was discussed already, because it allows for the automatic registration and unregistration with the context middleware.

Step 3.5: Implement the "contextChanged" method to handle received context events [optional step for context reasoners]

As it was already argued, the most interesting part of this class is in the contextChanged() method. In here, received events are analyzed to infer whether the detected motion and the Bluetooth's presence (or absense) should trigger an event. Once it is decided that an event needs to be triggered, the fireContextChangedEvent helper method is invoked.

Step 3.6: Pack everything in a JAR file, as per the OSGi’s bundle packaging specification

This is a mandatory step for every OSGi component. The process to package the plug-in has been described in detail in the previous tutorials.

This concludes the development of the User-in-the-Room context reasoner plug-in. It is assumed that the other two plug-ins are already implemented, and we resume with the development of the CaMP application.

Step 4: Develop the functional aspects of your application

This step has no significant details. Just like in usual software development, we try to reuse existing libraries as much as possible. For example, in the case of the CaMP application, we reuse the Java Media Framework (JMF) [1] libraries by SUN in order to avoid having to develop complex media handling code ourselves.

What is important to notice however, is that with this approach it is possible to build your application with Separation of Concerns [2]. At first, you develop the functional aspect of your application (the media playback code and the GUI in this case) and then you hook-up the context-aware behavior (see next step).

Step 5: Register your application to the relevant context types and implement the code that adapts the application accordingly

To bind a client to the context middleware, one need to follow these steps:

Define your client as an OSGi component
Define a service descriptor with a reference to the “IContextAccess” service
Implement the “IContextListener” interface and define the code that will handle the asynchronous context notifications
Pack everything in a JAR file, as per the OSGi’s bundle packaging specification

The first step is straight-forward. As the context middleware offers its services over OSGi, the clients must also be defined and deployed as OSGi components.

To enable automatic context access (using Declarative Services), the developer needs to define a reference to the IContextAccess service in the service descriptor. For example, consider the service descriptor of the CaMP application:

<?xml version="1.0"?>

<component name="CaMP">

 <implementation class="cy.ac.ucy.cs.camp.CaMP"/>

 <reference name="context_access"
         interface="org.istmusic.mw.context.IContextAccess"
         bind="setContextAccess"
         unbind="unsetContextAccess"
         cardinality="0..1"
         policy="dynamic"/>

</component>

As it is illustrated in this descriptor, the IContextAccess service is referenced and appropriate binding methods are defined. The service descriptor is of course referenced by a Manifest file, as illustrated in the following figure:

Finally, the actual code where the binding to the context middleware and the handling of the context events takes place is illustrated here in the following:

package cy.ac.ucy.cs.camp;

import org.osgi.service.component.ComponentContext;
import org.istmusic.mw.context.IContextAccess;
import org.istmusic.mw.context.plugins.IContextPlugin;
import org.istmusic.mw.context.exceptions.ContextException;
import org.istmusic.mw.context.events.IContextListener;
import org.istmusic.mw.context.events.ContextChangedEvent;
import org.istmusic.mw.context.ontologies.DefaultMusicOntologyV0_1;
import org.istmusic.mw.context.model.api.IEntity;
import org.istmusic.mw.context.model.api.IScope;
import org.istmusic.mw.context.model.api.IContextElement;
import org.istmusic.mw.context.model.api.IValue;
import org.istmusic.mw.context.model.impl.values.BooleanValue;

import javax.swing.*;
import java.util.logging.Logger;
import java.awt.*;

public class CaMP extends JFrame implements IContextListener
{
public static final String DISCONNECTED = "CaMP - Disconnected from the context middleware";
public static final String CONNECTED = "CaMP - Connected to the context middleware";

public static final IEntity ENTITY = DefaultMusicOntologyV0_1.ENTITY_ENVIRONMENT_ROOM;
public static final IScope SCOPE = DefaultMusicOntologyV0_1.SCOPE_ABSTRACT_USER_IN_THE_ROOM;

private final Logger logger = Logger.getLogger(CaMP.class.getCanonicalName());

private final MediaPlayer mediaPlayer;
private final UnderTheHoodPanel underTheHoodPanel;
private final AboutPanel aboutPanel;

public CaMP()
{
    super("CaMP");

    setLayout(new BorderLayout());
    final JTabbedPane tabbedPane = new JTabbedPane();
    add(tabbedPane, BorderLayout.CENTER);

    mediaPlayer = new MediaPlayer();
    tabbedPane.add("Media player", mediaPlayer.getVisualComponent());

    underTheHoodPanel = new UnderTheHoodPanel();
    tabbedPane.add("Under the hood", new JScrollPane(underTheHoodPanel));

    aboutPanel = new AboutPanel();
    tabbedPane.add("About", aboutPanel);

    pack();
    tabbedPane.updateUI();
    setSize(400, 300);
    setVisible(false);
}

protected void activate(ComponentContext componentContext)
{
    logger.info("CaMP: activate");

    setVisible(true);
}

protected void deactivate(ComponentContext componentContext)
{
    logger.info("CaMP: deactivate");

    // make sure the media player is stopped
    mediaPlayer.stop();

    setVisible(false);
}

public void setContextAccess(IContextAccess contextAccess)
{
    logger.info("CaMP: setContextAccess");

    try
    {
        contextAccess.addContextListener(ENTITY, SCOPE, this);

        setTitle(CONNECTED);
    }
    catch (ContextException ce)
    {
        logger.severe(ce.getMessage());
    }
}

public void unsetContextAccess(IContextAccess contextAccess)
{
    logger.info("CaMP: unsetContextAccess");

    try
    {
        contextAccess.removeContextListener(ENTITY, SCOPE, this);

        setTitle(DISCONNECTED);
    }
    catch (ContextException ce)
    {
        logger.severe(ce.getMessage());
    }
}

public void contextChanged(ContextChangedEvent event)
{
    final IContextElement[] contextElements = event.getContextDataset().getContextElements();
    for(int i = 0; i < contextElements.length; i++)
    {
        final IContextElement contextElement = contextElements[i];
        IValue value = contextElement.getContextData().getContextValue(
                DefaultMusicOntologyV0_1.SCOPE_ABSTRACT_USER_IN_THE_ROOM).getValue();
        BooleanValue booleanValue = (BooleanValue) value;
        if(booleanValue.getBooleanValue().booleanValue())
        {
                mediaPlayer.start();
         }
        else
        {
                mediaPlayer.stop();
         }
    }
}
}

Just like in the context reasoner plug-ins, the most interesting part here is the implementation of the contextChanged method, defined in the IContextListener interface.

The actual context-aware logic is very simple: The received events are analyzed and when an event corresponds to the user entering the room, then the media playback is resumed. Otherwise, if the received event corresponds to the user exiting the room, then the media playback is paused.

Step 6: Pack your application in JAR file as per OSGi's bundle packaging specification

Of course, once the code and the artifacts are finalized, they are all compiled and packaged together in a JAR file, according to the OSGi's packaging specification.

JARs of the used plug-ins, including the source code and an ANT build script, are available here:

CaMP.jar
BluetoothSensor.jar
MotionSensor.jar
UserInTheRoomSensor.jar
JMFBundle.jar (needed by the CaMP and the MotionSensor bundles)

Exact details about the requirements and the deployment method for CaMP are provided in this webpage. Finally, some screenshots of the CaMP application active are available here (click to enlarge):

References

[1]. SUN Microsystems, Java Media Framework (JMF), http://java.sun.com/javase/technologies/desktop/media/jmf

[2]. Nearchos Paspallis, Frank Eliassen, Svein Hallsteinsen, and George A. Papadopoulos, Developing Self-Adaptive Mobile Applications and Services with Separation-of-Concerns, At Your Service: Service-Oriented Computing from an EU Perspective, E. Di Nitto, A-M. Sassen, O. Traverso and A. Zwegers (eds), MIT Press, June 2009, chapter 6, pp. 129-158

Developing a context client - Tutorial 9

2009-01-30T10:33:00.000+02:00

This is the next post in the series of tutorials that introduces OSGi and the MUSIC Context System. The previous tutorial, described how to develop a context sensor plug-in, that monitors the memory use and periodically generates events containing data about the last measurements. This tutorial describes how to develop a context client that listens for changes to the memory context type.

Developing the Memory Viewer context client

As usual, a memory viewer is first a normal OSGi component bundle. We described how to create components and bind them with services in the second and the third tutorials. As such, to develop a context client we need to specify three parts:

Define its Manifest: The Manifest describes the properties of the bundle. As such it defines the imported and possibly exported packages and it also provides a pointer to the service descriptor.
Define its service descriptor XML file: In the case of a context client, the service descriptor is simply used to define the needed IContextAccess service (which it was introduced in this tutorial).
Define the code that implements the context client: The code of the context client is implemented in one or more classes. In principle, a context client implements the IContextListener interface which allows it to asynchronously access context data.

For example, the development of the memory context client results to the following parts:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Memory viewer client for the MUSIC Context System
Bundle-SymbolicName: MemoryViewer
Bundle-Version: 1.0.0
Bundle-ClassPath: .
Import-Package: org.istmusic.mw.context,
org.istmusic.mw.context.exceptions,
org.istmusic.mw.context.events,
org.istmusic.mw.context.ontologies,
org.istmusic.mw.context.model.api,
cy.ac.ucy.cs.osgi.tutorial7.memory_model
Service-Component: OSGI-INF/MemoryViewer.xml

As a typical OSGi component, its Manifest defines imported and exported packages and a pointer to the service descriptor XML file. In this case, the service descriptor is named "MemoryViewer" and is as follows:

<?xml version="1.0"?>

<component name="MemoryViewer" immediate="true">

<implementation class="cy.ac.ucy.cs.osgi.tutorial9.MemoryViewer"/>

<!-- Reference to the context access service -->
<reference name="context.access"
   interface="org.istmusic.mw.context.IContextAccess"
   cardinality="1..1"
   bind="setContextAccessService"
   unbind="unsetContextAccessService"
   policy="dynamic"/>

</component>

The most interesting part of this service descriptor is that it defines a reference to the context access service. By referring back to the details of dynamically binding (declarative) services, you can see that this definition will result to the automatic binding of this client to the IContextAccess service, which is provided by the context middleware. Furthermore, the "1..1" cardinality indicates that in order to activate the client, exactly one binding to a single provider of the context access service must be made. When bound (or unboun), a corresponding method is invoked.

Finally, we are ready to present the code of the Memory Viewer context client:

package cy.ac.ucy.cs.osgi.tutorial9;

import org.istmusic.mw.context.IContextAccess;
import org.istmusic.mw.context.exceptions.ContextException;
import org.istmusic.mw.context.events.IContextListener;
import org.istmusic.mw.context.events.ContextChangedEvent;
import org.istmusic.mw.context.ontologies.DefaultMusicOntologyV0_1;
import org.istmusic.mw.context.model.api.IEntity;
import org.istmusic.mw.context.model.api.IScope;
import org.istmusic.mw.context.model.api.IContextElement;

import java.util.logging.Logger;

import cy.ac.ucy.cs.osgi.tutorial7.memory_model.MemoryContextElement;

public class MemoryViewer implements IContextListener
{
public static final IEntity ENTITY = DefaultMusicOntologyV0_1.ENTITY_DEVICE_THIS;
public static final IScope SCOPE = DefaultMusicOntologyV0_1.SCOPE_RESOURCE_MEMORY;

private final Logger logger = Logger.getLogger(MemoryViewer.class.getCanonicalName());

public MemoryViewer()
{
    logger.info("MemoryViewer: constructed");
}

    public void contextChanged(ContextChangedEvent event)
{
    IContextElement [] contextElements = event.getContextDataset().getContextElements();
    for(int i = 0; i < contextElements.length; i++)
    {
        IContextElement contextElement = contextElements[i];

        MemoryContextElement memoryContextElement = (MemoryContextElement) contextElement;
        logger.info("ContextViewer: Received -> " + memoryContextElement);
    }
}

    public void setContextAccessService(final IContextAccess contextAccess)
{
    try
    {
        contextAccess.addContextListener(ENTITY, SCOPE, this);
    }
    catch (ContextException ce)
    {
        logger.throwing(MemoryViewer.class.getName(), "setContextAccessService", ce);
    }
}

    public void unsetContextAccessService(final IContextAccess contextAccess)
{
    try
    {
        contextAccess.removeContextListener(ENTITY, SCOPE, this);
    }
    catch (ContextException ce)
    {
        logger.throwing(MemoryViewer.class.getName(), "unsetContextAccessService", ce);
    }
}
}

The most interesting parts in this class are the handling of the binding (and unbinding) of the context access service (in bold) and the handling of the received events (also in bold). The "setContextAccess" method is used to register this context listener for notifications of events related to changes in the memory of this device. Symmetrically to it, the "unsetContextAccess" method is used to unregister from events of the same type.

At this point, we should note that the context types are defined via the Ontology, which guarantees semantic consistency. For this purpose the entity and the scope are defined by referencing to the appropriate concepts in the ontology, which correspond to the memory resource of this device.

While registered with the context access service, the memory client receives every notification which corresponds to the registered context type. These notifications are received at the "contextChanged" method (which is defined in the IContextListener interface). In the Memory Viewer client, we simply read each context element received, cast it to the MemoryContextElement type (defined in Tutorial 7) and then simply print it out on the console. A real, context-aware application would of course the received context data in a more interesting way (e.g., to adapt its behavior).

Packaging and deploying the Memory Viewer context client

Following a similar approach to when developing OSGi bundles (and context plug-ins), we package the resulting code and the artifact documents (i.e., the Manifest and the service descriptor) in a single JAR file. An example of this JAR file, including a copy of the source code and the "build.xml" ANT configuration file that was used to create it, is available here.

When deployed and started, the memory viewer produces the following output:

osgi> install file:MemoryViewer.jar
Bundle id is 10

osgi> refresh 10

osgi> ss

Framework is launched.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.2.R34x_v20080826-1230
1       ACTIVE      org.eclipse.equinox.ds_1.0.0.v20080427-0830
2       ACTIVE      org.eclipse.equinox.util_1.0.0.v20080414
3       ACTIVE      org.eclipse.osgi.services_3.1.200.v20071203
4       ACTIVE      RunnableProvider_1.0.0
5       ACTIVE      RunnableConsumer_1.0.0
6       ACTIVE      CLI_Client_1.0.0
7       ACTIVE      music-context_0.2.1.0-SNAPSHOT
8       ACTIVE      MemoryModel_1.0.0
9       ACTIVE      MemorySensor_1.0.0
10      RESOLVED    MemoryViewer_1.0.0

osgi> start 10

osgi> Jan 29, 2009 12:34:15 PM cy.ac.ucy.cs.osgi.tutorial9.MemoryViewer <init>
INFO: MemoryViewer: constructed

Jan 29, 2009 12:34:15 PM org.istmusic.mw.context.manager.ContextManager addTrigger
INFO: Adding trigger for context type: http://www.ist-music.eu/Ontology_v0_1.xml#concepts.entities.device|this/http://www.ist-music.eu/Ontology_v0_1.xml#concepts.scopes.resources.memory

Jan 29, 2009 12:34:15 PM cy.ac.ucy.cs.osgi.tutorial8.MemorySensor activate
INFO: c_activating: Memory plugin

Jan 29, 2009 12:34:16 PM cy.ac.ucy.cs.osgi.tutorial8.MemorySensor run
INFO: MemorySensor: firing event: (#concepts.entities.device|this, #concepts.scopes.resources.memory)->[availableMemory=2437856, memoryLoad=0.5291299940664558]

Jan 29, 2009 12:34:16 PM cy.ac.ucy.cs.osgi.tutorial9.MemoryViewer contextChanged
INFO: ContextViewer: Received -> (#concepts.entities.device|this, #concepts.scopes.resources.memory)->[availableMemory=2437856, memoryLoad=0.5291299940664558]

osgi> stop 10

Jan 29, 2009 12:34:29 PM cy.ac.ucy.cs.osgi.tutorial8.MemorySensor deactivate
INFO: c_deactivating: Memory plugin

osgi>

There are many interesting observations to be made here. First, when the memory viewer (bundle 10) is started, it causes a sequence of events:

First, the constructor of the memory viewer bundle is invoked.
Second, the context access service is bound, and the memory viewer registers for memory context types, as it is indicated by the info log of the context middleware (which adds a trigger for asynchronous notification).
Third, the context middleware realizes that the needed context type is offered by the installed memory context plug-in (bundle 9) and it activates it. This is indicated by memory sensor itself which logs the corresponding action.
Next, the memory context plug-in (bundle 9) starts producing (i.e., firing) context change events encoding MemoryContextElements. These are communicated to the context middleware.
Finally, the memory viewer (bundle 10) receives the corresponding events and prints out to the console the value of the received MemoryContextElement.

Actually, steps 4 and 5 will continue to be triggered automatically, repeatedly producing the corresponding output, until you stop the memory viewer (bundle 10). In particular, as long as the memory context plug-in (bundle 9) is active, it will keep generating events with the predefined interval (5 seconds in this case). As a result, the memory viewer context client will receive a copy of the event from the context middleware and will display it in the output.

Finally, when you stop the memory viewer (bundle 10), it first unregisters from the context middleware, which in result causes it to deactivate the memory context plugin, returning it to the C_RESOLVED state. More details about the extended plug-in lifecycle were discussed in the previous tutorial and are also available in [1].

Homework 9.1: Develop a context client for the location context type and name it LocationViewer. The resulting component must register for location context types when active and unregister when not. The received context events must be printed out to the console. You can use the model defined in homework 7.1 and the LocationPlugin defined in homework 8.1.

Homework 9.2: Develop a graphical context client for the weather context type and name it WeatherViewer. The resulting component must register for location context types when active and unregister when not. The received context events must be displayed in a simple Graphical User Interface (GUI). You can use the model defined in homework 7.1 and the LocationPlugin defined in homework 8.1.

Hint: Use Java's swing to develop the GUI. In that case, do not forget to include all used packages (e.g., "javax.swing") into the imported packages definition of the bundle's Manifest. Also make the component visible when it is started and invisible when it is stopped, by implementing the "activate(ComponentContext)" and "deactivate(ComponentContext)" methods, as described in Tutorial 5.

[1]. Nearchos Paspallis, Romain Rouvoy, Paolo Barone, George A. Papadopoulos, Frank Eliassen, Alessandro Mamelli, A Pluggable and Reconfigurable Architecture for a Context-aware Enabling Middleware System, 10th International Symposium on Distributed Objects, Middleware, and Applications (DOA'08), Monterrey, Mexico, Nov 10 - 12, 2008, Springer Verlag LNCS 5331, pp. 553-570

Developing your first context sensor plug-in - Tutorial 8

2009-01-28T16:28:00.008+02:00

This tutorial builds on the foundations defined in the previous one, which described the use of the MUSIC Context Model, in order to describe the process needed to develop a Context Plug-in. These tutorials are part of a series which aims to first introduce OSGi and declarative services and then the MUSIC Context System.

What are the Context Plug-ins?

In Tutorial 6, we introduced the MUSIC Context System architecture and argued that one of its main advantages is the fact that it allows to develop context producers and context consumers independently. Furthermore, as the sources and the sinks are independent, it is possible to reuse the same plug-ins (i.e., sources) to satisfy the needs of multiple context clients (i.e., sinks).

Furthermore, as the plug-ins define their provided (and potentially required) context types in a well-defined, Ontology-backed manner, it is quite possible that the same plug-ins are reused by multiple developers for the construction of various applications and even, sometimes, across various platforms. On the other hand, again as the context clients express their needs in the same well-defined, ontology-backed manner, it is quite possible that the same clients accept context input from various plug-ins, depending on the availability (and resource consumption profile) of the latter.

Finally, this architecture has the additional benefits of allowing automatic resolution of plug-ins (only those which have no needs for context input or those of which their input is provided are resolved)
A more scientific discussion of the nature of the context plug-ins, along with a description of the intelligent resolution and activation mechanism are described in [1].

So, the answer to the question of the header, in a few words, is the following: "Context plug-ins are custom OSGi bundles which are designed to produce context data, perhaps by combining lower-level, more elementary context types or simply by wrapping hardware or OS-based sensors."

Anatomy of a Context Plug-in

As discussed already, Context Plug-ins are first and foremost OSGi bundles. Furthermore, these bundles have the special characteristic that they are discoverable via Declarative Services and they also implement the IContextPlugin interface. Most importantly, this interface specifies two custom life-cycle operations, activate and deactivate, which are automatically controlled by the middleware.

In principle a context plug-in, like all other OSGi components adhering to the Declarative Services standard, consists of the following parts:

A bundle Manifest descriptor, defining its name, the imported and exported Java packages of the bundle and finally a reference to the service descriptor XML file.
The service descriptor XML file that specifies the service provided by the plug-in (fixed to IContextPlugin) and the properties characterizing the context types provided and required by the plug-in.
The actual code implementing the Context Plug-in. In its simplest form, this code implements the IContextPlugin interface (possibly by extending one of the abstract implementations available). In practice, the code needs to respond to life-cycle commands as instructed by the middleware with the purpose of starting (and stopping) the generation of context data (encapsulated in context events).

This structure is illustrated in the following class diagram:

In this class diagram, we illustrate the three parts comprising a typical context plug-in measuring the memory use in the device. Notably, this plug-in extends an AbstractContextPlugin class provided by the core context middleware, and which automates a portion of the required functionality. The exact implementation of the memory context plugin are discussed in more detail further on.

An important detail is the extended life-cycle of the context plug-in components. In particular, while active the context plug-ins can transition among three possible states:

C_INSTALLED: In this state, the plug-in is simply installed meaning that it has not been resolved. To be resolved, a context plug-in must either have no context types required or it must require context types provided by already resolved plug-ins.
C_RESOLVED: In this state, the context plug-in has resolved its dependencies and can be started at any time. The only reason for a plug-in to be resolved but not started is when there is no current need for its provided context type, in which case the plug-ins stays inactive to avoid unnecessary resource consumption.
C_ACTIVE: This is the third and final possible state for the plug-ins, which indicates that it is resolved and active. In this state, and only in this, the plug-ins are active and generate context events.

Notably, these states are triply nested in each other: C_INSTALLED contains C_RESOLVED which itself contains C_ACTIVE. This is also illustrated in the following state diagram:

While transitioning into (or out of) the C_ACTIVE state, the activate (or deactivate) method of the corresponding plug-in is invoked. To illustrate all these concepts, we here describe the development of a memory context plug-in step-by-step.

Developing the Memory Context Plugin

Similar to developing a normal OSGi bundle component, the first two steps are to define the Manifest file and the service descriptor. In the case of the memory context plug-in, the Manifest is defined as follows:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Memory sensor plug-in for the MUSIC Context System
Bundle-SymbolicName: MemorySensor
Bundle-Version: 1.0.0
Bundle-ClassPath: .
Import-Package: org.istmusic.mw.context.plugins,
org.istmusic.mw.context.events,
org.istmusic.mw.context.model.api,
org.istmusic.mw.context.model.impl,
org.istmusic.mw.context.util.scheduler,
cy.ac.ucy.cs.osgi.tutorial7.memory_model
Service-Component: OSGI-INF/MemorySensor.xml

As you can see, this Manifest is identical to any other OSGi bundle-describing Manifest file. It does not export any packages at all, but it imports a few. Notably, the set of imported packages cannot be typically defined a priori. First, the actual sensor plugin must be coded, and then any packages, beyond the standard ones, which are needed in the code must be added to the "Import-Package" declaration. As you have probably noticed already, this sensor imports the memory_model package that was defined in the previous tutorial. The reason for this is that we will leverage that model for encoding the sensed context information. Finally, the Manifest file points to the service descriptor of the plugin (in this case the "MemorySensor.xml"), which is described in the following.

<?xml version="1.0"?>

<component name="MemorySensor" immediate="true">

<implementation class="cy.ac.ucy.cs.osgi.tutorial8.MemorySensor"/>

<service>
   <provide interface="org.istmusic.mw.context.plugins.IContextPlugin"/>
</service>

<property name="PROVIDED_CONTEXT_TYPES" value="memory"/>
<property name="PROVIDED_CONTEXT_TYPE_ENTITY[memory]" value="#concepts.entities.device|this"/>
<property name="PROVIDED_CONTEXT_TYPE_SCOPE[memory]" value="#concepts.scopes.resources.memory"/>

</component>

Again, the service descriptor is similar to those used in the development of typical OSGi components, as it was described in the second tutorial. The "implementation" element defines the absolute path of the implementing class (which must be a sub-type of IContextPlugin). By default, all context plug-ins must export the IContextPlugin service, which is achieved with the "service" XML element as shown above. In addition to these however, context plug-ins also define a number of properties. These properties describe the provided and the required context types of the plug-in. In this example, only provided types are defined but in other cases (i.e., when developing a context reasoner plug-in), required context types can also be defined.

The format of the properties is as follows:

PROVIDED_CONTEXT_TYPES: This property contains a space-separated list of names denoting what context types are provided by the plug-in. For example, a possible assignment could be "p1 p2", where the "p1" and the "p2" types are defined as provided. For each provided type defined in this property, an entity and a scope must also be defined, using the following two parameters.
PROVIDED_CONTEXT_TYPE_ENTITY[p]: This property must be defined for each context type "p" that has been specified in the provided context types property. The value of this property should be a string corresponding to the actual value of the entity. For example, in the case of the "memory" context type, the entity is the device itself (i.e., "#concepts.entities.device|this").
PROVIDED_CONTEXT_TYPE_SCOPE[p]: Similar to the entity property, thus one must be defined for each context type "p" that has been specified in the provided context types property. The value of this property should be a string corresponding to the actual value of the scope. For example, in the case of the "memory" context type, the scope is the memory resource (i.e., "#concepts.scopes.resources.memory").

It should be noted that besides these three properties, the following three are also possible:

REQUIRED_CONTEXT_TYPES: This property contains a space-separated list of names denoting what context types are required by the plug-in. For example, a possible assignment could be "r1 r2", where the "r1" and the "r2" types are defined as required ones. For each required context type defined in this property, an entity and a scope must also be defined, using the following two parameters.
REQUIRED_CONTEXT_TYPE_ENTITY[r]: This property must be defined for each context type "r" that has been specified in the required context types property. The value of this property should be a string corresponding to the actual value of the entity.
REQUIRED_CONTEXT_TYPE_SCOPE[r]: Similar to the entity property, thus one must be defined for each context type "r" that has been specified in the required context types property. The value of this property should be a string corresponding to the actual value of its scope.

Required context types are communicated to the context plug-in automatically (by the middleware), as it will be described later on.

Finally, to finish with the development of the context plug-in, we define its actual implementation in code. As mentioned already, the implementing class must be a sub-type of IContextPlugin. In this regard, the context plugin can either implement the IContextPlugin interface directly, or it can extend the AbstractContextPlugin class, as illustrated in the context plugins class diagram. The code of the plugin is listed in the following:

package cy.ac.ucy.cs.osgi.tutorial8;

import org.istmusic.mw.context.plugins.AbstractContextPlugin;
import org.istmusic.mw.context.util.scheduler.RecurringEvent;
import org.istmusic.mw.context.util.scheduler.Scheduler;
import cy.ac.ucy.cs.osgi.tutorial7.memory_model.MemoryContextElement;

import java.util.logging.Logger;

public class MemorySensor
     extends AbstractContextPlugin
      implements Runnable
{
 private final Logger logger = Logger.getLogger(MemorySensor.class.getCanonicalName());

 public static final String MEMORY_PLUGIN_ID = "Memory plugin";

 public static final long MIN_WAIT_TIME = 500L; // 0.5 sec

 public static final long INTERVAL = MemoryContextElement.MILLISECONDS_BEFORE_EXPIRY / 2;

 private final RecurringEvent recurringEvent = new RecurringEvent(this, MIN_WAIT_TIME, INTERVAL);

 private final double totalMemory;

 public MemorySensor()
 {
     super(MEMORY_PLUGIN_ID);

     logger.info("MemorySensor: constructed");
     this.totalMemory = Runtime.getRuntime().totalMemory();
 }

 private final Scheduler scheduler = Scheduler.getInstance();

 /** Automatically invoked by the context middleware when the plugin must be activated. */
    public void activate()
 {
     logger.info("c_activating: " + this);
     scheduler.scheduleEvent(recurringEvent);
 }

 /** Automatically invoked by the context middleware when the plugin must be deactivated */
    public void deactivate()
 {
     logger.info("c_deactivating: " + this);
     scheduler.removeRecurringEvent(recurringEvent);
 }

    public void run()
 {
     // acquire memory measurements
     final long availableMemory = Runtime.getRuntime().freeMemory();
     final double memoryLoad = 1d - (availableMemory / totalMemory);

     // generate memory context element
     MemoryContextElement memoryContextElement
             = new MemoryContextElement(MEMORY_PLUGIN_ID, availableMemory, memoryLoad);

     // fire context change event
     logger.info("MemorySensor: firing event: " + memoryContextElement);
     fireContextChangedEvent(this, memoryContextElement);
 }

 public String toString()
 {
     // produce a human-readable string
     return MEMORY_PLUGIN_ID;
 }
}

The first thing to note here is the fact that the class uses the "memory_mode package defined in the previous tutorial. The second important observation is that the memory sensor plugin extends the AbstractContextPlugin class. With this, we do not need to implement each and every method defined in the IContextPlugin interface, but rather simply implement the abstract methods defined in the abstract class and override any methods we need to change the functionality for. This is actually a popular idiom used extensively even in the J2SE libraries themselves (e.g., in the "javax.swing" package).

The constructor is quite straight-forward: we simply delegate the call to the super-constructor with the plug-in's ID as argument. Furthermore, in the constructor we initiate the "totalMemory" constant using a core JVM command.

The interesting part of the plug-in lies in the implementation of the activate and deactivate methods as well as to the implementation of the run method (of the "java.lang.Runnable" interface). The activate (and deactivate) method does a simple thing: it schedules (or unschedules) a recurring event. In this case, we use a custom scheduler which allows for the definition of one-time or recurring events. As shown in this example, the RecurringEvent is constructed by passing it three arguments:

A class implementing the Runnable interface: this is the code that will be invoked each time the recurring event is fired. In this case, the MemorySensor class itself is defined to implement the IContextListener interface, so the passed argument is itself (i.e., "this").
Minimum wait time: This long arithmetic value indicates the number of milliseconds the scheduler must wait before it fires an event for the first time. In this example this number is set to 500 (i.e., half a second).
Interval: The interval is also a long arithmetic value indicating the number of milliseconds which the scheduler waits before it repeats an invocation. In this example, the interval is set to 10000 (or 10 seconds) which means that the scheduler will invoke the runnable listener once every 10 seconds).

When scheduling the recurring event with the scheduler ("activate" method), in principle you register for asynchronous invocation of the run method. When you remove the recurring event, then you unregister form the asynchronous invocations. This mechanism is quite similar to using Threads, but it uses a Thread pool instead which can be quite beneficial in case you need to deal with resource constrained, mobile devices.

Finally, we examine the run method. This is where the actual context sensing takes place. In the first place, we collect our needed data. In this case we measure the available memory using the freeMemory core call of Java. Then we compute the memory load as a function of the available and total memory.

In the next step, we construct an instance of the MemoryContextElement (defined in the previous tutorial) by using the sensed data as input.

Finally, using the generated context element, we fire an event by using the overriden fireContextChangedEvent method. The only two arguments are the source (i.e., the plugin itself) and the context element.

Packaging and deploying the Memory Context Plugin

As usual, we package the code of the plug-in in a JAR file which contains the Manifest, the service descriptor XML file and the Memory Sensor class. A ready JAR file with the source code and an ANT build script is readily available here.

To deploy it, follow the steps indicated in the following screen:

osgi> install file:MemorySensor.jar
Bundle id is 9

osgi> bundle 9
file:MemorySensor.jar [9]
 Id=9, Status=ACTIVE      Data Root=C:\eclipse\configuration\org.eclipse.osgi\bundles\9\data
 Registered Services
   {org.istmusic.mw.context.plugins.IContextPlugin}={PROVIDED_CONTEXT_TYPE_SCOPE[memory]=#concepts.scopes.resources.memory, component.name=MemorySensor, PROVIDED_CONTEXT_TYPE_ENTITY[memory]=#concepts.entities.device|this, component.id=6, PROVIDED_CONTEXT_TYPES=memory, service.id=31}
 No services in use.
 No exported packages
 Imported packages
   org.istmusic.mw.context.plugins; version="0.0.0"<file:music-context-0.2.1.0-SNAPSHOT.jar [7]>
   org.istmusic.mw.context.util.scheduler; version="0.0.0"<file:music-context-0.2.1.0-SNAPSHOT.jar [7]>
   org.osgi.service.component; version="1.0.0"<file:plugins\org.eclipse.osgi.services_3.1.200.v20071203.jar [3]>
   cy.ac.ucy.cs.osgi.tutorial7.memory_model; version="0.0.0"<file:MemoryModel.jar [8]>
 No fragment bundles
 Named class space
   MemorySensor; bundle-version="1.0.0"[provided]
 No required bundles

osgi> start 9

osgi> Jan 29, 2009 10:05:45 AM cy.ac.ucy.cs.osgi.tutorial8.MemorySensor <init>
INFO: MemorySensor: constructed
Jan 29, 2009 10:05:45 AM org.istmusic.mw.context.manager.ContextManager installPlugin
INFO: CM:Installing: Memory plugin

Notably, the bundle exports (i.e., registers) the IContextPlugin service. Also, when started (i.e., when the plug-in moves in to the ACTIVE state), the middleware detects it and automatically binds to it moving it to the C_INSTALLED state (shown in the extended plugins state diagram shown above). At this point, the plug-in is not started for a simple reason: There is no context listener actively requiring the memory context type, and thus the middleware keeps the plug-in inactive albeit resolved.

Developing context reasoner plugins

Besides the AbstractContextPlugin, the developer can also extend the AbstractContextReasonerPlugin class. As shown in the context plugin class diagram, the AbstractContextReasonerPlugin class extends the AbstractContextPlugin class. In addition to the facilities provided by the latter, the former also allows for receiving and handling context events. In this regard, the corresponding plugin must implement the "contextChanged" method (inherited from the IContextListener interface), in which it should listen to events of its required context types (as defined with "REQUIRED_*" properties in the service descriptor) and react based on them. The development of a context reasoner plug-in is the object of the second homework.

Homework 8.1: Develop a context plug-in to monitor the location. The actual coordinates reported can be simulated (i.e., fixed or random). You can use the location model developed in homework 7.1 of the last tutorial. You are actually encouraged to do so.

Homework 8.2: Develop a context reasoner plug-in that will use the location context type (i.e., as generated from the plug-in of the previous homework) to produce the weather context type. The actual value will be computed as a function of the latitude as follows: "temperature = 5 + (90 - |latitude|) / 1.5". I.e., the temperature is reported as -5°C at the poles and 65°C at the equator (which is of course an exaggeration even with the most pessimistic global warming predictions). The humidity should be constantly reported as 10%. You can use the location and weather models developed in homework 7.1 of the last tutorial. You are actually encouraged to do so.

References

[1]. Nearchos Paspallis, Romain Rouvoy, Paolo Barone, George A. Papadopoulos, Frank Eliassen, Alessandro Mamelli, A Pluggable and Reconfigurable Architecture for a Context-aware Enabling Middleware System, 10th International Symposium on Distributed Objects, Middleware, and Applications (DOA'08), Monterrey, Mexico, Nov 10 - 12, 2008, Springer Verlag LNCS 5331, pp. 553-570

The MUSIC Context Model - Tutorial 7

2009-01-28T13:00:00.004+02:00

In this tutorial, we will cover the context model which supports the MUSIC Context System (introduced in the previous tutorial). For a brief view of the objective of these tutorials, check out the introductory post.

The context model is used to enable the following features:

Data encapsulation: In all programming languages, the developers use specialized data structures, like sets and maps, to implement their software. For the purposes of context-aware applications, we provide a model which is used for encapsulating context data, as it is described in [1] and [2].
Context semantics: In order to allow interoperability among individual context providers and context consumers (possibly distributed across different devices), a context model is needed to establish the semantics of each individual context element.

In our approach, the context model achieves both these goals by leveraging a three-layered approach as described in [2]. To do so, we employ technology originating from Semantic Web research in the form of Ontologies.

The MUSIC Context Ontology

The MUSIC Context System provides an Ontology-backed context dialect which can be used to facilitate interoperability between different devices. This dialect also serves as a common point of reference for developers leveraging third-party context plug-ins for their context-aware applications.

The MUSIC context dialect is based on two basic terms: Entities and Scopes. The former are used to determine which entity the context type refers to. For instance, is it a person (and who) or a device (and which). The latter are used to identify the scope of the context type. For instance, a context type might refer to the memory resource of a device. While this context dialect is not restricted in any way, we here present the most basic entities and scopes defined in it, to allow for developers to better understand its logic.

Entities

There are only three entities possible, corresponding to persons (i.e., users), devices and the environment. This is consistent with Dey's definition of context [3]: "[Context is] any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves".

#concepts.entities.user
#concepts.entities.device
#concepts.entities.environment

Furthermore, these entities can be combined with a so-called grounding, which further clarifies the entity. In the case of the user, the grounding can be either the special ID "myself", which is automatically dereferenced by the system to the ID of the user who is logged in the system. Alternatively, the grounding can be set directly to the ID of the user in reference. The ID is typically set to the email address of the user.

For example, when a user with an email address of "nearchos@cs.ucy.ac.cy" is logged in the system, then the following entity:

#concepts.entities.user|myself

is automatically dereferenced to:

#concepts.entities.user|nearchos@cs.ucy.ac.cy

The "#concepts.entities.user|myself" is the default user entity value, meaning that it is equivalent to "#concepts.entities.user".

Additional details and a description of all the groundings possible are available here.

Scopes

The scopes are the basic identifiers of context information. Once the entity to which the context information corresponds to (i.e., by defining it as described above), then the next step is to define the scope of the context information you will provide.

While there are practically unlimited possibilities on the things you can model with this approach, the default MUSIC Context Ontology defines a limited domain of scopes with the purpose of allowing reuse, interoperability and ease of development. Thus, we here describe these scopes, which can be used to describe mainly basic information about the users, the device resources and the environment.

One of the most fundamental context scopes is the location, which (as we will see in the following section) can be represented either as absolute coordinates or in the form of a physical address.

#concepts.scopes.location

This scope can be combined with any of the three possible entity types to indicate the location of either a user, a device or the interaction environment.

Additional details and a more extensive description of the available scope is also provided here.

Representations

The concept of representations is primarily aimed to facilitate Model-Driven Development (MDD) by enabling automatic transformation among many possible representations of the same data-structure. For example, a date can be represented both as a string (e.g., "2009-01-18T10:54:03+02:00") or as a long arithmetic value (e.g., "1232268843773").

As this concept is not a critical part of this series of tutorials, I skip further description and point interested readers to this web-page and to papers [1] and [2].

Context Model data-structures

In our context model, we define the following data-structures:

Context elements: These are the basic structures abstracting context information. For instance, of a developer needs to define a weather or a memory context type, then a corresponding context element is typically developed to abstract it. Each context element is associated to a structure, which contains the actual context information in terms of context values.
Context data: This data structure is simply used as a container for the actual context values. In this respect, it implements a map which points from a Scope to a Context Value. For example, if the corresponding context element is of weather type, then the contained context values can be of temperature and humidity types.
Context values: The context value data-structures are the actual containers of individual context values. For example, a temperature context type is a container of the temperature value.
Values: The value structure are elementary data structures such as strings, integers, etc. They are used as containers of context value data. For example, in the case of the temperature context value, it is associated to a float or double value type. Besides elementary context types, arrays (of elementary types) are also supported.
Metadata: The metadata are extra-functional information characterizing context elements and context values (such as for example a time-stamp indicating the time when the element or value were created). Similar to context elements, the metadata structures consist of finer-grained metadatum value containers.
Metadatum: Similar to context values, but specialized in encapsulating metadata values only. They also leverage value types for encoding the actual data.

The hierarchy of the context model is illustrated in the following class diagram:

This figure graphically illustrates the relationship among the basic concepts of the context model. Also, it depicts the three main Ontology-based concepts: Entities, Scopes and Representations. However, to avoid cluttering in the diagram we omit links denoting relationship between the structures and the Ontology concepts. Furthermore, this figure illustrates a number of elementary Value implementations (however these are not complete; for example the arrays of elementary values are not depicted).

Developing the Memory Context Model bundle

In order to illustrate the use of the context model, in the following we describe how to develop a bundle providing the model for a simple context type: memory. For this purpose, we define a memory context element, enclosing two trivial context values: available memory and memory load.

The development of the memory context model starts with detecting the appropriate entity and scope ontology concepts. In this case, the memory refers to this device (i.e., the device in which the sensor is deployed) and the corresponding scope refers to the memory resource. In this regard, the entity and the scope are defined as follows:

Entity: "#concepts.entities.device|this"
Scope: "#concepts.scopes.resources.memory"

The code of the new MemoryContextElement class is illustrated in the following:

package cy.ac.ucy.cs.osgi.tutorial7.memory_model;

import org.istmusic.mw.context.model.api.*;
import org.istmusic.mw.context.model.impl.Factory;
import org.istmusic.mw.context.ontologies.DefaultMusicOntologyV0_1;

public class MemoryContextElement implements IContextElement
{
public static final IEntity ENTITY = DefaultMusicOntologyV0_1.ENTITY_DEVICE_THIS;

public static final IScope SCOPE = DefaultMusicOntologyV0_1.SCOPE_RESOURCE_MEMORY;

public static final long MILLISECONDS_BEFORE_EXPIRY = 20000L; // 20 seconds

private final String source;

private final IMetadata metadata;

private final MemoryContextData contextData;

public MemoryContextElement(final String source, final long availableMemory, final double memoryLoad)
{
this.source = source;
this.metadata = Factory.createDefaultMetadata(MILLISECONDS_BEFORE_EXPIRY);
this.contextData = new MemoryContextData(availableMemory, memoryLoad);
}

public IEntity getEntity()
{
return ENTITY;
}

public IScope getScope()
{
return SCOPE;
}

public IRepresentation getRepresentation()
{
return null; // ignore for now
}

public String getSource()
{
return source;
}

public IContextData getContextData()
{
return contextData;
}

public IMetadata getMetadata()
{
return metadata;
}

public String toString()
{
return "(" + ENTITY.getEntityTypeAsShortString() + ", "
       + SCOPE.getScopeAsShortString() + ")->" + contextData;
}
}

The code in this example is straight-forward: The memory context element is constructed by specifying its entity and scope (as constants) and by assigning the memory context data (see the following paragraph on the MemoryContextData) and the metadata (as a default implementation abstracting the creation and expiry timestamp).

The provided availableMemory (long) and memoryLoad (double) values are passed on for the construction of the MemoryContextData. Also, the accessor method for the representation is ignored for now, as we are not tackling inter-representation issues in this series of tutorials.

In the following, we illustrate the implementation code for the memory context data:

package cy.ac.ucy.cs.osgi.tutorial7.memory_model;

import org.istmusic.mw.context.model.api.IContextData;
import org.istmusic.mw.context.model.api.IContextValue;
import org.istmusic.mw.context.model.api.IScope;
import org.istmusic.mw.context.model.api.IValue;

import java.util.Set;
import java.util.HashSet;

public class MemoryContextData implements IContextData
{
private final AvailableMemoryContextValue availableMemoryContextValue;

private final MemoryLoadContextValue memoryLoadContextValue;

public MemoryContextData(final long availableMemory, final double memoryLoad)
{
availableMemoryContextValue = new AvailableMemoryContextValue(availableMemory);
memoryLoadContextValue = new MemoryLoadContextValue(memoryLoad);
}

public IContextValue getContextValue(IScope scopeKey)
{
if(scopeKey == null)
{
    throw new IllegalArgumentException("The scopeKey cannot be null");
}

if(scopeKey.equals(AvailableMemoryContextValue.SCOPE))
{
    return availableMemoryContextValue;
}
else if(scopeKey.equals(MemoryLoadContextValue.SCOPE))
{
    return memoryLoadContextValue;
}

return null;
}

public IValue getValue(IScope scopeKey)
{
IContextValue contextValue = getContextValue(scopeKey);

return contextValue == null ? null : contextValue.getValue();
}

public Set keySet()
{
final Set keySet = new HashSet();

keySet.add(AvailableMemoryContextValue.SCOPE);
keySet.add(MemoryLoadContextValue.SCOPE);

return keySet;
}

public String toString()
{
return "[" + availableMemoryContextValue + ", " + memoryLoadContextValue + "]";
}
}

In this case, the provided arguments are used to initialize the AvailableMemoryContextValue and the MemoryLoadContextValue (both realization of the ContextValue type). The stored values are then accessed via named invocation of the getContextValue method where the specified argument indicates the scope of the corresponding value.

To avoid cluttering, the complete code of the other custom context types is omitted, but is available for examination and reuse in the MemoryModel.jar file., which will be discussed later on.

The resulting context model, along with its associations to the original model, is illustrated in the following diagram:

As illustrated in this figure, each custom type corresponds (i.e., extends) to an equivalent basic model type. The code for the AvailableMemoryContextValue and the MemoryLoadContextValue, although not depicted, is also straight-forward: it provides a reference to the corresponding elementary context type (LongValue and DoubleValue respectively).

Deploying the Memory Context Model bundle

Although it provides no actual functionality, here we describe how the context model bundle is dormed and deployed. Its use is limited to exporting the memory context model classes.

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Tutorial 7: MemoryModel
Bundle-SymbolicName: MemoryModel
Bundle-Version: 1.0.0
Import-Package: org.istmusic.mw.context.model.api,
org.istmusic.mw.context.model.impl,
org.istmusic.mw.context.model.impl.values,
org.istmusic.mw.context.ontologies
Export-Package: cy.ac.ucy.cs.osgi.tutorial7.memory_model

Notably, the Manifest file in this case does not define an XML service descriptor (as we mentioned already, this bundle does not use or provide any services; it is rather used as a library providing (i.e., exporting) the "cy.ac.ucy.cs.osgi.tutorial7.memory_model" package.

When deployed, the bundle simply exports the corresponding package, as illustrated in the following console output:

osgi> install file:MemoryModel.jar
Bundle id is 8

osgi> bundle 8
file:MemoryModel.jar [8]
Id=8, Status=INSTALLED   Data Root=C:\eclipse\configuration\org.eclipse.osgi\bundles\8\data
No registered services.
No services in use.
Exported packages
cy.ac.ucy.cs.osgi.tutorial7.memory_model; version="0.0.0"[exported]
No imported packages
No fragment bundles
No named class spaces
No required bundles

osgi> ss

Framework is launched.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.2.R34x_v20080826-1230
1       ACTIVE      org.eclipse.equinox.ds_1.0.0.v20080427-0830
2       ACTIVE      org.eclipse.equinox.util_1.0.0.v20080414
3       ACTIVE      org.eclipse.osgi.services_3.1.200.v20071203
4       ACTIVE      RunnableProvider_1.0.0
5       ACTIVE      RunnableConsumer_1.0.0
6       ACTIVE      CLI_Client_1.0.0
7       ACTIVE      music-context_0.2.1.0-SNAPSHOT
8       INSTALLED   MemoryModel_1.0.0

osgi>

This concludes this tutorial. It is recommended that you try to implement some sample models, as described in the exercises, in order to familiarize yourself with the context model.

Homework 7.1: Develop a bundle containing the model for a location context type. The created context element should be named LocationContextElement. Argue which entity and scope are the most appropriate, based on the discussion presented here. The context element must refer to a LocationContextData structure, containing descriptive information for the longitude and the latitude (their semantics and value range are described in Wikipedia: longitude and latitude). The resulting context values should be named LongitudeContextValue and LatitudeContextValue. Both must point to a single DoubleValue. The resulting structure must be packaged in a JAR bundle, along with the necessary Manifest file. You must override the "toString" method in the LocationContextElement to generate an easily readable one-line output encoding the location.

Homework 7.2: Develop a bundle containing the model for a weather context type. The created context element should be named WeatherContextElement. Argue which entity and scope are the most appropriate, based on the discussion presented here. The context element must refer to a WeatherContextData structure, containing descriptive information for the temperature and the wind (described by the direction and the power). The resulting context values should be named TemperatureContextValue and WindContextValue. The former must point to a single DoubleValue, and the latter must point to a StringValue and an IntegerValue (in the range 1 to 10). The resulting structure must be packaged in a JAR bundle, along with the necessary Manifest file. You must override the "toString" method in the WeatherContextElement to generate an easily readable one-line output encoding the weather.

References

[1]. Roland Reichle, Michael Wagner, Mohammad Ullah Khan, Kurt Geihs, Massimo Valla, Cristina Fra, Nearchos Paspallis, George A. Papadopoulos, A Context Query Language for Pervasive Computing Environments, 5th IEEE Workshop on Context Modeling and Reasoning (CoMoRea) in conjunction with the 6th IEEE International Conference on Pervasive Computing and Communication (PerCom), Hong Kong, 17–21 March 2008, IEEE Computer Society Press, pp. 434-440

[2]. Michael Wagner, Roland Reichle, Mohammad Ullah Khan, Kurt Geihs, Jorge Lorenzo, Massimo Valla, Cristina Fra, Nearchos Paspallis, George A. Papadopoulos, A Comprehensive Context Modeling Framework for Pervasive Computing Systems, 8th IFIP International Conference on Distributed Applications and Interoperable Systems (DAIS), 4-6 June, 2008, Oslo, Norway, Springer Verlag LNCS 5053, pp. 281-295

[3]. Anind K. Dey, Understanding and Using Context, Personal and Ubiquitous Computing Journal, Volume 5 (1), 2001, pp. 4-7

Introduction to the MUSIC Context System - Tutorial 6

2009-01-07T10:44:00.014+02:00

Continuing in the next section of the "OSGi and MUSIC Context" series of tutorials, we here introduce the basics of the MUSIC Context System. The MUSIC Context System [1] is an OSGi component which provides automated management for multiple, dynamically-available context providers and consumers. As an OSGi component, the MUSIC Context System exports two services:

IContextAccess
IContextManagement

The former provides an API for accessing context information both synchronously and asynchronously. Furthermore, it allows for the use of the Context Query Language (CQL) [2]. The latter, provides more advanced access to the internals of the context management component, allowing external components, such as the Distributed Context Management System to function (make context remotely available in this case).

To install the MUSIC Context System, you first need to build or download the corresponding JAR file. You can build the latest version from source code (using Maven), or you can download a recent version of it from here: "music-context-0.2.1.0-SNAPSHOT.jar".

Once you build (or download) and install this JAR file, you can notice a few installed services, as illustrated in the following console output:

osgi> install file:music-context-0.2.1.0-SNAPSHOT.jar
Bundle id is 7

osgi> start 7

osgi> ss

Framework is launched.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.2.R34x_v20080826-1230
1       ACTIVE      org.eclipse.equinox.ds_1.0.0.v20080427-0830
2       ACTIVE      org.eclipse.equinox.util_1.0.0.v20080414
3       ACTIVE      org.eclipse.osgi.services_3.1.200.v20071203
4       ACTIVE      RunnableProvider_1.0.0
5       ACTIVE      RunnableConsumer_1.0.0
6       ACTIVE      CLI_Client_1.0.0
7       ACTIVE      music-context_0.2.1.0-SNAPSHOT

osgi> services (objectClass=org.istmusic*)
{org.istmusic.mw.context.cache.IContextCacheService}={component.name=context.cache, component.id=5, service.id=28}
Registered by bundle: file:music-context-0.2.1.0-SNAPSHOT.jar [7]
Bundles using service:
file:music-context-0.2.1.0-SNAPSHOT.jar [7]
{org.istmusic.mw.context.cqp.IContextQueryService}={component.name=context.query, component.id=4, service.id=29}
Registered by bundle: file:music-context-0.2.1.0-SNAPSHOT.jar [7]
Bundles using service:
file:music-context-0.2.1.0-SNAPSHOT.jar [7]
{org.istmusic.mw.context.IContextAccess, org.istmusic.mw.context.IContextManagement}={component.name=context.manager, component.id=3, service.id=30}
Registered by bundle: file:music-context-0.2.1.0-SNAPSHOT.jar [7]
No bundles using service.

As you can see here, there are three sub-components defined in the context bundle:

Context Cache
Context Query [processor]
Context Manager

This architecture is also depicted in the following figure:
As shown in this figure, the "Context Manager" is the central component, utilizing the services offered by the other two components. For instance, the "Context Cache" component, provides a simple storage service, that is used by both the "Context Manager" and the "Context Query Processor". The latter, offers the CQL service, which is used by the "Context Manager" whenever it needs to handle CQL queries.

From an client-side point-of-view though, what matters are the two services offered by the "Context Manager" and which were mentioned already. In the following, we show their exact definition and briefly explain what they are used for.

The IContextAccess service

As mentioned already, the context access service is used for allowing external components, deployed in OSGi, to leverage the capabilities of the context system. The interface (API) of this service is shown in the following listing:

/**
* This is the main point of interaction with the context service (and the
* context system in general). Any context client requiring to interact
* with the context system can achieve it through this interface.
*/
public interface IContextAccess
{
/**
 * Provides synchronous access to the specified context data. It returns
 * the last context element stored only.
 */
public IContextElement queryContextLastElement(IEntity entity, IScope scope)
        throws ContextException;

/**
 * Provides synchronous access to the specified context data.
 */
public IContextDataset queryContext(IEntity entity, IScope scope)
        throws ContextException;

/**
 * Provides asynchronous access to the specified context data.
 */
public void queryContext(IEntity entity, IScope scope, IContextListener listener)
        throws ContextException;

/**
 * Provides synchronous access to the context data.
 */
public IContextDataset queryContext(final IContextQuery query)
        throws ContextException;

/**
 * Provides asynchronous access to the context data. The provided context
 * listener is asynchronously contacted once the results of the given
 * IContextQuery are available.
 */
public void queryContext(IContextQuery query, IContextListener listener)
        throws ContextException;

/**
 * Provides asynchronous access to the context data. By providing a the
 * IEntity and the IScope of the required data, the provided
 * IContextListener reference is asynchronously notified of context
 * changes in the specified entity-scope pair automatically.
 */
public void addContextListener(IEntity entity, IScope scope, IContextListener listener)
        throws ContextException;

/**
 * Provides asynchronous access to the context data. This method is used
 * along with the #addContextListener(IEntity, IScope, IContextListener) method
 * in order to allow unregistering of a context client from a particular
 * entity-scope pair.
 */
public void removeContextListener(IEntity entity, IScope scope, IContextListener listener)
        throws ContextException;

/**
 * Provides the ability to the context clients to specify which context
 * types they require (i.e. because an application was launched, requiring
 * additional context types). The identification of a type is done in terms
 * of a doublet comprising of an IEntity and a IScope.
 *
 * When registered as needed, a context type is monitored by the
 * context system be means of activating an appropriate context sensor (if
 * available). When multiple sensors are available providing the same
 * context type, then the system might decide to activate only one or more
 * of them, based on the resource availability and the quality of the
 * available sensors.
 *
 * Registering the same (Entity,Scope) doublet twice does not throw an
 * exception and does not result in any noticeable change.
 */
public void addNeededContextType(IEntity entity, IScope scope, Object requestor)
        throws ContextException;

/**
 * Provides the ability to the context clients to specify which context
 * types they do not need anymore (i.e. because an application was shut
 * down). The identification of a type is done in terms of a doublet
 * comprising of an IEntity and a IScope.
 *
 * Unregistering a non existing (Entity,Scope) doublet does not throw an
 * exception and does not result in any noticeable change.
 */
public void removeNeededContextType(IEntity entity, IScope scope, Object requestor)
        throws ContextException;
}

As defined in the comments of the corresponding methods, these methods are used to either explicitly request a specific context type, or register a query (formulated in the CQL language [2]) for processing. As the context system needs to be aware of the runtime context needs of the individual applications, it either registers the applications' needs implicitly or it allows for them to express them explicitly (using the last two methods). More details about the functioning of each method can be found in the Javadocs of the "IContextAccess.java" interface.

The IContextManagement service

Unlike context access, the context management service aims for other components which aim at improving or complementing the functionality of the context system. For instance, a component can be used to distribute the local context information across a predefined set of nodes. Another example is of a component which connects to the context system in order to access and visualize relevant information.

In order to enable this kind of functionality, the context management service provides methods which allow to access information about the needed and the provided context types of the node. The interface of the service is illustrated here:

/**
* Provides management-level access concerning the internal state of the MUSIC
* context system.
*/
public interface IContextManagement
{
  /**
   * Returns a set of EntityScopePairs which correspond to the currently
   * required context types.
   */
  public Set getCurrentRequiredContextTypes();

  /**
   * Registers for asynchronous notification of when a new required context
   * type (i.e. EntityScopePair) is added or removed.
   */
  public void addRequiredContextTypesListener(IContextManagementListener listener);

  /**
   * Un-registers from asynchronous notification of when a new required
   * context type (i.e. EntityScopePair) is added or removed.
   */
  public void removeRequiredContextTypesListener(IContextManagementListener listener);

  /**
   * Returns a Set of EntityScopePairs which correspond to the currently provided
   * context types.
   */
  public Set getCurrentProvidedContextTypes();

  /**
   * Registers for asynchronous notification of when a new provided context
   * type (i.e. EntityScopePair) is added or removed.
   */
  public void addProvidedContextTypesListener(IContextManagementListener listener);

  /**
   * Un-registers from asynchronous notification of when a new provided
   * context type (i.e. EntityScopePair) is added or removed.
   */
  public void removeProvidedContextTypesListener(IContextManagementListener listener);

  /**
   * Returns a set of EntityScopePairs which correspond to the currently
   * required context types from remote sources.
   */
  public Set getCurrentRequiredRemoteContextTypes();

  /**
   * Registers for asynchronous notification of when a new required remote
   * context type (i.e. EntityScopePair) is added or removed.
   */
  public void addRequiredRemoteContextTypesListener(IContextManagementListener listener);

  /**
   * Un-registers from asynchronous notification of when a new provided
   * context type (i.e. EntityScopePair) is added or removed.
   */
  public void removeRequiredRemoteContextTypesListener(IContextManagementListener listener);

  /**
   * Allows external entities (such as the "Distributed Context Manager") to
   * raise ContextChangedEvents.
   */
  public void contextChanged(ContextChangedEvent event);
}

The methods of this service allow direct (synchronous) and indirect (asynchronous) access to three context types:

Required Context Types: Those context types that are needed by the currently deployed (i.e., started) applications
Provided Context Types: Those context types that are provided by the currently deployed plug-ins (context sensors and context reasoners)
Required Remote Context Types: Those context types that are needed locally (by the deployed applications) but which are not offered by any of the locally deployed plug-ins

The last method allows for other components (besides the context system and the plug-ins) to generate context events.

In the following tutorials, we will describe the architecture of the context plug-ins, and how a component-based application can be designed to exploit context information from the context system.

[1]. Nearchos Paspallis, Romain Rouvoy, Paolo Barone, George A. Papadopoulos, Frank Eliassen, Alessandro Mamelli, A Pluggable and Reconfigurable Architecture for a Context-aware Enabling Middleware System, 10th International Symposium on Distributed Objects, Middleware, and Applications (DOA'08), Monterrey, Mexico, Nov 10 - 12, 2008, Springer Verlag LNCS 5331, pp. 553-570

[2]. Roland Reichle, Michael Wagner, Mohammad Ullah Khan, Kurt Geihs, Massimo Valla, Cristina Fra, Nearchos Paspallis, George A. Papadopoulos, A Context Query Language for Pervasive Computing Environments, 5th IEEE Workshop on Context Modeling and Reasoning (CoMoRea) in conjunction with the 6th IEEE International Conference on Pervasive Computing and Communication (PerCom), Hong Kong, 17–21 March 2008, IEEE Computer Society Press, pp. 434-440

Component lifecycle support - Tutorial 5

2009-01-04T12:15:00.008+02:00

In this part of our series of tutorials, we examine a few details about the component lifecycle support, and also how to update components at runtime.

Component lifecycle support

When a component is installed, it is first resolved and then started. Resolving a component implies that all its static dependencies (i.e., the imported packages of its bundle container) are resolved (i.e., exported by some other, installed bundles).

Furthermore, when using Declarative Services, the dynamic service dependencies of a component must also be resolved in order to be able to start it (i.e., activate it). We demonstrate these two dependencies in the following example.

Revisiting the CLI Client

In this tutorial, we will revise the "CLI_Client" that was developed in the previous tutorial. In this respect, you can simply copy the code used in the previous example into a new folder and make changes as stated in the following.

The source code of the new "CLI_Client" class looks as follows:

package cy.ac.ucy.cs.osgi.tutorial5;

import org.eclipse.osgi.framework.console.CommandProvider;
import org.eclipse.osgi.framework.console.CommandInterpreter;
import org.osgi.service.component.ComponentContext;

import java.util.logging.Logger;

public class CLI_Client implements CommandProvider
{
  private final Logger logger = Logger.getAnonymousLogger();

public CLI_Client()
{
  super();

    logger.info("CLI_Client: Constructed component");
}

public String getHelp()
{
  return "\ttest - Tests interaction with the Runnable service";
}

  protected void activate(ComponentContext componentContext)
  {
    logger.info("CLI_Client: activate");
  }

  protected void deactivate(ComponentContext componentContext)
  {
    logger.info("CLI_Client: deactivate");
  }

private Runnable runnableService = null;

public void setRunnableService(Runnable runnableService)
{
  this.runnableService = runnableService;
}

public void unsetRunnableService(Runnable runnableService)
{
  this.runnableService = null;
}

public void _test(CommandInterpreter ci)
{
  if(runnableService == null)
  {
    System.out.println("Testing failed: no Runnable service provider available");
  }
  else
  {
    System.out.println("Invoking Runnable service ...");
    runnableService.run();
    System.out.println("Done!");
  }
}
}

The changes are marked in bold, and consist of the following additions:

Two new packages were imported (org.osgi.service.component.ComponentContext and java.util.logging.Logger)
A logger field was defined, and an info log message was added to the constructor
Two methods were defined, with the signature "protected void (de)activate(ComponentContext)"; both of them are simply used to output an info log message

To make things more interesting, we also make a change in the "CLI_Client.xml" service descriptor, so that the referenced service is not optional, but rather mandatory. This is illustrated in the following code, where the "0..1" value was replaced by "1.1" (be reminded that the first digit signifies optionality and the latter multiplicity):

<?xml version="1.0"?>

<component name="CLI_Client">

<implementation class="cy.ac.ucy.cs.osgi.tutorial5.CLI_Client"/>

<service>
<provide interface="org.eclipse.osgi.framework.console.CommandProvider"/>
</service>

<reference name="runnable_service"
interface="java.lang.Runnable"
bind="setRunnableService"
unbind="unsetRunnableService"
cardinality="1..1"
policy="dynamic"/>

</component>

Next, define the new "MANIFEST.MF" file. Note that the file is exactly the same, except for adding a new, second imported package:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Tutorial 5: CLI_Client
Bundle-SymbolicName: CLI_Client
Bundle-Version: 1.0.0
Import-Package: org.eclipse.osgi.framework.console,
org.osgi.service.component
Service-Component: OSGI-INF/CLI_Client.xml

Finally, proceed to build the "CLI_Client.jar" JAR file using the same structure as the one used for the original "CLI_Client" (we keep the name of the JAR file the same as the one of the last tutorial on purpose).

Deploying the new CLI_Client

To deploy the newly developed component, copy the generated JAR file in the deployment folder and replace the one from the previous tutorial. Please note at this point that this has no implications on the running instance of the "CLI_Client" component. To update the actual new component, run the "update" command in the console, as follows:

osgi> ss

Framework is launched.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.2.R34x_v20080826-1230
1       ACTIVE      org.eclipse.equinox.ds_1.0.0.v20080427-0830
2       ACTIVE      org.eclipse.equinox.util_1.0.0.v20080414
3       ACTIVE      org.eclipse.osgi.services_3.1.200.v20071203
4       ACTIVE      RunnableProvider_1.0.0
5       ACTIVE      RunnableConsumer_1.0.0
6       RESOLVED    CLI_Client_1.0.0

osgi> update 6

osgi> ss

Framework is launched.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.2.R34x_v20080826-1230
1       ACTIVE      org.eclipse.equinox.ds_1.0.0.v20080427-0830
2       ACTIVE      org.eclipse.equinox.util_1.0.0.v20080414
3       ACTIVE      org.eclipse.osgi.services_3.1.200.v20071203
4       ACTIVE      RunnableProvider_1.0.0
5       ACTIVE      RunnableConsumer_1.0.0
6       INSTALLED   CLI_Client_1.0.0

At this point, note how the state of the "CLI_Client" component has changed from "RESOLVED" to "INSTALLED". The "CLI_Client" component can be started again using the "start 6" command.

osgi> start 6
Jan 4, 2009 7:05:14 PM cy.ac.ucy.cs.osgi.tutorial5.CLI_Client <init>
INFO: CLI_Client: Constructed component
Jan 4, 2009 7:05:14 PM cy.ac.ucy.cs.osgi.tutorial5.CLI_Client activate
INFO: CLI_Client: activate

osgi> stop 4
Jan 4, 2009 7:05:17 PM cy.ac.ucy.cs.osgi.tutorial5.CLI_Client deactivate
INFO: CLI_Client: deactivate

osgi> start 4

Jan 4, 2009 7:05:21 PM cy.ac.ucy.cs.osgi.tutorial5.CLI_Client <init>
INFO: CLI_Client: Constructed component
Jan 4, 2009 7:05:21 PM cy.ac.ucy.cs.osgi.tutorial5.CLI_Client activate
INFO: CLI_Client: activate

Interestingly, when a component is constructed, activated and deactivated, appropriate log messages appear in the console. This is the result of the OSGi framework constructing the component and invoking the "activate" and "deactivate" methods on it. This is done using a technique commonly referred to as Inversion of Control (IoC).

What is even more interesting though, is that stopping and starting a different service (in this case the "RunnableProvider"), causes the component to be stopped and started automatically. This happens because the service descriptor of this updated component defines a mandatory, one-to-one dependency on the "java.lang.Runnable" service. As component with ID #4 starts and stops, the "java.lang.Runnable" service becomes unavailable and back available. Since the "RunnableProvider" is the single only component that offers this service, the Declarative Services runtime realizes that the "CLI_Client" must be deactivated first, and then activated again when the service is available again.

Homework 5.1: Build a second "java.lang.Runnable" provider, and name it "RunnableProvider2" (other than the name, it can be identical to the original "RunnableProvider"). Then deploy and start it. While both the "RunnableProvider" and the "RunnableProvider2" are both started, along with the new "CLI_Client", try to stop the used provider and note what happens to the "CLI_Client".

Homework 5.2: Discuss with a few words each possible transition in the OSGi bundle's lifecycle state diagram (from OSGi Service Platform Release 4 Version 4.1 Core Specification):

Homework 5.1: Read section 2.9 (Incremental Development) in the second chapter of Neil Bartlett's book

Interacting with the CLI - Tutorial 4

2009-01-03T13:32:00.007+02:00

In the next post of this series of tutorials, we describe a way to interact with the Command Line Interface (CLI) of the Equinox OSGi console. Taking advantage of this functionality, we then illustrate the power of Declarative Services by demonstrating how dynamic binding is handled by the components.

Developing the CLI Client

In this example, we leverage a mechanism provided by OSGi which allows interacting with the framework via commands at the console at runtime. To achieve this, we use OSGi's CommandProvider mechanism. The latter, is implemented as a service which is exported by a component that wishes to interact with the framework via CLI, and which is consumed by the framework itself.

The bundle structure is similar to the one used in the previous two tutorials, and is omitted for brevity. The service descriptor on the other hand, has the distinctive that it both provides a service (the "CommandProvider") and it references one (the "java.lang.Runnable"):

<?xml version="1.0"?>

<component name="CLI_Client">

<implementation class="cy.ac.ucy.cs.osgi.tutorial4.CLI_Client"/>

<service>
<provide interface="org.eclipse.osgi.framework.console.CommandProvider"/>
</service>

<reference name="runnable_service"
   interface="java.lang.Runnable"
   bind="setRunnableService"
   unbind="unsetRunnableService"
   cardinality="0..1"
   policy="dynamic"/>

</component>

It is worth noting that the reference element in this XML descriptor is identical to the one used in the "ServiceConsumer" described in the previous tutorial. On the other hand, the implementation class is of course adjusted to the new class, and a service element is added to define that this component implements the "CommandProvider" service, and thus is capable of interacting the CLI in the console.

Proceeding to the source code of the CLI_Client component, again you can observe some similarities to the code of the "RunnableConsumer", i.e., the default constructor and the standard setter methods for the "java.lang.Runnable" service :

package cy.ac.ucy.cs.osgi.tutorial4;

import org.eclipse.osgi.framework.console.CommandProvider;
import org.eclipse.osgi.framework.console.CommandInterpreter;

public class CLI_Client implements CommandProvider
{
public CLI_Client()
{
super();
}

public String getHelp()
{
return "\ttest - Tests interaction with the Runnable service";
}

private Runnable runnableService = null;

public void setRunnableService(Runnable runnableService)
{
this.runnableService = runnableService;
}

public void unsetRunnableService(Runnable runnableService)
{
this.runnableService = null;
}

public void _test(CommandInterpreter ci)
{
if(runnableService == null)
{
  System.out.println("Testing failed: no Runnable service provider available");
}
else
{
  System.out.println("Invoking Runnable service ...");
  runnableService.run();
  System.out.println("Done!");
}
}
}

The most important observation in this code is that the implementing class in not a POJO anymore (compared to the previous two tutorials). Rather, the class implements the "CommandProvider" interface and even imports two classes:

org.eclipse.osgi.framework.console.CommandProvider
org.eclipse.osgi.framework.console.CommandInterpreter

Furthermore, a method with the signature "getHelp()" is defined, in order to implement the "CommandProvider" interface. Finally, the class defines a method with the signature "_test(CommandInterpreter)", which is its custom way of interacting with the console (the preceding underscore is a required character for a new command).

Finally, the bundle's MANIFEST is similar to those defined in the previous tutorials, but it introduces the new "Import-Package" parameter type:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Tutorial 4: CLI_Client
Bundle-SymbolicName: CLI_Client
Bundle-Version: 1.0.0
Import-Package: org.eclipse.osgi.framework.console
Service-Component: OSGI-INF/CLI_Client.xml

This new parameter type specifies packages that this bundle needs. A similar parameter type, namely "Export-Package", defines packages that are exported by the bundle. At runtime, OSGi evaluates the needs of each bundle against the offered packages, and it resolves only those bundles of which their needed packages are offered by some other, installed bundles. This, in principle, provides a powerful encapsulation mechanism (cf. information hiding), which improves that of plain Java.

Overall, with the new additions we achieve to introduce new functionality to the CLI Client (compared to the "RunnableProvider" of the previous tutorial), in terms of the "test" method that can be invoked in the console. We illustrate this new functionality by deploying, starting and testing the CLI Client.

Deploying and activating the CLI_Client

First, make sure that you have followed the steps described in the previous tutorials to install and activate the "RunnableProvider" and the "RunnableConsumer" (if some components are not started, start them with the "start ID#" command).

Then, proceed to install and activate the CLI_Client. Providing the "bundle 6" command (where 6 is the ID assigned to the CLI Client by the framework), we observe that the component registers the "CommandProvider" service (which is used by the framework for Command Line Interaction as described already) and it uses the "java.lang.Runnable" service, provided by the "RunnableProvider". Furthermore, we note that the bundle imports a package related to OSGi.

osgi> install file:CLI_Client.jar
Bundle id is 6

osgi> start 6

osgi> bundle 6
file:CLI_Client.jar [6]
Id=6, Status=ACTIVE      Data Root=C:\eclipse\configuration\org.eclipse.osgi\bundles\6\data
Registered Services
{org.eclipse.osgi.framework.console.CommandProvider}={component.name=CLI_Client, component.id=10, service.id=30}
Services in use:
{java.lang.Runnable}={component.name=RunnableProvider, component.id=9, service.id=29}
No exported packages
Imported packages
org.eclipse.osgi.framework.console; version="1.0.0"<System Bundle [0]>
No fragment bundles
Named class space
CLI_Client; bundle-version="1.0.0"[provided]
No required bundles

osgi> test
Invoking Runnable service ...
RunnableProvider says hi!
Done!

osgi> stop 4

osgi> test
Testing failed: no Runnable service provider available

Notably, when we invoke the custom "test" command, the framework invokes the corresponding method in the "CLI_Client" component, which prints out a message ("Invoking Runnable service ..."), then invokes the service (which results to the output of "RunnableProvider says hi!", as it was specified in the second tutorial) and finally it prints out a third line ("Done!").

This means that the invocation of the service was successful, and resulted to the invocation of the "run()" method all the way from the client side, to the service side. Just to make sure that the dynamic binding works, we can try to stop the "ServiceProvider" and run the "test" command again. The former causes the unbinding of the "java.lang.Runnable" service from the clients, which results to setting it to null and thus the print-out of the "Testing failed: no Runnable service provider available" message.

Finally, to show how a service provider can serve more than one clients simultaneously, we can try starting the service back again (via the "start 4" command), and then inspect the service:

osgi> start 4

osgi> services (objectClass=java.lang*)
{java.lang.Runnable}={component.name=RunnableProvider, component.id=12, service.id=32}
Registered by bundle: file:RunnableProvider.jar [4]
Bundles using service:
file:RunnableConsumer.jar [5]
file:CLI_Client.jar [6]

In this case, we can observe that the service is registered by the "RunnableProvider" component, and is assigned an ID (32 in this case, might be different in your case). Notably, there are two bundles using the service: the "RunnableConsumer" defined in the previous tutorial and the "CLI_Client" defined in this one.

Homework 4.1: Read section 2.10 (Interacting with the Framework) in the second chapter of Neil Bartlett's book.

Homework 4.2: Write a bundle that periodically checks the contents of a directory in the filesystem. Whenever a new file with the extension ".jar" appears in that directory, print out an appropriate message.

Binding declarative services - Tutorial 3

2009-01-02T12:32:00.011+02:00

This is the next entry in this series of tutorials, where we will show how a simple component can be bound to a service. In the first tutorial, we learned how to install and start the Equinox OSGi framework and in the second one, we learned how to construct a simple component declaring an offered service.

Assuming you have followed all the steps described in the first two tutorials, then your OSGi runtime should have four components installed and started, as illustrated in the following screen:

osgi> ss

Framework is launched.

id State Bundle
0 ACTIVE org.eclipse.osgi_3.4.2.R34x_v20080826-1230
1 ACTIVE org.eclipse.equinox.ds_1.0.0.v20080427-0830
2 ACTIVE org.eclipse.equinox.util_1.0.0.v20080414
3 ACTIVE org.eclipse.osgi.services_3.1.200.v20071203
4 ACTIVE RunnableProvider_1.0.0

Developing the client side of the Runnable service

In this part, we describe how to develop a component that can be automatically bound to the java.lang.Runnable service, exported by the Runnable Provider component. We will name this component "RunnableConsumer".

The bundle structure is quite similar to the one of the "RunnableProvider", described in the second tutorial:

+- META-INF
|  +- MANIFEST.MF
|
+- OSGI-INF
|  +- RunnableConsumer.xml
|
+- cy
+- ac
+- ucy
+- cs
+- osgi
  +- tutorial3
     +- RunnableConsumer.class

The MANIFEST file is also quite similar to the one defined for the "RunnableProvider":

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Tutorial 3: Runnable consumer
Bundle-SymbolicName: RunnableConsumer
Bundle-Version: 1.0.0
Service-Component: OSGI-INF/RunnableConsumer.xml

The main differences of the client side from the service provider are in the Java source code implementing the component, and in the service descriptor. As opposed to the "RunnableProvider", the "RunnableConsumer" does not define a provided service, but rather just a reference to a needed service, as follows:

<?xml version="1.0"?>

<component name="RunnableConsumer">

<implementation class="cy.ac.ucy.cs.osgi.tutorial3.RunnableConsumer"/>

<reference name="runnable_service"
   interface="java.lang.Runnable"
   bind="setRunnableService"
   unbind="unsetRunnableService"
   cardinality="0..1"
   policy="dynamic"/>

</component>

The "reference" element in the service descriptor specifies that:

The component has a binding to a service, and the name of the binding is set to "runnable_service"
The needed service is one which implements the "java.lang.Runnable" interface
To bind this component with a provider of the service, the framework must invoke the "setRunnableService" method
Similarly, to unbind the component from a provider, the framework must invoke the "undetRunnableService" method
The cardinality parameter has the form "x..y", where x can be either '0' or '1' and y can be either '1' or 'n'. The first parameter specifies optionality, and the second one specifies multiplicity. For instance, x='0' means that a binding to the service is optional, while x='1' means that the binding is (otherwise the component can not be resolved and activated). On the other hand, y='1' implies single binding only, where the component can only be bound to just one service provider at a time, while y='n' implies that multiple service providers can be bound to the component simultaneously.
The last parameter, policy, can be set to either "dynamic" or "static". This controls the binding to new service providers at runtime. When the value is set to "static", then it is implied that the component cannot handle dynamic switching of service providers and thus the framework constructs a new instance of the component when the service provider changes. On the other hand, when the policy is set to "dynamic", then the binding and unbinding of service providers takes place dynamically on the same component instance. As the former is more heavy-weight, it is recommended that the components are designed and implemented so that they support the dynamic policy. The default value is "static", which means that unless you specify the policy parameter as "dynamic", it is going to be set as "static".

Next, we show the class source code, which is quite straightforward:

package cy.ac.ucy.cs.osgi.tutorial3;

public class RunnableConsumer
{
private Runnable runnableService = null;

public void setRunnableService(Runnable runnableService)
{
this.runnableService = runnableService;
}

public void unsetRunnableService(Runnable runnableService)
{
this.runnableService = null;
}

public RunnableConsumer()
{
super();
}
}

This class is also a POJO object, just like the Service Provider. It specifies a reference to a "java.lang.Runnable" type of service, along with straightfoward setter methods (complying to the signatures defined in the service descriptor). Evidently, this code is not too fascinating, but combined with the service descriptor it reveals the power of OSGi and Declarative Services.

The last step is to put everything together and construct the JAR file of the bundle. Similar to the "RunnableProvider", we construct the "RunnableConsumer" by compiling the Java class and adding the metadata as defined in the bundle structure. The source code, the metadata and an optional ANT build script are included in the RunnableConsumer JAR file.

Deployment and activation

We first install the newly constructed component using the, now familiar, "install" command of the console:

osgi> install file:RunnableConsumer.jar
Bundle id is 5

osgi> bundle 5
file:RunnableConsumer.jar [5]
Id=5, Status=INSTALLED   Data Root=C:\eclipse\configuration\org.eclipse.osgi\bundles\5\data
No registered services.
No services in use.
No exported packages
No imported packages
No fragment bundles
No named class spaces
No required bundles

As shown in this listing, at the time the component is simply installed, assigned the ID #5, and has no services in use. As soon as we start the service, using the "start 5" command, the component is bound to the "java.lang.Runnable" service provided by the "RunnableProvider" component, as shown here:

osgi> start 5

osgi> bundle 5
file:RunnableConsumer.jar [5]
Id=5, Status=ACTIVE      Data Root=C:\eclipse\configuration\org.eclipse.osgi\bundles\5\data
No registered services.
Services in use:
{java.lang.Runnable}={component.name=RunnableProvider, component.id=0, service.id=26}
No exported packages
No imported packages
No fragment bundles
Named class space
RunnableConsumer; bundle-version="1.0.0"[provided]
No required bundles

Later on, if we stop the "ServiceProvider" bundle, then the component is unbound from the service, although its instance is still around, deployed in the framework and awaiting for a new service provider:

osgi> stop 4

osgi> bundle 5
file:RunnableConsumer.jar [5]
Id=5, Status=ACTIVE      Data Root=C:\eclipse\configuration\org.eclipse.osgi\bundles\5\data
No registered services.
No services in use.
No exported packages
No imported packages
No fragment bundles
Named class space
RunnableConsumer; bundle-version="1.0.0"[provided]
No required bundles

In the next tutorial, we will develop a more powerful client for the "java.lang.Runnable" service, featuring user-interaction via the command-line.

Homework 3.1: Read the third chapter (Introduction to Services) of Neil Bartlett's book. You can read just the first four sections for now, i.e., 4.1, 4.2, 4.3 and 4.4.

Your first component - Tutorial 2

2009-01-01T11:51:00.011+02:00

In the previous tutorial, we introduced OSGi and showed how you can download, install and start the Equinox framework, and prepared it for using Declarative Services. In this tutorial, we will see how your first component can be implemented.

The bundle structure

As already mentioned in the first tutorial, bundles are packaged in JAR files. Inside a JAR, the files are organized with the following structure:

+- META-INF
|  +- MANIFEST.MF
|
+- OSGI-INF
|  +- RunnableProvider.xml
|
+- cy
+- ac
+- ucy
 +- cs
    +- osgi
       +- tutorial2
          +- RunnableProvider.class

This structure contains the Java classes (i.e., in the "cy.ac.ucy.cs.osgi.tutorial.*" package structure) along with the configuration data of the bundle (i.e., "META_INF/MANIFEST.MF") and of the component (i.e., "OSGI-INF/RunnableProvider.xml"). We will study these parts one by one.

The implementation code

In this tutorial, we develop a very simple component, offering a very simple service. The source code for the implementing class looks as follows:

package cy.ac.ucy.cs.osgi.tutorial2;

public class RunnableProvider implements Runnable
{
public void run()
{
System.out.println("RunnableProvider says hi!");
}
}

This simple class implements the "java.lang.Runnable" interface, which specifies a single method: "public void run()". In this example we provide the most simple (and useless) implementation, just to illustrate how Declarative Services work. When the service is invoked, a message is printed in the console where the "RunnableProvider" is deployed.

It is worth noting that this class is a Plain Old Java Object (POJO), and thus requires no additional libraries for compiling it. But, in order to become OSGi deployable, and Declarative Services recognizable, this component must be accompanied with the appropriate metadata.

The service descriptor

As a Declarative Services component, the RunnableProvider must be accompanied by an appropriate service descriptor, as the one illustrated in the following:

<component name="RunnableProvider"></component>

<implementation class="cy.ac.ucy.cs.osgi.tutorial2.RunnableProvider"/>

<service>
<provide interface="java.lang.Runnable"/>
</service>

</component>

This file, which we named "RunnableDescriptor.xml" in this example, is expressed in XML and is used to specify the defined component, along with any provided (and as we will later on, required) services.

In this case, the component is named "RunnableProvider" and its implementation is provided by the class we specified already: "cy.ac.ucy.cs.osgi.tutorial2.RunnableProvider". Furthermore, this component provides a service, as it is specified by the "java.lang.Runnable" interface.

In real applications, the provided services correspond to more complex, custom interfaces. However, in this case we chose an interface which is standard in the JRE, so that we do not have to export/import any classes at this point (this will be presented in another tutorial).

The bundle manifest

Finally, the last piece that is needed to make the bundle deployable is the bundle manifest. This file describes the library dependencies of the bundle (imported and exported packages), the name and version of the bundle and a reference to the service descriptor.

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Tutorial 2: Runnable provider
Bundle-SymbolicName: RunnableProvider
Bundle-Version: 1.0.0
Service-Component: OSGI-INF/RunnableProvider.xml

(Important: Please make sure that you add an empty line at the end of every MANIFEST file you define, because otherwise you risk that the parser will truncate the last line of your file.)

Most of the properties in this bundle descriptor are self-explanatory. The last parameter points to the corresponding service descriptor, inside the JAR package. Finally, in this example, there are no imported or exported packages.

To produce the required file, simply compile the Java class and package everything together in a JAR file with the structure described above. A version of such a JAR file is available here. It is also possible to automate building such bundles using ANT or MAVEN. An example ANT build script is included in the RunnableProvider JAR file. Furthermore, the same JAR file includes a copy of the RunnableProvider's Java source code.

Deploying and starting your first component

Once you have produced the JAR-packaged bundle, the next step is to deploy it. Following the same approach as the one described in the first tutorial, you can install and start the RunnableProvider bundle:

osgi> install file:RunnableProvider.jar
Bundle id is 4

osgi> start 4

osgi> ss

Framework is launched.

id State Bundle
0 ACTIVE org.eclipse.osgi_3.4.2.R34x_v20080826-1230
1 ACTIVE org.eclipse.equinox.ds_1.0.0.v20080427-0830
2 ACTIVE org.eclipse.equinox.util_1.0.0.v20080414
3 ACTIVE org.eclipse.osgi.services_3.1.200.v20071203
4 ACTIVE RunnableProvider_1.0.0

osgi> services (objectClass=java.lang*)
{java.lang.Runnable}={component.name=RunnableProvider, component.id=0, service.id=26}
Registered by bundle: file:RunnableProvider.jar [4]
No bundles using service.

The "services" command results to the system displaying all services registered by any components. As those services might be numerous though, we use a filtering option ("services (objectClass=java.lang*)". This filter blocks any services that do not start with a "java.lang" package prefix.

For testing purposes, you can then stop the RunnableProvider bundle and issue the same "services" command a second time. You will then realize that the "java.lang.Runnable" service is not offered anymore.

Homework 2.1: After you deploy and start your component, as explained in this tutorial, test again the commands that you have investigated in Homework 1.1 (Tutorial 1).

Homework 2.2: Read the second chapter (First Steps in OSGi) of Neil Bartlett's book. You can skip sections 2.2, 2.3, 2.4, 2.5 and 2.6. You can also skip sections 2.9 and 2.10 for now (they will be covered in follow-up tutorials).

Starting with OSGi - Tutorial 1

2008-12-31T10:55:00.013+02:00

This is the first part of a series of tutorials which show how you can build context-aware applications with the MUSIC Context System. This system is part of the general MUSIC Middleware, developed by the MUSIC Consortium. As the MUSIC Context System is built on top of OSGi and it leverages Declarative Services (which are based on Service Binder), we start with an introduction to these technologies. For an additional, well-structured tutorial on OSGi and Declarative services, you can also check out this blog.

OSGi Component Framework Basics

The Open Service Gateway initiative (OSGi) commonly refers to a standard specifying a Java-based service platform that can be remotely managed. The core part of the specifications is a framework that defines an application life cycle management model, a service registry, an Execution environment and Modules (see Wikipedia entry on OSGi). There are currently five certified implementations complying to OSGi specification R4, including Eclipse Equinox and Knopflerfish.

As component frameworks, OSGi implementations provide a way to encapsulate and package functionality into well-defined packages. In this case, the packages correspond to bundles, which can import and export services as a way of interacting with other bundles. These bundles are packaged in JAR files which enclose the Java classes of the implementing code, along with the required metadata (i.e., the MANIFEST file).

Components and Services

Before we delve into the core of OSGi installation and use, we need to provide some additional explanation as per the motive for OSGi. Since the early 70's, computer scientists realized the importance of encapsulation (see this classic work from Parnas for example).

Encapsulation allows implementing complex software with only a small fraction of it (the API) exposed to its users. This makes it possible to edit and update the internal implementation of the software without requiring any action from its users. In its most modern form, encapsulation (or information hiding) is enabled using components and services.

One of the most popular definitions of software components specifies them as "[software components] are units of composition with contractually specified interfaces and explicit context dependencies only; [software components] can be deployed independently and is subject to composition by third parties" (Component Software - Beyond Object-Oriented Programming book). On the other hand, services are used to indicate a predefined set of functionality through an interface (functional logic) along with some policies and/or contracts defining its extra-functional properties, such as Quality of Service (QoS) contracts, etc.

In OSGi, encapsulation is achieved via software components and services. The former can register (i.e., provide) or use (i.e., consume) services dynamically, as needed. Services allow loose coupling of components, i.e., the service providers do not know about their users and the service users do not know about their providers. Notably, in OSGi the coupling is done dynamically (i.e., at runtime) which provides much more functionality and reliability to the systems.

Downloading and Installing the Framework

While there are multiple implementations of the OSGi specification, for the purposes of this tutorial we will use Eclipse's Equinox.

Your first step is to download Equinox. At the time of writing this tutorial, version 3.4.1 is the latest one, and is available for download at this link.

Once it is downloaded, you should unzip the file to the folder of your choice (e.g., in "c:\", which creates the "c:\eclipse\..." folders).

The core of the Equinox implementation of OSGi is in the "plugins" folder, in a JAR file named "org.eclipse.osgi_3.4 ... .jar". Copy that file to "c:\" and rename it to "equinox.jar".

Starting the OSGi Console

To start the (console view) of the framework, simply issue the following command:

C:\eclipse>java -jar equinox.jar -console

osgi>

The framework is up. You can issue your first command to the console. Try "help" or "ss". The first one prints a list of available commands. The second one, shows the short status of the framework, as in the following:

osgi> ss

Framework is launched.

id State Bundle
0 ACTIVE org.eclipse.osgi_3.4.2.R34x_v20080826-1230

This output says that there is only one bundle installed in the framework (the core OSGi implementation by Equinox), which is assigned the ID "0" and is currently "active". Each bundle can be further introspected with the "bundle" command, as follows:

osgi> bundle 0
System Bundle [0] Id=0, Status=RESOLVED
Registered Services {org.eclipse.osgi.framework.console.CommandProvider}={service.ranking=2147483647, service.id=1} {org.eclipse.osgi.framework.log.FrameworkLog}={service.ranking=2147483647, service.pid=0.org.eclipse.core.runtime.adaptor.EclipseLog, service.vendor=Eclipse.org, service.id=4} {org.eclipse.osgi.framework.log.FrameworkLog}={service.ranking=-2147483648, performance=true, service.pid=46org.eclipse.core.runtime.adaptor.EclipseLog, service.vendor=Eclipse.org, service.id=5} {org.eclipse.osgi.service.runnable.ApplicationLauncher}={service.id=22}
Services in use: {org.eclipse.osgi.framework.console.CommandProvider}={service.ranking=2147483647, service.id=1}
No exported packages [PackageAdmin service is not registered]

As it was already mentioned in the OSGi Basics, bundles interact with each other via services. In this case, the services are abstracted and correspond to plain Java Interfaces. As such, each bundle specify a list of offered (i.e., registered) and needed (i.e., used) services. Notably, this status shows that the Equinox bundle offers (and uses) the "org.eclipse.osgi.framework.console.CommandProvider" interface. This is a service which allows interfacing with the Command Line Interface (i.e., the console), and it will be revisited in one of the following tutorials.

Getting ready for Declarative Services

While the current bundle is sufficient for the core OSGi, additional bundles are needed in order to add more functionality. For example, in order to deploy bundles which use Declarative Services, you need to install the following bundles: "org.eclipse.equinox.ds_1. ... .jar", "org.eclipse.equinox.util_1. ... .jar" and "org.eclipse.osgi.services_3. ... .jar".

Please note that all the needed JAR files are available in the "./plugins" folder, and they can be installed by referencing them directly as follows:

osgi> install file:plugins\org.eclipse.equinox.ds_1.0.0.v20080427-0830.jar
Bundle id is 1

osgi> install file:plugins\org.eclipse.equinox.util_1.0.0.v20080414.jar
Bundle id is 2

osgi> install file:plugins\org.eclipse.osgi.services_3.1.200.v20071203.jar
Bundle id is 3

osgi> ss

Framework is launched.

id State Bundle
0 ACTIVE org.eclipse.osgi_3.4.2.R34x_v20080826-1230
1 INSTALLED org.eclipse.equinox.ds_1.0.0.v20080427-0830
2 INSTALLED org.eclipse.equinox.util_1.0.0.v20080414
3 INSTALLED org.eclipse.osgi.services_3.1.200.v20071203

osgi> start 1

osgi> start 2

osgi> start 3

osgi> ss

Framework is launched.

id State Bundle
0 ACTIVE org.eclipse.osgi_3.4.2.R34x_v20080826-1230
1 ACTIVE org.eclipse.equinox.ds_1.0.0.v20080427-0830
2 ACTIVE org.eclipse.equinox.util_1.0.0.v20080414
3 ACTIVE org.eclipse.osgi.services_3.1.200.v20071203

Finally, please note that after you install a bundle, it is copied in "./configuration" (which is created by OSGi the first time you launch it) and thus it is not needed to keep it at the source folder anymore.

In this case, we have started all the bundles and executed the short status (ss) command afterwards.

Shutting the OSGi console down

To exit the console, you can simply issue the "shutdown" command followed by "exit" command:

osgi> shutdown

osgi> ss

Framework is shutdown.

id State Bundle
0 RESOLVED org.eclipse.osgi_3.4.2.R34x_v20080826-1230

osgi> exit

Homework 1.1: Run the "help" command in the console. Report what each of the following commands does:

status
diag ID
h ID
services
packages
close

Homework 1.2: Read the first chapter (Introduction) of Neil Bartlett's book. You can skip sections 1.3 and 1.8.

Tutorials for OSGi, Declarative Services and the MUSIC Context System

2008-12-30T15:23:00.021+02:00

As a research associate at the University of Cyprus, I work for the MUSIC-IST (somehow, the anagram for "Self-Adapting Applications for Mobile Users in Ubiquitous Computing Environments"), which is an FP7 IP project funded by the European Union. It aims at enabling the development of context-aware, self adaptive applications. One of the most important novelties of MUSIC, is that it provides a comprehensive development methodology. This means that the developers have a plethora of guidance, tools and libraries available when they depart developing such an application. Furthermore, as it is based on a Middleware architecture, MUSIC provides flexibility and facilitates code reuse.

As part of my research, I am the principal architect and developer of the MUSIC Context System. In the following posts, I will describe how this system can be used to build context-aware applications. As this system builds on top of OSGi, and especially leverages the Declarative Services specification, the first tutorials cover the basics of OSGi, starting from installing and launching the framework. As new tutorials become available, I will update the list in this blog entry.

OSGi and Declarative Services

Starting with OSGi - Tutorial 1 (published Dec 31st, 2008)
Your first component - Tutorial 2 (published Jan 1st, 2009)
Binding declarative services - Tutorial 3 (published Jan 2nd, 2009)
Interacting with the CLI - Tutorial 4 (published Jan 3rd, 2009)
Component lifecycle support - Tutorial 5 (published Jan 4th, 2009)

MUSIC Context System

Introduction to the MUSIC Context System - Tutorial 6 (published Jan 7th, 2009)
Context Model and Ontology - Tutorial 7 (published Jan 28th, 2009)
Developing your first context sensor plug-in - Tutorial 8 (published Jan 29th, 2009)
Developing a context client - Tutorial 9 (published Jan 30th, 2009)
Developing a complete context-aware application (CaMP) - Tutorial 10 (published Feb 12th, 2009)

The only requirement for attending these tutorials is a reasonable command of Object-Oriented programming in Java.

For comments, or suggestions regarding these tutorials, please contact the author via email (you can find it in my homepage: http://member.acm.org/~nearchos).

Resources

OSGi website and and the Specifications of Release 4 (R4)
Neil Bartlett's blog entries on Getting Started with OSGi and the first chapters of his book (in draft)
A 6-page quick-start introduction to OSGi and Equinox (requires registration): Getting Started with Equinox and OSGi Refcard
Andre L. C. Tavares, Marco Tulio Valente, A Gentle Introduction to OSGi, SIGSOFT Software Engineering Notes, Vol. 33, No. 5 (Aug. 2008), pp. 1-5
A few books by Amazon are unfortunately not available until Summer ("Equinox and OSGi" and "OSGi in Action: Creating Modular Applications in Java")

2nd Workshop on Context-aware Adaptation Mechanisms for Pervasive and Ubiquitous Services (CAMPUS 2009)

2008-12-29T21:14:00.000+02:00

Building on last year's success, the "2nd Workshop on Context-aware Adaptation Mechanisms for Pervasive and Ubiquitous Services (CAMPUS 2009)" will be organized again, in conjunction with the "4th International federated conference on Distributed Computing Techniques (DisCoTec 2009)".

As a member of the Program Committee of the workshop, I encourage you to consider submitting any work you have done relevant to "Context-awareness" or "Adaptation Mechanisms" for Pervasive and Ubiquitous Services. I honestly think is a good forum, with experienced reviewers, for discussing and potentially presenting your work.

Important dates:
Paper submission: March 20, 2009
Paper notification: April 24, 2009
Camera ready: May 08, 2009
Workshop: June 12, 2009

iPod touch

2008-12-29T12:31:00.009+02:00

As promised in a blog entry some weeks ago, I now post my impressions of iPod touch.

I bought an iPod touch (2nd generation) as a gift to myself while we were visiting Hawaii. The Apple Store I got it from was great! So was the price ($230 plus tax), considering how much more expensive iPods are in Europe. Let me say here that I chose iPod to iPhone for two simple reasons: First, I already have a NOKIA phone with which I am very happy and, second, I wanted a device primarily for browsing the Internet without a laptop and for killing my time in airports etc.

The first impression was actually not very positive. I got frustrated because I could not get iPod paired with my iTunes account. The reason was that iTunes purchases are available only in selected countries (and Cyprus is not one them yet), which was OK with me. The problem was that although I did not mind not being able to buy staff (I have plenty of CDs already), I still wanted to be able to get the freely available products (mostly apps and podcasts). Thanks to instructions from this site, I was finally able to set up my iTunes account without having to enter any data for a credit card or mailing address (it is too bad Apple did not make it easier to skip attaching a credit card to an iTunes account).

Other than this little glitch though, I have to admit that iPod touch is an amazing gadget. Most of all, I enjoy the touch UI, and the orientation sensors which add a lot to the user experience (especially in the context of game apps). MUSIC and video playback are excellent. In my last 4.5h flight back from Schiphol, I felt as if time flew by! I was using my iPod touch to watch video snippets of stand-up comedy from Comedy Central and also I was playing with what has become my favorite iPod game: TAP Defense.

I would like to also cover the development aspects of iPhone/iPod touch, but unfortunately I soon realized that the development tools for iPhone and iPod touc are limited to Macs only.

In summary, the pros:
1. Great UI
2. Excellent web and mail applications
3. Great audio and video playback
4. The appstore is a vibrant active community generating challenging and useful apps
5. As a device, it is small and light
6. It charges from USB

and cons:
1. It does not have an embedded microphone
2. Docking base comes as an extra
3. Its accessories (e.g. docking station, video connector, power adapter) are quite expensive
4. The Development tools are available for Macs only

Photos from Hawaii

2008-12-28T19:53:00.010+02:00

It's been more than a month since we visited Hawaii now. But I need to write this blog entry so that I don't forget how wonderful everything was. I think Oahu is a gorgeous island, even though I understand that the other islands of Hawaii might be even prettier (at least less developed = more natural).

While Honolulu is a nice city, Waikiki is too touristic for my taste. But apart from this, the rest of the island is amazing. Even just outside the limits of the city, there are tropical forests and wonderful waterfalls. Just a few miles east of Honolulu, Hanauma bay, which is typically very busy, provides an astonishing experience. Then, the Polynesian Cultural Center to the northeast of the island is definitely worth visiting. Although the day we visited the Polynesian Cultural Center was quite rainy, it was still a quite memorable experience. And of course, the beaches of Hawaii, especially Kailua, is a must visit/must swim activity for everyone visiting Oahu.

I am looking forward to the next opportunity to visit Hawaii!

This and other pictures from Oahu are posted in my Picasa account: "Oahu, Hawaii".

Gearing up for Hawaii

2008-11-04T10:53:00.005+02:00

Just a week before heading for Hawaii, I am all excited about visiting these tropical islands in the middle of the Pacific. Adding up to the big-brother-is-watching-me [1] feeling, GMail offered some Hawaii-related hotel offers while watching a completely unrelated message. Lucky guess, or does Google actually know more about me than I thought? I am sure that somewhere in the future, we will be able to query Google "where to is my next trip?" and receive the right answer!

One of the many things I am anticipating to for this trip is shopping. Actually, I am always happy when I visit the States as there are always some things (usually gadgets) I would like to buy. This time, I have set my eyes on iPod touch. As it has been almost five years since I bought my last iPod (2nd or 3rd generation, white with 20Gb disk), technology has progressed a lot. I am especially looking forward to the touchscreen with gestures experience. Although I have considered iPhone too, I am going with iPod touch for several reasons: First, I am already quite happy with my Nokia E65 phone (we all know that Nokia knows how to make good phones); Second, I hear that iPhone has some rough edges, at least wrt its phone aspects; Third, it is quite expensive to buy it in Europe and in the US it is locked and requires a 2-year contract. I will probably follow up with a blog with my experiences with iPod touch once I try it long enough.

[1]. Actually, to me the "big brother" term is quite unsuccessful; my big brother has always looked after me in the metaphorical sense only! I guess I am lucky :-)

Dude, where is my computer?

2008-09-17T16:24:00.005+03:00

You know how you sometimes read an article somewhere and you think this is so cool, I should write a blog entry about this as well? Well, I do!

I was just reading an article on cloud computing in IEEE Spectrum (by the way, an excellent magazine for technology lovers). This article, titled the cloud is the computer, discusses how Paul McFedries (the author) expects cloud computing to power the future of pervasive (or ubiquitous) computing. This makes two of us! (Well, most likely more.)

Being a researcher in pervasive computing technologies, and an active user of several cloud computing-based applications myself, has affected my thinking of how the future of computing could be. The original idea behind ubiquitous computing, as expressed by Mark Weiser, is for technologies that result to computing receding to the background of our lives. In other words, the users continue receiving the benefit of using their favorite services without necessarily having to bother about the actual machinery that offers them.

If you think about it, when you connect to GMail from your desktop's favorite browser, you do not bother about the complex machinery that is required to enable that. You rather concentrate on your goal, which in this case is textual communication. Later on in the day, when you access your account using GMail for mobile on your smart-phone, you still have access to similar functionality, which (ideally) is adapted to your context. For instance, a smaller screen, lower bandwidth and a more constrained keyboard.

Personally, I think that GMail is currently the most successful, and definitely the most widespread, example of a pervasive computing application. Although we are still not at the point where the service is experienced with absolute transparency of the machinery, still this is the best example of how truly useful pervasive computing will be.

Google Docs success story

2008-08-21T08:25:00.006+03:00

As a member of the organizing committee of the 17th International Conference on Information Systems Development (ISD 2008), I spent some time (and still do as of today) in updating the conference's website (the original pages were created by the National University of Ireland, Galway for ISD2007, and we were granted the right to reuse them).

During this exercise, I found that Google Docs, and especially the spreadsheet application is extremely useful. For instance, while the authors were registering and submitting the camera-ready version of their papers, we used a dynamically updated spreadsheet to indicate the status of their paper.

Furthermore, while filling in the slots for session chairs and forming the program, we used another dynamically updated page which indicated which slots were empty. This page was updated in almost real time, as we edited the spreadsheet as soon as we handled the incoming emails and then the corresponding web-page was updated within minutes.

Finally, an important aspect of each conference is the publication of its statistics. In this regard, Google spreadsheets really rocks, not only because it allows to publish information dynamically, but also because it allows the creation of graphs which are also dynamically updated along with their associated data. For instance, we were able to publish a graph with information about the number of submitted papers per track, along with their acceptance ratio. Furthermore, using the nice gadgets available in the web application, we were also able to publish a map that illustrates the origin of the (affiliation of the) authors of accepted papers and the program committee.

Evidently, although an excellent tool, Google Docs is not perfect yet. One limitation I found is that I could not insert isolated fields of information in my web-pages (i.e., corresponding to a single cell). For instance, in one of the spreadsheets, I maintain information like the total number of accepted papers (which changes as some authors withdraw theirs). Unfortunately, that number had to be hard-coded in HTML, because I could not find a way to insert isolated (but dynamically updated) fields in my page. I understand that this can be solved with a custom gadget (if not done already), but of course it would be nice if it was provided as a standard gadget.

Although not perfect yet, Google Docs have really helped us with the organization of the conference, and I think this is something worth mentioning. As I really did not want to deal with anything but static HTML pages, Google Docs has proved to be an extremely useful tool.

Testing Google Maps for mobile again

2008-08-19T10:40:00.008+03:00

Like I mentioned before, I am using Google Maps for mobile. While in my previous entry I praised the accuracy of the automatic positioning feature, I soon found out that this is not always the case. While at the new campus of the University of Cyprus, my phone centered my location as shown in the following screen-shot:

It took some zooming out to realize that this is actually Buenos Aires :-) Only 12270 Km away ;-)

Update: Today (September 17th, 2008) I tried again and this time it gave me a somewhat more accurate reading. Again from the University of Cyprus campus, it showed me at the headquarters of my carrier (Cytamobile Vodafone) with an accuracy of 5 Kms. This of course covers more or less the whole city of Nicosia. Well, at least the results were imrpoved by a magnitude of X2454!

Google Maps in Cyprus

2008-08-12T08:52:00.005+03:00

I have been using Google Maps for mobile for a while. Recently, I had to reset my E65 to install the latest firmware from NOKIA. When I reinstalled Google Maps, I apparently got a new version where the My Location feature if finally working (in Cyprus). Interestingly, the results were quite accurate (at least while close to the center of Nicosia).

If you own a supported device (most NOKIA smart-phones are supported), then check it out. Although the actual location is determined by inquiring the cell IDs via GSM, a WiFi or GPRS connection is needed for the map data.

The beginning

2008-08-03T17:09:00.026+03:00

This is the beginning of my blogging life. Actually the beginning of my English blogging life. I was blogging in Greek before (and still do sometimes). But to enlarge my audience and allow more people to benefit from my wisdom, I started this blog in English as well.

Let me introduce myself. My name is Nearchos Paspallis and I was born and live in Cyprus (which is such a small and complicated country that people tend to add a link to its Wikipedia entry when they first mention her).

Back to myself, I spend most of my time in front of a computer screen. However, my tan (seen in my profile picture) is mostly natural due to sunlight I am exposed to during coffee breaks (rather than to LCD radiation). There are primarily two main reasons I spend this much time in front of my computer: First, I work as a researcher in Software Engineering (so, you could say it's because of my job). Second, I pursue a PhD in Computer Science.

The motivation for this blog is that it will help me organize my [public] thoughts, and have an archive of them in case I need to recall them. For instance, I plan to blog about technical stuff, and also thoughts related to my PhD research (e.g., try-and-fail lessons). Hopefully my ideas and opinion will not be completely useless to everyone.