Using Jini to Enable Pervasive Computing Environments Karthik Harihar
Stan Kurkovsky
Department of Computer Science Columbus State University 4225 University Avenue Columbus, GA 31907 1-706-568-2410
Department of Computer Science Columbus State University 4225 University Avenue Columbus, GA 31907 1-706-565-3520
[email protected]
[email protected]
ABSTRACT Pervasive computing is a vision aimed at facilitating access to information anywhere and anytime, wherein stationary and mobile devices interact seamlessly to aid the users in their tasks. As the enabling hardware becomes smaller, smarter and cheaper this vision is poised to become a reality. While hardware devices form the building blocks of pervasive environments, a pervasive environment requires a robust software technology that can integrate them into a single cohesive unit. This paper discusses the suitability of Jini networking technology as an enabling and integrating technology used by pervasive environments. Specific issues of Jini’s suitability for mobile devices and alternative technologies are also discussed.
Categories and Subject Descriptors C.2.4 [Computer-Communication Networks]: Distributed Systems – distributed applications. D.3.3 [Programming Languages]: Language Constructs and Features – frameworks.
General Terms Design, Reliability, Security, Languages.
Keywords Jini, pervasive computing, smart services, mobile devices.
1. INTRODUCTION Rapid advances in network technology led to the development of new computing models from distributed computing to a new generation of large-scale ubiquitous computing environments, in which smart services are able to interact with each other and adapt themselves to the changing environment with little or no manual intervention. With decreasing costs and increasing capabilities of the essential components of pervasive environments, such as mobile devices, sensors and wireless technologies, ubiquitous access to information is poised to become a reality. In order to be successful, a pervasive system needs to be simple and based on a Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. 43rd ACM Southeast Conference, March 18-20, 2005, Kennesaw, GA, USA. Copyright 2005 ACM 1-59593-059-0/05/0003…$5.00.
widely accepted and robust technology providing sufficient flexibility based on the requirements of specific applications. The Jini API [2] extends the Java programming language, which is widely accepted as a standard for object-oriented software development. Jini has several features necessary to provide the fundamental infrastructure required to integrate disparate smart components. In this paper, we show that Jini is capable and suitable for developing pervasive computing environments. The paper is organized as follows. Section 2 discusses pervasive computing and its elements. Sections 3 and 4 give an overview of Jini and its suitability for use in pervasive environments. A discussion of Jini and mobile devices is presented in Section 5, followed by a comparison of Jini to several competing technologies in Section 6. Section 7 presents a brief survey of several pervasive computing applications implemented in Jini. Section 8 concludes this paper with a brief summary.
2. PERVASIVE COMPUTING Pervasive computing is a concept wherein aiding computing devices and technologies are mostly invisible and integrate seamlessly into an environment conducive for users to perform their tasks. A pervasive computing environment is a collection of a wide variety of smart devices and services that react to their environment, coordinate with each other and network services to assist the users in completing their tasks, and provide them with ubiquitous access to information [12]. The vision of pervasive computing environments is about enhancing our world with devices and technologies that vanish into the background and become a part of our natural environment. This integration frees users to use the technology without restraint and much thought and allows the users to focus on more important tasks [20]. Pervasive computing has the potential to change the way we do things in our day-to-day activities. Some of the potential applications include smart homes, which can adapt automatically to their inhabitants, smart vehicles that can adjust depending on the person driving it, etc. The enormous potential of pervasive computing attracted tremendous attention both from academia and industry with many projects currently underway. The Oxygen project [9] at the MIT envisions a future where ubiquitous computing devices are freely available and easily accessible as oxygen. The goal of Project Aura [10] at the Human Computer Interaction Institute of Carnegie Mellon University is to provide users with an invisible ambience of persisting computing and information services regardless of location. Major corporations are also researching and developing new projects in pervasive technologies, which include the Planet Blue [14]] project at IBM and the Cooltown Project [13] at HP.
1-188
3. JINI NETWORKING TECHNOLOGY Jini is a dynamic open architecture networking technology enabling spontaneous networking of services. The primary goal of Jini is to enable any service (software component or a hardware device that has a processor, some memory and network connectivity) to interact with one another without worrying about drivers, protocols, and operating system compatibility. Jini was developed with an assumption that the network is unreliable and services were to be transient; it provides a robust infrastructure for defining, advertising and finding services in a network [5].
3.1 Jini Architecture The core objective of Jini [2] is to enable dynamic addition and removal of distinction between the hardware and software
The robust architectural design of Jini stems from the fact that it does not assume the network to be reliable and secure with zero latency. Jini architecture has been designed to take into account the problems inherent to networks, such as latency, low bandwidth, and thus provides a powerful, secure, resilient and scalable distributed environment where both services and clients (hardware and software) seamlessly interact with each other. The goals of Jini architecture are [5]: to enable network plug and work, to provide a service-oriented view, to erase the hardware and software distinction, and to enable spontaneous networking. As Jini advocates simplicity, creating a Jini service is simple with most of the complex details being handled by the Jini system itself. Jini provides the type safety features available in Java. Jini ensures reliability by providing mechanisms such as leasing to handle partial failures in the network. By viewing everything as a service, Jini allows easy access for clients/services interested in using them from anywhere on the network. Also, this view helps in erasing the distinction between a hardware device and software as Jini is not particular about the internal implementations as long as it conforms to the Jini specification [1]. Jini enables ad-hoc network formation through mechanisms such as service discovery/join and distributed events. Services plugged in to the network can discover other services and interact without expending much effort.
Jini
Since a pervasive framework includes a variety of devices that need to interact seamlessly, it needs a robust technology that can integrate these devices into a single unified environment. Jini is a self-configurable and self-diagnosing distributed network platform enabling the creation of network-centric services that are highly adaptable to change. Jini is based on the widely used and popular Java programming API and provides several vital features for building pervasive computing environments. The following section provides an overview of Jini.
network components (plug and work). A Jini federation is a community of autonomous, co-operating entities that satisfy the minimum requirements for joining the network and connected together by the Jini network [7]. Devices in the Jini federation offer services and consume services of other members of the federation. The Jini architecture is a distributed extension of the Java language system (Figure 1); it provides a single homogeneous platform for execution irrespective of the underlying host environment. Jini also supports non-Java objects by wrapping them in Java code, which makes it not languagecentric, but application-centric [3].
Java
A pervasive computing environment consists of several critical components such as compact mobile or wearable devices, sensors, controllers and wireless connectivity medium [1]. In general, pervasive computing environments have the following characteristics: ubiquitous access, context awareness, intelligent behavior, and natural interaction. Along with these features, pervasive computing systems must also be reliable and secure. Ubiquitous access refers to an environment wherein users are surrounded by computational power and applications and can access information anytime and anywhere. In order to support ubiquity, devices in a pervasive environment must be able to discover and seamlessly interact with each other. Dey [21] defines context as any information that can be used to describe the situation of a person, place or object relevant to the interaction between an application and its user. Using context information provides an application with the ability to offer relevant information to the user. Ubiquitous services are context-aware in terms of awareness, ability to recognize and adapt themselves to location, time, devices and their users. Intelligence in pervasive computing describes the ability to adapt to user behavior, personalization of services and supplying users with information at the right place and time. Along with the support for user mobility, pervasive computing environments must be able to adapt themselves at runtime to handle variation in resources (e.g. network bandwidth) due to the mobility of the user, system faults (e.g. component failure) and changing the user needs and priorities with minimal human intervention [8]. Grimm [12] describes three design principles for pervasive systems in order to provide support for dealing with change: expose change instead of hiding it; support dynamic composition and extension of applications and services at runtime; and provide a clean separation of data and functionality. Natural interaction in pervasive environments refers to a system modality where the same functionality is delivered through many interface modes, such as voice (speech recognition and synthesis), wireless interfaces, or gesture recognition.
Infrastructure
Programming model
Services
Discovery/Join
Leasing
JavaSpaces
Distributed Security
Transactions
Transaction Manager
Lookup Service
Distributed Events
Java Virtual Machine
JavaBeans
Java RMI Java Security
Events Delegation Model Swing Graphics Toolkit
Enterprise JavaBeans Java Naming and Directory Service Java Transaction Service
Figure 1. Components of Jini architecture. The core components of the Jini architecture [2] are Infrastructure component, Programming Model Component and Services Component (Figure 1). These have only a fine degree of separation and are often interdependent on each other. For example, Lookup Service makes use of Leasing and Distributed Events.
3.2 Infrastructure Components Jini uses and extends the existing Java infrastructure mechanisms. Jini’s infrastructure is built on Remote Method Invocation, which is used for moving objects in a distributed setting. These
1-189
infrastructure components enable Jini with features such as service discovery and enhanced distributed security making it a powerful facilitator for network-centric computing. Jini provides a mechanism for dynamic network federation formation through its discovery/join protocols. Clients and services search for a lookup service through the discovery protocol that describes how the entities should search for the lookup service. Clients and services use a multicast request protocol by sending a discovery packet when the location of the lookup service is unknown. Otherwise, they send a discovery packet through a unicast discovery protocol. The lookup service provides a TCP-based unicast response to the requests. Periodically, the lookup service uses multicast announcement protocols to announce its presence in the federation. This enables the clients and services to re-register in case of any failure. Services join the Jini federation through the join protocol that specifies how a service should register with the lookup service. As Jini federation is a collection of Java Virtual Machines, it provides a stable and secure means for dynamic class loading needed for object mobility through the Java class loading mechanism incorporated in Java Virtual Machine’s. This allows only trusted classes to be loaded on to the client machine thus extending the Java security to the distributed environment. The central component necessary to form a Jini federation (djinn) is a lookup service that facilitates easy location of objects distributed in the federated network. The lookup service is implemented as a Jini service enabling a client interested in joining the Jini federation to find services through the discovery protocol and providing a mechanism for the services to join the network and advertise themselves. The lookup service is akin to the naming/directory/trader services used in CORBA, DCOM and other distributed technologies but is more robust and rich in features that support querying by name and attribute values such as service ID and type. It also eliminates the need for the client and the service to know “beforehand” the information about the naming service as in other distributed technologies. In Jini, the client and the service “discover” the location of the lookup service through the discovery protocol. The lookup service stores not only an object reference, but also service description, special properties (if any) along with the service proxy. As there can be multiple instances of lookup services running and services can register to any number of lookup service instances, a failure of a lookup service does not bring the entire community to a halt, which is an important feature missing in many other frameworks.
3.3 Programming Model Components The traditional Java programming model incorporates JavaBeans [23] (for Introspection), Event Delegation model (for event handling) and AWT/Swing toolkits (for generating graphics). Jini programming model extends the above to the distributed environment and incorporates features such as Leasing, Transactions and Distributed Events. A failure in a distributed system tends to be partial, i.e. a failure can be in one of the distributed components or a portion of a network; the system might not crash completely, but behave erratically. In a single host environment a failure is total in the sense that a problem brings the complete application to a halt and the pre-failure state information in the operating system can be used for recovering from failure [3]. Detecting and repairing the
erratic behavior of the partially failed distributed system is difficult due to the absence of a centralized mechanism to record the pre-failure state, which, in turn, necessitates a manual intervention. Jini addresses this need through its leasing mechanism. The concept of leasing resources or services in Jini architecture accounts for its self-healing, self-configurable and selfadministrable mechanism that provides resilience to partial failures eliminating the need for manual intervention. Leasing provides a means (contract) between lessee (client) and lessor (service or resource) for time bound allocation and de-allocation of resources or services that are renewable and cancelable upon request. This ensures that any client using the service will do so for a certain period of time and thus does not lock up the resources indefinitely. As transactions in distributed systems are complex, may be nested and involve heterogeneous resources, Jini defines a twophase commit protocol needed for the completion of a transaction, but leaves the transaction implementation details to the service. This provides the freedom for the implementers to decide how they want to get it done. Also, it incorporates leasing within the transaction mechanism to account for partial failures. Jini Distributed Event Model is an extension of the Java Event Model in Java Beans [22]. Jini Distributed Event Model provides support for remote event registration and reliable remote event propagation [3]. Jini allows events to be delegated to third parties. The distributed event protocol in Jini allows any object in the federation that is interested in any state change in another object to register and receive notifications when such a change occurs. The initial leasing period is specified by the client that is interested in the events and upon acceptance, the event source returns a feasible lease period.
3.4 Services Jini technology is mainly focused on services. The ability of Jini to treat everything as a service (service-oriented view) makes it possible to dynamically form a network of both devices and software services. Services are implemented as objects that need to conform to the Jini specification [2]; they are built of the infrastructure components using application components as their building blocks [3] and provide an interface describing the operations that the service offers, thus hiding the details of implementation from the clients. The lookup service enabling clients to find services and for services to advertise themselves in the Jini federation is implemented as a Jini service. Jini also defines and provides numerous other services such as Javaspaces service for storing related object groups and also to provide communication between these objects; Transaction service for aiding distributed transactions; Lease renewal service for handling lease renewals on behalf of its clients; Event mailbox service for event notification delivery to the interested clients and several others. The lookup service is the only mandatory service while others are optional third party services that can be used only when needed.
4. JINI IN PERVASIVE ENVIRONMENTS As mentioned in Section 2, a pervasive computing environment must support user mobility, adapt at runtime to handle resource
1-190
variation due to user mobility, handle system faults and changing user needs and priorities with minimal human intervention. In particular, the environment must provide support for dealing with change by exposing it instead of hiding it, support dynamic composition and extension of applications and services at runtime and provide a clean separation of data and functionality. The technology that glues these smart components and communicating technologies together into a pervasive framework must incorporate most or the entire feature set mentioned in Section 2. Let us consider a simple example. Most museums usually provide audio tour guides that viewers carry with them. Since different museum visitors may have somewhat varying interests, paying more attention to some exhibits than others, these tour guides might prove to be more annoying than useful. This is due to the fact that these audio guides do not adapt to their users, are hard to synchronize if they are used within a group of visitors and describe only a relatively small subset of the exhibits that may not be the ones a particular viewer is interested in hearing about [17]. In a pervasive museum guide, users equipped with handheld or wearable devices tour the museum equipped with pervasive technologies that co-ordinate to assist them based on their context, interests and several other factors. Jini has several interesting features that match the requirements mandated by a pervasive environment. We now look into how Jini can satisfy the demands of pervasive systems and use the museum guide as an example to illustrate our view. An important requirement of a pervasive framework infrastructure is to allow disparate smart devices to discover, join, communicate and collaborate with one another anytime and anywhere and therefore, provide ubiquitous access to the services offered by the system. In a museum guide, handheld or wearable devices should be able to discover and coordinate with other devices and display relevant information accordingly. Jini views both software components and hardware devices as a service and hence allows virtually any device to join the network. It supports “service discovery” through a lookup service and discovery/join protocol which allows the services to discover and join the network in order to interact with other services connected to the network with ease. As the code is downloaded to the clients that use the services at runtime, it eliminates the need for device drivers. Also, Jini can be used in conjunction with any underlying communication protocol, wired or wireless in order to enable the services to communicate.
attributes related to intelligence, it provides support for the required infrastructure for implementing the intelligent components through the application logic. Natural interaction in a pervasive computing environment refers to the ability of a system to support multiple interfaces so that the same functionality can be delivered through voice, wireless interfaces, or gesture recognition. Interfaces in a pervasive environment may be provided by the environment or by the handheld/wearable devices. In a museum guide, interface is provided by mobile devices as museums are quiet places. Also, a user interface could include other types of services such as a voice interface, a text interface or any other service that a component may provide or publish. Jini enables multiple user interfaces to be associated with a single Jini service through its ServiceUI adapter. This provides a mechanism to attach any user interface adapter to a service thus allowing a Jini service to be accessible by users with varying user interface capabilities. A pervasive environment must also be reliable and secure and adapt at runtime to handle resource variation due to user mobility and handle system faults. In our museum guide example, though the requirement for security is not so stringent, the system should provide the users with reliable information. Jini provides mechanisms, such as leasing, that offer resilience to partial failures in the network without the need for manual administration. Also, pervasive environments must provide mechanisms for examining and restricting access to potential threats or vulnerabilities. Jini extends Java in a distributed environment and thus provides the type safety features of Java and mechanisms for protection against malicious code running in the JVM. But, as Jini is a network technology, it should support the standard concepts of network security such as authentication, confidentiality and integrity. The Jini Davis Project [6] defines the security architecture for Jini that supports basic and nonuniform network security and also provides various security implementations with differing protocols, algorithms, mechanisms and policies.
5. JINI AND MOBILE DEVICES
Pervasive systems are context-aware and provide appropriate services to the users based on the context information in terms of awareness of location, time, devices and their users. Mobile devices in the museum guide should be able provide relevant information based on the context information. As Jini enables spontaneous network formation of services and can be used with any communication protocol, information about the context could be easily obtained through interactions between Jini-enabled smart devices.
While the features of Jini indicate that it is a good fit for pervasive environments, there are certain issues that must be resolved to fully enable the use of Jini in some components of a pervasive infrastructure. Though Jini’s service-oriented architecture accommodates both hardware and software devices into its network community, there are certain minimum requirements that every participant must meet in order to join and interact successfully in the Jini network; these include: storage, processing and network connectivity capabilities, ability to partake in the discovery and join protocols and also the ability to download, execute and export the code. Running a Jini system on mobile devices requires considerable computing resources that they do not always possess. Here we describe the efforts of the Jini developers’ community dealing with these issues in order to make it a powerful technology for enabling pervasive environments.
Pervasive computing systems exhibiting an intelligent behavior must have the ability to dynamically adapt to user behavior in order to supply the user with proper information. The museum guide should adapt to the varying patterns in user behavior and display useful information that is of interest to the user. Though Jini does not offer inherent personalization capabilities and other
Jini Surrogate Architecture [4] provides a means for devices that have limited capabilities to participate in the Jini network using the help of another Jini-capable component, which has the resources to participate in the Jini federation by meeting its requirements. The surrogate host is a machine that meets all the requirements of the Jini federation and has enough resources to
1-191
support the surrogate; it does all the work of Jini-enabling the surrogate by handling the Jini network requirements on behalf of the surrogate. The surrogate (proxy object of the device) and the device are in contact with each other through a interconnect adapter resident on the host machine and an interconnect protocol. Any protocol, wired or wireless can be used for communication between the host and the device. ServiceUI plays an important role in supporting natural interaction in a pervasive environment implemented in Jini, in which services should be able to support multiple interfaces in order to present the same functionality through different interfaces. Services must be attached to voice interfaces as easily as graphical UIs or any other special interfaces such as the ones that recognize gestures intended to help people with disabilities. Jini ServiceUI framework [19] allows Jini services to provide UIs for a variety of clients that can download them upon requirement. The underlying logic associated with the UI can also be downloaded along with the UI and run locally or can be accessed remotely depending on their deployment requirements [18]. Although technological advances have made mobile devices more powerful, they still have limited processing power, relatively small amounts of memory, short battery life and small screens. As Jini relies on the features of Java, such as object serialization, security and automatic codebase downloading, it requires a complete version of Java 2 virtual machine and a substantial amount of memory. A solution to this problem has been devised by researchers at Rochester Institute of Technology with the development of a miniature version of Jini for mobile devices such as cell phones, pagers, personal information managers, and personal digital assistants. Jini Mobile Edition (JiniME) [11] is designed for devices having the Java 2 Micro Edition (J2ME), Connected Limited Device Configuration (CLDC) and Mobile Information Device Profile (MIDP). A JiniME federation consists of a number of JiniME-capable mobile devices. JiniME technology also has an optional Jini Bridge that combines the standard Jini federation with a JiniME federation into a single federation. The bridge allows the services residing on the standard Jini side of the bridge to be utilized by the JiniME clients on the other side of the bridge and vice versa. While one end of the Jini Bridge is connected to the wired Jini network, it is connected to the wireless mobile network on the other side. In general, the main architectural distinction between JiniME and Jini is that every JiniME-capable device runs its own Lookup Service and HTTP server. Also, the Lookup service of a JiniME device contains the service items of only that device.
6. ALTERNATIVES TO JINI Features such as service discovery, self-healing and selfconfiguration make Jini a powerful tool for creating dynamic networks and facilitates its usage in pervasive environments. But Jini is not the only distributed computing technology that facilitates pervasive computing. Sun Microsystems faces stiff competition from HP and Microsoft who have designed and developed new technologies in order to facilitate interaction between devices. The most prominent ones are UPnP (Universal Plug and play) [16] from Microsoft and HP’s JetSend [16]. Microsoft’s UPnP is a distributed computing architecture aimed at enabling some components of pervasive computing. It is open source, open architecture, platform- and language-independent
and follows established industry standards for the web such as HTTP, SOAP and XML. It provides an infrastructure for dynamic device community formation [3] and like Jini, it also eliminates the need for device drivers and supports zeroconfiguration and automatic discovery [15]. In UPnP, any device that wishes to offer services, advertises through SSDP (Simple Service Discovery Protocol) and the clients use the same to query the services that they are looking for. HTTP GET is used to obtain more information about the services (by clients) and devices (by service providers). Service providers and clients interact using SOAP. Even though UPnP uses industry standards and works well with devices, it does not support software services at present. This lack of support gives Jini the edge in its usage for developing pervasive computing applications. HP has developed JetSend, a powerful, peer-to-peer, mediaindependent communications technology, allowing devices to connect together and exchange information in the proper context without the need to know any information about one another and eliminating the need for device drivers [16]. Devices are required to be JetSend-enabled, which means that they need to have the JetSend software that accounts for device interoperability and intelligent information exchange. JetSend brings with it a concept called e-material or a surface that each device needs to possess. The surface acts as a shared medium for devices to advertise their capabilities or announce their presence that can be used by other devices. Devices can communicate with each other through any protocol. JetSend has a simple but powerful architecture model; it is machine- and protocol-independent; it eliminates the need for device drivers and facilitates device interoperability. However, JetSend, like UPnP, is limited to device communication only and also imposes a requirement for devices to be JetSend enabled. These restrictions limit its choice as an integrating technology for pervasive environments. Table 1 provides a comparison of Jini features that make it suitable for pervasive environments with the alternative technologies discussed above. Table 1. Features of Jini and competing technologies Features
Jini
UPnP
JetSend
Protocol Independence
Yes
No
Yes
Self-Configuration
Yes
Yes
Yes
Self-Healing
Yes
Yes
Yes
Handling Network Latency Elimination of Hardware/ Software Distinction
Yes
Yes
Yes
Yes
No
No
7. JINI IMPLEMENTATIONS Even though Jini is relatively new, it has already been seen as a reliable technology for distributed and pervasive computing needs. This section discusses some of the implementations of Jini technology in pervasive environments. Eko systems Inc (http://www.ekosystems.com), a company focused on developing products for the healthcare industry used Jini technology to create an electronic patient monitoring system. The requirements for the system were: simple to operate, reliable, ability to capture and analyze patient data in real time to create electronic patient records at the point of care and the ability to include data output from a wide variety of medical equipment. The most important requirement for this system was reliability as
1-192
it was used for monitoring patient records and critical care units. Jini’s ability to accept any devices in its network without the need for device driver installation and also the way it handled the network failures to give a high degree of fault tolerance was instrumental in the development of a reliable system.
9. REFERENCES
One of the interesting Jini project in academia is the JGrid (http://pds.irt.vein.hu/jgrid_index.html) project being developed by the Parallel and Distributed Systems group of the University of Veszprem, Hungary. The goal of JGrid is to develop a Jini-based service-oriented grid infrastructure wherein components can dynamically join and leave the system at any time and the users can access grid services with ease. JGrid benefits from several features of Jini such as service discovery, leasing, serviceoriented view for creating reliable and dynamic grid systems.
[3] Kumaran, I. Jini Technology: an Overview, Prentice Hall PTR, 2001.
[1] Sathyanarayanan, M. Pervasive Computing: Vision and Challenges. IEEE Personal Comm., 8(4), 2001, pp. 10-17. [2] Jini specification. http://wwws.sun.com/software/jini/specs.
[4] Jini Surrogate Architecture Specification, http://surrogate.jini.org/specs.html. [5] Arnold, K. The Jini architecture: dynamic services in a flexible network. In Proceedings of the 36th ACM/IEEE conference on Design automation, (1999), 157 – 162. [6] The Davis Project, http://davis.jini.org/index.html#v2_0
Few companies have developed products that focus on resolving issues faced when using Jini for usage in pervasive environments. PsiNaptic (http://www.psinaptic.com) has developed a pervasive computing platform using Jini that consists of modular hardware and software that can augment an object's ability to interact in a pervasive computing environment and is called the “PsiNode” technology solution. Their JMatos software is a small footprint implementation of Jini and extends the capabilities of Jini to devices with embedded processors, thus bringing the power of Jini to resource-constrained devices. The PsiNode technology solution is a combination of JMatos, JVMs, embedded processors and standard communications protocols.
[7] Jini Technology - network-centric services, California Software Labs, http://www.cswl.com/whiteppr/tutorials/jini.html.
Zucotto Systems (http://www.zucotto.com/) has developed a commercial version of the Jini surrogate architecture called Edge Zucotto Xpresso that is designed to enable devices, from simple to complex ones to make use of and provide Jini services. Their high speed, low power embedded Xpresso processor is conducive for pervasive computing environments that are size constrained and require superior efficiency.
[12] Grimm, R. et al. Programming for Pervasive Computing Environments, Technical Report, UW-CSE-01-06-01, University of Washington, Department of Computer Science and Engineering, June 2001.
8. SUMMARY A pervasive environment accommodates a variety of devices, which interact with one another in order to provide users with anytime and anywhere access to information. Jini is an exciting new technology that shows promise with respect it its ability to facilitate spontaneous networking. Jini’s service-oriented architecture is instrumental in accommodating both software services as well as hardware devices. This is something that no technology has been able to offer before. Jini has the ability to satisfy the demands of pervasive systems, namely ubiquitous access, context awareness, intelligent behavior, natural interaction, reliability and safety. Jini has gained ground as a reliable technology for serving ubiquitous computing needs and has been adopted by many companies for developing pervasive applications. Although, several prominent corporations have introduced new technologies that are aimed at the same problem space as Jini, they lack certain features, which limits their effectiveness in implementing pervasive environments. The Jini Surrogate Architecture Specification and JiniME have been instrumental in making Jini a viable technology for use in pervasive environments.
[8] Cheng, C. et al. Software Architecture-Based Adaptation for Pervasive Systems. In Proceedings of the International Conference on Architecture of Computing Systems: Trends in Network and Pervasive Computing, April 2002, pp. 67-82, Springer-Verlag, UK. [9] Project Oxygen, http://oxygen.lcs.mit.edu. [10] Project Aura, http://www-2.cs.cmu.edu/~aura/. [11] Jini Mobile Edition, http://www.cs.rit.edu/~anhinga/.
[13] Cooltown, http://cooltown.hp.com. [14] Planet Blue, http://www.research.ibm.com/compsci/planetblue.html. [15] UPnP architecture, http://www.upnp.org/download/UPnPDA10_20000613.htm. [16] JetSend Introduction, http://www.embedded.com/internet/0001/0001ia2.htm. [17] Benjamin, B. Audio augmented reality: a prototype automated tour guide, In Proceedings of Conference on Human Factors in Computing Systems, Colorado, May 1995, pages 210-211, ACM Press. [18] Newman, M. User interfaces when and where they are needed: an infrastructure for recombinant computing. In Proceedings of the 15th annual ACM symposium on User interface software and technology, Paris, 2002, pages 171180, ACM Press. [19] The ServiceUI project, http://serviceui.jini.org. [20] Weiser, M. The Computer for the 21st Century, Scientific American, 265, 3, September 1991. [21] Dey, A. Understanding and Using Context, Personal and Ubiquitous Computing, Vol. 5, No. 1, pp. 4-7, SpringerVerlag 2001. [22] JavaBeans specification, http://java.sun.com/products/javabeans/docs/spec.html.
1-193
