tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Nash <n...@apache.org>
Subject Re: [2.x] builder woes
Date Fri, 07 Aug 2009 11:22:59 GMT
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.


> Thanks,
> Raymond
> --------------------------------------------------
> From: "Mike Edwards" <mike.edwards.inglenook@gmail.com>
> Sent: Thursday, August 06, 2009 7:14 AM
> To: <dev@tuscany.apache.org>
> 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. 

View raw message