Atelier Infrastructure for Ubiquitous Computing

Atelier Infrastructure for Ubiquitous Computing Antti Juustila, Toni Räisänen Department of Information Processing Science, University of Oulu 90014 UNIVERSITY OF OULU, Finland [email protected], [email protected] Abstract. Ubiquitous computing systems, running on distributed heterogeneous hardware and operating system platfoms, need a software infrastructure hiding the complexity of the underlying hardware, software and networking technologies form the components and applications. A software infrastructure for ubiquitous computing should enable software components and applications consisting of these components to communicate over different types of networks, using different types of protocols. We describe an infrastructure called Atelier Infrastructure for ubiquitous computing, aiming at supporting the application developers in building distributed ubiquitous applications in heterogeneous hardware, operating system and programming environments. The Atelier Infrastructure addresses the abstraction, programming language independence, extendability and configurability requirements for an ubicomputing infrastructure by a message based communication and a distributed micro kernel software architectural pattern. We suggest that future research should be directed towards specifying open, common standards to enhance the interoperability of components, services and applications in ubiquitous environments. Keywords. Ubiquitous computing, software infrastructure, distributed systems.

Introduction Development of ubiquitous computing applications and systems face many technical and social challenges (Banavar & Bernstein 2002, Bell & Dourish 2006, Kindberg & Fox 2002, Lyytinen & Yoo 2002, Schmidt et al. 2006, etc.).

Proceedings of the 30th Information Systems Research Seminar in Scandinavia IRIS 2007

1

Juustila, A., Räisänen, T.: Atelier Infrastructure for Ubiquitous Computing

Ubiquitous computing, being still in a very early stage of development and research, presents a vision where computers are embedded in our environment, providing contextual information services and helping in organizing and mediating social interaction. Mobility, large-scale services and infrastructure and the multiplicity of different services in terms of processed and transmitted data characterize ubiquitous computing (Lyytinen & Yoo 2001). Ubiquitous computing – implying mobility and pervasiveness of computing – requires a technological setting where computing power can be compressed into small devices and even to clothing, and also connectivity of these devices (Weiser 1993, Lyytinen & Yoo 2002). Integrating various heterogeneous computing devices, operating systems and software platforms seamlessly to minimize the complexities and coordinate the collaboration among devices and services requires a good software infrastructure (Nakajima 2003). There exists many implementations of these types of systems, based on different technologies, such CORBA (Vinoski 1997; Gaia system, see Román et al. 2002), Java, Jini and OSGi (Nakajima 2003); or message based MVC (Qiu 2005). On mobile devices, XML-RPC and RFID tags (Salminen & Riekki 2005) have been used in implementing the distribution of components on top of Symbian OS, as well as HAVi (Home Audio Video Interoperability), SOAP and UPnP (Nakajima & Satoh 2006). For additional examples of ubiquitous infrastructures, see e.g. Banavar & Bernstein (2002) and Nakajima (2003). Many technologies and standards address features that are needed in (development and use of) ubiquitous computing environments. An example of such is the device and service discovery features included in Jini as well as in Bluetooth™ (Edwards 2006). In this paper, we address mainly ubiquitous software infrastructures, not the underlying technological infrastructures. With technological infrastructures we mean existing and emerging technologies such as TCP/IP, Bluetooth™, Jini, SQL, XML, HTTP and other protocols build on HTTP, different operating systems, etc. which can be used in developing also ubiquitous infrastructures. With ubiquitous software infrastructures we mean a software platform (build on top of the aforementioned technological infrastructures) for building ubiquitous components, services and applications. The latter infrastructure should provide means for the upper level components, services and applications to be found, communicated with and used for some particular purpose in particular settings. Components and services should be configurable (Lyytinen & Yoo 2001) and by combining them to applications the needs of a particular situation should be satisfied. Since it is difficult to assume in beforehand the possible usage situations, these systems must be incrementally extensible (Nakajima 2003). We will discuss the requirements and challenges for such infrastructures and describe one attempt to achieve an infrastructure for ubiquitous computing, the Atelier Infrastructure, developed during the Atelier IST project


2


(http://atelier.k3.mah.se/home/). After this, we will discuss the limitations of software infrastructures for ubiquitous computing and propose an additional abstraction to the software infrastructures, based on standards and message based XML languages as a framework for ubiquitous systems.

Technological challenges in ubicomputing Ubiquitous computing systems (components, applications and/or environments) are inherently distributed and heterogeneous (Banavar & Bernstein 2002). Ubiquitous computing, aiming at making use of many different types of computers (and, effectively, computing services) available throughout the physical environment means that both the hardware and network architectures used are also heterogeneous. Especially moving devices have to adapt to the capabilities of the currently available networks, ranging from hi-speed wireless LAN connectivity to GSM data networks, or occasionally, to no connectivity whatsoever. Adaptation is also needed in supporting the user’s tasks in the changing environment. The users may need to change their goals either by external influence or by the changes in the immediate environment and the resources available there. The infrastructure must be capable of finding, adapting and delivering the necessary functionality to the user in the changing conditions. (Banavar & Bernstein 2002). In addition to adaptation, awareness of the environmental resources available and control of using the resources available are important elements of mobile computing in providing the necessary services to the users (March et al. 2000). Even though the issues of adaptation to heterogeneous content and devices have been addressed in mobile computing research, the issues of functional heterogeneity (which devices are capable of providing which kind of services and at what level of functionality) needs further research (Kindberg & Fox 2002). Physical constraints posed by the hardware again limit the resources the applications have available: battery power is limited, size of device limits the ways of interactions with the user (Siewiorek 2002), connection speed limits the type and amount of data that can be transferred. Furthermore, different devices contain different operating systems and application programming interfaces. For application development different languages and tools are needed. In order to make application development in ubiquitous environments easier, a software infrastructure, hiding the heterogeneous hardware, network and operating systems environments, is necessary. The following discusses some essential non-functional requirements for ubiquitous software infrastructures.


3


Hardware and operating system independency The scale of different devices in ubicomp systems range from small sensors and actuators, handheld devices and smart phones to backend systems comprising of large-scale servers and database systems. Ubiquitous computing applications would have to run on multiple incompatible operating systems, from embedded real time OS’s to smart phone and server OS’s, and naturally be able to communicate with each other. The concept of a system or an application in ubiquitous computing is different from the usual idea of an application running on a single computer, or even from the common client-server type of a system. Ubiquitous applications are themselves distributed over the network. The application user interface may be distributed so that a device can be used to input data or select commands, while the output is displayed on a remote display or on several mobile devices even far away. The application logic can be also spread over the network. Therefore, the application consists of several communicating components cooperating over different kinds of networks. The widely known Model-View-Controller (MVC) design pattern can be thought of being further distributed to D-MVC (Graham et al. 1996, Hansen 2005, Qiu 2005). Even further, the UI can be broken down to many individual but cooperating input and output components, implemented on different hardware and software platforms.

Network independency Communication happens over multiple types of networks, e.g. Bluetooth™, GSM/3G, WiFi, Ethernet and near field communications (NFC), e.g. using RFID technology. For ubiquitous computing applications, this means multiple protocols that should be supported to achieve the seamless functioning of the services and applications. The heterogeneous nature of the technologies cannot be handled without an infrastructure that hides the complexity of the underlying technologies. An infrastructure for ubiquitous computing should address the technological complexity by hiding the various communications protocols as well as the transport layer so that applications would not need to adjust to the current surrounding environment to be able to do what is expected. To some extent, of course, the applications need to be aware of their surroundings and resources available to be able to adjust the functionalities to the context at hand. Application areas are numerous. It is difficult to design an infrastructure that fits all needs. Special purpose infrastructures may be needed in specific situations to support specialised functionalities. This may hinder the support for more generic or totally different settings than to which the infrastructure was originally planned to support. For example, a system supporting the work of physicians and nurses in hospitals requires so different types of functionalities and hardware


4


requirements, that an infrastructure to support the learning process of designers cannot be fitted as-is to the former type of environment. There are different ways to address these challenges. One way to approach the problem is to build a platform or an operating system for ubiquitous computing. This kind of platform would resemble a virtual machine, since it would be necessary to be able to run it on existing operating systems. This virtual machine would act as an abstraction on top of the underlying operating system and network and additionally provide services for the ubicomp components. It would also need to either provide a programming interface for the developers, based on existing programming languages such as Java or C++, or provide a new one. Gaia (Román at al. 2002), building on CORBA and TAO (Schmidt et al. 1997), is an example of one such implementation.

Programming language independency Infrastructures such as Gaia require a hardware platform capable of running the underlying CORBA and TAO. However, in many cases, the devices that are used are small in size and in computing resources and cannot run these types of systems. There may be the problem that the device cannot even run the compiled code or that are no tools to compile the software for such devices. In some situations, the device cannot be programmed at all, leading to a situation where one must write an adapter component on some other attached device to be able to use the device in the system.

Extendibility and configurability Extendibility of the system to support new requirements and features is also important. Since all scenarios of usage cannot be taken into account when designing the supportive infrastructure, one should design the system to be extendable to new features (Kindberg & Fox 2002, Nakajima 2003). Otherwise, the platform is too rigid to be used in heterogeneous environments – not only technologically heterogeneous, but also from the user requirements perspective. Another requirement for ubiquitous systems is the question of configurability: to what extend the devices in an environment can be dynamically configured to work in different contexts. For example, a remote controller device can be used to control the presentation of media, but it could also be used to navigate other data elements and manipulate them. In research settings, this is more or less easy, requiring the intervention of a technical person, but in real life settings users should be able to change the setting and enable using the devices in the environment to be used in different contexts (Binder et al. 2004). The question is, to what extent we can proactively design the functionality of the system, or do we need tailoring for a specific purpose (Lyytinen & Yoo 2002), or is it even possible for the users and/or the system themselves to configure for a specific situation.


5


For example, users themselves could decide on which display to show particular media in a particular situation and be able to flexibly change this (Salminen & Riekki 2005).

Information formats, content The diversity and heterogeneousness of content and information formats is a significant factor in all distributed systems (March et al. 2000). There are ontologies and standards for application specific, narrow areas based on XML, for example RDF. Usually these standards are for textual data and presenting numeric content, although some XML based standards related to multimedia exist (e.g. SMIL, for synchronized multimedia; see http://www.w3.org/AudioVideo/). As ubiquitous applications and components are distributed across hardware, running on top of and communicating across heterogeneous hardware and operating systems, it is important to ensure that the content is usable in different devices, ranging from sensors and mobile phones to PDAs and other devices.

Summary Ubicomp components and applications should be hardware, operating system and programming language independent. Furthermore, ubiquitous applications are heavily distributed, relying on input and output devices in the environment, on services residing either on mobile devices, in the surrounding immediate environment or in the background systems usually accessed through different networks. The extendibility and configurability of the environments and the support of this by the underlying software infrastructure is essential. These are challenging requirements and there are many ways to address this problem. One can use virtual machines that are capable of running applications in many different devices. Java virtual machine is an option, with additional support by a layer of software with supporting ubiquitous computing features, such as device and service discovery. Some ubiquitous infrastructures act themselves as a virtual machine, a layer on top of an operating system. Some of these, e.g. Gaia, even work on top of many operating systems. Different protocols and standards, such as XML, can be used in implementing the software infrastructures. The Atelier Infrastructure is one attempt to respond to the challenge. In the following, we will describe the infrastructure in detail.

The Atelier Infrastructure The Atelier Infrastructure is a software platform where the main goal is to ease the development of applications in ubiquitous computing so that the developer of the application need not to take account the fact that the application is running in


6


a heterogeneous and distributed environment. The Atelier infrastructure strives to hardware, operating system and programming language independence by a messaging based solution on top of a Java Virtual Machine (JVM). Components of the Atelier Infrastructure, forming the building blocks of a ubiquitous system, communicate over standard protocols using an XML based messaging language. The protocol architecture is extensible, thus giving room to multiple, even simultaneous use of different protocols, such as TCP/IP or JAXTA, for example. Since components communicate asynchronously using XML, the implementation language of the component is of no relevance. The developers can choose whichever programming language and tool appropriate for a certain component in the application, even though most of the components in current and past implementations have been built on top of Java and Personal Java. The most obvious benefit of using Java is the availability of the already implemented utilities, message handling code, etc., though implementations using e.g. C++ are as feasible. As a prototype, the current implementation does not address issues related to e.g. security or quality of service, assuming secure, friendly networks with sufficient resources. These and other issues important in real life situations should be addressed in future development.

The Atelier project The Atelier Infrastructure was originally designed and implemented during 20012004 in the EU funded Atelier project, a part of the Information Society Technologies (IST) program. The project was also closely related to the Disappearing Computer call. The users in the project were students of architecture and interaction design, already passed the first 2-3 years of their studies. The aim of the project was to contribute to inspirational learning environments, which are grounded in an understanding of creative practices within design, architecture and art. The project started out from interactions between people and material artefacts in physical places and asked how we should enhance such an environment with digital technologies to turn it into a resource for inspiration and creative learning by an integrated design of learning materials, interactive technologies and architectural space. One part of the project was to design and build a software infrastructure to support developers in building distributed ubicomp tools to support the students in their design work. The technical goals of the project were, among others to use …Large interactive screens, mobile phones, personal digital assistants and diverse information appliances allow us to design new augmented, flexible, and plastic and situation aware workplaces. The ATELIER project … aims to develop and integrate these new technologies to create an augmented place for what we call ‘inspirational learning’ and, by doing so, to


7


increase our understanding of how to design systems that support more flexible and creative learning. The inspirational learning environments that we envision are dedicated physical places where people in collaboration can establish and explore a particular thematic learning space by activating, manipulating, combining and assembling configurations of representational objects of mixed media origin. Emphasis will be given particularly to learning spaces that facilitate and exploit dynamic interactions between people and objects. The environments will be open for the ad hoc introduction of new participants and new objects with associated portfolios of qualities and resources.

To support the different user scenarios of the project, the platform was designed to be extendable. As usual in a research project, the actual functional requirements were not available or were quite vague in the beginning of the project – a context of ubiquitous systems in general (Nakajima 2003). Thus the extendibility is in the core of the platform and it is implemented by following the Micro Kernel software architectural pattern (Buschmann et al. 1996), with extensions to support the distribution requirement. Micro Kernel architecture can be seen as a special type of a Layered software architecture (see Figure 1). In this architecture, the Kernel corresponds to the device service registry of Service Oriented Device Architecture (SODA) proposed by de Deugd et al. (2006, p. 96).

Figure 1: Architecture of the Atelier infrastructure. A key requirement for the system was the support for dynamic configuration of the system. As different users and devices enter and exit the design space and different applications were used with the various hardware elements, it was important that the devices could be used for different purposes with different applications. For example, in one situation a device is used to select media from a hypermedia database1 while in other situation it is used as a control device,

1

Hypermedia database supports storing of media (images, videos) which can be hyperlinked. Also metadata on the media can be stored (e.g. location, origin, descriptions and so forth).


8


enabling the user to select which display should present the output from specific application logic.

Design principles of the Atelier Infrastructure The key design principles of the Atelier Infrastructure can be summarized as follows: • It should provide support design and implementation of distributed applications. • The infrastructure should ease the programming of applications and components in distributed environments. • It should provide the means to enable the independence of the components and applications from the underlying technologies. • It should be extendable with new services and protocols. • It must be configurable to provide support dynamic interactions between people and objects. These key requirements were derived in the beginning of the project from the overall goals of the project, reviewing the current research on ubiquitous software infrastructures and also by looking at the various existing implementations for ubiquitous computing (e.g. Gaia). Key issues, such as flexibility, extendibility, distribution, etc. were identified. The design solutions and the implementation of the Atelier Infrastructure, based on these key issues, are discussed below.

Distributed MVC and microkernel The platform was designed to support the division of an application to a distributed application where the different parts of the application such as view, model, and control in the Model-View-Controller (MVC) pattern communicate through a network by sending XML based messages. This distributed MVC

Figure 2: Registration message to Kernel (simplified example).


9


model enables the change of the configuration of the application, i.e. change and move input or output devices from other type device to another without restarting the “application”. Before a software component can send or receive messages to the kernel and/or other components or services, it needs to register itself to the Kernel. This is done by sending a special registration message (Figure 2), describing the type of the component and the message categories and types the component both publishes (sends to other components) and consumes (listens and reacts to when messages are passed to the component). The design follows the Publish/Subscribe paradigm for interaction, where components publish data and events as others consume them, supporting effectively spontaneous interaction inside the environment (Kindberg & Fox 2002, p 74). To simplify message passing, an open message hierarchy was designed. Each message has a category, describing a larger group of message categories, such as registration messages, events, input data messages, output data messages, application specific messages, etc. Message types, describing in more detail what type of a message is, enable a finer distinction of messages inside the categories. These categories and types then are used by components in specifying of which kind of messages they register to receive, and which kinds of messages the component produces. A component can then query the Kernel if there is a component, which can consume and/or produce certain types of messages. This enhances the awareness of components of the surrounding services and other components. Each and every Atelier component must respond to one specified category of messages – the HelloWorld message, which can be used to demonstrate the functionality of the system (the Hello world application for ubiquitous computing) as well as test that all components are connected and functioning. If the component’s metainformation (provided with the registration message) would contain location information, a component to cooperate with can also be searched and selected on the basis of where the component resides. To support the distributed MVC model a variation of a micro kernel pattern is used which we call distributed microkernel pattern. In the distributed microkernel architecture the Adapter (encapsulating the intercomponent communication, corresponding to the bus adapter of SODA; see de Deugd et al. 2006), Kernel and external services are separated from each other with the Adapter proxies that hide and implement the network connection between these parts. The role of the Adapter is to abstract the communication links between the system elements, taking care of initiation of the connection as well as the data transfer and necessary manipulation of the messages before sending and/or receiving. Adapter also hides the use of different protocols from the components using the Adapter.


10


Ease of programming The platform makes easier to implement distributed applications by hiding the configuration, initialization, and communications over the network under an Application Programming Interface (API). The API consists of utility classes to manage the messages without the knowledge of XML (Figure 3), an active object handling the sending and receiving messages (the Adapter), and an event interface to be called when a receiving a message to be handled. The example code creates a notification message to other interested components that a new multimedia item has been added to the Hypermedia database, in the Media entrance hyperdocument, and includes the new media ID to the notification message. The API is an asynchronous event based API, where sending of a message returns immediately and the reply is notified via an event from the active object to the program. The programmer registers the component to receive events when a certain type of message (or a message directly addressed to that component) arrives to the component. As the message arrives, the event is handled as an ordinary event similarly to event based GUI programming. The application programmer does not need to generate the XML message from the scratch but there are again utility classes and methods, which marshals and demarshals the events as XML messages and converts XML messages to events. public void newHyperNodeAdded(HyperNode newNode) { AtelierXMLMessage msg = new AtelierXMLMessage("application/entrance", "newitemadded"); msg.setBodyContentType("text/xml"); XMLElement content = XMLMessageFactory.getInstance().createXMLElement("node"); Integer idOfNode = newNode.getID(); content.putAttribute("hypernodeid", idOfNode.toString()); msg.setBodyContent(content.toString()); adapter.sendMessage(msg); }

Figure 3: Creating a XML message with Infrastructure API. Future enhancements include a new client API where the current client interface class is split to two parts: a client interface, which is able to communicate with adapter and a listener interface to able to register a handler for different kinds of messages. These changes allow multiple components to use the same adapter for communication, ease the message subscription, ease the application start-up, and allow lazy initialization of components. This allows flexibility of the subscriptions and is more intuitive to the programmer.


11


Independency from underlying technologies To be as general platform as possible the Atelier Infrastructure was designed to use messaging as base of communication between components. The architecture can be classified as a hybrid P2P architecture (Wilson 2002) where one node (the Kernel) is a central node to hold the catalogue of addresses of other nodes (directory of services). The other role of the central node was to filter and transform the messages and subsequently route the messages to the nodes that had requested to handle the type of messages. It is also possible to create direct routes between two components to achieve greater quality of service of the communication needed i.e. transporting videos or other multimedia. Even though the current API is implemented with Java, it is possible to create components with any programming language and to any technical platform, as long as connecting through TCP/IP is possible.

Extendibility The extendibility of the platform rises from three factors: the extendibility of the micro kernel architecture, the extendibility of message schemas, and the support of different protocols. To extend the platform a programmer could implement either new internal services (extensions to the Kernel, according to the Micro kernel architecture) used inside the Kernel and/or external services, which can be used from other external services and/or components and applications. Each internal service has two parts: a filter that routes the messages to the right service and the service itself. The internal services are run inside the same virtual machine as the kernel in their own threads. In the current implementation, there are three internal services: filter pipeline, name server and id factory. In future, there are plans to implement an internal service to add, configuration and remove other internal services, so that internal services could be added to the kernel at the runtime without restarting the Kernel. External services are run in their own virtual machine and/or physical device. From the Kernel’s viewpoint, external services are just plain components of the system, providing general services to other components. The second way to extend the platform is by the support of message categories and types. The header part of a message describes the category and type of the message, described above. This information is used as routing information. The categorization is the base of the publish/subscribe messaging. In addition to the categorization the header can include other meta-information, like contextual (e.g. GPS) information, for example. By defining new message categories and types, in addition to the payload of the message, it is possible to define new “languages” and data contents for specific purposes.


12


Thirdly, each Adapter can use a different protocol for each channel of communication Adapter has opened. The protocol could even be changed during runtime via configuration messages. The message is currently transported via vanilla TCP/IP sockets as a stream of UTF-8 characters. As a proof of concept, a JXTA (Wilson 2002) transport protocol has also been implemented. In addition, another protocol implementation is currently planned, which sends SAX or StAX events instead of sending the message as whole and then parsing the message.

Configurability The configurability of the system is based on two factors: the publish/subscribe type of messaging and message filtering and transformation. When a component subscribes to the Kernel, it registers the types of messages it produces and handles. Other metainformation items that components could use as registration information are e.g. screen resolution, display size, location of the device, etc. This further enhances the adaptation of the system elements to different types of hardware. In the future, the information is used to advertise the components in JXTA and/or ZeroConf/Bonjour. To minimize the traffic, each node registers the type of messages it is able to handle. The routing component uses the registration information to route the message to the receivers. To bypass this routing and message multiplexing the sender could set the receiver of the message. This of course breaks the flexibility of the system and the use of explicit receivers is strongly discouraged. Usually the receiver is set or changed by filters to support the runtime configuration of application composition. To meet the requirement for configurability during runtime, the central node has an internal service to support the manipulation of messages before routing to receiver(s). This filtering and transformation support enables, for example, changing the preconfigured output and/or input device as needed. Each filter is prioritized, which determines in which order the filters transform the message. Each transformation could either stop the message routing, skip other filters and put the message directly to the outbox to be send to other components via the router, set the message back to inbox to be filtered from the start or forward the message to next filter in the change. The filter engine adds the IDs of the filters that have changed the message into the message. This information can be used by the message recipients to analyse the message, or in analysing the behaviour of the system for research purposes.

Example components and applications In the Atelier project some prototypes utilizing the infrastructure were developed. A barcode reader and a TV remote controller were both used as input devices in the environment, acting as physical handles to digital media (Binder et al. 2004,


13


Loregian et al. 2006). As media (images, videos) were stored in the Hypermedia database (developed also by Oulu team in the Atelier project), the media file was assigned an ID. This ID can be printed out with a small thumbnail of the image. As users then present their designs, they can use the barcode reader and the printouts to flexibly include digital media of their presentations of the design by reading barcodes attached to physical models. Barcodes were also used as commands to handle e.g. playing of media. Certain IDs were reserved to act as commands (e.g. “play” or “stop”). Another usage of barcodes was to use them to configure the actual technical environment. Each device and application was assigned an ID, and using a barcode printout of the system components it was possible for the users to configure a “routing table”. This routing table then effectively configured the system (by using the Kernel’s filtering system) to pass the input messages from a specific input device to a software component, and the output from a software component then was also routed to an output component, usually a display. The same functionality could be achieved using RFID tag readers and writers by inserting the id of the media file into a writable RFID tag. In both of these cases, a component was programmed into a computer attached to these devices, since the devices were not programmable. Other similar case in the project was to use an infrared television remote controller as a navigation device. In addition to these component types of elements in the Atelier infrastructure, we also implemented External services, which provide extensions to the basic Kernel of the system. One such service is the eMailEntrance. This service has no user interface, as it is meant to be used by other components to enhance their functionality. The service helps the users to import media into the hypermedia database by simply sending email or MMS messages. The service reads periodically an email account, extracts media attachments from the message, metadata from the message headers and content, and stores these into the hypermedia database. The service also sends a broadcast message to all components registered to receive certain types of notification messages to alert the components of the new content added to the database (message creation illustrated in Figure 3).

Development plans In the future, the central node (Kernel) is to be split into the proxies so that every node can act as a router for components that it knows about. Therefore the need of an always-available Kernel is going to be removed. This effectively transforms the infrastructure to the direction of the Pervasive server architecture proposed by Nakajima (2003) and the “infrastructure without infrastructure” (Edwards 2006) where there necessarily is not any fixed system structure (the central Kernel). In


14


this situation the Kernel can optionally be used as a directory server to minimize device and service discovery overhead. We also aim to further move to support existing standards in our implementation by adhering to the OMG standard on Super Distributed Object API (Sameshima et al. 2001, Kawakami et al. 2004 & Yamamoto et al. 2004). Also we aim to add support for mobile devices by implementing the relevant parts of the system in selected mobile platforms. The Pervasive server architecture proposed by Nakajima (2003) shares many of the development ideas we have discovered to be very useful in developing infrastructures for ubicomp systems. Nakajima, as we, propose a XML based communication between components, using simple standards and protocols for intercomponent communication, as well as discusses how components could be assembled to appliances (or applications) from separate components dynamically.

Conclusions The infrastructures supporting ubiquitous computing should adhere to standards and support multiple protocols. An underlying, specific technical implementation should not really be relevant in developing ubiquitous applications and services. Even though we strived to use standards and aim at hardware and OS, network (protocol) independency, programming language independency and flexibility towards information formats by using XML, usually our and other existing infrastructures are still incompatible constructs among others. In order to really reach towards ubiquitous environments, there is a need for common standards for infrastructures, applications and appliances. Research should aim to define higher levels of abstractions for ubicomputing environments. These abstractions should be based on open standards related to device and service discovery and use well known specified communication protocols. Standards and technologies such as OSGi, HTTP, UPnP, Bonjour/ZeroConf, Jini, Bluetooth, RDF, etc. should be taken as the basic elements of ubiquitous building blocks (see e.g. Nakajima 2003, Kindberg & Fox 2002, de Deugd et al. 2006, Schmidt et al. 2006, Raatikainen et al. 2002). Ubicomp services and components should use the selected standards and building blocks in implementation to ensure interoperability between implementations. Commonly agreed upon XML based languages (again built on top of the already existing exploitable standards) should be defined, which can then be used in device and service discovery and selection and exchanging both content and evoking actions in the environment (Kindberg & Fox 2002). Instead of using proprietary message schemas in Atelier Infrastructure, we should be using open standard message schemas, thus improving the interoperability of the Atelier Infrastructure with other components, applications and infrastructures adhering to the same ubiquitous data standards (ibid). Specifying the message schemas should


15


start from the most basic features of any ubiquitous environment. For example, we specified a XML based language to be used in remotely controlling a Pac Man game and also to control a media presentation, to be used with a TV infrared remote controller and a barcode reader. Both “languages of interaction” should be defined as a standard language to be usable in a “real” (to date non-existent) ubiquitous environment. There is also the need to specify ontologies for describing objects (both physical and computational) in a standard way. In this respect our conclusions are similar to Nakajima’s (2003). Also the environment should include a set of standard ways (protocols, ways to do device and service discovery, etc.) to find both the controllable services or components and similarly, the controllers.

Summary Software infrastructures are necessary for building interoperable platforms for ubiquitous applications and application components. Such infrastructures should provide support design and implementation of distributed applications and ease the programming of applications and components in distributed environments. They should provide the means to enable the independence of the components and applications from the underlying technologies such as operating systems and hardware. To support various types of application areas, the platforms should be extendable with new services and protocols. Also, the configuration of the environments to provide support dynamic interactions between people and objects is essential. There are several approaches to develop software infrastructures for ubiquitous systems. The Atelier infrastructure is based on message and event based distributed architecture, where a micro kernel acts as a router and a service repository. The communication of components and services within the infrastructure is based on XML. Using XML as the basis for the language further supports the extendibility of the system. By defining new “languages” for component interaction one can develop new functionality in the system. Implementation of components producing and consuming these messages is therefore programming language, operating system and hardware independent. The Atelier Infrastructure is still ongoing development. Issues such as security, quality of service and performance are still to be addressed. Also, many features build in to the Infrastructure still miss the (ubiquitous) user interfaces that empower the users to really utilize the features of the system. These issues will be addressed in our future work. Most importantly, we suggest that defining a higher abstraction layer for ubiquitous infrastructures, based on open standards and consisting of protocols, ontologies and XML based languages, should be explored, as also suggested by others. Even though these infrastructures would remain messy and complicated,


16


requiring continuous assembly work as suggested by Bell and Dourish (2006), developing ubiquitous environments could be much easier by agreeing on at least some common technologies to build them on.

Acknowledgments This work has been supported by the EU funded Atelier and IPCity projects and the Academy of Finland funded Studio’n’Site project. This work is also part of the INFOTECH/INTERACT group activities in the University of Oulu, Finland. The authors were the main architects of the Atelier Infrastructure, Toni Räisänen being the main designer and implementor. We also thank the anonymous IRIS reviewers of their insightful comments.

References Banavar, G., Bernstein, A. (2002) Software infrastructure and design challenges for ubiquitous computing applications. Communications of the ACM. Volume 45, Issue 12 (December 2002). Pp 92 – 96. ACM Press New York, NY, USA. ISSN:0001-0782. Bell, G. and Dourish, P. (2006). Yesterday’s tomorrows: notes on ubiquitous computing’s dominant vision. Personal Ubiquitous computing. 11/2007. Pp 133-145. Binder, T., De Michelis, G., Gervautz, M., Jacucci, G., Matkovic, K., Psik, T., and Wagner, I. 2004. Supporting configurability in a mixed-media environment for design students. Personal Ubiquitous Comput. 8, 5 (Sep. 2004), 310-325. http://dx.doi.org/10.1007/s00779004-0294-7. Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M. (1996). Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. Wiley. ISBN: 978-0471958697. de Deugd, S., Carroll, R., Kelly, K. E., Millet, B. and Ricker, J (2006). SODA: Service-Oriented Device Architecture. Pervasive computing. July-September 2006. Edwards, W. K. (2006). Discovery systems in ubiquitous computing. Pervasive computing. AprilJune 2006. Graham, T., T. Urnes, R. Najabi (1996). Efficient distributed implementation of semi-replicated synchronous groupware, ACM UIST'96, Seattle, WA, 1-10, Nov. 1996. http://citeseer.ist.psu.edu/graham96efficient.html. Hansen, S. S. (2005). Composite Device Using a Distributed MVC Architecture. Center for Pervasive Computing. University of Aarhus. 3 May 2005. http://www.daimi.au.dk/fileadmin/images/common/secretaries/HansenSS.pdf Kawakami, J.; Sameshima, S.; Kawano, K.; Suzuki, J.; Suda, T.; Steglich, S.; Shin, S. (2004). SDO model and its standardization activity. Applications and the Internet Workshops, 2004. SAINT 2004 Workshops. 2004 International Symposium on, Vol., Iss., 26-30 Jan. 2004. Pages: 342- 347. Kindberg, T. Fox, A. (2002). System software for ubiquitous computing. IEEE Pervasive Computing,. Volume: 1, Issue: 1. Pp: 70- 81. ISSN: 1536-1268. Loregian, M.; Matkovic, K.; Psik, T. (2006). Seamless browsing of visual contents in shared learning environments. Pervasive Computing and Communications Workshops, 2006. Proceedings of the Fourth Annual IEEE International Conference on Pervasive Computing and Communications Workshops, P. 235. March 2006. ISBN:0-7695-2520-2.


17


Lyytinen, K., Yoo, Y. (2001). The next Wave of Nomadic Computing: A Research Agenda for Information Systems Research. Sprouts: Working Papers on Information Environments, Systems and Organizations. Vol 1, No 1 (Summer) pp. 1-20. http://sprouts.case.edu/2001/010301.pdf. Lyytinen, K., Yoo, Y (2002). Issues and Challenges in Ubiquitous Computing. Communications of the ACM, Vol 45, No 12. December 2002. March, S., Hevner, A., Ram, S. (2000). Research Commentary: An Agenda for Information Technology Research in Heterogenous and Distributed Environments. Information Systems Research,. Vol 11, No 4. Pp. 327-341. December 2000. Nakajima, T. (2003). Pervasive Servers: A framework for creating a society of appliances. Personal Ubiquitous Computing 7. pp. 182-188. 2003. Nakajima, T., Satoh, I. (2006). A software infrastructure for supporting spontaneous and personalized interaction in home computing environments. Personal ubiquitous computing 10/2006. Pp. 379-391. 2006. Raatikainen, K., Christensen, H. B., Nakajima, T. (2002). Application Requirements for Middleware for Mobile and Pervasive Systems, Mobile Computing and Communications Review, Volume 1, number 2. Pp: 16 – 24. 2002. Qiu, Xiaohong (2005).. Message-based MVC Architecture for Distributed and Desktop Applications. PhD Thesis. Graduate School of Syracuse University. May 2005. http://grids.ucs.indiana.edu/~xqiu/complete_thesis.pdf. Román, M., Hess, C., Cerqueira, R., Ranganathan, A., Campbell, R. H., and Nahrstedt, K. 2002. Gaia: a middleware platform for active spaces. SIGMOBILE Mob. Comput. Commun. Rev. 6, 4 (Oct. 2002), 65-67. DOI= http://doi.acm.org/10.1145/643550.643558. Salminen T & Riekki J (2005). Lightweight middleware architecture for mobile phones. Proc. 2005 International Conference on Pervasive Systems and Computing, Las Vegas, NE, 147153. Sameshima, S.; Kawano, K.; Funabashi, M. (2001) A trend to super distributed system and standardization activity in OMG. Applications and the Internet Workshops, 2001. Proceedings. 2001 Symposium on, Vol., Iss., 2001 Pages:5-8. Schmidt, A., Spiekermann, S., Gersham, A., and Michahelles, F. (2006). Real-world challenges of pervasive computing. Pervasive computing. July-September 2006. Schmidt, D. C. Levine, D. L. and S. Mungee (1997). The design of the TAO real-time object request broker. Computer Communications Journal, Summer 1997. http://citeseer.ist.psu.edu/article/schmidt97design.html. Siewiorek, D. (2002). New Frontiers of Application Design. Communications of the ACM, Vol 45, No 12. December 2002. Vinoski, S. (1997). CORBA: Integrating Diverse Applications Within Distributed Heterogeneous Environments. IEEE Communications Magazine, vol. 14, no. 2, February 1997. http://citeseer.ist.psu.edu/vinoski97corba.html. Yamamoto, H.; Sameshima, S.; Kawano, K. (2004). Service reconfiguration using super distributed objects (SDO) in context-aware service systems. Software Technologies for Future Embedded and Ubiquitous Systems, 2004. Proceedings. Second IEEE Workshop on, Vol., Iss., 11-12 May 2004. Pages: 163- 165. Weiser, M. (1993). Hot topics-ubiquitous computing. Computer. Volume: 26, Issue: 10. Pp. 7172. Wilson, B. J. (2002). JXTA. New Riders Publishing; 1st edition, June 15, 2002.. ISBN: 9780735712348.


18