ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Willem Janssen <>
Subject Re: Short introduction and presentation of work
Date Fri, 13 May 2016 15:30:28 GMT

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

KvK (CoC) 09 16 28 93
BTW (VAT) NL8170.94.441.B.01

View raw message