tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Sebastien Delfino <jsdelf...@apache.org>
Subject Re: Investigating assignment of endpoint information to the domain model was: Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
Date Mon, 03 Mar 2008 21:57:08 GMT
I apologize in advance for the inline comment puzzle, but you had 
started with a long email in the first place :)

Simon Laws wrote:
>>> And here's the separate thread following on from [1]... I'm looking at
>> what we can do with any endpoint information we have prior to the point at
>> which a composite is deployed to a node. This is an alternative to
>> (replacement for?) having the Tuscany runtime go and query for endpoint
>> information after it has been started. I have been summarizing info here
>> [2][3].  Looking at this I need to do something like...
>> - associate composites with nodes/apply physical binding
>> defaults/propagate physical addresses based on domain level wiring
>>    1. Read in node model - which provides
>>       1. Mapping of composite to node
>>       2. Default configuration of bindings at that node, e.g. the
>>       root URL required for binding.ws


>>    2. For each composite in the domain (I'm assuming I have access to
>>    the domain level composite model)
>>       1. Find, from the node model, the node which will host the
>>       composite
>>       2. for each service in the composite
>>          1. If there are no bindings for the service
>>             1. Create a default binding configured with the
>>             default URI from the node model

Create a <binding.sca> configured with the URI found on the 
<binding.sca> from the node configuration. Same as your else branch 
"Take the default binding configuration and apply it to the binding".

>>             2. We maybe should only configure the URI if we
>>             know there is a remote reference.

Maybe later :) I think that always configuring the URI for now is better 
than starting to couple binding configuration with reference resolution.

>>             2. else
>>             1. find each binding in the service
>>                1. Take the default binding configuration
>>                and apply it to the binding


>>                2. What to do about URLs as they may be
>>                either
>>                   1. Unset
>>                      1. Apply algorithm from Assembly
>>                      Spec 1.7.2


>>                   2. Set relatively
>>                      1. Apply algorithm from Assembly

                       Spec 1.7.2

>>                   3. Set absolutely
>>                      1. Assume it is set correctly?


>>                   4. Set implicitly (from WSDL
>>                   information)
>>                      1. Assume it is set correctly?
>>                     3. The above is similar to what goes
>>          during compositeConfiguration in the build phase


>>       3. For each reference in the composite
>>          1. Look for any targets that cannot be satisfied within
>>          the current node (need an interface to call through which scans the domain)
>>          2. Find the service model for this target
>>          3. Do policy and binding matching
>>          4. For matching bindings ensure that the binding URL is
>>          unset and set with information from the target service
>>          5. The above is also similar to what happens during the
>>          build phase
>>          4. Domain Level Autowiring also needs to be taken into
>>       account
>>       5. Wire by impl that uses domain wide references also need to
>>       be considered

IMO (3), (4), (5) should be taken completely separately. Resolution of 
references inside a node, across nodes, or when nodes provide default 
binding configuration or not can just always work the same way:
a) find the target service inside the set of composites included in the 
b) configure the reference from the resolved service configuration.

>> Referring to the builder code now is feels like 2.2 above is a new "model
>> enhancement" step that could reuse (some of) the function in
>> CompositeConfigurationBuilderImpl.configureComponents but with extra
>> binding specific feature to ensure that URLs are set correctly.

Yes exactly.

>> 2.3 looks very like CompositeWireBuilder.

Which should continue to work as-is :)

>> My quandry at the moment is that the process has a dependency on the node
>> description so it doesn't fit in the builders where they are at the moment.
>> It feels like we need a separate module. So comments about whether any of
>> this makes sense and, if so, where I should put it are welcome.

If that helps: The dependency on NodeImplementation is not really 
necessary, as the only info you need is the list of Binding objects from 
the node description.

Something like that should work:

configure(Composite composite, List<Binding> defaultBindings);

>> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28299.html
>> [2]
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Contribution+Processing
>> [3] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Runtime+Phases
> I have some code [1] for steps 1, 2.1 and 2.2 above and I want to move it
> out of my sandbox to see how it fits. Two questions
> A) I have a relatively stand alone algorithm [2] that populates service
> binding URIs (similar to the CompositeConfigurationBuilder and I would like
> to combine the two in the future) and am assuming for now that it will slot
> into o.a.t.s.workspace.configuration.imp. Anyone not happy with that please
> speak up.

I'm happy with workspace.configuration.impl. However applying default 
binding configuration to bindings in a composition doesn't have much to 
do with the workspace so I'd suggest to push it down to assembly, 
possible if you use a signature like I suggested above.

> B) The algorithm (A) that calculates service endpoints based on node default
> binding configurations depends on knowing the protocol that a particular
> binding is configured to use.

That part I don't get :) We could toy with the idea that SCA bindings 
are not the right level of abstraction and that we need a transport 
concept (or scheme or protocol, e.g. http) and the ability for multiple 
bindings (e.g. ws, atom, json) to share the same transport... But that's 
a whole different discussion IMO.

Can we keep this simply on a binding basis? and have a node declare this:

<component ...>
   <implementation.node ...>
     <binding.ws uri="http://localhost:1234/services"/>
     <binding.jsonrpc uri="http://localhost:1234/services"/>
     <binding.atom uri="http://localhost:9999/services"/>

Then the <binding.ws uri=...> declaration can provide the default config 
for all binding.ws on that node, <binding.jsonrpc> for all binding.json, 
<binding.atom> for all binding.atom etc. As you can see in this example, 
different bindings could use different ports... so, trying to share a 
common transport will probably be less functional if it forces the 
bindings sharing that transport to share a single port.

As this is a result of a binding
> configuration, based on binding, interfaces descritions, policy I have taken
> the approach of creating a new extension point, BindingURICalculator [3],
> which will hold this and probably other binding specific function related to
> URI calculation. I want to check that there isn't somewhere else that people
> think this function should live.
> Am writing tests at the moment so you have time to comment before I do move
> out of my sandbox.

+1 from me to continue this work in trunk.

> [1]
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/domain-rework/
> [2]
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/domain-rework/src/main/java/org/apache/tuscany/sca/workspace/configuration/impl/NodeAssigner.java
> [3]
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/domain-rework/src/main/java/org/apache/tuscany/sca/binding/BindingURICalculator.java


To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

View raw message