You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2007/11/09 13:05:41 UTC
Processing reference targets for remote bindings
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
Re: Processing reference targets for remote bindings
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Simon Laws wrote:
> 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.
OK I'll take a look at the code if it's already in SVN.
> 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.
>
(3) needs to be after ServiceBindings have been started, i.e. after (2) :)
From your comment I gather that it's currenty the other way around, or
did I misunderstand?
> Are you suggesting that this processing should be more closely integrated
> with the composite activator?
>
I'd suggest to have it self contained with a clean interface, not
closely integrated with anything.
CompositeActivator needs some serious cleanup before adding more code to it.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Processing reference targets for remote bindings
Posted by Simon Laws <si...@googlemail.com>.
On Nov 12, 2007 5:23 PM, Jean-Sebastien Delfino <js...@apache.org>
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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> 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
Re: Processing reference targets for remote bindings
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org