One more point is that bindings other than binding.sca can also take
advantage of SCA wirings, for example:
<component name="Component1>
<reference name="ref1" target="Component2/Service1">
<binding.ws/> // URI is looked up from the target service
</reference>
</component>
<component name="Component2">
<service name="Service1">
<binding.ws/> // The binding URI will be derived from the structural URI
</service>
</component>
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[email protected]>
Sent: Tuesday, June 23, 2009 2:10 AM
To: <[email protected]>; <[email protected]>
Subject: Re: [2.x] remote binding.sca
What i was getting at is that the way they talk should be decoupled
from the hosting environment so we avoid the problems we've had in the
past such as a sample configured to use port 8085 as part of the build
then doesn't work out-of-the box when people try to use it on port
8080.
I agree that we would like to see a lot of our samples using
binding.sca and that that should be as flexible as possible, However
we can't exclusively rely on binding.sca and will have to configure
binding.ws, binding.http etc. In these latter cases we can't disregard
the hosting environment. As we are going to have to have some
configuration for a node I'd rather it was all in one place so it's
obvious what the user has to configure.
And, its looking likely to me that the endpoint registry and sca
binding can be closely tied together, for example there doesn't seem a
whole lot of point in wanting a WS based sca binding for
network/firewall reasons if the endpoint registry is using multicast
so wont work across that firewall.
I agree, if you adopt one approach for one part you would assume it's
going to work for another. I would though treat something like tribes
as a transport. That means you can still run SOAP over it if
appropriate.The endpoint ceases to be something you derive a direct
physical address from but supplies the name of the member in the group
that supports the service (the node) and then the name of the
component/service at that node. Most of that info comes from the
wiring and some of it (node info) would have to be added to the
endpoint structure (has been suggested before).
The logical configured root for the binding.sca uri could be the info
that is used so set up tribes. I've not played with it so I don't know
precisely what info is required.
So, in summary, I think this cuts both ways. You would like a
binding.sca that exploits a non HTTP transport. I'd like an endpoint
registry that exploits an HTTP transport. Doesn't mean either one is
invalid. But it would be good if we could use the same configuration
mechanism to support both.
Before i go further, do you agree with all that?
...ant
