The use of electronic services is spreading more and more to an increasingly broader group of users, and there is a growing need for support for continuous interaction with multiple services, via different types of devices, and from all sorts of places and locations. Further more, it is desirable that this is done in a way that assures the user control over personal information that services gather and maintain. The user should also be able to control what services do and whether or not, and how, they collaborate with each other.
sView is an electronic service environment with heavy focus on the individual user. It enables a user to collect, store, and run electronic services, locally, or in a distributed fashion. The whole purpose of sView is to serve as a common area for the services to cooperate amongst themselves and to provide a unified access method to the services for the user. To a developer of services, the sView platform is characterized by openness, modularity, security, and a high degree of flexibility. To a user of the platform, it is accessible in many ways and available continuously.
With the sView platform in the FEEL project, the project partners developing the base software platform were able to deploy the FEEL intrusiveness management system in a prototype and run two user studies on the complete system. Using sView it has been easy to construct components for various technologies that represent a common type, for example, user interface components all follow a common specification for how they should function within sView and how they should supply their service to other services in the briefcase. This means that it is easy to introduce a new type of interface capability by constructing a component (service) for the new type of functionality that adheres to the common formats.
Thanks to the modular design of sView it was easy to introduce several different communication channels that were to be intrusiveness controlled.
The demands on sView represent current research topics such as privacy in the context of electronic service usage, service collaboration, and ubiquitous user interface design. The sView system has been designed as a solution to some of these research topics, and to cater for further research on others. The system assumes a client/server model, but instead of having a uniform client without service specific functionality for access to all servers (as in the case with the World Wide Web), access to the servers is channeled through a virtual service briefcase. The briefcase in turn, supports access from many different types of devices and user interfaces. It is also private to an individual user, and it can store service components containing both service logic and data from service providers. This allows the service provider to split the services in two parts. One part provides commonly used functionality and user specific data that executes and is stored within the virtual briefcase. The other part provides network-based functionality and data that is common between all users. Finally, the service briefcase is mobile and it can follow its user from host to host. This allows local and partially network independent access to the service components in the briefcase.
At a high level, the sView system consists of two parts. The core sView specification constitutes an API that defines the basics of service components and personal service environment handling. It specifies service components, a runtime environment for service components, a data structure for persistent and mobile images of service environments (service briefcases), and a server for handling service briefcases. The specification has been implemented as a set of Java packages (which contains mostly interfaces and a few classes). Implementing these APIs and adhering to the design guidelines that accompany the APIs, assures compatibility between sView services and service infrastructure of different origin. The sView reference implementation provides developers with a development and runtime environment for service components as well as a sample implementation of a sView server.