Raymond Feng wrote:
I share the pains too as I try to find cleaner ways to calculate the
effective policies for a given endpoint or endpoint reference. Here are
a few things that make the build complicated:
1) The inheritance and overriding rules for the two hierarchies:
a) Implementation hierarchy of an element: component -->
componentType (including the composite as a componentType for
implementation.composite)
b) Structural hierarchy of an element: binding --> reference/service
--> component --> composite
c) The implementation.composite spans over a) and b) as its
componentType is built from the composite.
d) Combine the configuration from a) and b)
2) Navigation through the model objects to determine the effective
settings for a given element
a) For implementation hierarchy, our model allows us to go from the
component to the peer componentType. For example, we can call
component.getImplementation(), componentService.getService(),
componentReference.getReference() and componentProperty.getProperty().
b) For structural hierarchy, our model doesn't maintain backward
pointers from child elements to its parent/ancestor elements. We have to
do a top-down build so that an element can see all its ancestors and use
them to calculate the effective settings for that element. I'm wondering
if we can simplify this path. Maybe we can use the structural URI as the
keys.
I think this limitation of no upward pointers is the cause of quite a
lot of complexity and "hacks". Adding a parent pointer to each model
object would be a simple way to allow the builders to get access to
the necessary information.
Ideally, to build an endpoint and endpoint reference, we can start from
the reference/binding or service/binding and then navigate the model
tree following 1.a and 1.b. We may don't have to pollute the static
model objects on the way (for example, copying the interface contract
from componentType.service to component.service), but use the
Endpoint/EndpointReference to hold the calculated results for runtime.
+1 for this. I think it's much cleaner to hold the runtime information
in separate objects.
I agree with Simon's proposal for the stages.
+1 for this as well.
Simon
Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <[email protected]>
Sent: Thursday, August 06, 2009 7:14 AM
To: <[email protected]>
Subject: Re: [2.x] builder woes
Simon,
Simon Laws wrote:
I started looking at ASM_9004 a couple of days again and various fixes
are needed in the builders. Having worked with the builders for a long
time I've come to the conclusion that their current configuration,
which has evolved over the last couple of years, has become
un-maintainable. The primary reason for this is the jumble of logic
across the 14 active builders we have. It's very difficult to spot and
isolate what rules are being applied to the creation of the model and
hence whether these rules comply with the specs.
Given that we have a model that combines both a representation of the
static assembly model and the runtime model that is derived from it
(I'm not brave enough to suggest that we move away from this
configuration) I think there are a number of distinct phases the build
phase has to go through. The primary thrust of this is to move away
from the seemingly arbitrary and inconsistent traverses through the
model toward a clearly defined pattern of processing.
============
Pre-processing
rationalize includes
etc.
Static model processing
build the component type of each composite (non-composite component
types are previously calculated at the resolve stage)
Apply the OASIS rules for promotion of
properties/services/references/policy
configure each component based on its component type
Apply the OASIS rules for promotion of
properties/services/references/policy
Runtime model processing
augment the static model with the runtime information
Component URIs
Binding URIs
Endpoints
Endpoint references
etc.
Post-processing
not sure if there is anything that goes here
============
At r801592 I've started adding a ModelBuilder to replace the
CompositeBuilder to follow this kind of pattern. In reality I haven't
done much at all and it neither runs nor affects the current builder
code (it would be switched on via META-INF/services). I want to get
thoughts on this before spending real effort.
Regards
Simon
I have a lot of sympathy with this approach.
The spec lays down rules for the calculation of the componentType of a
composite and it lays down rules for the calculation of the
configuration of a component involving the componentType of its
implementation. It would be far better to have these two pieces of
calculation each tidily in its own place. At the moment, it is
scattered all over the place, which makes it very hard to pin down
some of the bugs that the OASIS tests are revealing.
I'm happy to help out building the new code for ModelBuilder that you
propose.
Yours, Mike.
