APAM/APAM Details/APAM Dependecy Management/APAM Vibility Control

From Wiki Adele Team
< APAM‎ | APAM Details‎ | APAM Dependecy Management
Revision as of 12:22, 10 January 2013 by Mehdi (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This APAM Wiki is no longer maintained. Please switch to the following github Wiki for newest APAM information:

In Apam, with respect to the platform, a composite can be a lender and/or a borrower, or none. A composite is a lender if it allows other applications to use the components it owns. A composite is a borrower if it prefers using an existing component (pertaining to another composite) instead of creating its own one. In this section the <expression> is either a Boolean (“true” or “false”) or a filter to apply to the component candidates. Borrowing implementations and instances A composite designer must be able to decide whether or not to borrow the instances lent by other composites. For this purpose, he can specify the property borrow Instance=<expression>. If the requested resource (implementation or instance) matches the expression, the platform must try to borrow an instance if it exists. If the expression is not matched, an instance must be created. By default, the expression is “true”, i.e., by default everything is shared.

<borrow implementation="(b=true)" instance="false"/>

In this example, the current composite will try to borrow the implementations that match the expression (b=true), but never an instance (instance="false"). If we have <borrow implementation="false" instance="false"/>, the composite will have to deploy all its own implementations and instances, from its own repositories. It means that it is auto-contained and fully independent from the other composites and components. It can be safely (re)used in any application. Nevertheless, its resolution constraints can include contextual properties such that it can adapt itself to moving context, still being independent from its users. By default, both expressions are “true”, meaning that the composite is fully opportunistic, and will use as much as possible the available components.

Lending implementations and instances Conversely, a composite designer can decide whether or not its own components can be lent to other composites. This is indicated by the local, friend and application tags.

<local implementation= "Exp" instance="Exp" /> <friend implementation= "Exp" instance="Exp" /> <application instance= "Exp" />

Local means the components matching the expressions are only visible inside the current composite: can are lent to nobody. Friend means that the components matching the expressions are lent only to the friend composites. A composite cp is a friend of the current composite if a friend relationship is established from the current composite to cp. An instance pertains to a single composite instance; therefore the instances in a platform are organized as a forest. An application is defined as a tree in that forest (i.e., a root composite instance). Therefore, two composite instances pertain to the same application if they pertain to the same instance tree. Application means that the instances contained in the current composite and matching the expression can be lent to any other composite pertaining to the same application. By default, if nothing is said, all the implementation and instance contained in the current composite are visible by anyone in the platform. It is the default and unique strategy of usual service platforms.