Providing Mobile Multimodal Social Services Using a Grid Architecture

Introduction

The penetration of mobile device in western countries is high and still increasing. At the same time new generation terminals feature ever increasing computing power, opening new possibilities for innovation, especially in service delivery.

One emerging trend in service evolution is for services to cater not only to individuals but also to communities of users. Communities are a social phenomenon where people with common interests, experiences, and objectives are brought together. They provide a social place where individuals exchange and share information, knowledge, emotions and jointly undertake activities. Managing the creation or deletion of flexible communities improves the user experiences in communities (NEM, 2006).

MoSoSo (Mobile Social Software), is a class of mobile applications that aims to support social interaction among interconnected mobile users (Lugano, G., 2007). While existing Internet-based services have already shown the growing interest in communication support for communities, MoSoSo adds additional dimensions to group communication by exploiting contextual data such as the user geographical position (Counts, S., 2006).

When designing MoSoSo applications, three important differences between desktop and mobile environments should be taken into account:

• •

  The physical context of use is no longer static and poses some constraint to user attention;

• •

  The social context is also dynamic: mobile communities member are tied up by common interest and contextual information, like location and time;

• •

  MoSoSo applications are designed not just for communication but for usage in everyday life situations: users are always socially connected.

In our vision the MoSoSo concept could also benefit “public” (e-Government) services leading to innovative, more effective mobile services, able to leverage on dynamic management of ad-hoc communities, context-awareness (i.e. time and location), user profile management and multimodal interaction.

One domain where such benefits will matter most will be emergencies and crisis management. In fact, the response to such situations typically implies the coordination of physical resources, (emergency services personnel, often belonging to different organizations, or even possibly volunteers) in hardly predictable environments in situations where ineffective operations can cause the loss of lives.

From an IT standpoint, implementing such a vision requires coordination of services and sharing of resources among different organizations that typically operate heterogeneous hardware and software environments. The Virtual Organizations paradigm address this issue: “VOs enable disparate groups of organizations and/or individuals to share resources in a controlled fashion, so that members may collaborate to achieve a shared goal” (Foster I., 2001). In those circumstances dynamism, flexibility and interoperability become essential requirements.

Interoperability, in particular, is a key issue in the e-Government domain due to the increasing demand for integrated services. We aim to integrate MoSoSo users into a typical Grid resource management model. To this end, we designed an experimental platform to support the development of multimodal MoSoSo application, allowing an easy integration of mobile community users into a Grid based VO.

OGSA (Open Grid Service Architecture (Foster, I., 2006), a refinement of the SOA concept, allows the interoperability of “resources”. In fact the OGSA specification allows each resource to be seen as a service with a standard interface. In the WS-Resource framework conceptual model, a Web service is a stateless entity that acts upon, provides access to, or manipulates a set of logical stateful resources (documents) based on the messages it sends and receives (WSRF, 2006) (Foster I, 2004).

Obviously, to evolve from SOA to OGSA, all architectural components must be extended to deal not only with services but also with resources. For example, as far as process execution is concerned, the workflow engine has to be able to compose both services and resources. Similarly a logical enhancement to the UDDI registry is required to store information about WS-Resources too.