On Mon, Jun 22, 2009 at 3:49 PM, Simon Laws<simonsl...@googlemail.com> wrote: > On Mon, Jun 22, 2009 at 1:46 PM, ant elder<ant.el...@gmail.com> wrote: >> On Mon, Jun 22, 2009 at 1:15 PM, Simon Laws<simonsl...@googlemail.com> 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.
I'm not sure what you're mean? > > 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. > Great. > 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
