Re: [fractal] packaging for Fractal

[Hervé Roussain <Herve.Roussain@xxxxxxxxxxx>]

Hi, 
> I would like to start a discussion on the Fractal mailing list about 
> packaging for Fractal components. Indeed packaging is a first 
> important step to develop configuration, deployment and 
> administration tools for Fractal, but nothing has been done yet in 
> this area for Fractal (AFAIK).
> 

Hi,

The CASA Action of the Valoria laboratory, whose I am a member, has
recently developped a packaging system that could be used in Fractal.

This packaging system is currently used by the platform called Jason
that provides owners of mobile devices with means to discover, to
deliver and to host (component-based) mobile applications in mobile ad
hoc networks. More information about this platform can be found in [1].

Software packages are currently jar archives and are described with
software descriptors. An exemple of descriptor is attached to this mail.

More information on our research activity can be found at
http://www-valoria.univ-ubs.fr/Composants/CASA

In that work we have asked ourselves some of the questions you also ask
yourself. See below some answers we can do or requirements we have
noticed.


> The first step is to gather requirements for the content of Fractal 
> packages. Here are some ideas:
> 
> - a Fractal package is a kind of jar file (which could be named .car 
> or .far) that contains classes, resources and meta information about 
> one or more component(s)
> - the meta information must include, in particular, the ADL files 
> describing the components and their Fractal dependencies.

And more important: meta information about the package itself. This meta
information also have to be extractable in order to manage packages
repositories or to manage the discovery and the delivery of the
packages.

The meta information describing components is thus only a set of
component definitions described with the current (or future) ADL, with
no change.

We think that dependences must be described for packages (and not for
components):
   - Dependences between Fractal components are already described by
bindings and should be used at deployment time only.
   - Dependences between packages are not always bound to dependences
between Fractal components (e.g. if a package contains more than one
component, or if a package contains "legacy components" or non-Fractal
components).

> Other possible meta information include "legacy" dependencies, i.e. 
> dependencies on "legacy components" (native libraries, OS, ...)

Native libraries and OS are two different kind of dependences:
   - Native libraries can be bundled in packages, with an associated
description, and thus be managed as (non-Fractal) components.
   - We consider a dependence to a specific OS as resources (CPU,
memory, etc.) dependence. To manage this kind of dependences, we use our
resource discovery environment: SAJE/RAJE [2]. This environment has been
developped for the JAMUS platform, a secured hosting platform of mobile
untrusted software. More information can be found in [3].


> - a versioning system is also required. This system could distinguish 
> interface and implementation versions (multiple implementation 
> versions per interface version are useful to capture "minor" 
> implementation changes such as bug fixes). It must also be possible 
> to define (in)compatibility relations between versions.

Our packaging system provides functionnalities to manage version number
and version release of components (see attached example).


> - other possible meta information include: author name, short 
> description of the component, ...

See attached example for more ideas...

> - like Fractal components can be assembled into composite components, 
> and so on recursively, it should be possible to aggregate several 
> Fractal packages in a single package, and so on recursively (this is 
> convenient to distribute complete Fractal applications,  made of many 
> small components, as single self contained Fractal packages)

This is a good idea, but package management should maybe also be able to
dynamically generate "flat-packages" that bundle many components.

> there are also requirements about Fractal packages "installation" and 
> "instantiation". For instance, it could be useful to have several 
> versions of a component installed simultaneously on a given system, 
> or even to have several versions of a component instantiated 
> simultaneously in the same JVM (which could differ at the interface 
> and/or implementation level).



> In addition to the requirements, several questions must also be 
> resolved in order to precisely define the packaging system:
> 
> - where is the meta information in a Fractal package?

I think it has to be described in a file that can be available
separately AND in the package itself.

>  Should we put 
> everything in the ADL files, with new ADL modules?
> 

I am currently extending our work to be able to create a new ADL module
for packaging management.

> - is it necessary to explicitly define what a package "exports" and 
> what it "imports" (cf OSGi)? or could this be deduced automatically 
> (with a transitive closure operation) from the provided and required 
> interfaces of the component, as declared in the ADL files?

If packages contains other things that Fractal-components, exports and
imports (dependencies) have to be described in the package description.
But it should be generated from components definition, using external
packaging tools.

> - how must be defined the compatibility relations between versions, 
> especially if interface and implementation versions are 
> distinguished? Dependency relations from an itf version to another 
> itf version is ok, likewise for an impl version to an itf version, 
> but itf to impl and impl to impl relations should probably be 
> avoided.
> 
> - a Fractal package must include the interfaces provided by the 
> components, as well as the classes that implement them, but should it 
> also include the interfaces required by these components?

If, like we plan to be able to manage, there are "optional
dependencies", this is required. But I noticed during tests that I don't
know how to describe "optional bindings" between components (interfaces
are optional but not bindings).

> - normal or inheritance references betwen ADL files may also introduce 
> problems or new kind of dependency relations between Fractal 
> packages. Do we need separate version numbers for the ADL files, in 
> addition to the version numbers for interfaces and classes?

> Another important question is the relation with existing packaging 
> systems. Indeed, since we will never have a situation where 
> everything is Fractal based, we (at France Telecom) would like to 
> have deployment tools (made of Fractal components) that could deploy 
> not only Fractal components, but also "legacy" components (Debian or 
> Redhat packages, raw data, script or configuration files, EJB 
> components...) [this is a long term goal].
> 

This should not be a long term goal, since many features you could
provide should not be necessarily be specific for Fractal but should be
generic.

> The question is then: should we define a generic packaging system that 
> could work with Fractal components, but that could also "encapsulate" 
> other packages such as Debian or Redhat packages, OSGi bundles, ...? 
> is it even possible? or should we handle the problem at the tools 
> level, i.e. develop tools that can work with various packaging 
> systems?
> 
> ---
> 
> Any feedback is welcome, especially from user needs, and from people 
> who know very well existing packaging systems such as Debian, Redhat, 
> OSGi, EJB and CCM (in order to keep the good ideas and to try to 
> solve the drawbacks of these systems)

If you're looking for information about Debian and RedHat packaging
systems, you could have a look at the "rpm-metadata" project which plan
to provide a generic packaging system for (m)any linux distributions.

> 
> Eric
> 

Cheers,
Hervé



[1] N. Le Sommer and H. Roussain. Jason: An Open Platform for Discovery,
Delivery and Hosting Applications in Mobile Ad Hoc Networks. To be
published in The 2004 International Conference on Pervasive Computing
and Communications, Las Vegas, June 2004.

[2] SAJE: System Aware Java Environment.
http://www-valoria.univ-ubs.fr/Composants/CASA/SAJE/

[3] N. Le Sommer. Contractualisation des ressources pour les composants
logiciels : une approche réflexive. Mémoire de thèse. Université de
Bretagne Sud. Décembre 2003.

[4] rpm-metadata project
http://linux.duke.edu/projects/metadata/
http://hackers.progeny.com/~licquia/rpm-metadata/

________________________________________________________________________
-- 
Hervé Roussain
Université de Bretagne Sud - Laboratoire Valoria
Centre d'Enseignement et de Recherche Yves Coppens
Campus de Tohannic, 56000 Vannes, France
Email: Herve.Roussain@xxxxxxxxxxx