to access a user-defined set of subscribed services including initiation and reception of calls, on the basis of unique personal network-transparent UPT numbers.
A CORBA BASED FRAMEWORK FOR UNIVERSAL PERSONAL COMPUTING ON THE INTERNET Mária Törö, Jinsong Zhu, Yalun Li, Victor Leung Department of Electrical and Computer Engineering The University of British Columbia 2356 Main Mall, Vancouver BC, Canada V6T 1Z4 {mariat, jzhu, yalun, vleung}@ece.ubc.ca
ABSTRACT This paper presents a CORBA based framework for universal personal computing (UPC) where nomadic computing on the Internet is supported for both mobile users and mobile terminals. In the UPC environment, a mobile user, identified by a globally unique logical identifier, can access computing resources anywhere on the Internet, using any available mobile or stationary terminal attached to any network supporting UPC services. CORBA, a middleware enabling platform independent distributed object-based computing, provides a natural framework to support the UPC environment. Using CORBA technology, computing resources can be modeled as distributed objects scattered around the Internet, and access to these objects is facilitated by CORBAservices and CORBAfacilities. We first define an object-oriented model for the UPC system in which UPC components such as user agent, user terminal agent, user profile, terminal profile, and initial agent are specified as a set of distributed objects. We then describe the necessary interactions among these objects to enable various UPC services, such as user registration and authentication. The interactions between objects are performed through CORBA, which allows objects to locate each other dynamically. Finally, we discuss our implementation efforts currently in progress. Keywords: Internet, user mobility, personalized computing environment, CORBA, agents. 1. INTRODUCTION The increasingly widespread use of portable computers and wireless communication facilities has opened up a new area of nomadic computing on the Internet [1]. With mobility support, mobile users can make use of their portable equipment, ranging from PDAs, palmtops, to powerful laptops, to access the Internet anywhere an
Internet connection (wireline or wireless) is available. In such an environment, it is often desirable to be able to provide mobile users with computing and communication services transparently, independent of their current location. Mobile IP, which provides transparent host mobility support on the Internet, allows a mobile terminal (or host) to be reached regardless of where it migrates. However, the binding between a mobile user and a terminal (mobile or stationary) is not addressed and is assumed to be fixed. This would not allow the location of a mobile user whose terminal binding may be changed, for example, when she uses a foreign (e.g. leased) terminal in a hotel or at an airport terminal when travelling. Moreover, in many cases, especially when a foreign terminal is being used, it is desirable for the mobile user to be able to use her familiar home computing environment and resources. This requires an additional level of mobility support over the Internet, which we call user mobility. The concept of user mobility exists in the CCITT (now ITU-T) Universal Personal Telecommunication (UPT) draft standard [2]. UPT is one of the applications of the Intelligent Networks, which aims at enabling users, irrespective of their current geographic locations, to access a user-defined set of subscribed services including initiation and reception of calls, on the basis of unique personal network-transparent UPT numbers. This access is limited only by the terminal and network capabilities. The extension of this concept is the Personal Service Communication Space [4] concept, which offers a wider range of telecommunication services and advanced service personalization on the basis of more powerful service profile management capabilities. A challenging aspect for TINA-C [3] is the extension of these to the concept of Nomadic Personal Communication Service (NPCS), which will provide user access to every kind of services in the telecommunication information network regardless of
the user’s location, even while migrating during a service session [4].
technical reasons, we assume that a terminal can be bound only to a single user at a time.
Universal Personal Computing (UPC) is a similar concept, which however targets the network computing world rather than telecommunications. This means that a user would be able to access her personal computing environment adjusted to the local facilities from any location, even during migration [5, 6]. Resources, applications and services configured according to the user preferences constitute the user’s personal computing environment. Since the goal is to provide global network access for the user, she may use for this purpose any available terminal at any place. Consequently, the available computing environment may vary over a wide range according to the capabilities of the terminal, the method of communication, and the facilities and services supported at the actual point of attachment to the network. To provide a specific personal computing environment for the user, the available facilities must be evaluated, compared to the user’s personal needs and adjusted to them as much as possible. This requires a virtually homogeneous distributed processing environment. The recent development of the Common Object Request Broker Architecture (CORBA) [7] by the Object Management Group (OMG) can provide this homogeneous distributed processing environment independently from the underlying hardware and software technology. In [8] it is proposed to use CORBA as the middleware layer for UPC.
The user’s personal computing environment is the set of resources, applications, and services adjusted to the user’s personal preferences. All this information constitutes the user profile.
The rest of the paper is organized as follows. We first give an overview of UPC and examine its requirements more closely. We then propose an object-oriented model for UPC, followed by discussions on applying CORBA technology to this model. We conclude by discussing our implementation efforts currently in progress. 2. OVERVIEW OF UPC Currently network computing users may access their personal computing environment locally at their home network, where they are registered and have an account; or remotely still using the resources of the home network. The goal of UPC is to provide global access to the network for a user regardless of her location, even during migration. In addition, the personal computing environment offered to the user by UPC during this mobility and migration shall be continuous and optimized as much as possible. By global access we mean that the user will have access to the computing environment from any geographical location where Internet access is provided, by means of any terminal available, whether it is mobile or stationary, owned by the user or provided by the service provider or a third party at the location. Since the user-terminal binding does not mean a physical binding, the user is allowed to have multiple simultaneous terminal bindings. For
The user profile can originally be based on the facilities available at the user’s home network, which later on may be extended according to the adjustments to the visited networks. Since some of the adjustments are not straightforward, and the visited network may offer new facilities, it is important to provide to the user selectable options and any extra information that the selection may depend on. For certain services, filters, rerouting, automatic response, etc., may be requested when the user is away from home. The Internet Engineering Task Force has already standardized the IP Mobility Support [9] to provide terminal mobility. It allows an IP level location management for mobile hosts, which is transparent to the TCP level. With IP mobility support a mobile host can communicate transparently with other hosts during its migration among subnetworks on the Internet. To support user mobility in UPC, similar to a terminal’s IP address, users must have unique identifications in the system. In [5, 6] the use of a logical user identifier (LUI) is suggested, which is composed of the user’s home domain address and a unique user name at that domain. For example, the e-mail address satisfies this requirement. The user’s home domain is responsible for maintaining the user profile and a database of her current location and user-terminal binding. To provide the same or at least similar services at different locations, a virtually homogeneous distributed computing environment (DPE) is required. At its upper border the DPE provides a homogeneous/standard interface to its users. Its lower interface is system (hardware and software) specific. The DPE maps the services offered by the underlying technology to the standard upper interface. CORBA is an emerging DPE that is attracting a lot of interest recently. Finally, to achieve the goals of UPC, three entities, i.e., the user’s preferred computing environment, the terminal, and the network system, have to be coordinated dynamically at the user’s current point(s) of attachment to the system. This kind of coordination can benefit from autonomous decision making by agents, which act on behalf of another process, object, or person. To provide flexible access, the agent concept is used in TINA [3, 10] for the definition of the access model in NPCS. The model determines two types of agents: user agent and terminal agent. The user agent represents and acts on behalf of a user in the system. Among other functions, it keeps track of the set of subscribed services that a user
may access. The terminal agent, on the other hand, represents the terminal in the system. It is responsible for obtaining the precise location of the terminal. In the UPC framework, we extend this model so that agents manage and personalize the computing environment according to the user profile, the available facilities and possible optimization goals. As an overview, the required framework of UPC can be represented by the layered architecture shown in Figure 1.
Personalized user interface Personal environment management Standard interface Distributed computing environment Technology dependent private interface Native computing and communication environment
In order to provide the functionality of UPC described in Section 2 the following entities are required. • For each user: - identification; - location management; - profile maintenance. • For each terminal: - identification; - location management; - capability profile. • For each facility (resource, service, or application) and its configurations: - naming; - availability at a given location; - comparability; - compatibility. The User: The user is represented in the system by a user agent. The user agent object is bound to the user’s unique LUI. The user agent’s responsibilities are: 1) to provide the user location management information; 2) to maintain the user’s profile object describing her personal computing environment;
Figure 1. Layered architecture of UPC
3) to synchronize the user’s personal computing environment with the capabilities of the terminal the user currently is associated with.
3. AN OBJECT-ORIENTED MODEL FOR UPC
Whenever the user wants to gain access to the system she has to contact her user agent in order for the user’s identity to be authenticated. Therefore, it makes sense for the user agent to have the responsibility of maintaining the user’s location information, i.e., the IP address(es) at which the user is logged in, or the status that the user is not currently accessible. In this role the user agent receives incoming calls or connection requests for the user. The user may also define a policy according to which the user agent will act differently depending on the user’s location or accessibility.
As object orientation is a natural methodology for modeling a system, we also adopt it in our UPC framework. Thus, all entities involved in UPC are represented as objects. Agents are objects which are able to make decisions. Objects may collaborate with each others to create other objects. Figure 2 gives an overview of the objects involved in UPC.
To synchronize the user’s personal computing environment with the terminal capabilities the user agent has to get the terminal profile object and derive the supported subset of the required facilities. The result is a compound object - the terminal specific user profile maintained for the given user-terminal association until the end of the current session, when the user logs out from that terminal (recall that we allow multiple logins of the same user at different terminals). The most efficient place for the terminal specific user profile is the terminal itself
Figure 2. The objects of UPC
The Terminal: To identify a terminal we use its permanent IP address. The location management of a mobile terminal is provided by IP Mobility Support [9]. As mentioned above, the terminal profile object representing the terminal capabilities is associated with the terminal address and located in the terminal itself.
The User-terminal Association: As we have mentioned, the synchronization of the user’s computing environment with the capabilities of the terminal results in a new object: the terminal specific user profile. It is the user terminal agent’s task to maintain the user’s terminal specific computing environment and to discover any facility available at a visited domain. According to the classification of the facilities the user terminal agent searches only for the general-purpose facilities supported at the location that can be mapped into the user profile. Also it may search for other offered local facilities which can be supported by the terminal. The search results extend the menu of available facilities. Finally, the user terminal agent is responsible for closing the user-terminal association when the user logs out from the system, and synchronizing the current state of her computing environment with the environment maintained at the home domain. User Mobility: By user mobility we mean that the user may have an access from any appropriate terminal, i.e., the terminal may be a foreign terminal where the user’s computing environment has to be started up from scratch. To provide network access to the user in a foreign domain, the foreign terminal has to provide an initial agent, which initiates the user authentication and authorization and finds the user agent at the user’s home domain on the basis of the LUI.
Object Adapter
Server
Dynamic Skeleton
Client
Static Skeleton
2) shared between a group of users. They can be specialized for a group of users at a given subnetwork; hence they are also assumed to be available only at that given location. Other shared facilities are general-purpose facilities. This group of facilities can be provided at a visited location instead of using resources remotely at the home network. They can provide a location specific or location independent service. Location dependency is important from the point of view of migration: location specific service can be obsolete after the user has moved away. Shared facilities can be parameterized according to the user’s preferences.
ORB Interface
1) personal, i.e., objects belonging to a given user. These objects are user specific; hence they are available only at the user’s home network.
CORBA combines object oriented technology with distributed computing. It uses the client/server model. The CORBA model separates the object implementations - the servers - from the user(s) of the objects - the clients - at the interfaces between them as shown in Figure 3. The Object Request Broker (ORB) is the communication bus between the clients and the objects which delivers the client requests to the appropriate objects and returns the results to the respective clients where applicable.
IDL stub (static inv.)
Computing facility objects can be classified as:
4. COMMON OBJECT REQUEST BROKER ARCHITECTURE
Dynamic Invocation
The Facilities: Each facility is implemented as an object in the system. These objects are self-descriptive, so that they can provide information about their services and the interfaces to these services. Naming conventions, listings, comparability and compatibility of facilities are requirements related to the computing environment, which should be homogeneous. CORBA can provide such a homogeneous DPE.
Object Request Broker Core (ORB) Figure 3. The structure of ORB Interface CORBA provides transparent access and location independence with the use of object references; i.e., the client does not need to know the address or the actual location of a requested object. Instead, it is the ORB’s responsibility to find or create the appropriate object based on the object reference submitted by the client. The object reference is a unique identifier of an object instance generated at its creation. Implementation independent access to objects for any client is achieved by the standardization of the CORBA Interface Definition Language (IDL). All CORBA object interfaces should be specified in IDL. From an IDL specification, invocations can be derived at run-time. The standard includes also language mapping between IDL and programming languages (C, C++, SmallTalk, Java, etc.). This way CORBA enhances the underlying technology to create a homogeneous DPE. There are two ways of object invocations at the client side: 1) If the object interface is known at the client’s compilation time, the invocation can be built into the client code in a static way with IDL stubs;
2) Otherwise, CORBA supplies the Dynamic Invocation Interface to let the client discover methods to be used at run time. Information about the available services can be obtained at run time from the Interface Repository. These features of CORBA are significant for UPC since services can be discovered and subsequently used at run time. Similar to the client side, on the server side, implementations can be invoked by the ORB via the implementation skeleton or the Dynamic Skeleton Interface. The method of invocation at the client side does not determine which method is used at the server side. Information about object implementations is contained in the Implementation Repository. Object implementations use ORB services mainly through Object Adapters. A variety of Object Adapters may be constructed, optimized for different types of objects. The current CORBA documentation specifies the Basic Object Adapter and the Portable Object Adapter. Since there are functionalities which may be required by many applications, a set of Object Services [11] and Common Facilities [12] have been defined in CORBA. For objects of both groups the documentation specifies the interface (in IDL) and the semantics, but not the implementation (which is vendor specific). Object Services and Common Facilities are building blocks for CORBA based applications, which may inherit their interfaces to provide basic and common features. 4.1 CORBA Interoperability CORBA V2.0 has also defined interoperability between ORBs. As an intermediator for bridging between ORBs, the General Inter-ORB Protocol (GIOP) is specified on a more abstract level, while Internet Inter-ORB Protocol (IIOP) is specifically for TCP/IP based systems. These protocols provide a dynamic object location capability (necessary for both object migration and location) with the full support of CORBA. GIOP (and consequently IIOP) retains the client/server model. The server has to listen to incoming connection requests initiated by clients. Once a connection is established the client may send any of the request messages. The server should answer the requests with reply messages. Requests are identified uniquely so that the ordering of the replies is not significant. The client may close a connection at any time. The server is allowed to close a connection by issuing the Close Connection message only after answering all the received and not cancelled requests. From the point of view of mobility the Location Request and Location Reply messages are important. These messages provide the discovery of the current location of an object in terms of whether the given ORB
owns the object, knows its current location, or has no knowledge of the object. Optionally this information can be provided in the Reply message sent for a pending Request. It is the responsibility of the ORB to resend any request for which a new object reference has been received. At present there are no well-known ports assigned to IIOP. The agent’s TCP/IP address, which can provide the interoperability, is published in the Interoperable Object Reference (IOR) Profile. These profiles identify objects accessible through the Internet. 4.2 UPC Assumptions on CORBA The current version of CORBA is V2.2, and definition of V3.0 is in progress. V2.0 has introduced interoperability by defining GIOP. For the Internet, IIOP is the specified inter-ORB protocol. However, since there is no wellknown port assigned for this protocol, interoperability between two arbitrary ORBs is impossible. Currently interoperability works only under the assumption that a client can somehow get the object reference of the required object. IBM and Sun are working together on the Interoperable Naming Service, for which they assigned as well-known bootstrap port, port 900, to get the initial naming context by IIOP. For UPC we make the same assumption. The client/server model of CORBA is, obviously, not symmetric and the current scheme considers only migration on the server side. That means registered objects can migrate and be found after migration at invocation. This is not true in the opposite direction for the responses, since a client is not necessarily an object. Implementations of CORBA for the client-side and the server-side can be different in this respect. For UPC we require that the client-side is an object, hence we assume the symmetry of the ORB(s) involved. 5. APPLYING CORBA TECHNOLOGY TO UPC 5.1 Type of Terminals Supported As we mentioned earlier, a mobile user can use a wide range of terminals: fixed or mobile, user-owned or provided at the location, and with diverse computing power ranging from simple PDAs to full-featured workstations. This consideration results in different scenarios. However, since we are mostly concerned with mobile computing on the Internet, we expect a relatively powerful terminal, which has the following capabilities: 1) the terminal supports a CORBA V2.0 compliant ORB, and client objects for the supported user environment can be downloaded to the terminal; 2) the terminal supports Java;
3) the terminal “knows” its capabilities, which are represented by the terminal profile object. With today’s powerful palmtops, laptops, and desktops, we believe that the requirements are reasonable and can be satisfied by most computers connected to the Internet. Availability of CORBA is supported by commercial products such as IONA’s Orbix, while Java is available on all popular platforms. They are the basis of our framework. 5.2 Personal Computing Environment Computing facilities of UPC are represented as CORBA objects. In CORBA the client and the implementation sides are separated, and the interface between them is defined in IDL. To enable the user to invoke methods on appropriate objects the user requires client side access. Hence we can define a user’s personal computing environment (PCE) as the set of parameterized clientside objects the user uses on a regular basis. Personal facilities are user specific, and so is their client side objects; therefore at least the client side objects has to be moved to the user’s site whenever she wants to use them. Note that in the case of object call chaining the client is providing the user interface. Specialized-shared objects are domain specific. Out of the domain they require similar handling as personal facilities, i.e., the client part has to be moved to the user’s site. However, inside the domain, there is no need to maintain a client object for each user. It is enough to remember the user specific information, and to create an appropriate copy of the client for the user upon request. General purpose shared objects can be found beyond the domain, so it is feasible (because of speed, access, etc.) to provide local service at a visited site. Obviously the appropriate clients can also be found there, but a repository is required to find them (e.g., CORBA Interface Repository), or they have to be moved from the user’s home. These objects can be parameterized at both the domain and at the user level. For the appropriate mapping of the user’s preferences into a facility found at another domain both information are required; so beside the user profile a domain specific profile is also required. For shared location independent services the system may provide the client mapping automatically on the basis of the profiles and according to some optimization or other policies. However, for location specific services, the system needs to provide only information on service availability, and the choice is left up to the user. To aid service selection, the user may require some additional information, e.g., cost, expected delay, etc. These selection criteria can also be stored in the user profile, so that it can be used automatically. In addition, a visited domain may offer services that are not available at the user’s home domain. The system
has to provide a list of these services to the user. In case the user uses any of them, her preferences may be used to update her user profile. 5.3 User Agent The user agent is a CORBA object representing and acting on behalf of the user in the system. This object is bound to the user’s name, i.e., the LUI. This binding is provided by the Naming Service. To be able to find this object at any time from any domain, the name must identify the domain at which it is registered with the Naming Service. One of the tasks of the user agent is to maintain the user’s profile. With the use of CORBA Relationship Service the user profile is represented as a tree of the client objects (or references to client objects) and parameters for these client objects. Since the user is allowed to log in at several terminals simultaneously the access to some of the user’s personal resources has to be controlled, which is provided by the CORBA Concurrency Control Service. The user agent and the user profile must also be persistent objects that can be facilitated by CORBA’s Persistent Object Service. 5.4 Initial Agent The initial agent provides the start up procedure for the user. Based on the Security Service it authenticates the user and finds the user agent. It contacts first the Naming Service of the user’s domain and gets the object reference for the user agent. In the next step it invokes a method on the user agent to get the user’s computing environment. The object reference to the terminal profile object is sent as an argument of this invocation. As a result the user terminal agent is created in the terminal holding a copy of the user’s terminal specific profile. To create this copy the CORBA Life Cycle Service is used together with the Relationship Service. The relationships (shallow or deep) in the user profile will determine whether a client object itself is copied or only a reference to the original one at the user’s home domain is created. The copy of the object is required, for example, if the given facility has to be started at login. If only an object reference is created the appropriate client object will be copied when the user initiates that given facility. 5.5 User Terminal Agent The user terminal agent’s task is to maintain the user’s terminal specific computing environment and discover the facilities available at a visited domain. The user may move with the terminal during an access session, i.e., she can migrate. The question is how to handle this migration. On the one hand IP Mobility Support handles the terminal migration, and this is
transparent to TCP and the levels above, and hence to CORBA as well. However, one of the UPC requirements is to use local facilities whenever it is required or preferred. To provide this capability we need a signaling from the IP level that the terminal has registered at a new subnetwork. We assume that subnetwork and domain boundaries are the same for those domains which provide services to visiting mobile users, and that there is a well-known port to access at least the Naming Service of any domain. Upon reception of a signal that a new domain has been entered the user terminal agent first contacts the Naming Service, and then (if this is not enough) the Trader Service to find out what services are available at the visited network. According to the classification of the facilities the user terminal agent searches only for those general-purpose facilities supported at the location that can be mapped into the user profile. Also it may search for other offered local facilities which can be supported by the terminal. The menu of available facilities for the user is adjusted according to the search results. There can be different strategies of this adjustment. Because once an object reference has been obtained it can be used later on, there is no technical need to remove it from the menu, so that services offered by previously visited domains can remain on the menu and be invoked later if desired. Of course, beside technical reasons, there may be other (e.g., economical or efficiency) reasons for removing or keeping a given facility on the menu. For those facilities kept on the menu it is up to the user to initiate the use of any of them and to decide whether she wants to use it locally or remotely as applicable. At the initiation of a given facility the user terminal agent has to obtain the client object for it. The visited domain may require authentication and/or authorization of the user before she is permitted to use any of the facilities. This requires the CORBA Security Service. Figure 4 shows the collaboration of agents related to user mobility. Table 1 summarizes the CORBA service usage by UPC objects.
Table 1. Use of CORBA services by UPC objects Object
CORBAservice Persistent Object Service Relationship Service
PCE Life Cycle Service
Persistent Object Service Naming Service User Agent
Life Cycle Service with Relationship Service Concurrency Control Service Security Service
Initial Agent
Naming Service
Naming Service
User Terminal Agent
Trader Service
Security Service
Functionality Persistency of the PCE state Tree of the user related client objects composing the PC E Copying/moving/ deleting of client objects into/from the PCE Persistency of the User Agent object Binding the LUI to the User Agent object Copying of the appropriate part of the PCE to the terminal Control of simultaneous access to the PCE User authentication at login Lookup for the User Agent object reference Get object reference for the Trader Service and other CORBA services Lookup for user required or new facilities at a location User authentication/ authorization w.r.t. a given local facility
5.6 Client objects According to the discussions above, copies of the client objects are moved to the terminal, so they must be portable in every respect. The only platform independent language at this moment is Java. A further advantage of using Java is that OMG has specified the language mapping at both interfaces: between the client and the stub, and between the stub and the ORB. Consequently Java stubs are also portable. This is important because it allows static invocations. Otherwise the client objects have to use the dynamic invocation interface, which is much slower and more cumbersome.
Figure 4. Collaboration of agents in UPC
6. CONCLUSIONS
ACKNOWLEDGMENT
We have presented a CORBA based object-oriented framework for the Universal Personal Computing system. The major contributions are the object-oriented model for UPC and the application of CORBA technology to provide UPC services. The use of object oriented model makes the whole system well structured, and by using CORBA technology the issue of heterogeneity between various networks and operating platforms is resolved nicely. All objects, as long as they reside on the CORBA bus (i.e., support standard CORBA interfaces), can be accessed equally well regardless of what platform it is running on. This is important since the UPC environment may consist of a variety of platforms and operating systems.
This work was supported by a grant from the Wireless Data Systems Division of Motorola Canada Ltd., Richmond, B.C., Canada.
To evaluate the real benefit of such a framework, we are currently implementing a prototype using a CORBA product. Currently available CORBA products include IONA’s Orbix, Sun’s NEO ORB, VisiBroker from Visigenic and the freeware OmniORB by Olivetti and Oracle Research Lab. We are using VisiBroker for prototyping. We have defined a number of protocols that are used between objects to provide UPC services, such as the registration protocol used by the user agent to register in a foreign network and to inform the home network of its current location. All these protocols are specified in the formal description language SDL [13] and verified using SDL tools (e.g., ObjectGEODE). We are also in the process of defining detailed IDL interfaces for all objects in our system and building the objects in our testbed. In addition to implementation, further architectural considerations include: 1) Security - the higher degree of openness of this system requires an appropriate security policy. Since the user may use foreign terminal(s) as her point of attachment, and may communicate sensitive data through foreign networks, it increases the possibility of attack and gives rise to the question of trustability. Similarly the providers must be protected against malicious/unverified users and agents. 2) Accounting, licensing, charging - it is reasonable to assume that all or part of the services offered by foreign networks will have associated charges. Secure protocols to enable networks to exchange service usage information for billing purposes will be needed.
REFERENCES [1] L. Kleinrock: Nomadic Computing - An Opportunity, ACM SIGCOMM Computer Communication Review, vol. 25, pp. 36-40, January 1995. [2] CCITT SG1, Draft Recommendation F.851 UPTservice Description, Version 7, Geneva, 1992. [3] TINA-C: Overall Concepts and Principles of TINA, 17th February 1995. TB_MDC.018_1.0_94 [4] T. Eckardt, T. Magedanz, T. Pfeifer: On the Convergence of Distributed Computing and Telecommunications in the Field of Personal Communications, KIV’S 95 [5] Y. Li, V.C.M. Leung: Supporting personal mobility for nomadic computing over Internet, ACM Mobile Computing and Communications Review, Vol.1, No.1, pp. 22-31, April 1997. [6] Y. Li, V.C.M. Leung: Protocol architecture for universal personal computing, IEEE Journal of Selected Areas in Communication, Oct. 1997. [7] CORBA V2.2, The Common Object Request Broker: Architecture and Specification, OMG, February 1998. [8] Y. Li, V.C.M. Leung: Object oriented model for universal personal computing, UBC Technical Report, May 1997. [9] RFC2002: IP Mobility Support, IETF, November 1996. [10] TINA-C: Service Architecture, Version 5.0, 16th June 1997. [11] CORBA V2.0, CORBAservices: Common Object Services Specification, OMG, March 1995. [12] CORBA V2.0, CORBAfacilities: Common Facilities Architecture, OMG, November 1995. [13] ITU Z.100 Specification and Description Language (SDL), 1992.
