Managing mutiple applications in a service platform

Abstract

Information hiding and hierarchical decomposition are the corner stone of Software Engineering best practices. These principles have been applied in methods, architectures, programming languages, and run-time platforms. It is therefore a big surprise to notice that the recent dynamic service platforms, like OSGi, do not make use of these principles. In OSGi, all services are visible; a client asking for an interface will be wired to any service, randomly selected and implementing that interface,which makes almost impossible protection and encapsulation. Nevertheless, OSGi is very successful for its almost unique capability to support dynamicity; and because the current practice is to run a single application per platform. Unfortunately, the future of gateways, like OSGi, is to manage the "discovery", access and control of resources (logical as well as physical (sensors, devices)) shared by many applications. In the near future, OSGi will have to scale from a light weight mono-application gateway to a full-fledged dynamic platform. We have developed a layer on top of OSGi called APlication Abstract Machine (Apam) which provides OSGi dynamic capabilities, but also introduces a composite concept allowing multiple applications to cover the range isolation/collaboration from "black-box" (information hiding and hierarchical decomposition) to "scrambled eggs" as in service platforms, and through a variety of grey and white boxes with variable degrees of collaboration, sharing and control. The paper presents the state of practice, the challenges future dynamic platforms have to address, and how the Apam platform provides a solution to these issues. An assessment of the first Apam experimentations concludes the paper.

Building reliable dynamic applications for ubiquitous computing

“…The first purpose of the Apam machine is to introduce the concepts and mechanisms needed to manage protection, sharing and isolation among applications. Apam proposes a new component model which includes the concepts of application, scope, visibility and conflict management [6] [7].…”

“…The presence of B in the service platform is detected by that platform interpretation handler that creates B in Apam and establishes the interpretation link (3) and creates a connection from A to B (4). Then B is instantiated in Apam creating b, which is captured by the interpretation handler that creates the instances b in the platform (5) and establishes the interpretation link (6). Finally a wire is created between b and a in Apam (7), which is captured by the interpretation handler that injects b address in the a' code in the service platform; and execution is resumed.…”

“…In OpenTheBox project 1 , the house automation box will support many services coming from different providers. Apam is mostly seen as the central manager of the house automation box, in charge of providing isolation and controlled collaboration between applications [6], and in controlling the conflicting accesses to the shared devices [7].…”

Model-Driven Design, Development, Execution and Management of Service-Based Applications

“…We have tested different scenarios and compared the performance of our core runtime environment [10] to those of iPOJO [8], FraSCAti [11] and Tuscany [12] platforms. We have measured the instantiation and method call rates, and the memory used in each case.…”