The goal is to enforce the continuity of execution of distributed applications when voluntary or involuntary network disconnections occur. To this end, we are designing a design pattern and a framework for partitioning application components between mobile terminals and remote computers so as to support disconnections as transparently as possible.
We have started by focusing on the adaptation of legacy CORBA-based applications in order to support network disconnections. We have shown how in the CORBA context ``Objects by Value'' and ``Any'' types can be used for achieving the local copy of remote objects, and that ``Portable Interceptors'' can be used for transparent switching between modes [Cona01a,Cona02a]. In order to validate and evaluate the design choices, a sample application (wireless email browser) has been implemented on a Compaq iPAQ running Orbacus4.1 over WindowsCE2.0, with a IEEE 802.11b wireless network connection to a remote server [Cona01b,Cona02b]. We have evaluated the impact of using Portable Interceptors over application performance [Cona02c]. Moreover, a generic architecture for coupling disconnected mode management with roaming between several wireless networks (eg., Bluetooth, WLAN and GPRS) has been designed [Cona02d]. This work has been achieved within the European ITEA VIVIANproject.
Whereas our recent work was targeted to application-transparent adaptation of CORBA-based legacy applications to network disconnections, we are now focusing on more general application-aware adaptation of component-based applications [Cona00] to wireless environments. We will handle non-functional properties such as bandwidth variability or fault tolerance. In the case of component-based applications, non-functional properties are handled by the container [Cona01c], so that some negotiation between application components and containers is required in order to support application-aware adaptation. We are designing a middleware platform called DOMINT (Disconnected Operation for Mobile INternetworking Terminals) that hides as much as possible the details of the hardware, the operating system, and the communication protocols to application developers and users [Cona04a].
We address the issue of determining which objects are mandatory, and which ones are optional, for an application to run in disconnected mode. To this end, we have introduced the notion of ``disconnection metadata'' [Koui03a] and proposed a design pattern for its integration into the CORBA Component Model [Koui03b,Koui04a]. A global software architecture aimed at supporting disconnections has been designed, which includes dedicated containers and four services (connectivity detection, logging, disconnected components management and reconciliation management) [Koui04b]. Following a model driven architecture approach, the UML profile of CCM can be extended to support this architecture [Koui04d]. The issue of managing the cache of software components on the mobile terminal is addressed through application profiles, which specify the dependencies between components and application services [Koui04c].
This work is being developed within the french-finnish AMPROS and the European ITEA OSMOSE projects.
We are also addressing the issue of disconnection detection. We have shown how disconnection detection and failure detection are related [Tema04]. We are studying how legacy middlewares can be enriched with three detectors: failure, connectivity (local detection) and disconnection (distributed detection) [Bhat04]. These three detector types can be used jointly for extending disconnection management and enhancing fault tolerance.
In the same area, we have also investigated how transparent disconnection management can be handled in the Web Services environment [MdC04b,MdC04a,MdC05].
Guy.Bernard@int-evry.fr 2005-03-03