RE: Short introduction and presentation of work

["Oliveira Filho, J.A. (Julio) de" <ju...@tno.nl>]

Dear Jan Willem,

First, sorry for the long delay in responding.  Did not forget, but was really busy.  You said:

===
"""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."""
===

We (TNO) are working now on making a small demo/sandbox code package for you to test the ideas and see what we did.  That may take sometime as other projects are in the pipeline.  I estimate between mid July to mid August.  Please, let me know if you expect other timeline (faster).

That is also the time frame I need to get  the necessary permissions within TNO in respect to legal stuff (intellectual property, inform partners in projects, etc.).  Probably, the test package you will get (with sources) is not yet to be open to a large public, but only for your evaluation.  If you find it usable, we go further in getting the final openness.  I keep you informed on that as well.

Best,

Julio de Oliveira Filho

-----Original Message-----
From: Jan Willem Janssen [mailto:janwillem.janssen@luminis.eu] 
Sent: vrijdag 13 mei 2016 17:30
To: dev@ace.apache.org
Cc: Oliveira Filho, J.A. (Julio) de
Subject: Re: Short introduction and presentation of work

Hi,

> On 22 Apr 2016, at 07:28, Oliveira Filho, J.A. (Julio) de <ju...@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

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.