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
+1
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
+1
2. What to do about URLs as they may be
either
1. Unset
1. Apply algorithm from Assembly
Spec 1.7.2
+1
2. Set relatively
1. Apply algorithm from Assembly
Spec 1.7.2
+1
3. Set absolutely
1. Assume it is set correctly?
Yes
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
+1
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
domain
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 ...>
<service...>
<binding.ws uri="http://localhost:1234/services"/>
<binding.jsonrpc uri="http://localhost:1234/services"/>
<binding.atom uri="http://localhost:9999/services"/>
</component>
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
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
