The Internet has evolved into a global and ubiquitous communication
medium interconnecting heterogeneous devices such as powerful
application servers, diverse desktop computers and mobile notebooks.
The way how people use computers and the Internet has changed people’s
working habits. On the one hand, nomadic computing is becoming more and
more important since different computing devices like PDAs and
notebooks converge and are alternately used while the user is on the
move, as illustrated in fig. 1.
Fig. 1 - Nomadic Computing
On the other hand, the ubiquitous availability and pervasive interconnection of computing systems have fostered various trends towards the dynamic utilization and spontaneous collaboration of available remote computing resources, which are addressed by grid computing and peer-to-peer computing approaches.
A common objective of these scenarios is the use of Internet applications on demand, i.e. applications which are not installed in advance by a platform administrator but dynamically deployed and run as they are requested by the application user. The heterogeneous nature of the Internet represents a major challenge for the on demand use and management of custom Internet applications across different hardware platforms, operating systems and network environments. Promising remedies are autonomic computing systems that are supposed to maintain themselves without user or application intervention.
In this project, a cross-platform runtime environment is being
developed which supports the autonomic deployment, composition,
hosting, personalization, interconnection and migration of on demand
Internet applications and is dynamically deployed itself. The project
is based on an integration middleware called “ crossware” that
does not replace existing middleware but operates as a mediator to
uniformly interact with heterogeneous platform installations, resources
and features. An autonomic cross-platform runtime environment is built
on top of it to support the relevant properties of on demand Internet
applications. The application of the approach is being evaluated by an
Internet Application Workbench and an Internet Application Factory for
local and remote application hosting, respectively.
The objectives of the project can be separated into functional requirements imposed by the described application scenarios and cross-cutting autonomic features needed to cross platform boundaries in a self-managing way. The overall goal is the seamless and on demand employment of Internet applications across different operating systems and platforms without particular user intervention.
2.1 Functional Requirements
The functional requirements can be deduced from the workflow an
Internet application passes while it is being deployed by the
application developer and used by the application user. The related
issues are shown in fig. 2 and explained in the following.
Fig. 2. Issues of On Demand Internet
In an Intranet it would in principle be possible to deploy all applications that can ever be requested on every node, but in an Internet environment this is practically impossible. Consequently, mobile code and hot deployment of applications is an essential objective. The distribution is performed not only by a single application repository but by various, separately maintained repositories. In addition, due to the heterogeneous nature of the Internet, the deployment process can not be individually prepared for each node but it must be designed to be self-manageable without any user intervention.
A major goal in an Internet environment is to avoid transmitting unnecessary data and therefore to reduce the required bandwidth to deploy an application. Internet applications are typically composed of smaller parts which can be individually selected, downloaded and plugged into a running application. Thus, the goal is to support the appropriate self-managed selection of the required component according to the requested operation and the current hosting environment. In addition, components already downloaded by other applications should be stored and shared in a local cache.
An application developer can not address every kind of platform architecture or operating system on which the application will probably be hosted in an Internet environment. In turn, a platform administrator is not able to prepare an application system which can host any application, e.g. by installing all existing libraries. Instead, a self-managing application system should dynamically prepare an appropriate runtime environment according to the application requirements and platform capabilities. Another related issue is the provision of a common interface to interact with the platform and its resources, e.g. how to request components or establish network connections.
Users typically customize employed applications according to their personal needs and likings, e.g. picking a certain web proxy server or choosing a particular color scheme. Concerning a cross-platform application environment, an important requirement is the seamless synchronization and application of customized profile settings across the employed platforms without explicit application or user intervention. In particular, this is a non-trivial task in a heterogeneous environment where profile settings may not be directly transferable, e.g. a configured web proxy server could be inaccessible from a different platform and a different proxy has to be determined automatically.
For distributed environments like the Internet a further major requirement is the collaboration with remote applications and services. An application can either request remote services and objects or provide access to its business logic, e.g. publishing a web service. However, in heterogeneous environments with changing groups and roles of requestors and providers there is not always only a single but there are often multiple ways for establishing a connection. Consequently, there is a necessity to dynamically select and create an appropriate network link suitable for the current scenario.
The movement of nomadic users requires the migration of running applications from one host to another. The same is valid for remote applications which have to switch the hosting server while they are executed due to load balancing issues or user request. A related requirement is the seamless migration and restoration of the application session as well as the transparent reconnection of remote resources used by the migrating application. In turn, the reestablishment of network links bound to resources of the migrating application is a particular challenge since distributed applications are involved which should actually not be aware of the migration.
2.2 Autonomic Features
Besides the functional requirements which address the on demand
operation of the cross-platform runtime environment, there are
cross-cutting autonomic features which are related to the
self-managing behavior of the implementation, as outlined in
Fig. 3 Autonomic Features
The application represents the requesting element which uses the middleware to access particularly managed elements of the underlying platform. The middleware acts as the autonomic element which monitors and adjusts the managed elements in a closed control loop providing the self-managing features explained in the following.
The first objective is the ability to prepare the target node according to the requirements of the application and with respect to the capability of the currently involved computing system. Furthermore, migrating applications and nomadic users come with specific profiles about their global and platform-specific preferences which may have to be moved and processed as well. The interconnection with remote objects can not always be configured in advance but has to consider current network constraints such as blocking firewalls. As a result, self-configuration enables applications to be dynamically requested on a different Internet application system without intervention by the user or the application, respectively.
To deploy an application, already installed components and available features of the currently used Internet application environment must be considered. The application should seamlessly integrate itself into an existing application environment and utilize existing features instead of asking for a separate installation or configuration. To this end, the application system should be customized according to the application requirements on the one hand and platform capabilities on the other hand. As an example, instead of downloading application specific components for each application separately, already installed compatible components should be reused. Similarly, an existing network link to a remote object should be shared among applications instead of establishing different communication paths.
Once an Internet application has been distributed and a suitable configuration has been determined, there is still the need to survey the existing configuration whether the operation can be improved to better fit to the current application requirements and system conditions. For instance, the release of new software libraries could offer the update of already deployed and configured applications. Running applications may have to migrate to another computing system and established interconnections are re-routed due to changing workload. Therefore, autonomic cross-platform computing should provide facilities to monitor existing application installations in a self-optimization manner to make them more efficient.
In contrast to self-configuration and self-optimization, which are derived from given high-level objectives with respect to expected conditions of an application, there is also the need to deal with unexpected conditions like software failures, network interruptions or runtime errors. In this sense, self-healing is the ability to repair parts of an operational system without shutting it down. As an example, a remote object connection might be lost due to the migration of the object to another host and must be individually re-established. In another scenario, an application may use a software component that suddenly fails and which then has to be dynamically exchanged. Thus, self-healing is another objective that should be supported by an autonomic cross-platform computing environment.
Another objective is the prevention of errors arising from security related problems that can not be managed by self-configuration or self-healing measures. To this end, self-protection essentially organizes the defense against malicious attacks or incorrect usage. For distributed Internet application scenarios this objective is important to ensure proper operation of applications. For instance, network communications should be appropriately encrypted, if necessary. Deployed software packages have to be validated before they are used and the distribution of user profiles should only be allowed to trusted platforms.
The basic approach of the project is the introduction of an
autonomic cross-platform runtime environment in conjunction with an
integration middleware, as shown in fig. 4
Fig. 4. Autonomic Cross-Platform Runtime Environment
Along with the use of a virtual runtime environment such as Sun Java or Microsoft .NET, the integration middleware provides a homogeneous interface to relevant functions needed by on demand Internet applications across heterogeneous platforms. It does not replace installed features but incorporates different middleware approaches to provide the needed functions. On top of it, an autonomic cross-platform runtime environment is installed which manages the features provided by the integration middleware in a self-managed way according to the application and user requests. As a result, the Internet application can be developed without considering and managing the actual platform configuration. Instead, a suitable runtime environment is dynamically provided and customized.
The project is currently realized by a Java-based implementation
which enables the on demand employment of Java Internet applications
across heterogeneous platforms. Various functional requirements have
already been or are currently being addressed with respect to the
autonomic features as shown in fig. 5 and outlined in the
Fig. 5. Java-Based Realization
Java Class Collections
The deployment of Java applications is facilitated by the introduction of Java class collections which decouple the real deployment of Java classes from the actual composition of Java applications. Particular collection descriptions are used to group selected classes and tag this assembly with custom properties. Subsequent class loading requests are resolved by evaluating the passed property query and property sets of available class collections. The lookup and loading of matching class collections is performed in a self-managed way without involving the application.
Java Loadable Modules
Apart from loading single Java classes, there is no native support for composing applications from particular units like Dynamic Link Libraries in Microsoft Windows or Shared Libraries in Linux. In this project, a new approach has been developed by introducing Java loadable modules which represent customizable building blocks of Java applications. Similar to DLL's they can be explicitly requested and released by the application whereby related init and exit methods are called to trigger the module logic according the inversion-of-control design pattern. Furthermore, modules provide configurable access to contained resources like components and references to singletons.
Java Class Spaces
The next implementation aspect of the workflow is dealing with the hosting of Internet applications and the proper configuration of a suitable runtime environment. While the native Java Virtual Machine can only host a single application, a certain requirement is the concurrent use of various Java applications like in a graphical desktop or server application scenario. In this project, a related multi-application hosting approach is being developed using Java class spaces . Individually managed and configurable class loaders are used to share and shield application classes. The same class can be hosted in different variants, and already loaded classes can be dynamically replaced with updated variants. This particularly supports the implementation of the autonomic features listed above.
While the actual composition and configuration of Internet applications can be performed by evaluating the application requirements and platform capabilities, there is a certain need to further customize applications with respect to the personal profile of the user. In this project, a particular personalization option has been introduced which relies on semantic profiles and recommender systems to determine an appropriate application customization on the fly. Missing profile settings are derived by processing working profiles of other users with a collaborative filter. The separation of globally synchronized and locally managed user profiles enables the discrete customization of each profile setting.
Remote Method Streaming
The interconnection of Java applications is supported by various middleware approaches such as CORBA or RMI. Basically, object-oriented middleware approaches provide transparent access to remote objects while they differ in the way how they are used. In this project, we have developed a Java specific approach which harmonizes the employment of different middleware implementations and provide seamless interconnections of Java objects using remote method streaming . They can be used without particular adaptation of existing code and provide various hooks to insert autonomic aspects like dynamic reconnection and adaptive encryption of method calls. Remote method streaming supports the switching of the underlying network communication as well as the transparent migration of remote objects without involving the application.
A particular feature implemented in this project is the spontaneous migration of Java loadable modules mentioned above. Each time a module is requested, the caller gets a Java dynamic proxy which intercepts every method call to the module and its resources. In case an application or service has to migrate from one host to another, the state of its modules is serialized and the related modules are unloaded. The module states are transferred to the new host and are read in after the application has been configured and personalized. In addition, existing connections are reestablished using the method stream approach and without notifying the application or user.
The project is conducted in collaboration with the University of Siegen and the Fraunhofer Institute for Media Communication in Sankt Augustin , Germany . The produced software is being used within two ongoing research projects, CAT and AWAKE, in which the developed Internet Application Factory and the Internet Application Workbench are used.
5.1 Internet Application Factory
The aim of the project CAT is the development of a distributed open
community portal and knowledge management system which supports the
interdisciplinary collaboration of artists, engineers, and industry. A
basic requirement is the on demand publishing and use of various
services and art installations which should be provided to the
community but without actually been deployed on a central server. The
crossware project supports this application scenario with the
Internet Application Factory as illustrated in fig. 6.
Fig. 6. Internet Application Factory
5.2 Internet Application Workbench
The project AWAKE investigates and develops knowledge management
tools for the discovery and exploration of tacit knowledge. A certain
feature is the development of a knowledge explorer which is used to
interact with knowledge maps using a graphical interface. The developed
Internet Application Workbench provides a GUI desktop and
cross-platform runtime environment which is employed to concurrently
host various applications such as the knowledge explorer and other
client-side tools, as shown in fig. 7.
Fig. 7. Internet Application WorkbenchIt can be dynamically installed using a Java-enabled Internet browser and is subsequently composed and configured according to the capabilities of the currently employed platform and the requirements of the requested application, as shown in fig. 8. The actual cross-platform runtime system and the hosted applications do no longer directly rely on JNLP.
Fig. 8. Initial Deployment of the Cross-Platform Application System
As a result, the Internet Application Workbench attempts to provide the illusion of a pervasive application environment to the nomadic user which customizes itself while the user is on the move to another host.
Funding: German Ministry of Education and Research (BMBF), since 2001
Cooperation: Fraunhofer Institute for Media Communication, Sankt Augustin , Germany ; Department of Electrical & Computer Engineering, University of Siegen , Germany
Contact: Stefan Paal