>
>> 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.
>>
>
> Absolutely, I agree. I think there are two pieces, one is how the
> distributed runtimes find each other, the other is how they talk to
> each other. The finding each other could be some static configuration
> with a properties or xml file, or it could use some dynamic approach
> using multicast or zeroconf etc. (you likely even want to combine
> those so you can use both approaches at once) Once they're found each
> other they'll know the addresses so could use a point to point
> protocol to talk to each other. I do think it would be good to support
> a dynamic approach as that makes it so much easier for getting
> started, but i agree we'll need the static configuration too for lots
> of production scenarios.
>
> 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.
>
> 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.
>
> Before i go further, do you agree with all that?
>
>  ...ant
>

Made some changes yesterday to bring the node configuration file into
play. Some thoughts on this exercise

- it's optional. When it's not provided I think we need a more obvious
way of defining what the defaults the bindings will use. At the
moment, for example, HTTP bases bindings pull the info from the
servlet host.. It would be useful to make that info more generally
available in the runtime to allow the endpoints to get hold of it
before the binding is started. Of course, in a container environment
not configured to our programmatic default you will have to either
configure the node or the SCDL explicitly in order that the endpoint
information is know in the domain

- The config file currently supports a bespoke format for bindings. We
may want to exploit real binding models here but it's ok for now. As
it happens I clashed with changes that Raymond was making to add model
types to bindings which helps match bindings against this binding
configuration. I also think we should move this configuration to a
more basic module than node so that assembly can depend on it in order
that the builders can refer to it directly.

- Did you get any further in the thinking about decoupling binding.sca
from the hosting environment. Or to put it another way, what
technology and default configuration should we adopt?

Simon

Reply via email to