Here - Agents Lab - University of Nottingham

the LaserLocalization if the first fails when the ambient light drops below thegiven threshold.4 Distributed Self -OSGi & PEIS IntegrationWhile the Self -OSGi system described in [3] [4] and summarised in the previoussection was limited to components and services running on a single platform andsingle JVM, the latest Self -OSGi version described in this paper has been fittedwith extension mechanisms in order to provide seamless system distribution.By default, such mechanisms leverage the R-OSGi distributed extension ofOSGi to support service goal invocation across remote platforms. The otherdistributed extension of OSGi, D-OSGi, specifically targets Web Services technologyand poses a much bigger overhead - 10MB - compared to the 230KB ofR-OSGi footprint. R-OSGi can be deployed in minimal OSGi implementationsand uses a very efficient network protocol. This makes it ideal for small andembedded devices with limited memory and network bandwidth.Both R-OSGi and D-OSGi allows programs to bind and invoke remote servicesthrough port and proxy mechanisms. To this end, application componentsmust register their services for remote access. Subsequently, other peers mustconnect to the R-OSGi registry of their peers to get access to their remote services.Within Self -OSGi, the framework automatically manages these steps so thatdistribution becomes totally transparent to the application developer. In addition,Self -OSGi extends its automatic instantiation and selection of componentplans to multiple platforms by integrating agent-based negotiation protocolswithin the standalone Self -OSGi system.In the example depicted in Figure 2, a model bundle containing the specificationsof three service goals (their Java interfaces) is equally shared by fourplatforms (A, B, C, D). However, the implementation of these service goals is distributedacross the system. Specifically, platform A hosts two component plansimplementing two of the service goals while platform D hosts one implementationof the service goal missing in platform A.Developers can install a number of protocol components to handle the distributionof service goal requests. Thanks to OSGi DS, the fitting of a distributionprotocol is done completely transparently from the application components,which do not need to be aware of their distribution across platforms.Distribution protocols can range from simple delegation mechanism, whichroutes the service goal requests to specific platforms in the network, to more complexagent-style negotiation protocols, such as the contract net protocol (CNP)depicted in Figure 2. The latter can be used to query a group of platforms - whichcan be discovered via any network discovery solution - through a call for proposal(CFP) message. Upon reception of such a message, each platform will lookuptheir XML component repository and - in the case they can satisfy the request -reply with a bid message reporting the details of the component plan they considermost suitable to satisfy it. At this point, the original requester (platform78