Pervasive computing [1-3] is “omni-computing”. It is “allpervasive” by combining open standards-based applications with everyday activities. Computing is a rapidly developing area of Information a n d Communications Technology (ICT). The term refers to the increasing integration of ICT into people's lives and environments, made possible by the growing availability of microprocessors with inbuilt communications facilities. Pervasive computing has many potential applications, from health and home care to environmental monitoring and intelligent transport systems. Pervasive Computing Systems (PCS) and services may lead to a greater degree of user knowledge of, or control over, the surrounding environment, whether at home, or in an office or car. They may also show a form of 'intelligence'.

Mark Weiser has been named as the father of ubiquitous computing (Ubicomp) and has presented his vision [3] in the following way: “Ubiquitous computing has as its goal the enhancing computer use by making many computers available throughout the physical environment, but making them effectively invisible to the user.” In his another paper [1] Weiser predicts that there will be quite commonly hundreds of computers in one room but by then they are so small and commonplace that they are virtually invisible to users.

Pervasive computing is the third wave of computing technologies to emerge since computers first appeared:

• First Wave - Mainframe computing era: one Computer shared by many people, via workstations.
• Second Wave- Personal computing era: one computer used by one person, requiring a conscious interaction. Users largely bound to desktop.
• Third Wave - Pervasive (initially called ubiquitous) computing era: one person, many computers. Millions of computers embedded in the environment.

Any piece of software that glues together various other pieces of software can be labeled as middleware [1,13]. The two most common functions handled by middleware solutions are messaging and data access services. A typical usage scenario is one where a Graphical User Interface (GUI) component needs to access a remote database. Usually the GUI part has to be independent of the actual database implementation and a middleware component or a set of middleware components provide that functionality to the GUI. Thus middleware provides a service layer in the software architecture that separate the details of implementation from users of middleware in Figure 1. The typical users of middleware are application developers who build new applications to be deployed in the target environment.

Figure 1. Middleware layer is placed between applications and hardware or operating system or network layer services

Other typical middleware services include message passing, transaction monitoring, directory lookup and object brokerage or other distributed computing environment services. Many of the middleware solutions in use today are application- specific or optimized for a set of applications but naturally there are also generic middleware solutions [4]. Examples of current genericpurpose middleware solutions are CORBA(Common Object Request Broker Architecture), DCOM (Distributed Common Object Model), J2EE (Java 2 Enterprise Edition), J2ME (Java 2 Micro Edition) and WAE (Wireless Application Environment).

Of these only J2ME and WAE are intended to be used on mobile devices. The remaining three are still suitable for server-side computing but they don't adapt well to more challenging requirements of pervasive computing like automatic reconfiguration and service discovery or context-awareness on the device.

Pervasive computing involves three converging areas of ICT[3]:computing('devices'),communications ('connectivity') and 'user interfaces'.

PCS devices are likely to assume many different forms and sizes, from handheld units (similar to mobile phones) to near-invisible devices set into 'everyday' objects (like furniture and clothing). These will all be able to communicate with each other and act 'intelligently'.

Such devices can be separated into three categories:

• sensor : input devices that detect environmental changes user behaviors, human commands etc;
• processor : electronic systems that interpret and analyze input-data;
• actuator : output devices that respond to processed information by altering the environment via electronic or mechanical means.

For example, air temperature control is often done with actuators. However the term can also refer to devices which deliver information, rather than altering the environment physically. There are many visions for the future development of PCS devices. The idea is that each one would function independently, with its own power supply, and could also communicate wirelessly with the others.

Pervasive computing systems will rely on the interlinking of independent electronic devices into broader networks. This can be achieved via both wired (such as Broadband (ADSL) or Ethernet) and wireless networking technologies (such as Wi-Fi or Bluetooth), with the devices themselves being capable of assessing the most effective form of connectivity in any given scenario. The effective development of pervasive computing systems depends on their degree of interoperability, as well as on the convergence of standards for wired and wireless technologies.

User interfaces represent the point of contact between ICT and human users. For example with a personal computer, the mouse and keyboard are used to input information, while the monitor usually provides the output. With PCS, new user interfaces are being developed that will be capable of sensing and supplying more information about users, and the broader environment, to the computer for processing. With future user interfaces the input might be visual information – for example recognizing a person's face, or responding to gestures. It might also be based on sound, scent or touch recognition, or other sensory information like temperature. The output might also be in any of these formats. The technology could 'know' the user (for example through expressed preferences, attitudes, behaviors) and tailor the physical environment to meet specific needs and demands.

Pervasive computing devices can be connected to each other using three types of networks. Wireless Wide Area Networks use typically digital cellular radio technologies from the end user devices to base stations. Short-range Wireless technologies can be used typically indoors since the range is usually just a few tens of meters. The third type of networks can be found at residential and office environments where they connect controls and appliances.

Several ubiquitous middleware architectures and infrastructures have been introduced in the academic and industrial world. The current middleware treat ubiquity from slightly different perspectives. We distinguish various middleware technologies [1,8] ranging from partially integrated middleware to fully-integrated middleware. We mean by fully-integrated middleware, middleware providing key elements for all applications requirements such as discovery, adaptation/composition, context management, and management of ubiquitous applications. In this category we cite ubiquitous middleware systems such as Aura, Gaia, Oxygen, Pcom and One.world. Partially-integrated middleware range from platforms that were specially realized to handle one or two ubiquitous requirements, such as the application discovery in Jini and UPnP, to platforms that are being extended to ubiquity for the application management such as OSGi and .Net Framework . We survey the current state-of-the-art architectures from the viewpoint of the core requirements identified above. In this survey, we will highlight the most known and used fully and partiallyintegrated middleware. We will not deal with the platforms that are being extended to ubiquity as these extensions are still in a preliminary state. Later on, a classification will focus on the strength and weakness of each of the ubiquitous middleware, based on the identified requirements.

Aura [3] provides user with an invisible halo of computing and information services that persists regardless of location. A personal Aura acts as a proxy for the mobile user it represents. Aura aim is to allow users to execute their tasks regardless their location. It allows users to dynamically realize daily tasks modeled as abstract software applications, in a transparent way, without manually dealing with the configuration and reconfiguration issues of these applications. Aura deals more with adaptation, replacement of services, the dynamic configuration and reconfiguration of user tasks. Project Aura provides several pervasive applications adapted to both homes and offices.

Gaia [10] is a services-based middleware that integrates resources of various devices. It manages several functions such as forming and maintaining device collections, sharing resources among devices and enables seamless service interactions. It also provides an application framework to develop applications for the device collection. The application framework decomposes the application into smaller components that can run on different devices in this collection. The notion of ad-hoc pervasive computing in Gaia is a cluster of personal devices that can communicate and share resources among each other. The cluster is referred to as a personal active space. The user can program this cluster through a common interface. Mobile Gaia role is to provide services that discover devices that form the personal space, maintain the composition of the cluster, share resources among devices in the cluster and facilitate communication. Similarly to Aura, Gaia focuses on the dynamic aspect of ubiquitous environments and provides the support for dynamically mapping applications to available resources of a specific active space.

Oxygen [11] vision is to bring an abundance of computation and communication within easy reach of humans through natural perceptual interfaces of speech and vision. Computation blends into peoples' lives enabling them to easily do tasks they want to do, collaborate, access knowledge, automate routine tasks and their environment. In other words, it enables a pervasive, human centric computing. The approach focuses on four technological areas: embedded computational devices, handheld devices, networks, and also on adaptive software. Perception is a central issue, however the focus is mainly on vision and speech aiming to replace explicit traditional input mechanisms with conversational and gesture input.

One.world [12] is a system architecture for ubiquitous computing. It provides an integrated, comprehensive framework for building pervasive applications. The One.world architecture builds on four foundation services. First, a virtual machine provides a uniform execution environment across all devices and supports the ad hoc composition between applications and devices. Second, tuples define a common type system for all applications and simplify the sharing of data. Third, events are used for all communications and make change explicit to applications. Applications are composed from components that exchange events through imported and exported event handlers. Events make change explicit to applications, with the goal that applications adapt to change instead of forcing users to manually reconfigure their devices and applications. Finally, environments host applications, store persistent data, and through nesting facilitate the composition of applications and services.

Pcom [13], a Component system for ubiquitous computing is a light-weight component system that offers application programmers a high-level programming abstraction which captures the dependencies between components using contracts. Pcom allows the specification of distributed applications that are made up of components with explicit dependencies modeled using contracts. Pcom relies on a communication middleware,

Base is a flexible middleware for Pervasive computing environments. It provides adaptation support on the communication level by dynamically selecting or reselecting communication protocol stacks, even for currently running interaction. Base is written in Java using the Java 2 Micro Edition with the Connected Limited Device Configuration. It assists application programmers by providing mechanisms for device discovery and service registration that can be used to locate and access local as well as remote device capabilities and services. It also provides a simple signaling mechanism to determine the availability of these devices and services.

Jini [14] is a Java-based architecture for spontaneous networking. Participants in a Jini community require no previously knowledge of each other, and can take full advantages of the dynamic class loading and typechecking of the Java language, which requires a Java Virtual Machine (JVM) for all participants. A Jini community is established around one or more Lookup Services, which organize the services deployed in the community and respond to requests from clients. The Lookup service is itself a Jini service, acting as a bootstrapping service. References to these Lookup services are obtained either by unicast or multicast discovery protocols defined by Jini. The main idea of Jini for supporting “spontaneous networking” is achieved by a leasing principle, which means that services are leased into the community. When a service provider registers a service in the Lookup service it obtains a lease, which must be renewed before it expires, otherwise the Lookup service automatically deregister the service. Clients can register for changes in the Jini community, such as new, discarded, or changed services, using remote event registrations. By the same principle clients and service providers can register for events of new or discarded Lookup services. Event registrations are leased in the community, so automatic cleanup can be initiated for non-responding clients. These are the real benefits of Jini, enabling opportunity to create a self maintaining ubiquitous computing.

UPnP [15] technology defines an architecture for ubiquitous peer-to-peer network connectivity of intelligent appliances, wireless devices, and PCs of all form factors. It is designed to bring easy-to-use, flexible, standards based connectivity to ad-hoc or unmanaged networks whether in the home, in a small business, public spaces, or attached to the Internet. UPnP technology provides a distributed, open networking architecture that leverages TCP/IP and the Web technologies to enable seamless proximity networking in addition to control and data transfer among networked devices. It is designed to support zero-configuration, “invisible” networking, and automatic discovery for a breadth of device categories from a wide range of vendors. A device can dynamically join a network, obtain an IP address, convey its capabilities, and learn about the presence and capabilities of other devices. A device can leave a network smoothly and automatically without leaving any unwanted state behind.

The authors propose a classification of the previously mentioned ubiquitous middleware. The classification was established upon the challenges raised by ubiquitous computing and upon how the various ubiquitous middleware respond to them. Figure 2 classifies the existent ubiquitous middleware defined above using the requirements of ubiquitous middleware. For each middleware technology, we focused on the requirements it respects and the ones it does not fulfill. If some requirements are relatively well fulfilled by nowadays systems, such as discoverability, context awareness and adaptability, others are far from being fulfilled or even dealt with such as security, interoperability scalability and autonomous management.

Figure 2. Classification of ubiquitous middleware

Computing devices already cover a wide range of platforms, computing power, storage capacity, form factors, and user interfaces. We expect this heterogeneity to increase over time rather than decrease, as new classes of devices such as pads or car computers become widely used. Today, applications are typically developed for specific classes of devices or system platforms, leading to separate versions of the same application for handhelds, desktops, or cluster-based servers. Furthermore, applications typically need to be distributed and installed separately for each class of devices and processor family. As heterogeneity increases, developing applications that run across all platforms will become exceedingly difficult. As the number of devices grows, explicitly distributing and installing applications for each class of devices and processor family will become unmanageable, especially in the face of migration across the wide area.

For a single application programming interface (API) and a single binary distribution format, including a single instruction set, that can be implemented across the range of devices in a pervasive computing environment. A single, common API makes it possible to develop applications once, and a single, common binary format enables the automatic distribution and installation of applications. It is important to note that Java does not provide this common platform. While the Java virtual machine is attractive as a virtual execution platform (and used for this purpose by one.world), Java as an application platform does not meet the needs of the pervasive computing space. In particular, Java's platform libraries are rather large, loosely integrated, and often targeted at conventional computers. Furthermore, Java, by itself, fails to separate data and functionality and does not encourage programming for change. Given current hardware trends and advances in virtual execution platform, such as the Java virtual machine or Microsoft's common language runtime. We can reasonably expect that most devices can implement such a pervasive computing platform. Devices that do not have the capacity to implement the full platform, such as small sensors, can still interact with it by using proxies or emulating the platform's networking protocols.

Furthermore, legacy applications can be integrated by communicating through standard networking protocols, such as HTTP or SOAP, and by exchanging data in standard formats, such as XML. A pervasive computing platform that runs across a wide range of devices does impose a least common denominator on the core APIs. Applications can only assume the services defined by the core APIs; they must implement their basic functionality within this framework. At the same time, a common platform does not prevent individual devices from exposing additional services to applications. It simply demands that additional services be treated as optional and dynamically discovered by applications. All system inter faces are asynchronous, and application components interact by exchanging asynchronous events.

Weiser identified nearly a decade ago several research areas for Ubicomp from the different fields of computer science and many of them have been solved. The place of “IP middleware” and Wireless Middleware have been defined but what is exactly inside them is still an open research issue. Since it is highly improbably that there will be a single dominant middleware platform there is a clear need for interoperability. The paper identifies two levels of interoperability: “between middleware platforms and between parts of an application running on different middleware platforms” in Figure 3.

Figure 3. Layered architecture of middleware and Internet protocols

Ubiquitous computing expects a mobile user to be embedded into surroundings filled with communicating and interacting artifacts, all serving the spontaneous needs of the user. Moreover, interaction between users and the surroundings in highly mobile and dynamic settings has to be mediated by a common middleware platform [16,17], together with personalized devices and specialized services, facilitating the needs of mobile users. This basic system model of nomadic users and smart infrastructures poses a number of challenges for such middleware support.

First of all, mobility by itself requires different paradigms for interaction than those found in classical distributed systems. Many paradigms, well-established in static distributed systems are likely to fail when applied to these new settings. One prominent example among many is the request/reply paradigm, which is too static and tight coupled to be successful in dynamic mobile settings. Here, different paradigms, like loose-coupling and data centric computing, are more likely to succeed.

The next challenge for middleware is to support mobile applications to react “smartly” to changes of their execution environment. Users of such applications obviously expect their electronic helpers to 5.2 Requirement analysis adapt themselves to the current situation they are used in. A wellknown example is to turn off the ringer tones of a mobile phone when the user is in a meeting situation. Such adaptation is part of what usually is called context- or situation-aware computing. The challenge for middleware support lies here in providing means to retrieve context information from the environment on a syntactic and semantic level. Here we face issues of heterogeneity, together with efficient filtering of large volumes of information available.

Another challenge for middleware support in dynamic and mobile scenarios is the need to decouple producers and consumers of data in the system in time and space. Effective means for anonymous interaction are therefore essential. Moreover, for mobile clients the receiver cannot be assumed to be online at the same time the sender produces the data. Again, a middleware solution can provide facilities for buffering and access to past information.

The scale of pervasive systems we envision is also a challenge. On the one hand, systems will grow in physical size, like spanning a whole city. On the other hand, systems also can be rather small in size, but dense in the number of processors and applications contained within. Thus, the key challenge is to provide a communication infrastructure in which data and information is still manageable even for small devices while communication remains efficient and scalable.

This constitutes a strong demand for a mediator between producers and consumers of data, i.e., a middleware solution to the challenges listed above using mechanisms that are based on a publish/subscribe notification service with Rebecca model.

Among the requirements, the need for proper support for mobility and environment awareness is of outstanding importance. Moreover, we compare several different communication paradigms for distributed systems to identify one which will serve best as the basis for extensions needed in pervasive systems. We identify the well established publish/subscribe paradigm as a suitable basis for such extensions.

This is a common requirement for clients of the infrastructure that roam freely. Certain aspects of the handling of this issue are located in the infrastructure and are opaque to the client. This can be beneficial for a client either because it is not aware of its own mobility, e.g., together with legacy applications, or deliberately wants to delegate some aspects into the infrastructure. Therefore, devised a relocation algorithm that facilitates location transparency, offering the possibility to transfer existent event-based applications seamlessly into mobile environments [18]. The algorithm extends the existing content-based routing infrastructure to support non interrupted, sender-FIFO ordered delivery of notifications in the mobile case, without having a client even to be aware of this extension.

First, most information can be related to some location and next, we need strong selection criteria to distinguish relevant from irrelevant information. However, to make location usable together with a content-based publish/subscribe notification service, we introduced a special location model. It serves as the foundation for location-dependent subscriptions and notifications, respectively. The challenge from the point of view of the publish/subscribe infrastructure is two folds: first, hiding the details and burdens of adaptation of location dependent subscriptions to the current position of a client. Second, due to the uncertainty of the client position and movement, to keep delivery of information timely and accurate and to keep the network load for the client bearable.

To a large degree the previous solutions, together with the basic publish/subscribe paradigm, already decouple sender and recipient of data in space and time. This can be done by virtually relocating the arrival time of a client at a new location into the past. Hence, we establish distributed buffers in the infrastructure together with a set of search and consolidation strategies, tailored to minimize the bootstrapping latency experienced by a client.

A framework for the development of context-aware applications

We identify context to be an important input for applications in pervasive computing systems. Usually, such context data is the result of changes in the volatile external computing environment the client operates in. Adaption therefore is reactive in nature. Some aspects of the framework resemble mechanisms also found in the rather recent paradigm of model driven development (MDD).

The publish/subscribe [19] communication paradigm is increasingly used in many application domains and areas of computer science. It allows processes to exchange information based on message type or content rather than particular destination addresses. Information about some event is published via notifications, which are conveyed by the underlying pub/sub notification service. A consumer registers its interest in certain kinds of notifications by issuing subscriptions, and it gets notified by the notification service about any newly published notification that matches at least one of its subscriptions. The loose coupling of producers and consumers is the prime advantage of pub/sub systems in Figure 4 and has many applications in the context of spontaneous, ad-hoc and pervasive environments.

Figure 4. Publish/Subscribe System

Publish/Subscribe (pub/sub): a powerful abstraction for building distributed applications such as Message based, anonymous communication, Participants are decoupled.

Pub/Sub is well suited for mobile systems

• Proliferates loose coupling
• Leverages reconfigurability and evolution
• Efficient support for many to many communication
• No explicit knowledge about participating parties necessary

One major characteristic of pervasive applications is mobility. However, up to now research is mainly focused on using pub/sub middleware in rather static, non-mobile environments, i.e., systems where clients (producers and consumers) do not roam and the infrastructure itself stays rather fixed or is only changing slowly during the system's lifetime. Consequently, most pub/sub infrastructures (e.g., SIENA, JEDI, REBECA, to name a few) have optimized algorithms for information delivery in those settings. Support and optimizations for mobile clients are not built in features of the infrastructure; it is left to the applications to adapt or reissue subscriptions. Publish/subscribe (pub/sub) proliferates loose coupling and is touted to facilitate mobility. The inherent loose coupling even allows existing applications to be transferred to mobile environments, if an appropriate infrastructure support is available. However existing pub/sub middleware are mostly optimized for static systems where users as well as the underlying system structure is rather fixed. In this paper the authors analyze the necessary steps to support mobile clients with publish/subscribe middleware. The REBECA content-based pub/sub service is extended to accommodate to physically mobile clients, offering a location transparent access to the middleware without degrading the previously guaranteed quality of service. The transparent access allows existing applications to be seamlessly transferred from a static to a mobile scenario without having to adapt client applications.

A first step towards mobility is to enhance existing pub/sub middleware to allow for roaming clients so that existing applications can be used in mobile environments. This means that the interfaces for accessing the middleware and the applications on top are not required to change. More importantly, the quality of service offered by the middleware must not degrade substantially. Generally speaking, location transparency is what makes existing applications mobile, e.g., stock quote monitoring can be seamlessly transferred from PCs to PDAs. Location transparency is the main aspect of what is called physical mobility.

Basically, the architecture is centered around a distributed network of communicating notification brokers. Because of its distributed nature, REBECA[20] is a representative example of a distributed notification service like SIENA, JEDI, etc. REBECA supports different routing algorithms and data and filter models.The role of the Rebeca notification service is to decouple sender and recipient of notification messages. This is done in a transparent way for clients Rebeca supports different routing algorithms and data and filter models. The original architecture of Rebeca in Figure 5 was designed for scalability and notification routing optimizations. To add extension to this basic model for proper support of mobile and pervasive applications and leave the basic functionality and properties untouched where possible for the structure of the broker network, besides the characteristic of being an overlay network, three types of brokers can be distinguished: local, border, and inner brokers.

Figure 5. Router network of Rebeca

Local brokers act as access points to the infrastructure. Typically, they are part of an application's communication library and are loaded on application startup. Thus, they cannot be handled as regular part of the broker network and they do not show in the actual graph structure of the notification service. A local broker is connected to a single border.

Border brokers are always the first “hop” into the network of brokers and form the boundary of the routing network. Border brokers play a major role for supporting and hosting mobile clients, as well as maintaining caches and connections to their local brokers.

Inner brokers are connected to other inner or border brokers and do not maintain any connections to clients.

Introduce an algorithm for extending standard REBECA brokers to cope with mobile clients, maintaining their subscriptions as well as guaranteeing the required quality of service.

The routing network of REBECA was extended to implement an algorithm consisting of three distinct phases, propagation, fetch, and relocation. Using exclusively the publish / subscribe paradigm together with the distributed broker network, each phase has a separate goal.

The goal of the propagation phase is basically twofold. In Figure 6(a) one can see that, after a client is reconnecting to a different broker, a new path to one or more producers of requested data must be set up. However, due to the special structure of the broker network this path is meeting the old delivery path at some point. We call this particular broker the junction broker. By identifying the junction where old and new path meet, the propagation phase is finished and a new delivery path is set up.

Figure 6. Moving client scenarios with one and multiple producers

After the identification of the junction a special fetch message is sent along the old delivery path, with the goal of shutting down the old delivery path and, more importantly, identifying which part of the old delivery path can be discarded and which part has to be redirected. This is the case in a multiple producer example as shown in Figure 6(b). After the fetch message reaches the border broker of a relocating client C, the second phase terminates.

The last phase is the actual relocation of cached messages for client C. A standard replay message as already being part of REBECA is used to sent messages from the old location to the new location.

An additional goal is to “garbage-collect” those parts of the old delivery path between junction and border broker not used anymore for message delivery. The replay is propagated along the old delivery path in the direction of the junction, from there it is sent along the new path to the new location of Client C where old notifications are delivered to the client eventually. After termination the effect of the algorithm is that a relocating client effectively has bridged phases of disconnected operation, without losing notifications and with almost the same delivery guarantees as in the non-mobile case.

Build an algorithm which is useful for

“Legacy” applications

• Already deployed
• Unaware of mobile environments and problems involved

• Install and maintain (local) buffers in border brokers
• Buffer notifications N for client C at broker B1 until:

• Client must re-issue subscriptions at (potential) new locations (case 1 and 2 above)

• Phase 1: subscription propagation

• Phase 2: junction Broker

• Phase 3: fetch

• Phase 4: replay

• Phase 5: de-allocation

• Phase 6: FIFO and event delivery

Device heterogeneity is not a unique characteristic of pervasive computing, but can be found in conventional systems, too. Different middleware systems like CORBA, Java RMI or DCOM have been developed, to provide a homogeneous access to remote entities independent of e.g. operating systems or hardware architectures. Typically, these middleware systems try to provide as much functionality as possible, which leads to very complex and resource consuming systems, that are not suitable for small devices. Approaches to solve this problem exist and are discussed below. Conventional middleware systems are designed for mostly stable network environments, in which service unavailability is a rare event and can be treated as an error.

Extending conventional middleware systems to dynamically reconfigurable middleware systems, enables such middleware to adapt its behavior at runtime to different environments and application requirements, e.g. how marshalling is done. Still, different communication models or different protocols for outgoing and incoming messages are typically not supported. As one exception, the Rover toolkit provides this functionality for its queued RPC (QRPC) concept, layered on top of different transport protocols. However, Rover only supports the QRPC and addresses potentially disconnected access to an infrastructure and not spontaneous networking. A further difference from BASE is that most existing reconfigurable middleware systems concentrate on powerful reconfiguration interfaces and not on supporting small, resource-poor devices. A notable exception to this is UIC, which is discussed below.

The resource restrictions on mobile devices prohibit the application of a full-fledged middleware system. One way to address this is to restrict existing systems and provide only a functional subset leading to different programming models or a subset of available interoperability protocols. Another option is to structure the middleware in multiple components, such that unnecessary functionality can be excluded from the middleware dynamically. One example is the Universally Interoperable Core (UIC). UIC is based on a micro-kernel that can be dynamically extended to interact with different existing middleware solutions. Still, the used protocol stack is determined before the start of the interaction and cannot be switched between request and reply as in BASE and abstractions are only provided for remote services. Most recent research efforts of middleware are shown in the Table 1.

Table 1. Recent Research effects

The traditional middleware solutions however have been designed for a complete different operating environment than where pervasive devices of today and tomorrow will live so they are not suitable solutions without (radical) modifications. Ubiquitous middleware are becoming the nowadays trend in the development of ubiquity in computer science fields. Ubiquitous applications rely upon this layer, to profit from the diverse functionalities it has to offer. Ubiquitous environments brought more constraints and challenges to mobile environments. The main constraints come from, the environment's heterogeneity and dynamics, and the variable connectivity of the devices coming and leaving. The main challenges are in maintaining the computing smartness, scalability, invisibility and pro-activity for the users in these environments. The functionalities offered by middleware need to cope with these challenging nature of environments. We sorted the middleware in two groups. The fully-integrated ones, provide functionalities such as discover y, adaptation/composition, and context management. The partially-integrated ones, provide one or two of these functionalities, as they were specifically developed for a specific purpose. We classified these middleware, by analyzing if they are interoperable, discoverable, adaptable, context aware, scalable, secure and autonomous. The development of the service-oriented paradigm, the semantics and the Web middleware shows the new trend the middleware research field is engaged in. At the other hand the intersection of this research field with artificial intelligence and autonomic computing leads to the development of the ambient intelligence, the future evolution of ubiquitous computing.

The ultimate purpose of the middleware is to ease the development of the end user applications. The already mentioned interoperability remains to be a problem, which is usually solved by writing application for just one platform, or pair of platform that are a “natural fit” to each other. For the application architect today the most important issue to solve during the design phase of a new application is how connect the mobile device to backend servers.