I'm on the same page as Simon. The distributed endpoint registry is an
effort to shield the physical locations from the logical SCA addresses
(componentURI/serviceName/bindingName). For binding.sca, we map it to a
remote protocol for cross-JVM cases, such as WS, RMI/IIOP. We'll look up the
physical endpoint from the registry based on the SCA structural URIs.
Worth to point, even for multicast-based stacks such as Tribes, some manual
configurations are required. For example, if you have multiple-homed
networks, such as WIFI and Ethernet, you need to configure the binding
address so that multicast works.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[email protected]>
Sent: Monday, June 22, 2009 7:49 AM
To: <[email protected]>; <[email protected]>
Subject: Re: [2.x] remote binding.sca
On Mon, Jun 22, 2009 at 1:46 PM, ant elder<[email protected]> wrote:
On Mon, Jun 22, 2009 at 1:15 PM, Simon Laws<[email protected]>
wrote:
3) We need to map it to an absolute WS URI when it publishes to the
endpoint
registry (Simon already mentioned that we need to have base URIs for a
given
node. For the moment, we can just use http://localhost:8080/ as the
default)
so that the client side sees the physical URI of the remote endpoint.
Right, this is the point about passing default binding information
into the binding URI calculation. Can we have a node configuration
file for this kind of info. I'm not suggesting that we use a composite
file as we do currently in the 1.x domain manager. but a specific XML
file for configuring the node. Could contain.
node configuration info (if not provided on command line)
default binding information
pointer to (or nested) composite file to describe management services
that node provides (future feature)
This is a piece that has never worked very well in past domain
attempts, because the http host and port is environment dependent and
quite variable and we don't have any way for the runtime to
programatically determine it. What would be better would be to find a
way for the sca binding to not be environment dependent. I guess the
way to do that is to not use the hosting web container for the sca
binding so probably using something other than our binding.ws as the
base for it. An in-VM based binding seems like it would work well for
things like the embeded webapp, tomcat and geronimo environments, when
the tuscany runtime needs to be distributed across JVMs maybe we
should look at a Tribes based transport for the SCA binding as that
could use the same config as the Tribes based endpoint registry.
...ant
I agree that we haven't got this right to date. However I do think we
need to look at as its scope is wider than the SCA binding.
An in VM binding is certainly what we want for in-JVM calls. Hence I
was setting up the build so we can detect this.
Re. the cross-JVM case. I don't want to stop you investigating Tribes
as an option. It sounds interesting. But an interesting question to
understand is how you need to have your network and firewall
configured to make it work. We may find that we still need to support
point to point protocols for both the endpoint registry and the
default binding.
Regards
Simon
