Application Requirements for Middleware for ... - Semantic Scholar

Application Requirements for Middleware for Mobile and Pervasive Systems Kimmo Raatikainena Henrik Bærbak Christensenb Tatsuo Nakajimac [email protected] [email protected] [email protected] [email protected] a Software Technology Laboratory, Nokia Research Center and Department of Computer Science, University of Helsinki, Finland b Center for Pervasive Computing, University of Aarhus, Denmark c Department of Information and Computer Science, Waseda University, Japan In this paper, we examine the requirements for future middleware to support mobile and pervasive applications and identify key research areas. We illustrate the research areas with requirements identified in two specific research projects concerning pervasive healthcare and home entertainment.

I. Introduction This decade will see the merger of telecommunications and IT worlds. The trends are already there; see, for example, the 3GPP specifications [1]. The current trend in developing forthcoming telecommunication networks is to utilize Internet protocols. An immediate implication is that IP is the network layer protocol (layer 3 in the ISO OSI model) and that the addresses are IP addresses. However, this is not sufficient. Other solutions—both above and below the IP protocol—are also needed to meet the requirements for the next generations of mobile networks. Issues under study in the Internet community and in various standardization bodies, forums and consortia include mobility, Quality-of-Service, security, management of networks and services, discovery, ad-hoc networking and dynamic configuration, and geospatial location. Another significant trend is the requirement of everfaster service development and deployment. An immediate implication is the introduction of various service and application frameworks and platforms. Middleware is a commonly proposed solution. It is a widely used term to denote a set of generic services above the operating system. Although the term is popular, there is no consensus of a definition. However, a good summary can be found in the IETF RFC2768 [2]. Typical middleware services include directory, trading and brokerage services for discovery transactions, persistent repositories, and different transparencies such as location transparency and failure transparency. Examples of middleware include Common Object Request Broker Architecture (CORBA) [7], Java 2 Enterprise [11] and Micro 16

Editions [12] (J2EE and J2ME), Distributed Common Object Model (DCOM) [9], and Wireless Application Environment (WAE) [30]. Characteristically, the competing middleware specifications provide many similar but slightly different services. In order to overcome the problems due to different specifications, the Parlay Group [25] has specified a set of UML models and corresponding APIs that can be implemented in CORBA, Java and DCOM environments. The recently established Open Mobile Alliance (OMA) [23] targets standardized open interfaces for generic services supporting mobile computing. In this paper we present a research agenda for future software infrastructure for mobile and pervasive systems. We examine two application areas: pervasive healthcare and home entertainment. We outline a practical roadmap to the next generation adaptive middleware that might enable our vision. However, before discussing the research agenda, we present an application architecture model that depicts our vision of future applications.

II.

Vision

During the past ten years several vision papers have been published including [33, 31, 13, 27]. Recently the European Commission has published scenarios for ambient intelligence in 2010 [8]. These scenarios are further elaborated in the Book of Visions 2001 by the Wireless World Research Forum [32]. When these visions are summarized, we can say that future applications need to be context-aware, personalized, and adaptive. In order to meet the requirement of ever-faster development and deployment of context-aware, person-

Mobile Computing and Communications Review, Volume 6, Number 4

alized, and adaptive services, various software architectures have been proposed: Sahara [14] and MITA [17], to name two examples. Such architectures typically identify an ”execution support layer” that encapsulates the functions of middleware for future applications. Such an execution support layer should support fast service development and deployment. It should make it easy to divide the application logic into co-operating parts, to distribute and configure these components as well as to redistribute and reconfigure them. Additional requirements for future mobile applications include adaptability to changes in the execution and communication capabilities, efficient use of available communication resources, dynamic configuration of end-user systems as well as robustness, high availability and stringent fault-tolerance. The requirements for data accessed by these applications are quite similar. The execution environment should provide consistent, efficiently accessible, reliable and highly available information base. This implies a distributed and replicated worldwide “file system” that also supports intelligent synchronization of data after disconnections.

III.

Research Areas

In this section we identify the key research areas in our research agenda for future software systems enabling seamless service provisioning in heterogeneous, dynamically varying computing and communication environments. The areas are not orthogonal; same or similar research items and issues appear in more than one research area. We have divided the research space into four key research areas. The areas are 1) Dynamic Reconfigurable End-User Systems, 2) Reconfigurable Applications, 3) Environment Monitoring, and 4) Mobile Distributed Information Base. Alternative but compliant divisions can be found, for example, in [33, 31, 13, 27].

III.A.

Dynamic Reconfigurable User Systems

End-

The end-user devices of today are primarily integrated units like PDAs, laptops, and mobile phones. However, the situation will change in the future. The successor of the current mobile phone, or at least the successor of its successor, will be quite different. It will not disappear or lose its importance, but its role will be very different. This “FuturePhone” will be the core of the personal computing and communication system.

The FuturePhone probes its surroundings looking for suitable peripheral devices such as displays, input devices, processors, and fast access memories and access points to communication channels. It dynamically builds up the most appropriate end-user system that can be autoconfigured. The set of rules for how the appropriateness of different configurations is evaluated is far from trivial. In addition, we must remember that the FuturePhone must be able to remain operational even if it cannot find any suitable peripherals. Moreover, the FuturePhone must be able to establish different kinds of adhoc networks that are simultaneously operational. In the area of dynamic configuration we have a large space of research items. On the conceptual level there are research issues related to profiles, various kinds of context also including the social context, roles and trust. On the technical level we must solve the problems related to authentication, authorization, and delegation.

III.B.

Reconfigurable Applications

Situations in which a user moves with her end-device and uses information services are challenging. Moreover, the nomadic user of tomorrow will not appreciate a static binding between her and an access device; not even in the case of multi-mode access devices that can handle several access technologies including wireless LAN, short-range radio, and packet radio. It must be possible to move a service session (or one end-point of a service session) from one device to another. In these situations the partitioning of applications and the placement of different co-operating parts is a research challenge. The support system of a nomadic user must distribute, in an appropriate way, the parts among the end-user system, network elements and application servers. In addition, when the execution environment changes in an essential and persistent way, it may be beneficial to redistribute the co-operating parts. The redistribution or relocation as such is technically quite straightforward but not trivial. On the contrary, the set of rules that the detection of essential and persistent changes is based on is a challenging research issue. Another research issue of fundamental importance in distribution is fault-tolerance. Replication, which is a commonly used method to achieve fault-tolerance in traditional distributed systems, is not sufficient by itself. The baseline applications must remain operational, at least in a tolerable manner, even if some services of the underlying execution environment cannot


17

be utilized. This is a requirement for research in modularization of applications and adaptability.

III.C. Environment Monitoring Adaptability is one of the fundamental requirements in nomadic computing. The basic principle of adaptability is simple. When the circumstances change, then the behavior of an application changes according to the desires of a user—or more precisely according to principles ascribed to her. Environment monitoring is one of the fundamental enablers of adaptive applications. The three primary issues are discovery (which equipment are available), service location (which services are available), and available capabilities (computing power, various storage capabilities, available capacity on communication paths).

our process of envisioning, designing and testing proposals for future support by pervasive computing technology. A main focus has been to provide easy access to electronic patient record (EPR) systems. Healthcare is an ideal test-bed for pervasive middleware technologies. First, healthcare at modern hospitals is characterized by mobility taken to the extreme—nurses and doctors are on the move almost constantly. Second, few clinicians even have a desk or a place to put a computer. Third, interruptions are frequent during everyday tasks. Thus, the activities and tasks in healthcare are well suited for being supported by mobile and pervasive solutions. Before we describe requirements in more detail, we will outline a future scenario that illustrates how we envision a pervasive computing infrastructure can aid clinicians in their work.

IV.A. III.D.

Mobile Distributed Information Base

File and information synchronization between different devices is already available but in quite primitive forms. A single information base for a user—possibly different views for her different roles—and for multiple user groups is a fundamental enabler for seamless reconfiguration of the end-user system for a mobile user and for seamless user roaming from one role to another one. The mobile distributed information base should provide consistent, efficiently accessible, reliable and highly available information base. This implies a distributed and replicated worldwide “file system” that also supports intelligent synchronization of data after disconnections. Shared access and support of transactional operations also belong to the list of requirements.

IV.

Pervasive Healthcare

In this section, we look at how the outlined research areas show up in a specific context, namely pervasive healthcare as defined at Center for Pervasive Computing (CfPC), University of Aarhus, Denmark [4]. The pervasive healthcare project is a collaboration between CfPC, a supplier of Electronic Patient Record (EPR) systems, and the Aarhus County Hospital. One of the cornerstones in our experimental research is testing prototype systems in realistic settings and we therefore work closely together with clinicians from the hospital. Clinicians are heavily involved in 18

Future Scenario

A younger physician has indicated interest in the result of a specific patient’s blood sample, because the patient’s condition has become worse overnight. When the lab result becomes available, a notification is sent to the computing device that happens to be nearest the physician—as he is walking in the corridor, this is the PDA in his pocket. He takes a look at the result and decides that he has to consult a senior physician and the nurse in charge of the patient at the ward. He sends a notification to them and asks them to meet him in the conference room. As he enters the conference room, the physician transfers the lab result graph to the SmartBoard in the room. He may control the graph viewed at the SmartBoard from his PDA. He discusses a new treatment with the senior clinician while the nurse studies the medicine description in the medicine book at a laptop in the room. Here she can see that discussed type of medicine is ill suited for the patient because of undesired effects. She explains the problem while displaying excerpts from the medicine book on the SmartBoard. They decide to give the patient another type of medicine right away and the younger physician records the changed prescription in the EPR. The nurse transfers the patient’s data onto her PDA, goes to the medication room and starts to find the medicine. While she is approaching the medicine room, the patient’s medication schema appears automatically on the PDA. When entering the medicine room the PDA discovers the barcode scanner located in the medicine cabinet containing the i.v. medicine. The nurse finds the medicine and uses the barcode scanner to register it. If there is a mismatch between the prescribed


medication and the medicine scanned with the barcode scanner, a warning is shown on the PDA. The nurse goes to the patient in order to explain the new situation to him. At the bedside, she uses the patient’s TV in the ceiling to display the graph and other information from the patient record. The images shown on the TV are controlled from the nurse’s PDA. Finally, the PDA is used to mark the medicine as given to the patient and the time and initials are recorded.

IV.B.

Requirements

The scenario sketched above is far from trivial as seen from an architecture and middleware point of view and touches upon the research areas outlined earlier. The scenario includes the aspect of dynamic reconfiguration of end-user systems—in essence PDAs in the scenario act as FuturePhones. The younger physician transfers the lab result graph to the SmartBoard but retains control on his PDA; the nurse “merges” her PDA and the TV set into a “composite device” [26] in the same manner to show the graph on a TV. The bar code scanner and PDA becomes a logical integrated system. While it is important that either the devices themselves or the middleware dynamically build lists of potential logical/composite devices, we think that the actual merging of physical devices into a composite device must be under full user control. First, the user experience is confusing if the user’s working context suddenly moves away from her device. Second, the problem of “guessing” or inferring the proper set-up for a given work context is non-trivial and may easily guess at an unsuitable configuration. In a healthcare context, the authentication and authorization issues are very important: nurses are not allowed to prescribe medicine, for instance. Thus, it is vital that the middleware can accurately authenticate the user or the user’s role to the EPR application. We have considered several proposals. A personal PDA/FuturePhone may act as authentication “key” to the middleware; however this seems less interesting as the PDA can easily get lost allowing someone else to act on behalf of the clinician, or run out of power cutting off the clinician from the computing infrastructure. At present we think that the best proposal is some lightweight, passive, device/tag that can be worn on the clinicians’ coat, and can be detected by the computing infrastructure, combined with some explicit user action to “log-on”. The explicit action is necessary to avoid turning on computers simply when walking by. A light device/tag worn on the coat does not easily get lost. This also frees the individual clinician from keeping track of “his”

or “her” PDA/FuturePhone—instead any unused computing device can be used and automatically becomes “personal” upon authorization. We denote this public computers as opposed to personal computers [6]. Environment monitoring and device discovery are evidently interesting, as they may be used as enabling technologies allowing physical devices to merge into composite devices: they (or the middleware) may respond to their proximity by providing the user with the opportunity to merge them. Monitoring the movement of the clinicians’ authorization tags/devices is of course also an essential part in our vision. We have also experimented with location- and context awareness to an even further degree, namely to facilitate activity discovery [5] where the middleware layer makes qualified guesses at recurring physical activities made by the clinicians. Our prime example is giving medicine to patients by nurses. In our set-up, the medicine tray is a device that can report its identity and contents to the middleware. Thus in the situation where a nurse, a medicine tray, and the patient that the medicine tray is associated with, are located in the same place, the middleware infers that it a likely “giving medicine to patient” event is going to occur and propose this as a session to the nurse. If she accepts, the proper data as well as views are automatically setup in the EPR given a substantial speed up compared to locating the data and navigating the user interface manually. The scenario also demonstrates reconfigurable applications as when the physician moves the lab result session from his PDA to the SmartBoard computer instead. Many (most?) decisions in healthcare require access to a broad range of information drawing upon many sources: lab results, X-ray images, medical records, medicine descriptions, and historical data. For a clinician to form a coherent picture of a situation, a large screen is important to view these many data sources simultaneously. Large screens are inevitably stationary while healthcare workers are extremely mobile and we conclude that transferring sessions from one device to the other is the rule rather than the exception. Thus it is a primary issue to support this in the middleware. The problem of fault tolerance is of course also very important in a healthcare setting where the treatment of patients must not be disrupted due to software related problems. The need of a mobile information base is relevant also in the healthcare sector. However, the focus in our project is supporting the healthcare staffs’ activities and less on the issues of quality of the underlying patient record data that we consider to be the respon-


19

sibility of the EPR.

IV.C.

Architectural Qualities

The research areas mentioned in section III and the requirements outlined above are basically functional requirements. From the architectural point of view, there are also a number of qualities that we would like our middleware solution to have. We have identified the following key quality attributes. The list is based upon the qualities outlined by Bass et. al. [3]. • Adaptability: The ability to gracefully cope with changes during the lifetime of a user session is one of the key characteristics of pervasive computing. The changes may come from the middleware layer itself (connection quality changes, etc.), from explicit user actions (“composing” new devices as in our scenario), or from the monitored environment (movement to a new location may provide new opportunities). • Availability: A characteristic of healthcare work is that computing is not the central issue—patient care is. Of course, we cannot accept low quality healthcare due to problems with the middleware and thus we must require high availability of the middleware platform. • Security: Security is important in two aspects. The patient’s data must be guarded against unauthorized inspection. In our vision even patients may use any public computer but is of course not allowed access to the full EPR. Another aspect is authority to modify EPR data, which depends on the user’s role. In both aspects it is import that the middleware correctly identifies the user. • Modifiability: Merging physical devices into coherent, composite, devices puts an implicit emphasis on modifiability of the middleware. A deployed middleware for mobile computing must expect new devices and services to appear at a high rate over its lifetime. Thus the components of the middleware that handles device interaction must be prepared for being modified often. • Performance: The most critical performance aspect is fast response time more than high data transfer rates in a healthcare environment. An important part of a successful architecture is making the right compromises between qualities that are often in conflict with each other. For instance, 20

the performance and modifiability qualities are usually contradictory requirements as modifiability is achieved through delegation and indirection in the code as is evident in design patterns. Indirection of course carries a speed penalty. The adaptability and modifiability qualities may pull in the same direction as a flexible and adaptable middleware architecture may lower the need to modify it. It may, however, be in conflict with the availability quality as flexible, adaptive, software is more complex to write and thus more prone to errors.

V.

Home Entertainment

Since software for home entertainment will have to run on a variety of heterogeneous hardware platforms, it is unrealistic to reimplement such components from scratch for each target hardware platform. The development of such system software is extremely expensive. Thus, the implementation needs to focus on software portability to reduce the development cost. However, future home appliances need to take into account various types of adaptability to support our requirements. For example, the appliances allow us to use various interaction devices to control them. Also, since many home appliances will be portable, and can be carried anywhere, their behavior should be adapted according to our surrounding environments. This section presents several requirements and some technology challenges for the implementation of home entertainment middleware.

V.A. Future Scenario After coming back from my office, I sit in the armchair in my living room to watch television. I point my PDA device at the television and the television control panel appears on it. I select the entry for today’s television programs, and the program is displayed on the television. I change channels by navigating the program on the TV display by moving a finger on my PDA screen. I select the program I’m interested in and the TV asks me if I want to watch the previous recorded version of that program first. I say ”yes”, and the recorded program starts playing. After a while, I move to the table to get some coffee and a snack. Now, when I want to switch to a different program, the TV program is displayed on the table, and I can change the current TV channel by tapping on the program displayed on the table. At this point, my friend phones me. I pick up my video phone near the television. The control panel appears on the screen of the phone and it allows me


to mute the sound of the television, and also to start recording the TV program so I can watch it later. While chatting with my friend, I can see his video on my television screen. During the phone conversation, I walk into the kitchen to refill my cup, and the video phone stream follows me there. The video is now displayed on the refrigerator screen (which is normally used to show recipes, calendars, and the like). After finishing the chat with my friend, I resume watching the TV program by navigating the control panel displayed on my PDA device.

V.B. Requirements In the near future, a variety of home appliances will be connected to each other via high-speed networks. Also, these appliances will have to be controlled by various input and output interaction devices. Both the interaction devices as well as many portable home appliances will be mobile. Also, people who are living in different places may want to create virtual domestic spaces for using a collection of appliances and sharing resources among them. Therefore, we believe that future home entertainment middleware will need to support a variety of adaptive behaviors. Currently, several middleware specifications for home entertainment such as HAVi[10] and Universal Plug and Play[29] have been published, and several commercial products are available now. However, these standard middlewares do not fully satisfy the requirements to make the dream presented in the previous section’s scenario true. First, we may have a large number of home appliances in our homes in the near future, and thus, it may be very difficult to identify a particular target appliance to control. If each appliance provides its own control panel, it will be complex and potentially confusing to use it. For example, if there is a television in a room, and a personal video storage in a user’s pocket, it is better to provide a single control panel to operate both. This provides us an illusion of controlling one appliance. This kind of reconfigurable applications described in Section III.B are important to reduce the complexity introduced by the number of appliances. However, it is not easy to develop a home entertainment application to support such an adhoc composition. Currently available middleware for home entertainment such as HAVi and UPnP do not provide a sufficiently high level of abstraction to compose appliances. Future home entertainment systems will have to provide flexible interaction to control appliances because the best way to control the appliances changes

according to a user’s situation. For example, we may use our mobile phone to control a television, but when our hands are not free, we would like to use voice commands to control it. Also, when we are moving, the nearest display should be selected to show a control panel or video streams. Current standard middlewares support document-based user interface description languages that make it possible to adapt user interface according to various display sizes, but the adaptation is not enough to support various advanced intaraction devices proposed in many research groups currently. We believe that dynamic configurability described in Section III.A is very important, and future home computing systems should provide a way to select interaction devices dynamically to support user mobility. This also makes it possible to use the same interaction technique when controlling the same appliance anytime, anywhere. Furthermore, the computing environment need to know each user’s private preference to behave in a consistent way. We believe that mobile distributed information base described in Section III.D is useful to solve this problem. It is not easy to implement the above scenarios because the behavior of home entertainment systems should be specialized according to the user’s situations. For example, a control panel to access an appliance may need to be changed according to a user’s preferences. Therefore, environmental monitoring described in Section III.C should be supported to make each appliance’s behavior context-aware.

V.C.

Technology Challenges

This section presents several technical problems that need to be attacked when building future home entertainment middleware. We encountered these problems during our experiences with building home computing systems as described in [20, 22, 21, 28].

V.C.1. High Level Abstraction For building complex home entertainment systems, abstraction is a very powerful tool to deal with the complexities. There are many places where using abstraction is effective. Home entertainment applications require accessing various home appliances such as televisions and videocassette recorders. Applications require accessing these appliances without taking into account the difference among implementations to build portable applications. Also, the applications require various new techniques such as service integration and context awareness. These techniques


21

require good abstraction to build well-structured applications. Also, complex software usually adopts various techniques such as optimization and adaptation. Adhoc uses of the techniques make the structure of programs very unclear. For example, by inserting a lot of “if” statements to check the current situation, we can build context-aware applications. However, the program is very difficult to modify when the program needs to consider another situation. We need good abstraction to support adaptive context-aware applications. Similarly, adopting aggressive optimization makes programs less portable since the optimization may not be effective in another situation. We believe that using better abstraction makes it possible to deal with optimization in a portable way.

V.C.2.

Portability Issues

We need to take into account a variety of platforms when implementing home entertainment systems. If we like to use commodity software components, it is important to consider how to exploit advanced characteristics provided by these underlying platforms. This requires adding meta level interface [15] or QOS parameters to control the internal algorithms of the COTS software components. However, it is not easy to export a generic interface to control underlying platforms because the generic interface usually hides some low level characteristics of the underlying platforms. We believe that it is desirable that the interface should be customized to respective underlying platforms for enabling us to use the full power of the platforms. Our research aims are how to provide platform specific meta interface or QOS parameters in a systematic way, and how to build portable applications that access the platform specific meta interface or QOS parameters. We are considering exploiting AOP techniques [16] and design patterns to implement commercial software components.

V.C.3.

Human-Computer Interaction

A user may have to control the same kind of home appliances in many different places; for example, we may find televisions at home and in public spaces, all of them with different user interfaces. Firstly, we want each user to be able to control those different applications in a common way, for example from his/her mobile phone. Secondly, we do not want to tie down the user to a specific controller: s/he should have the choice of, say, controlling the appliances by voice if the hands are busy. Other users may choose other in22

teraction devices as their preferred controllers. Everyone will have a familiar and uniform way to control appliances regardless of their make and location. There may still be higher-level constraints: a user needs to behave differently in a personal space and in a public space, because the public space is shared with many unknown people. But, as far as the technical aspects are concerned, the user should be able to behave uniformly without having to take into account the particular space in which s/he is. In our project, we define the universal interaction protocol between interaction devices and various applications and services [20]. Currently, our universal interaction protocol is based on bitmap images and keyboard and mouse events. In our system, any graphical user interface can be shown on any output device that has a display. The size and color are converted according to respective interaction devices and then our system can generate GUI on any output devices. Also, events generated by input interaction devices are converted into keyboard and mouse events, and the events are transferred to applications. We are currently considering better universal interaction protocols because the current protocol is too low level, and is difficult to customize the user interface according to a user’s preference. However, our approach shows the effectiveness of the idea that all appliances can be controlled in the same way.

VI.

Discussion

The benefits of middleware software are obvious. The most significant advantage—when compared to a pure IP-based socket programming approach—is in the improved programming model. The middleware solutions are usually based on object-oriented programming and method invocations. The invocations are based on strongly typed interfaces that provide both compile and run time error checking. They also hide many implementation details. Therefore, middlewarebased application development is much faster than the Internet based one. Although the middleware solutions provide superior programming environments over the Internet solution, they also pose serious shortcomings. The fundamental problem of the current middleware specifications is that they only take advantage of a narrow subset of useful Internet protocols. The current middleware specifications were born in a time when the Internet protocols were a synonym of the TCP/IP transport. Later they have developed solutions of their own for Quality-of-Service, directory, discovery, and


so on, independently from each other and from the IETF specifications. The fundamental research challenge is the question of how the developments in Internet protocols and in different middleware solutions can be harmonized. By harmonization we mean two things. Firstly, we need to solve the problem of incorporating evolving Internet solutions of Quality-of-Service, mobility, discovery, and security into the existing middleware specifications without breaking those specifications. Secondly, we need to find solutions to how different middleware solutions can become interoperable in the sense that components of an application can be executed on different middleware platforms. The increasing diversity of devices (terminals, network elements, and application servers) imply that different middleware solutions will be in use. It is highly improbable that there will be, in a near future, a single dominant middleware platform that would be good enough for different devices and purposes. This heterogeneity requires interoperability on two levels: between middleware platforms and between parts of an application running on different middleware platforms. The interoperability between different platforms is relatively more developed. In particular, the OMG has been the leading forum in specifying interoperability bridges between CORBA and other middleware platforms. In contrast, the interoperability between parts of an application running on different middleware platforms is still immature although OMG’s Model Driven Architecture (MDA)[24] has taken some initial steps.

VII.

the pervasive healthcare project, we have a vision of supporting clinicians in their daily healthcare work by providing seamless support by a ubiquitous computing infrastructure. In the home entertainment project, we explore the requirements for middleware to support home entertainment systems. Both are excellent cases where detailed solutions, as well as the interplay between the research areas, can be studied.

References [1] 3G Specifications. http://www.3gpp.org/, 2002. [2] B. Aitken et al. Network Policy and Services: A Report of a Workshop on Middleware. Technical report, IETF, Feb. 2000. [3] L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice. Addison-Wesley, 1998. [4] Center for Pervasive www.pervasive.dk.

[5] H. B. Christensen. Using Logic Programming to Detect Activities in Pervasive Healthcare. In Proceedings of International Conference on Logic Programming ICLP 2002, Lecture Notes in Computer Science, Copenhagen, Denmark, Aug. 2002. Springer Verlag. To appear. [6] H. B. Christensen and J. E. Bardram. Supporting Human Activities — Exploring ActivityCentered Computing. In Proceedings of the Fourth International Conference on Ubiquitous Computing UBICOMP 2002, Lecture Notes in Computer Science, Göteborg, Sweden, Sept. 2002. Springer Verlag. To appear.

Conclusion

Over ten years ago Mark Weiser identified the goal of future computing to be invisible computing [31]. To realize this vision, developers of mobile and pervasive applications will require a cost-effective and reliable middleware that provides a strong programming model on which to base their products. The challenges faced by developers of middleware solutions are many and difficult. In this paper, we have classified the challenges and requirements into four key research areas. We have described the four areas and given examples of specific challenges within each area. We have outlined two research projects: pervasive healthcare and home entertainment. Both of these projects show challenges that can be mapped into the above four research areas as well as more specific requirements particular to their respective domains. In

Computing.

[7] CORBA 2.6.1. Specification. http://www.omg.org/, May 2002. [8] K. Ducatel et al. Scenarios for Ambient Intelligence in 2010. Technical report, ISTAG, Feb. 2001. [9] G. Eddon and H. Eddon. Inside Distributed Com. Microsoft Press, 1998. [10] HAVi Consortium, http://www.havi.org/.

HAVi

Home

Page.

[11] Java 2 Enterprise http://java.sun.com/j2ee/, 2002.

Edition.

[12] Java 2 Micro http://java.sun.com/j2me/, 2002.

Edition.


23

[13] R. Katz. Adaptation and Mobility in Wireless Information Systems. IEEE Personal Communications Magazine, 1(1):6–17, 1994. [14] R. Katz. Sahara Overview. http://sahara.cs.berkeley.edu/, June 2002. [15] G. Kiczales, J. Lamping, C. V. Lopes, C. Maeda, A. Mendhekar, and G. Murphy. Open Implementation Design Guidelines. In Proceedings of the 19th International Conference on Software Engineering (ICSE), pages 481–490, 1997. [16] G. Kiczales, J. Lamping, A. Menhdhekar, C. Maeda, C. Lopes, J.-M. Loingtier, and J. Irwin. Aspect-Oriented Programming. In M. Aks¸it and S. Matsuoka, editors, ECOOP ’97 — Object-Oriented Programming 11th European Conference, Jyväskylä, Finland, volume LNCS 1241, pages 220–242. Springer-Verlag, 1997. [17] Mobile Internet Technical Architecture. Press, ISBN 951-826-671-9, July 2002.

IT

[18] T. Nakajima. A Framework for Building Adaptive Continuous Media Applications Using Service Proxies. In B. Furht, editor, Handbook of Multimedia Computing, pages 913–934. CRC Press, 1999. [19] T. Nakajima. Practical Explicit Binding Interface for Supporting Multiple Transport Protocols in a CORBA system. In Proceedings of International Conference on Network Protocols. IEEE Press, 2000. [20] T. Nakajima. System Software for Audio and Visual Networked Home Appliances on Commodity Operating Systems. In R.Guerraoui, editor, Proceedings of the IFIP/ACM International Conference on Distributed Systems Platforms Middleware, volume LNCS 2218, pages 273– 294. Springer-Verlag, November 2001. [21] T. Nakajima. Experiences with Building Middleware for Audio and Visual Networked Home Appliances on Commodity Software. In Proceedings of the ACM International Conference on Multimedia. ACM Press, 2002.

Symposium on Applications and the Internet, pages 246–255. IEEE Press, January 2002. [23] Open Mobile Alliance. http://www.openmobilealliance.org/, 2002. [24] OMG’s Model Driven Architecture. http://www.omg.org/mda/, 2002. [25] Parlay 2.1 specification. http://www.parlay.org/, 2001. [26] T.-L. Pham, G. Schneider, and S. Goose. Exploiting Location-Based Composite Devices to Support and Facilitate Situated Ubiquitous Computing. In P. Thomas and H. W. Gellersen, editors, Proceedings of Handheld and Ubiquitous Computing, HUC 2000, volume 1927 of Lecture Notes in Computer Science, pages 143–156, Bristol, UK, Sept. 2000. Springer Verlag. [27] M. Satyanarayanan. Pervasive Computing: Vision and Challenges. IEEE Personal Communications Magazine, pages 10–17, Aug. 2001. [28] D. Ueno, T. Nakajima, I. Satoh, K. Soejima, and H. Ishikawa. Web-based Middleware for Home Entertainment. In Proceedings of the International Symposium on Asian’02, 2002. [29] Universal Plug and Play Forum, UPnP Home Page. http://www.upnp.org/, May 2002. [30] WAP Wireless Application ronment Specification, Version http://www.wapforum.org/, 2001.

Envi1.3.

[31] M. Weiser. The Computer for the Twenty-First Century. Scientific American, pages 94–104, Sept. 1991. [32] The Book of Visions — Visions of the Wireless World. http://www.wireless-worldresearch.org/, Dec. 2001. [33] Nomadicity in the National Information Infrastructure. http://www.lk.cs.ucla.edu/LK/lkxiwt/, 1995. see also IEEE Personal Communications, Dec 1995, pp. 14–27.

[22] T. Nakajima, D. Ueno, E. Tokunaga, H. Ishikawa, I. Satoh, and H. Aizu. A Virtual Overlay Network for Integrating Home Appliances. In Proceedings of the International 24
