Comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[email protected]>
Sent: Friday, March 05, 2010 4:00 AM
To: <[email protected]>; <[email protected]>
Subject: Re: Propagating the SCA service endpoint address to the client
On Thu, Mar 4, 2010 at 11:00 PM, ant elder <[email protected]> wrote:
On Fri, Mar 5, 2010 at 11:40 AM, Raymond Feng <[email protected]>
wrote:
Hi,
When an SCA service is published to a binding protocol, it's assigned
with
an address (represented as a URI) so that the service can be accessed
from
the client side using that address. For example, a web service binding
can
be made available at http://myhost:9080/myService.
We use the endpoint registry to propagate endpoint descriptions from the
node that hosts the endpoint to other nodes in the SCA domain. The
protocol-specific physical endpoint address needs to be carried with the
endpoint description via the registry. The other tricky thing is to make
sure the endpoint address is accessible from a different machine. This
leads
to a few cases:
1) The service binding URI is http://localhost:9080/myService. Should
the
localhost be left as-is or replaced with the host ip or name?
2) Should we use IP addess or host name?
3) What do we do if the host machine is multiple homed?
For some of the bindings, we have ServletHost or RMIHost to represent
the
protocol stacks. The "regsiterService" can return a URI to represent a
physical endpoint address that can be used outside of the hosting
machine.
Now we allow the binding.sca to be mapped to any of the bindings. It
requires the mapped binding to propagate the physical URI to the client
side
too.
Two questions to be answered:
1) How does a binding generate the physical endpoint address based on
the
binding URI and other information?
2) The binding provider should be responsible for setting the binding
with
the "deployed" URI (do we need to have a separate property in the
Binding
java model?) into the endpoint so that it can be propagated into the
endpoint registry?
Yep its a problem alright, i've been thing about too.
The only way I can see it working well is if Tuscany has a proper
fixed base url per protocol and have _everything_ that uses that
protocol use that base url, that means anything that listens for
things remote requests eg the endpoint registry. Ideally as much as
possible we'd want to try to choose the value programatically so users
don't need to manually configure it, but that can get hard especially
with multiple network interfaces, virtual hosts, and public/private
host names. Pragmatically we're mainly interested in the host name/ip
addresses, so likely often times we might just need to manually
specify that/those when starting a Tuscany runtime.
...ant
In the binding.sca case:
- There is no binding URI on the service side so we have to rely on
the default binding URI generated schema for the binding that is
mapped
For binding.sca, the @uri attribute on service side is ignored. It will be
populated with the structural URI. The structural URI will be used by the
mapped binding to generate a physical endpoint address.
- The URI on the reference is an SCA target name and we rely on the
configuration of the service endpoint to configure the mapping on the
reference.
We need to make sure the @uri follows the <component>/<service>/<binding>
syntax.
- Ant's point is a good one and I think we have taken this approach
with the node configuration file where base URIs can be set for each
scheme.
The configured binding base URI will provide the accurate intension. What I
was asking is the case where a base URI is not defined.
I wondering though whether the default URI generated for bindings used
for remote binding sca support need to be different from default URIs
generation for bindings added manually. For example,
<component ...>
<service ...>
<binding.sca/>
<binding.ws/>
</service>
</component>
Assuming that ws maps to the sca binding, will that try to register
the same service endpoint twice?
This configuration is NOT valid. The SCA spec will require one of the
bindings to be configured with @name. The binding name will make the
structural URI unique within the same service.
As to the questions...
1/ I think based on the algorithm embodied in BindingURIBuilderImpl,
which pretty much takes the based URI for a scheme and adds either the
structural URI or and relative stuff from the binding URI.
Yes, I saw that. But the spec says the binding can choose to map it to a
physical URI on its own. The final URI is the deployed URI.
2/ Can you say a bit more about why another field might be required?
Is this to separate the deployed URI from what was originally entered
by the user into the binding uri field?
Yes. I was wondering if we need to separate the deployed URI from the
binding/@uri.
Simon
