tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raymond Feng" <enjoyj...@gmail.com>
Subject Re: [2.x] builder woes
Date Thu, 06 Aug 2009 17:10:12 GMT
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.

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.

I agree with Simon's proposal for the stages.

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