Mail Archive Home | architecture List | May 2004 Index
| <-- Date Index --> | <-- Thread Index --> |
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 MathieuAt 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 notcontradictory: 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 --> |
Powered by MHonArc.
Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.