|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ABSTRACT
The OSGi Service Platform is becoming the de facto middleware for deploying modularized Java applications. It is a dynamic platform that relies on a service oriented approach for loose coupling, but the absence of separate object spaces for isolating services of different modules cannot guarantee that service providers from uninstalled modules will no longer be referenced by active code. This may lead to memory retention and inconsistencies (e.g. a stale service that provides invalid cached data) that can introduce silent faults in the system by propagating invalid information. We present our ongoing work where we introduce an isolation layer between service consumer and provider by using dynamic proxies for services. When the corresponding service becomes unregistered (i.e. uninstalled) the mechanism is able to: 1) Guarantee that no consumers directly refer to the service provider; 2) allow finding out the misreferencing consumer code by using a fail-stop mechanism. We have tested this mechanism in different OSGi based applications and benchmarked it against other approaches for accessing services in the OSGi platform. REFERENCES
Note: OCR errors may be found in this Reference List extracted from the full text article. ACM has opted to expose the complete List rather than only correct and linked references.
INDEX TERMS
Primary Classification:
Additional Classification:
General Terms:
Keywords:
Collaborative Colleagues:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||