ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google


Mail Archive Home | deployment List | May 2004 Index

<--  Date Index     <--  Thread Index  -->

RE: [fractal] Re: [architecture] Fractal packaging & deployment, bis


Hi again

Right, if I understand well, you suggest that everything can be seen from
the packaging and deployment point of view as fractal components, ie the
application components, the infrastructure components, the OS and its
librairies, and any other legacy library

Then, you suggest that conflicts will be solved at deployment time (by the
deployment process) using metadata coming from the packaging and according
to some policies

I assume that metadata will be used to discover the possible conflicts and
policies will be used to take decisions

The issue I see is the following:

component C1 depends on legacy foo1.2
component C2 depends on legacy bar1.1

1) either foo1.2 and bar1.1 and packaged themselves and then you will see
that:

legacy foo1.2 depends on legacy shared1.1
legacy bar1.1 depends on legacy shared1.2

but unfortunately shared1.1 and shared1.2 do not work together

So you'll have to say somewhere (metadata ?) that the versions are not
compatible to discover this conflict, and I don't feel that it fits in the
binding constraint category (it's more a compatibility / versioning issue)

The main issue in the case is the fact that any legacy would have to be
packaged if used directly or indirectly by a component (which doesn't seem
to be feasible in practise)

2) or they're not (legacy is a black box from the deployment process point
of view)

and then the deployment process has no means to discover the conflict except
if it's stated explicitely in the component metadata (as Jose suggested)

I assume that such conflicts could be attach as arbitrary metadata, but then
the packaging and the deployment tools would have to be provided by the same
vendor, and this breaks the possible reuse of the components (this is why
it's essential to have standard metadata)


I've another question which arised in this mail: do you intend to manage
versioning issues in the packaging / deployment ? 

hope it helps
Mathieu

> 
> Several things:
> 
> - the 3 dependencies mentioned below : container 
> dependencies, binding dependencies and system 
> dependencies definitely are binding dependencies 
> in Fractal terms. And we do not need to have any 
> wrapping done because all system libraries for 
> instance can be understood as Fractal level 0 
> components (ie legacy stuff).
> 
> - you can always attach arbitrary metadata to Fractal 
> components via attributes
> 
> - deployment policies are not necessarily 
> entirely described in packaging metadata: it is 
> up to the deployment process or engine to 
> interpret these metadata in a way that is 
> conistent with whatever policies are in place. 
> Managing conflict is a potential example: how 
> conflicts are dealt with at deployment time is 
> not entirely dependent on packaging metadata but 
> on policies in place, which are clearly outside 
> of the packaging info.
> 
> Best regards,
> 
> Jean-Bernard
> 
> At 12:05 +0200 14/05/04, mathieu.vadet@xxxxxxxxxxxxxxxxxx wrote:
> >Hi all,
> >
> >I agree with Jose, I don't see how "containment and binding" 
> constraints
> >will apply to system dependencies
> >
> >If we take the rich example of the CCM, then we can see in 
> the software
> >component desriptors  the following dependencies:
> >
> >  - what you call "binding" dependencies, ie functional 
> dependencies (I need
> >interface Itf to work)
> >
> >  - container dependencies, ie dependencies against 
> technical services (I
> >need TX_NEVER policy on operation do_it of interface Itf, 
> for transactions)
> >
> >  - system dependencies, ie dependencies against the OS, 
> libraries, etc (I
> >need the libfoo.so, I need Linux 2.4.18 kernel)
> >
> >Please note that the last dependency can't be considered as "binding"
> >dependencies, except if the "feature" is wrapped by a 
> fractal component; but
> >then you'll have to wrap many system features
> >
> >I feel that there's some elements missing:
> >   - system dependencies description in metadata
> >
> >   - container dependencies description in metadata (but in 
> the case of
> >fractal, maybe they can be described as "binding" dependencies)
> >
> >   - conflict management, because you may not be able to 
> describe any system
> >dependency in a standard way (used in any package), 
> therefore, you may not
> >be able to discover all conflicts automatically from the 
> metadata, and you
> >may be forced to explicitely state these conflicts
> >
> >hope it helps
> >Mathieu
> >
> >>
> >>  At 17:05 +0200 11/05/04, Jose Luis Ruiz Revuelta wrote:
> >>  >El mar, 11-05-2004 a las 09:29, Eric Bruneton escribió:
> >>  >>  Richard S. Hall wrote:
> >>  >>  > This really depends on whether the purpose is to create a
> >>  >>  > deployment infrastructure for deploying Fractal-based
> >>  applications
> >>  >>  > or if the purpose is to create a more general
> >>  deployment middleware
> >>  >>  > (at least for Java), where Fractal-based applications
> >  > are just one
> >  > >>  > type of application to be deployed.
> >  > >>  >
> >  > >>  > If the purpose is only for Fractal-based applications
> >  > and the only
> >  > >>  > types of dependencies that exist among "packages" are
> >>  >>  > component-oriented dependencies (i.e., containment 
> and binding),
> >>  >>  > then it probably doesn't make a difference what you call it.
> >  > >>
> >  > >>  I hope it will be possible to create a deployment
> >  > infrastructure for
> >  > >>  deploying Fractal-based applications that can also deploy
> >  > arbitrary
> >  > >>  (Java and non Java) applications. This is not
> >>  contradictory: it just
> >>  >>  imply that arbitrary applications can be seen as Fractal-based
> >>  >>  applications (and this should be possible since the
> >>  Fractal model is
> >>  >>  modular, extensible, and not tied to Java; for 
> example, plain old
> >>  >>  Java objects are compliant with Fractal level 0). Or, in
> >>  other terms,
> >>  >>  that existing packaging formats can be seen as Fractal
> >>  packages (and,
> >>  >>  in particular, that their dependencies can be seen as Fractal
> >>  >>  "containment and binding" dependencies - hence this mail
> >>  >> 
> >>  
> http://www.objectweb.org/wws/arc/fractal/2004-05/msg00005.html). Or,
> >  > >
> >>  >Ummmm, are you sure that "contaiment and binding" 
> dependencies are
> >>  >expresive enough to represent all kinds of dependencies 
> for existing
> >>  >packaging formats?
> >>  >
> >>  >For example, in Debian, package metadata explicitly consider
> >>  conflicts
> >>  >between packages. How can contaiment and binding
> >>  dependencies be used to
> >>  >describe conflicts between packages?
> >>  >
> >>  >Sometimes due to any reason two existing packages can not live
> >>  >together(for example, both packages access a resource 
> that can not be
> >>  >shared), in other words, are incompatible. I feel that conflict
> >>  >management is an important aspect in order to keep the
> >>  consistency and
> >>  >the stability of an execution environment.
> >>  >
> >>  >Regards,
> >>  >Jose
> >>  >
> >>  >
> >>  >
> >>
> >>  It depends in large part of what you mean by
> >>  'package metadata exlicitly consider conflicts'.
> >>  If you have a component which enforces as a
> >>  policy to be bound at most once in any point in
> >>  time, you have in effect a non-sharable
> >>  component. Documenting a dependency by means of a
> >>  binding towards this component means that you
> >>  must follow the binding policy for this component
> >>  and, in this particular case, successfully deploy
> >>  your package if the referenced package is not
> >>  already bound. A binding in Fractal can have a
> >>  very rich (or complicated) semantics. To
> >>  determine if the approach Eric has outlined is
> >>  feasible or not, we need to assesss the nature of
> >>  the dependencies betwen 'deployment units' used
> >>  in existing systems.
> >>
> >
> >
> >
> >--
> >You receive this message as a subscriber of the 
> >fractal@xxxxxxxxxxxxx mailing list.
> >To unsubscribe: mailto:fractal-unsubscribe@xxxxxxxxxxxxx
> >For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> >ObjectWeb mailing lists service home page: 
http://www.objectweb.org/wws

-- 

*************************************************************
Jean-Bernard STEFANI
Research Director, SARDES Project
INRIA Rhône-Alpes
655, avenue de l'Europe
Montbonnot
38334 St Ismier Cedex
France
tel : +33 (0)4 76 61 52 57
fax : +33 (0)4 76 61 52 52
email : Jean-Bernard.Stefani@xxxxxxxx
*************************************************************



<--  Date Index     <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.