Jini Supporting Ubiquitous and Pervasive Computing

Transcription

1 Jini Supporting Ubiquitous and Pervasive Computing Kasper Hallenborg and Bent Bruun Kristensen Maersk Mc-Kinney Moller Institute University of Southern Denmark Odense M, 5230, Denmark Abstract. The overall purpose of this article is partly to give a brief overview of the TangO conceptual model, partly to explore the Jini technology as a means for support of pervasive systems in general and the TangO conceptual model in particular, and to emphasize the advantages and weaknesses of the Jini technology for ubiquitous computing. We will validate our survey of the Jini Technology against the TangO model in general, and through an implementation of a Pervasive Shopping Mall in particular. 1 Introduction During the last centuries our everyday life has gradually become more and more globalized; we have reached a state where physical borders and distances only have weak impact on our collaborations and interactions. In the information ages we experienced new means of accessing an infinitive amount of information through the internet, and we are no longer constrained by technological issues for these matters on stationary PC s. But, the age of pervasive computing, we are about to enter, raises new challenges for researchers. Small intelligent devices will ubiquitously be deployed in our environment. These artifacts will even initiate interactions between humans and computers, which depend on the current context and preferences of the human. Interactions can happen anywhere and anytime, as it is clearly stated by Mark Weiser in 1991, In the 21st century the technology revolution will move into the everyday, the small and the invisible... As previous evolutions this will not happen overnight. One of the greatest challenges for ubiquitous computing (UbiComp) is the infrastructure for connecting devices and retrieving reliant and relevant contextual information. There seams to be an endless number of applications for this area, because we more or less could replace human activities with these intelligent devices, but social issues must be addressed in order to create useful and usable applications. No matter how simple the task seams to be, we will discover that an enormous amount of information must be taken into account, and it is very hard to predict and adapt to individual behaviors of the user. Devices will be smaller and more powerful; eventually they will disappear, as stated by Mark Weiser The most profound technologies are those that disappear. They weave them-selves into the fabric of everyday life until they are indistinguishable from it. This research was supported in part by Danish National Centre for IT Research, CfPC-Project No. 212, Flexible Inter Processing (FLIP) and The A. P. Mller and Chastine Mc-Kinney Mller Foundation.

2 These are the challenges for research and development in pervasive computing. An important issue for deploying artifacts into a pervasive world is to have an architecture supporting spontaneous collaboration among these devices. In this paper we will briefly describe a conceptual model (TangO) for modelling artifacts of the pervasive world. We will investigate the Jini technology from Sun to clarify if Jini offers the required supporting architecture for a pervasive system in terms of the TangO model. After examining the features and details of Jini, we will relate the capabilities of Jini against those required by the TangO model in general. Further we will describe an implementation of a Pervasive Shopping Mall, which we have designed and implemented to get some practical experience with the Jini technology. The system provides various functionality to customers in a mall, such a maps, guidance, event-notification and pop-up commercial when shops of interests are being approached. 2 Tango Conceptual Model We need a way to model these applications and scenarios of the pervasive world, in order to get a common vocabulary for talking about these systems. The TangO conceptual model [12] is an approach for such a modelling tool. 2.1 Abstraction and Spaces According to [12] we interact with artifacts in physical, informational, and conceptual form and we classify the artifacts as either tangible objects, habitats, or associations as illustrated by figure 1. habitats associations spaces Fig. 1. Illustration of tangible objects, habitats, and associations in physical, informational, and conceptual spaces. Tangible Object: an artifact that has been modelled and designed for the pervasive world, incorporating design factors from each of the spaces. Habitat: a logical context in which tangible objects exist and interact. Association: a relation by which tangible objects and habitats collaborate in a given way at a given time the actual collaboration is not predetermined by properties of objects and habitats. We elaborate on the understanding of the TangO conceptual model by discussing tangible objects, habitats, and associations at an abstract level, and exemplify these concepts by the example at the intuitive level. In relation to our example a mall will work as a habitat for the shops and persons, which are seen as tangible objects. The advertising activities are seen as examples on associations. The conceptual aspect of for example an advertisement includes in our understanding usually a good offer, usually a time limited offer, often quantity

3 limited, and we know that the (underlying) intention probably is to tempt us to come to the shop and in addition or instead buy something not planned and at standard price. The physical aspects of the advertisement include big boards at the shop announcing the offer (especially the price) as well as advertisements from newspapers. The informational aspect of advertisement includes the view from a printing house with properties such as size, format, contents, dates etc. The spaces are not discussed further in this article. Tangible Object, Habitat, Association We distinguish between descriptions and instances of each of the concepts tangible object, habitat, and association. By a description we establish a denotation for the mall habitat, whereas the individual malls are instances of the description. Instances of any of the concepts may be created (and deleted) dynamically. Instances of habitats enable tangible objects to move in (or out) of a habitat. The existence of tangible objects enables the instantiation of associations between individual formations of tangible objects. In our example a new mall may be established, shops may be organized within the mall, customers may visit the mall, and advertisements may be announced from shops to customers. Only tangible objects of type shop can be established in the mall tangible objects of type persons can only visit the mall. We return to how to use the qualification of a tangible object to protect and control the possibilities of the functionality in a later section. 2.2 Habitat: Basics We distinguish between physical and logical habitats (and mixtures of these). Both kinds of habitats may be limited in time, but only physical habitats have spatial limitations. The mall (and the shops in the mall) usually has opening hours and both have physical boundaries. We return to the problems with physical boundaries in a later section. Habitats may be related either by being at same level or by one habitat being local to another. The mall may have a cinema as one of its facilities. The cinema may be seen as a habitat itself local to the mall habitat and the various theaters within the cinema may in turn be considered local habitats of the cinema. We return to the problems with visibility of local habitats in a later section. As mentioned habitats may be created and added to our system. As part of the creation various relations to existing habitats may be created as well. Habitats may also be removed from the system in this case attention must be given to local habitats and to inhabitating tangible objects. 2.3 Tangible Object: Basics Tangible objects exist in habitats. A tangible object may be in several habitats at the same time in which case such habitats are seen as overlapping (a trivial case of this is the local/enclosing habitat when a person is in the cinema that person is also in the mall). In certain food courts at malls the restaurants often share a common eating area. This may be seen as an example of overlapping habitats for each restaurant we see the eating area as an integrated part of the restaurant habitat. The collection of tangible objects inhabitating a habitat at a given time has an implicit relation between them. Because they are in the same habitat the (collection of) tangible objects are visible for each other. A tangible object may

4 not want to utilize the relation or it may even refuse to be utilized through the relation, but potentially the collection of tangible objects is related. The shops of a mall probably utilize knowledge of each other s existence in the mall. A person entering a mall may want to utilize the mall to get in contact with relatives also in the mall or may choose to obtain anonymity for other visitors in the mall. A tangible object may be created and removed. Both operations have explicit potential consequences for tangible objects inhabitating the same habitats. When a shop is established in a mall the existing shops will observe its arrival. Tangible objects may dynamically enter and leave habitats again with consequences for other related tangible objects. When a person leaves the mall the advertisements from the shops in the mall cannot reach the person anymore and the person is outside the possibilities for the person search facility. We return to the problems of the legibility of a tangible object to enter (or leave) a habitat in a later section. We return to the problem with tangible objects being open to the public or anonymous in a later section. 2.4 Association: Basics Associations exist between tangible objects. An association can be temporary or permanent. An example of a temporary association is the advertisement from a shop to a person the advertisement lasts until either it expires or the person leaves the mall. Different kinds of associations exist. An association can be a simple relationship between tangible objects (possibly only supporting mutual knowledge of each other) or it can provide collaboration between collections of tangible objects. The simple relationship may be seen as a more general association with respect to for example collaboration as a more special type. The shops of the mall may only have knowledge of each other but no collaboration, whereas the interaction between several persons in the mall who utilize the search person facility is an example of an association of the collaborative kind. Associations can be established between tangible objects within the same or in distinct habitats (in the last case some alternative knowledge of its other is necessary, while there is an implicit knowledge available in the first case). The tangible objects must be potential visible to each other. Associations can be preserved in the case where a tangible object leaves a habitat alternatively, it may have consequences dependent on the nature of the association. When a person leaves a mall that person can probably not be available for the search facility of that mall anymore. On the other hand if the person has established a permanent customer association to shops in the mall such associations are typically preserved no matter if the person is actually in the mall or not. The creation or deletion of an association has explicit consequences for the associated tangible objects. If a search facility association is established between certain persons visiting a mall (assuming that the persons agree to take part in it) the persons may be involved in interaction and collaboration with various other persons potentially leading to physical or informational contact between typically familiar persons. 3 Jini Technology Jini tm technology is a Java tm -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 type-checking of the Java language, which requires a Java virtual machine (JVM) for all participants. Surrogate architectures connecting device and applications, which is incapable of joining the Jini community, is a way to work around these limitations.

5 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. Service providers deploys their services to the Jini Community by registering the services in Lookup Services, and obtains an unique ServiceID in return, which must be used for all future registrations to the same or other Lookup Services, to eliminate multiple responses to requesting clients. A service is a serialized Java object which resides in the Lookup Service after registration. Typically, the service object is just a proxy object, using the RMI protocol for remote invocations of a backend service object located in the Service Provider. The clients requests services from discovered Lookup Services by sending a ServiceTemplate, which defines the services of interest. The service template can contain any combinations of a unique service id, class types of the requested service, or a set of attributes, which have been registered with the service. 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. Even event-registrations are leased in the community, so automatic cleanup can be initiated for non-responding clients. These are the real benefits of Jini, and enables opportunity to create a self-maintaining ubiquitous environment. 3.1 Jini protocol services Jini is basically build on three basic protocols, the discovery protocol for finding Lookup Services, which could be either unicast or multicast discoveries. The join protocol for joining services to the Jini community, and the lookup protocol for requesting services. The reference Jini API implemented by Sun has a number of helper classes abstracting the underlying protocols. LookupDiscoveryManager, which manages the discovery protocol, for both clients and service providers. It automatically keeps track of all Lookup Services in the community, and event notifications will be delegated to listeners through this object. The LookupDiscoveryManager manages both multicast and unicast discoveries, by setting group names and locators, respectively, which can be modified dynamically during the lifecycle of the object. Simpler managers for either just multicast or unicast discoveries in also part of the net.jini.discovery package. JoinManager, which manages the deployment of a service for the service provider. It maintains the renewal of service registrations based on a default or given LeaseRenewalManager, and communicates with the Jini community through the delegated discovery manager. The manager automatically deploys the service into known Lookup Services or future discovered Lookup Services. The attributes describing the service can dynamically be modified through the JoinManager, which keeps the consistence for a multi-deployed service up to date. ServiceDiscoveryManager, which manages service discoveries for clients. It collaborates with a sets of discovered Lookup Services through a given or default discovery manager, just like the JoinManager. The client could either poll the lookup method for requested services, or register for events,

6 when services matching a given ServiceTemplate are discovered, discarded, or changed. The event listeners cannot be registered directly in the Service- DiscoveryManager, but in a LookupCache, which is created and kept up-to-date through the ServiceDiscoveryManager. The helper classes reduces the complexity of Jini applications and removes the focus from the fundamental protocols, but users must still be familiar with Jini principle and understand some of the basic aspects of the attributes, locators, groups, events, and leases for taking full advantages of the helper classes. The hard part of using Jini for a distributed system, it not due the understanding of the principles of Jini, but more the complicated scripts for compiling and running the applications. Usually, some development time must be reserved for struggling with codebase, policy parameters, setting up HTTP servers for code retrieval, and combining the relevant class files into downloadable jar files. 4 Jini Features In this section we will describe some of the features and capabilities of using Jini for supporting various general architectural aspects and concepts of pervasive and ubiquitous computing. Some techniques are well supported, while others either need some additional adjustments or workarounds, or are not supported at all. Because Ubicomp systems are so different in nature, it is hard to describe the features in terms of real systems, but examples will be given, and the descriptions is more an evaluation of the Jini Technology. In the next section some of the features and Jini in general, will be evaluated in terms of the TangO conceptual model. 4.1 Services and discoveries As stated previously, Jini is based on a Service and Discovery architectural approach, which have become quiet popular as web-services and internet applications have invaded our everyday life. The basic idea is that some system, a server, a device or whatever offers a service, which can be requested by clients. The clients locate these services by discoveries, either through one or more central servers (the approach taken by Jini) or directly from the service provider. Some approaches, like JXTA [21], just offers a set of protocols and all communications is done through XML messages. Compared to Jini, full implementations are provided by the reference implementation for establishing and handling communication. The communication is done by RMI, thus it requires no parsing of XML messages, but alternative implementations of the Jini protocols could use almost any communication methods. The list of service-based architectures is long, including SOAP [23], Sun Web Services [16], J2EE [15], Brazil [14], ECA, WSDL, KnowNow [11], and a lot of other standards specifies parts of such an architecture, like describing services by XML documents, but the protocols and communications principles for discovering and requesting these services, must be provided by a another standard. Jini includes it all, protocols for communications, means for describing services and an advanced event-system for asynchronous notifications of clients in the community. Thus, compared to many of the other architectures Jini offers a fairly complex architectural backbone for spontaneous collaborations between peer-to-peer clients. More standards will appear, but the concepts of services and discoveries seams to survive, not just for the near future, which is a positive argument for using Jini, but the strong trends for sending everything by XML, may leave Jini as a stand alone product, which is hard to integrate with other systems or require extra experiences from the programmers. Of course Jini implementations could use or shift towards more XML-based protocols, but it might violate some of the original ideas of Jini, and for performance reason some of the other standards might be more appropriate.

7 4.2 Experience required Jini is more or less defined by a set of Java APIs, thus programming with Jini should be quiet easy for Java programmers. But, some experience and detailed knowledge of the Jini protocols and ideas are required for taking full advantage of the Jini technology. Set up a simple system, deploying a service, and looking it up from a client is quiet easy, and experienced Java programmers would be able to create a simple Jini service and client in less than an hour. The hard part of using Jini for such simple systems is not writing the actual code but setting up the Jini system. One of the strong arguments for using Jini is for creating self-maintaining and re-configurable devices, which can handle changing network connectivity. But, setting up the Jini system in the right way, actually requires some detailed knowledge of classpaths, codebases, HTTP repositories and security policies, and could easily require several hours of work, even for an experienced programmer. Providing the right stub and class files for clients through HTTP servers and codebases, usually requires several tests before everything is running smoothly. The good thing is, that a Lookup service never have to be restarted when first loaded, at least theoretically, thus when the system is set up it could run forever. Then the programmer could care less about these setting, and only additional HTTP servers may be required by new service providers, or perhaps multiple activation daemons, when running Jini in a distributed environment. Creating well-behaved services requires more than just a quick survey of the API documentation. Deploying a new instance of a service when recovering from a network failure or system breakdown, seams to work fine from the service providers perspective, but for clients in the community, who are looking for services of such a type, should not be notified about the appearance of a new service, when it comes alive again. The service has previously been discovered as a new service, and the client might already have lost interest for this particular service. The problem is that Jini services joining the community are assigned a unique service-id, which is transparent for all lookup services, where the services are deployed. Thus, after a system failure in the service provider, the service is restarted but the service-id is lost. It is avoided by setting a persistent-storage for all services, to which service-id and other configuration settings are stored. When restarting the service, settings from the storage could be retrieved and used in the join process. It is just one example, where the programmer has to know some details of the Jini protocols, in order to create a well-behaved service, because these ideas are not supported by the Jini API or utility classes. One way to work around these problems of using Jini is by relying on a service toolkit, which extends the Jini concept by more user-friendly interfaces, and hides some of the details of the low-level Jini protocols, by providing a set of utility and helper class for Jini system. Such a toolkit is described in [9]. 4.3 Spontaneous networking One of the fundamental ideas behind Jini is support for spontaneous networking, where network resources are not assumed to be reliable. The Jini system is a self-maintaining environment, where all peers could be notified about changes in the Jini community, such as deployment of new services or discarding existing ones. So a service or a resource is only trusted for a given lease duration, which is granted by the Jini community for any type of registration, such as service or event registrations. If a lease has not been renewed before it expires, the Jini community removes the registered service and free any resources related to that registration. This is a very strong mean for handling network systems with a high failure rate, or scenarios with a high number of spontaneous and dynamic arrivals and departures of collaborators of the network. It requires a minimum or almost none control and checking of the participating artifacts regarding their

8 current state and connectivity to the network, but is not a bullet-proof technique. Network failures could still happen within a lease period, resulting in dangling references. For a service, which is transferred as a serialized object to the lookup service, full access to service will continue even after the lease has expired, thus only the conceptual aspect of a service from a connected service provider is violated. If the deployed service object is just a proxy for a backend service, the client have to check for RemoteExceptions in any interactions with the service objects, which removes some of the transparent and high-level support for spontaneous networking, but the alternatives would require unlimited amount of performance. Any peer, who intentionally leaves the community before the end of the lease periods, should cancel all registrations to the community and discard deployed services. Then event notifications will be sent from the community to listening peers, which could have interest in such changes or even abort interaction with a service from a provider. The event system is an important piece of the spontaneous networking paradigm, because clients could listen for almost any type of changes, deployment or discarding of a particular service in the community. The event system is also efficient, because deployment of a new service requires no scanning of participants or initial negotiations before collaborations can be established. Jini offers little or no support for automating the process, clients must register for all events of interests and add appropriated listeners. A toolkit, like the one mentioned above, could enhance the interface to this event system, and provide a basic setup of registrations and listeners. 4.4 Serialized or backend The lookup service in a Jini community is the central repository for all services. More than one lookup service can exist within the same community, and the set of joined services do not have to be distinct. The utility classes of the reference implementation handles multiple joins as a single service completely transparent for the client, which is one of the strong arguments for the unique service-id mentioned above. A service object in a lookup service could be a full-blown service represented by a serialized object, or just a proxy object to a backend service residing in the service provider. A simple and full service is just a serialized Java object residing in the lookup service, which is completely independent of the JVM of the original service provider. This type of service is useful for providing static information or simple functional results. Providers have to be careful about using this type of service, because contextual information will be dependant and retrieved from the client not the provider. Any information send to the service object will never leave the client s JVM, thus it will have no impact on returned service objects for future requests to the lookup service, because the service is not transferred back to the lookup service after end of use. Such services is useful for instance to describe artifacts in a pervasive system, each device could provide a descriptive service, exposing any information, which could be useful and are allowed to be retrieved by any other artifact in the community. It could even be limited to a selected group of participants, by joining the service to a specific group in the lookup service, but the default Jini system, do not prohibit any client from joining any group. The alternative to the simple service object is a proxy object to a backend service. Typically, the service is implemented as an extension of the Unicast- RemoteObject, which is a server object from the Java RMI library. Stub objects to the service will be registered in the lookup service representing a remote interface through which the clients can interact with the backend service. In other words will the stub object act as a proxy object to the backend service, but the client cannot tell the difference. By this mean we can make the service

9 behavior dependant upon the current state of the provider, not the client, and even contextual information can be retrieved from the provider. This type of service is even more constructive than the simple, because all the simple services could be implemented by this mean as well (properly not that efficient), but there is a huge set of complex service, which could not be implemented by the simple service. Consider a moving artifact with some sort of positioning device, like a GPS receiver, it could provide a service giving proximity information to a certain object (could be an argument to a service method), which have to rely on sensor data of the provider. Alternatively, the provider could redeploy or update the service, whenever the context information is updated, which would scale very badly for most applications, but that is a trade-off between polling the service and change the service according to the current situation, which is left as a typical design decision to the programmer. 4.5 Event system One of the most important features of Jini is the event system, which is built on the same well-known principles from the GUI libraries of Java (AWT and Swing); the main difference is the distributed aspect. Some additional concerns have to be taken into account for a remote event model, compared to an event system in a single JVM. Within a single JVM we can assume a generated event always will be delivered, otherwise it would be most likely that the entire JVM has crashed, but in a distributed system failure could happen in the communication or the listener could have crashed or been temperately disconnected. Even the sequence of the event notifications cannot be assumed to be received by the same order of generation. Furthermore the latency for an event send from the generator to the listener must be considered in the design phase of the system. These problems makes it somewhat harder to work with events in a distributed system, than within a single JVM, but Jini comes with a utility packages (mercury), which is best described as an event-mailbox. 4.6 Administrating services Jini offers the opportunity that service providers can make their service administrable. Basically, it means that any client can modify the configuration of a deployed service, not the actual service object itself unless the service allows it, but settings like the attributes for the service, joined groups of the community, or even destroy the service. For a service to be administrable it must implement the Administrable interface, which defines a getadmin method. By invocation of this method, the service object returns an object implementing the administrable methods for the service. The Jini API defines 3 general interfaces for administrable services, named JoinAdmin, DestroyAdmin and StorageLocationAdmin. Through the first interface you can modify the set of lookup services to which the service is deployed, either by groups (multicast) or specific URLs (unicast), and the attributes set with the service. The DestroyAdmin allows you to destroy a service and notify the community from a client. The last one let you retrieve or specify a new storage location for services with persistent storage. It is still up to the service provider to decide whether a service should be administrable from clients or not, it depends on whether the service object implements the Administrable interface or not. The service provider itself could still administrate the service without implementing the interface, but clients, who have to lookup the service through a lookup service, would only have access to methods defined by the service provider, and the Administrable interface is a reasonable way to handle these ideas. The only problem with administrating services in Jini is security and authentication of the client, but this goes for every part of Jini. It seams that according

10 to the fundamental ideas of Jini, every participant of the community could be trusted. The lookup service does not care about which client request which services, as long as the service is available, a lease will be granted for the client. The only way to differentiate between the clients, is by grouping services in the lookup service, but there is no way of restricting which clients have access to which groups. Truthfully, most of these problems can be handled by extending the basic reference implementations from Sun, but then Jini fails as a complete and easy architecture for pervasive and ubiquitous computing. 4.7 Landlord leases The default lease principle of Jini described above could be manipulated in several ways. The Jini utility packages includes an API for customized lease handling, known as the Landlord lease system. Basically the Landlord system provides a set of interfaces and a paradigm of programming custom leases in Jini, but you have to do all the work by yourself. You must implement the Landlord interface for your lease grantor, which includes methods for renewing and cancellation of leases. How you will give access to the resources hold under lease, you have to decide by yourself, no methods has been specified, because it depends on the logical context and content of the lease grantor, as for the core Jini classes where register and notify are the names of the methods for registering services and event notifications respectively. Whenever you will grant a lease to a client, a new instance of the LandlordLease is created through the LandlordLeaseFactory, which is an inner class of the LandlordLease class, and takes a requested lease duration, a cookie for the resource, and a reference to the landlord object as arguments. The last part is important, because your landlord will be a remote object to your LandlordLeases, which are returned to the clients. By this mean LandlordLeases could be managed by the default LeaseRenewalManager of Jini, because when the manager wants the lease to be renewed the lease setup a RMI callback to the landlord, and asks for a new lease duration. You decide the leasing policy in terms of the methods for renewing and cancellation of lease, and the method for getting the lease in the first place. 4.8 User Interfaces Jini specifies no way of providing user interfaces for services; a client must rely on the interface specified by the service provider. This might be good enough for a number of smart Jini-enabled devices collaborating in a Jini community, where they are completely aware of each other and the services provided, but as soon as humans are participating in the community through PCs, PDAs, etc. and wants to interact with services, or the details of the service interface are unknown to the clients, more advanced user interfaces are required. Graphical User Interfaces (GUIs) is currently the way to support the most flexible interactions between humans and computers, thus the requirement for providing GUIs for services can not be left out of a successful architecture for pervasive computing. There are a number of ways to provide UIs for services, but several issues have to be taken into consideration, because in order to support a number of different client platforms, the service object must provide different GUIs, like for PDAs, Swing or AWT based, etc. A project named ServiceUI [1] has been started in the Jini Community [17], which hopefully will become part of the Jini specification in the future. The basic idea behind the ServiceUI project is that UIs should be provided as attributes to the service being deployed. Another problem of working with GUIs is static references to the GUI environment of the instantiator of the GUI object, which means that the service provider cannot instantiate the GUI as serialized objects

11 and provide them for the clients, because for most GUI libraries like Swing and AWT, the GUI object will then hold references to the memory space of the service provider. To work around this, the GUI objects provided as attributes to the service, must be GUI factories, so the real GUI will be instantiated by the client using the factory methods. The ServiceUI API defines a wrapper entry for these factories, known as the UIDescriptor public class UIDescriptor extends AbstractEntry { public String role; public String toolkit; public Set attributes; public MarshalledObject factory; } public UIDescriptor(); public UIDescriptor(String role, String toolkit, Set Attributes, MarshalledObject factory); public final Object getuifactory(classloader parentloader) throws IOException, ClassNotFoundException; where the toolkit indicates the required GUI library on the client, such as javax.swing or java.awt. The role specifies the purpose of the GUI, three types have been defined in the ServiceUI API; MainUI, AdminUI, and AboutUI. The set of attributes could contain any information used to describe the GUI. The factory member holds the factory object for the GUI as a marshalled object appropriate for serialization. Currently, eight standard factory classes have been defined in the ServiceUI API; DialogFactory, FrameFactory, JComponentFactory, JDialogFactory, JFrameFactory, JWindowFactory, PanelFactory, and WindowFactory, all representing the corresponding classes from the java.awt and javax.swing packages. Specialization still has to be performed in order to specialize for GUIs with other constraints, such as GUIs for PDAs, or they could be classified by the attributes. 4.9 Describing services by attributes In order to extend the search possibilities for services deployed in the community, services could have a list of attributes attached to the services. By this mean the clients do not have to know either the class-type or the serviceid of the service. The lookup process is initiated by the client setting up a ServiceTemplate, which partly consist of attributes to be matched by the services of interest. Attributes must implement the Jini Entry interface, but are typically specializations of the AbstractEntry class, which implement basic object methods. An entry A matches an entry B if it is the same or a subclass of B, and all their common public and non-primitive fields are equal. Jini comes with a set of standard entry types for describing standard information, such as service info, status, name, address, and location. Because attributes could be manipulated through the administrative interface, we must be able to control, whether an attribute could be changed by anyone or not. This is handled by the ServiceControlled interface, which is implemented by 3 of the standard entries (ServiceInfo, Status, ServiceType). When the client have received an administrative proxy object, like JoinAdmin, for the join process of a service provider, it will implement methods such as addattributes and modifyattributes. The administrative object will forward these messages to the JoinManager of the service, which have two versions of these methods. A strict version editing the attributes straight forward as expected, and a safe version with a flag indicating if services should be checked to determine if they are service controlled. If the administrative object forwards these messages through a checked safe version, then clients, who are attempting to manipulate service controlled entries will receive a SecurityException.

12 If services are discovered through the ServiceDiscoveryManager helper classes, a ServiceItemFilter could be used in the lookup process in addition to the ServiceTemplate. This interface defines a check method taking service items found by the standard lookup process as argument, and any additional checking of the service or attributes could be performed by customized implementations of this method, such as checking if a given value in an attributes is within an interval of accepted values, because traditional entry matching just compare entries by equality Java Spaces, support of transactions In addition to the infrastructure support, Jini offers a tuple space like service, known as JavaSpaces. As previous tuple spaces, such as the Linda System [8], JavaSpaces works as a distributed shared memory, but in contrast to tuples in the Linda System, JavaSpaces can store real Java objects, and be used to anything from a shared blackboard to a transaction model. The malaho service included in the Jini utility packages is a transaction manager for distributed clients. The approach for using transactions is rather simple, because basically you create a transaction object using the factory methods of the TransactionFactory class; either a standard or a nested transaction. Once the transaction has been created, clients can start grouping operations into the transaction. Currently, JavaSpaces is the only service in Jini supporting transactions, and the three basic operations on the space (read, take, and write) take a transaction object as argument. All operations grouped into a transaction using these methods will be executed when the transaction is being committed, and changes made to the space will first take effect if all operations are committed. Until the transaction have been committed, only clients holding the transaction object could read the space as it would look after committing the transaction, this is useful if a set of objects wants to hide information for all participants of the community. If they share a transaction object, the information could be put onto the space by one of the transaction holders and read by another. Eventually, the information could be securely removed from the space before the transaction will be committed, and other clients will never notice the content of the space has changed. As pervasive systems emerge into our everyday, many of these services, which are ubiquitously deployed in our environment, will be provided by companies and charged by use. Thus, transactions will be required in order to confirm if a user have received a service or not Jini on constrained devices The reference implementation of Jini provided by Sun is based on RMI from Java 2, which makes the real requirement of running Jini a JVM capable of running java code from the JDK 1.2. Thus, currently it is not possible to run Jini on PDA s using only reference implementations from Sun, because the latest implementation of the PersonalJava run-time environment for the Pocket PCs supports only JDK The J2ME implementations for Palm computers are even more constrained than PersonalJava. One way to run Jini on a Pocket PC, would be to the wipe out the Pocket PC operating system and install Linux onto the device, which includes a full JDK 1.4 (Blackdown). Several other approaches are possible as well, because PsiNaptic [18] have made their own implementation (JMatos) of the Jini protocols, which can collaborate with a standard Jini community. Recently, they have even enabled very constrained devices without a JVM or Java to participant in a Jini community and provide services to the community. Another approach is the SavaJE [19] operating system for ARM processors in

13 particular, which supports a full JDK 1.4.1, making it fully capable of running Jini. 5 Taking Jini for a Tango Previously, we have shown that creating a direct mapping between the TangO conceptual model and the Jini technology is clearly a hard job [10]. The different requirements for the TangO concepts in various applications make it impossible to make a simple and general solution fitting every purpose. Thus, it would be more interesting to investigate if Jini is useful and useable for implementing applications in respect to the TangO model. We will address the problems and concerns which have to be taking into account, when Jini is used as a networking architecture for such applications. The question is not whether it is possible to use Jini for such applications, because various workarounds and adapters can be added in standard Java code, but in stead we will examine if Jini is appropriate and do not violate the conceptual ideas of the model. Because the TangO model is closely connected to ubiquitous and pervasive systems in general, the outcome will clarify and expose the strengths and weaknesses of Jini supporting such systems as well. 5.1 Fundamental behavior of habitats and tangible objects Some of the most fundamental and important properties of artifacts in the pervasive world, is to dynamically move around and collaborate with a variety of other participants. In terms of the TangO model, we have various tangible objects which dynamically move from habitat to habitat and establish associations with other inhabitants. We could even have nested habitats, such as a local habitat limited by physical borders within a larger habitat, or logically as a more narrow classification of a wide collection of inhabitants. The number of levels in this hierarchy of nested habitats could be infinitive, but typically the most constrained habitats would have higher precedence, and only those have to be considered. Habitats with lower priority would just define some level of default behavior or functionality of the inhabitants. The basic functionality of moving in and out of habitats, establishing and breaking of associations between the habitat and the tangible object or among the tangible objects, is properly supported by Jini through the infrastructure for spontaneous networking. An advanced event system could be set up by the programmer in order to achieve the required model of the pervasive world with collaborative behavior. The challenge is collaborate within nested habitats. One way to achieve this by the help of Jini would be through groups in the community. Each lookup service is registered for one or more groups, into which the services can be registered. A client specifies the groups of interest in the multicast discovery protocol, thus we can selectively choose among a set of coordinated or nested habitats, but the clients have to be familiar with these group names, for instance through a service retrieval when entering the larger habitat. There is no built-in support for prioritizing the visible groups in a community, so the clients must chose the appropriate service or behavior using its own set of rules. This is a natural approach when thinking of human behavior, but it requires some amount of intelligence for complex systems. In many situations, when the tangible objects are augmentations of the real world, and closes the gap between a human user and the virtual world, a list of options could be presented to the user, and let the human do simple considerations. Jini could easily be extended with various tools supporting such ideas, but it would require some amount of work to do it in an intelligent way. The other part of merging or adjusting behavior from two or more habitats is

14 badly supported by the core implementation of Jini. Basically, it is the same problem, because if the functionality of a local habitat has to be adjusted or take advantage of functionality from the surrounding habitat, the habitat has to lookup the services and interprets them itself, and afterwards modifies its own behavior. Alternatively, the clients must merge these services from different habitats to gain something useful and appropriate, but it depends seriously on the problem of the current situation. Again helper classes and tools would be useful to assist the programmer with these decision rules. 5.2 The world of associations It is clearly hard to concretizing associations closer than those conceptual ideas presented in section 2. An association could be any kind of dependency or collaboration among participants. These associations are so different from system to system that is would be hard to systemize the development process, but the creation and establishment of associations are well supported by the Jini infrastructure. The event system would be handy to trigger the creations of new associations among participants in a habitat, or between the habitat and inhabitating tangible objects. Usually associations define some form of peer-to-peer communication between clients, which is easily achieved using backend services in Jini, but in some situations more than two participants must share a common communication media and collaborate all together. One participant could act as a master and manage and route the information to the others, but the approach suffers from the risk of a sudden failure of the master, due to network problems, system failures, etc. The JavaSpaces service available in the Jini system could be helpful in this situation, where all participants could communication through the space acting as an advanced blackboard for writing information and objects to other participants. This information could even be hidden for other participants by the help of transactions, but transactions could also be useful to secure individual parts of the collaborations. As anything, which is serializable, could be send as information or services through the Jini community, then almost anything programmable in Java could be used to construct associations, thus the programming model for association is as rich as we can get it, and should not cost us any trouble, just hard work for the programmer, because it would be hard to generalize from these associations. A toolkit could still offer some helper classes to setup the event system for creating and establishing the associations, and support the collaborative behavior between participants, so development and programming of these associations could be done on a more abstract level. 5.3 Describing unknown services to tangible objects Tangible objects would typically be introduced into new and unknown habitats when they move around in the pervasive world. They would have no idea of the functionality provided by the current habitat. They would try to retrieve these services and adjust or embed them into their current behavior, using the most profound and advanced intelligence of the artifact. Thus, the tangible objects require some form of dynamical adaptation and retrieval capabilities of unknown behavior at run-time. The hard part of using Jini to deploy services in a generic programming environment, is to describe the services in an appropriate way. These descriptions must be given in terms of attributes, but then these special attributes must be known by all clients and the service provider. Whereas dynamic class loading and codebases makes it possible for a client to retrieve services, which implementation is completely unknown beforehand. This is challenging in the perspective of pervasive computing, where artifacts could be introduced to a new habitat,

15 and are completely unaware of the functionality provided by the habitat. One way, would be to define a few general service types, which only have the purpose of transferring the real service with the whole functionality to the client, using dynamic class loading, codebases, and everything needed to setup the tangible object for the current habitat. Of course this mean raises the questions of vulnerability and privacy of the artifact, and the only means for preventing such attacks are security policies and trusted signed jar-files in codebases. Several attempts have tried to run Jini on top of an encrypted RMI, or similar protocols, but it requires a lot of customization. Another approach, which could be appropriate in some situations, is adapters or converting of services. In [22] it is described how a special service could be deployed in the Jini community with the sole purpose of converting services to an appropriate form. Basically, the service listens for services of known types that it has converters for. Whenever a service of type A is discovered, the service instantiates a new service of type B using the internal converter or adapter from type A to type B, and deploy the service into the community. When the original service is removed from the community, the converter service also takes care of cleaning up and removing the converted instances. It could be a useful mean for closing the gap between known and unknown services, by converting service to a more general form, known by more or all tangible objects. 5.4 Authentication, admission, and security When tangible objects move between habitats or retrieve functionality from the habitat, it all happen transparent to issues of privacy and security, not to speak about the constraints on being part of a habitat. From a conceptual point of view it is easy to limit the functionality to a selected group of artifacts, or decide if a tangible object is inhabitating a habitat or not. We have terms of security, privacy polices, user authentication, etc. to describe the allowances of the artifact, but from a programmer s point of view these concepts are not achieved that easy. Jini have little or no support for these problems, and it is up to the developer to customize the services and clients to achieve the necessary results. The default implementation of Jini from Sun works on standard RMI, thus there is no encryption or security whatsoever, but experiments and third party implementations have tried to cover this area, and could be used if necessary, because the Jini specification is open to almost any underlying protocols. Jini have no support for user authentication either, which could be useful by the lease grantor, in order to restrict the number of clients to a given service. The argument for not building authentication support into the lookup service, was that is would be fairly easy for hackers to sniff the authentication information, when no encryption is used and then pretend to be the user itself. Another problem of using authentication is that clients typically would trust lookup services, if they have logged in by a username and password. But, if a hacker has come across this information, he could setup a bugous lookup service, and Jini viruses could be born as services in this lookup service. Truthfully, some of these problems could be prevented by the sake of security policies and signed jar-files in codebases, as mentioned previously, but the problem of granting a lease for a service to a client is not just about identifying the user or not, it is also about context. Physical habitats are typically limited by physical borders, and it would clearly violate the concept of a habitat if the services are provided to any interested clients, which on their own decide if they are inhabitants or not. We cannot trust clients on such issues and grants for accepted clients only, would be a more natural approach too. The default lease grantor of a Jini community, the lookup service, has no restrictions for granting the lease. Any service provider registering a new service into the community will receive a lease registering for

16 a given lease duration, and clients requesting services from the lookup service will achieve full access to all services of a requested group. As described in the previous section the landlord leases is a way to implement custom lease grantors, but it suffers from some limitation in relation to decide whether a tangible object is in a habitat or not. For instance no information about the context of the client could be provided, when the lease have to be renewed. Thus, for a physical habitat, where crossing of borders determine if you are in or out, the landlord have to contact the clients and retrieve the necessary contextual information, which is inappropriate in stead of just providing the information in the lease renewing process, and makes the clients more complex in order to allow such a communication, but it gives a simple and general approach for the landlord system. Extending the default LandlordLease class is a technique to workaround this problem, but again you have to set up everything by yourself. Logical habitat could give a problem too, because we want to use the multicast discovery process of Jini in order not to set up any network addresses and configurations, but it would only work across a limiting number of gateways and not through firewalls. For a logical habitat the inhabitating artifacts could theoretically be spread all over the world, which seriously would disqualify the use of multicast protocols. To work around this problem, the client of a logical habitat must extract the URL of the lookup service representing the habitat, and use unicast discovery to reach this lookup service, when it is outside the reach of a multicast approach. 6 Pervasive Shopping Mall We have experimented with the implementation of a pervasive shopping mall, to get some practical experience with Jini for a scenario, which easily could be described in terms of the TangO conceptual model. We have tried to come up with some features for such a system, and the number of applications to support customers and staff members of the mall are endless, thus we haven chosen to implement just a few of these features, which were challenging to the Jini architecture. The system have never been tested in a real setup, which have not been the intension either, it has the sole purpose of experimenting and focusing on Jini as a supporting architecture. Thus, we allowed to use simplified techniques like GPS receivers to achieve the position information, which would not have worked in a real indoor shopping mall environment, but for a test case it does not matter. 6.1 Functionality of the system The main focus of the system was to provide support and information for customers in the mall. They could be provided with a map of the mall, showing their current location and properly highlight target stores. Shops could provide commercial to the customers, so when customers are in proximity of the shops, these ads will pop up on their screen if they accepted it by categories of interest. A number of other thoughts could be implemented as well, such as information about public transportation when you are close to an exit, announcement of special events in the mall, or even a friend-searching facility, which discover friends and relatives in the area, or a more general approach, which locate other people fulfilling some customized criteria. Such a feature might be restricted to a local habitat, such as a cafe-area or enabled when the same two people have stayed in the same narrow area and have been in proximity of each other for a while.

17 6.2 For the TangO point of view In terms of the TangO model, we could clearly identify some of the concepts in the mall example. The mall itself is a true definition of a habitat, not just for the customers acting as tangible objects within the mall, but also for the shops, which themselves are physical artifacts in the mall, but they are also informational artifacts to the mall, in relation to setting up the functionality of the mall, such as a map. 6.3 Implementation of the system The implementation of the system is build using the toolkit described in [9], which defines simple but general conceptual objects for the Jini community. The mall is the primary service provider in the system, which provides the functionality of the habitat. By the service made available to the customers of the mall, the customers could retrieve a GUI including a map and a message panel, where notification from shops and the mall would be announced according to the selected interests. The GUI is showed in figure 2. We have experimented with the ServiceUI API for transferring GUIs in the Jini Community, which also gave a convenient approach for announcing the functionality to the customer, even when they were unaware of the services provided. We just looked for services with an MainUI GUI object as an attribute. Fig. 2. Illustration of GUI downloaded by clients. Picture taken from hp.dk When the customer retrieves and initiates the UI hiding the low-level details of the functionality, they select the type of input for their current location, which could be either a GPS sensor on a specified COM port, or a selected file containing GPS sentences, which is intended for an indoor demo mode of the application. Coordinates from the GPS sensor is converted to Cartesian coordinates and related to the coordinates for the center of the mall, which can be inputted in the mall administrative window. The customer registers for messages and commercials through the GUI, and the event system of Jini makes it simpel to display new such services discovered or changed. Similar could the shops retrieve a map for selecting the spot in the mall, they want to rent. Afterwards they can start deploying commercials to the jini community in terms of serialized java object, because there is no backend functionality of a commercials. Both simpel text strings, styled documents and pictures are understood by the GUI of the customer.