Dear APACHE ACE team, Last years, our teams at TNO and Thales have been working on technologies for dynamic composition of software modules and adaptive deployment of software architectures. The functionalities we developed allow systems to define -- at runtime -- which software components should be deployed and in which computing resources. System design and deployment decisions are based on the current goal of the system, the actual availability of resources, and the desired computing performance. This allows us for example, to build systems that react to failing machines by re-deploying software modules in healthy resources. It also allows to dynamically share, bind, and re-deploy software modules when new functionality is introduced in the system. All that taking into consideration the computing resources available and for example, how their load will be after the system deployment.
We believe many of the technologies we developed could also be of value for the APACHE community, and in special the APACHE ACE community. Moreover, this would help us to possibly get a broader user base and development incentive. For this reason, we get in contact with you. We summarize our innovations in two aspects that we believe add value for the APACHE ACE community: 1. We extend the requirement-capability model of OSGI (used in ACE) to go beyond dependencies between software modules (bundles). In specific, we introduced simple but effective concepts in this model that enable software designers to: a. describe dependencies of software modules to physical computing resources. For example, it is possible to explicitly describe the required amount of memory, or the required use of special hardware, such as GPUs and graphical boards. A language model creates a standard for interoperability and semantic understanding. b. describe virtual software modules representing higher abstraction levels of composition. For example, it is possible to describe a signal processing chain as composed by a sampler module, a filtering module, and a detection module. At this level, the dependencies in the chain are resolved based on what they do and their performance level (accuracy, resolution, etc.), but not yet on implementation details, such as their interface. High abstract modules are resolved hierarchically into possible concrete implementations, which in turn provide the more specific dependency aspects such as the interface and the required physical resources. 2. We extend the functionality of the OSGi Resolver with the following features : a. we resolve requirement-capability constraints that takes into consideration the physical resources available. At our system, software requirements to computing resources (memory, cpu, special hardware) are resolved against special bundles/models that represent the (current) capabilities of the available hardware; In these cases, we not only produce a resolved module composition, but we guarantee that it can be deployed in the currently available hardware. b. we consider the physical allocation of software components to computing resources as part of the resolution process. In other words, we extended the resolution role to also determine where each software component should be deployed. c. we consider many possible solutions from the resolver at the same time, instead of the default behavior of the OSGI resolver that returns only the first feasible resolved solution back (or fail). The fittest solution is chosen among the several produced according to a customizable goal function -- for example, which system has the best response-time. d. the resolution step can optimize the physical deployment of software components based on a customizable goal function -- for example, by prioritizing deployments that balance the load among the available resources against deployments that overload a single machine. We believe the features above are an added value in the following situations: * Deployments of software components in heterogeneous resource environments, such as the cloud, embedded or high-performance specialized platforms, and interoperability hardware hubs. * Deployments of software components in unreliable environments where failing resources and communication links often happen -- examples could be ad-hoc installations, embedded and distributed platforms (Internet-of-Things); * Gradual deployments of software components, where functionalities are included on demand, but with risk of overloading the computing resources; We are curious to know if the APACHE ACE community would be interested in adopting these ideas. We would gladly demonstrate and discuss with you future possibilities. What do you guys think about the ideas above? Would they be of added value to ACE? Last, but not least, we would like to say a few words about ourselves. Julio Oliveira, Maarten Ditzel and Bardo Bakker are specialists on distributed and networked embedded systems for TNO. TNO is involved in the design and development of innovative software and hardware platforms, that use dynamic reconfiguration to improve their reliability, power consumption, or efficiency. Within this work TNO co-designed and co-implemented the mechanisms for dynamic functional composition and resource allocation. Pepijn Noltes, Rene van Hees, and Hans Schurer are software architects at Thales Nederland and have been involved in different research projects oriented around dynamic reconfigurable systems. The Thales team has a special interest in software evolution and time-critical systems. Pepijn Noltes himself is already a committer for the Apache Celix project. We look forward for hearing from you how we can continue this discussion. Sincerely, Julio A. de Oliveira Filho Dr.Rer.Nat. J.A. (Julio) de Oliveira Filho Innovator DSS/Technical Sciences T +31 (0)88 866 31 23 M +31 (0)64 684 73 73 E julio.deoliveirafi...@tno.nl<mailto:julio.deoliveirafi...@tno.nl> Location<http://www.tno.nl/locaties/DHW> Den Haag [cid:image001.gif@01D19CB3.7319E150]<http://www.tno.nl/> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages. Please note when visiting TNO Waalsdorperweg: In compliance with the strict security regulations for this location, the security staff will ask you to leave your smartphones with camera in the lockers available at the reception desk.
