Hi, > On 22 Apr 2016, at 07:28, Oliveira Filho, J.A. (Julio) de > <julio.deoliveirafi...@tno.nl> wrote: > > 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.
This is really cool! There was already some (offlist) discussion on whether the current model of artifacts-features-distributions is still capable of dealing with all the potential use-cases, especially for a domain, like IoT. Having a more generic model would obviously allow Ace to be more of use in such domains. This would be a nice addition to Ace indeed. > 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. This is something that builds on top of the OSGi resolver service if I understand it correctly? It would be a nice idea to make more and better use of the OSGi resolver service to determine the requirements and capabilities for a deployment package. I like the concept of having the ability to deploy a different deployment solution once the behaviour of one or more targets change in such way that the current operation either fails or is significantly downgraded. > 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? Certainly! From the looks of it, it would certainly be a good addition for Apache Ace. So, how can be make this more tangible? Is there a possibility that you provide access to your work? Is it already in such shape that it can be shared with others? I’d certainly like to take a look and play with your work and see how it would fit in the Apache Ace ecosystem. -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 My world is something with Amdatu and Apache Luminis Technologies Churchillplein 1 7314 BZ Apeldoorn +31 88 586 46 00 https://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8170.94.441.B.01
signature.asc
Description: Message signed with OpenPGP using GPGMail
