On Nov 12, 2007 5:23 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:
> Simon Laws wrote:
> > I've started putting some code in the node implementation to allow
> remote
> > bindings to make use of reference targets for identifying service
> endpoints.
> >
> >
> > It's very simple at the moment. The node implementation uses the
> > startComposite event as a trigger to
> >
> > 1/ scan all services in the composite and register them with the domain
> > I've updated the domain implementation so that when there is no remote
> > domain there registrations are cached locally. It's the same code
> > implementing the local and remote domain so the proxy effectively
> provides a
> > write through cache.
> >
> > 2/ scan all references in the composite and compare them against the
> > registered service. Replace the binding uri with the uri from the
> registered
> > service if appropriate.
> >
> > The "if appropriate" part is the tricky bit. At the moment the code [1]
> does
> > the following.
> >
> > for (Component component: composite.getComponents()) {
> > for (ComponentReference reference: component.getReferences())
> {
> > for (Binding binding: reference.getBindings()) {
> > if (binding.isUnresolved()) {
> > if (binding instanceof SCABindingImpl){
> > // TODO - only find uri if its in a remote
> node
> > } else {
> > // find the right endpoint for this
> > reference/binding. This relies on looking
> > // up every binding URI. If a response is
> > returned then it's set back into the
> > // binding uri
> > String uri = "";
> > try {
> > uri =
> > ((SCADomainSPI)scaDomain).findServiceEndpoint(domainURI,
> >
> > binding.getURI(),
> >
> > binding.getClass().getName());
> > } catch(Exception ex) {
> > logger.log(Level.WARNING,
> > "Unable to find service: "
> +
> > domainURI + " " +
> > nodeURI + " " +
> > binding.getURI() + " " +
> > binding.getClass().getName()
> + " " +
> > uri);
> > }
> >
> > if (uri.equals("") == false){
> > binding.setURI(uri);
> > }
> > }
> > }
> > }
> > }
> > }
> >
> > There is a bit of slight of hand here;
> >
> > It looks for all unresolved bindings (it seems that all remote bindings
> are
> > unresolved - is that right?)
> >
> > It then uses the binding uri to look up a service which either finds
> > something or it doesn't
> >
> > In the case that a binding.uri has no endpoint specified you will see
> > something like "MyComponent/MyService" in the binding uri and there's a
> good
> > chance that a service will have been registered under this name and
> hence
> > the correct target endpoint will be set back into the reference binding.
> >
> > In the case that a binding uri is set by other means (via the uri
> attribute
> > for example) then it will already look something like "
> > http://myhost:8080/MyComponent/MyService";. This will not match any
> > registered service name and hence will not be reset. This may not match
> the
> > real service uri but then that's the users fault for setting it
> incorrectly.
> >
> >
> > This processing is slightly removed from the model itself but relies on
> the
> > model and related processing to work out what the binding.uri should be
> > initially, based on specified target(s) (haven't done anything about the
> > multiplicity case yet). I welcome any feedback about whether this is
> going
> > in the right direction. If people are happy about this I will likely
> pull
> > the service registration logic out of the sca binding and treat it in a
> > similar, more generic, way.
> >
> > Simon
> >
> > [1]
> >
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/node-impl/src/main/java/org/apache/tuscany/sca/node/impl/SCANodeImpl.java
> >
> >
>
> Moving the logic to configure binding URIs from wire targets out of the
> SCA binding looks like the right direction (as this should eventually
> work for all bindings).
>
> IMO steps should be performed in the following sequence, which may
> slightly differ from what you described:
> 1. ServiceBindingProvider.start() is called.
> 2. Binding specific code in ServiceBindingProvider.start() sets the
> effective binding URI in the Binding model (as it's the only one to know
> how to determine it).
> 3. Generic domain code registers binding.getURI() with the domain
> controller.
> 4. Just before ReferenceBindingProvider.start() is called, generic
> domain code looks the target service up, finds its URI, calls
> binding.setURI().
> 5. ReferenceBindingProvider.start() proceeds and uses the resolved URI.
>
> Steps 4 and 5 could also be delayed until an invocation hits the
> ReferenceBinding.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Sebastien
Thanks for the comments. I think we are pretty close on the sequence. It may
be that we differ on how this is plumbed into the infrastructure. For steps
3 and 4 I'm dealing with all of the services, references in one go at the
Node level between calls to activate and start on the composite activator.
Are you suggesting that this processing should be more closely integrated
with the composite activator?
Regards
Simon
