On 5/1/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
More comments inline.
Greg Dritschler wrote:
> Replies within.
>
> On 4/30/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> I'm thinking about policy, but why limit it? Shouldn't it have access
to
> the complete model and sufficient context for where the wire is being
> added
> within the model?
I agree with you, it should have access to the complete model. I was
just trying to understand your scenario. So if it's about policies...
Policies can be specified at many different levels, ComponentTypes,
ConstrainingTypes, Components, Implementations... I would like to get
people's opinion on:
- Should the policy elements be left where they were initially placed in
the model? you may then have to navigate the model a bit to find them.
- Or do you think it would be useful to merge/combine the policy
definitions from different levels, and prepare "pre-compiled" lists of
policy definitions at the outmost level
(ComponentService/ComponentReference+Binding for example).
Intents can be specified all over the place so combining them would be
helpful. One problem is knowing which intent qualifiers can be combined and
which cannot. The Policy Framework spec has this example:
<composite requires="confidentiality.transport">
<service name="foo" />
<reference name="bar"
requires="confidentiality.message"/>
</composite>
In this case, both the *confidentiality.transport* *and* the *
confidentiality.message* intent are required for the reference 'bar'.
However the transaction spec now under discussion has mutually exclusive
qualifiers.
<composite requires="propagatesTransaction.true">
<service name="foo" />
<reference name="bar"
requires="propagatesTransaction.false"/>
</composite>
In this case only propagatesTransaction.false is required for the reference
"bar"; it overrides the qualifier at the composite level.
There is nothing in the intent definition to help distinguish these cases
which makes it difficult to write generic code to combine intents across
levels.
>
>
> I understand the problems with the runtime model but I'm not sure
> where you
> are going with it. I assume you are still going to have builders for
> extensible elements like implementation and binding. Are you planning
to
> get rid of the builders for other elements like component? How will the
> runtime objects created by builders be organized with respect to the
> assembly model?
I'd like to avoid the duplication of info and constant navigation
between the two models (as most of the existing builders simply build
the second model from the first one).
I think this can be simplified as follows:
- For model elements that represent extensibility points, Implementation
or Binding for example, we can have the runtime specific Implementation
or Binding model class simply extend the Implementation or Binding
assembly model class, and augment it with the runtime specific info.
- For generic model elements, Component for example, we can have a
simple field to host runtime and Implementation specific configuration,
like Component.set/getImplementationConfiguration().
This way we don't have to maintain two parallel (and often inconsistent)
hierarchies for everything, and the runtime layer can simply access the
SCA assembly metadata in the base model class or by following a simple
pointer.
I definitely agree with eliminating duplication across models. I'm not sure
how I feel about polluting the assembly model with runtime artifacts such as
invocation chains. Most systems I have worked on keep metadata and
implementation objects separate.
