On Dec 13, 2007 12:50 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> The discussion is getting too long for me to follow, sorry. We > (including me) should try harder to write shorter emails. > > Simon Laws wrote: > > When processing references at the domain level I need to know the name > of > > the target service which each reference binding... > > Question: When? are you installing, loading, building, starting, or > executing an invocation? Can you point to the code that needs to know > the name... > > Thanks > -- > Jean-Sebastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > This is the point at which the composites have been started. Two reasons why bindings need to be identified and have endpoint information updated. 1. The endpoint information is not known in the domain unless it is explicitly provided by the user. If it isn't provided by the user the nodes work it out as they run composites and then tell the domain. I.e. each service binding, during the activation phase, determines what its endpoint will be based on the various bits of information we discussed previously [1]. The domain doesn't actually run anything but just builds the model. Each node builds the runtime model of its composite separately as it has to link in with the local host environment. The domain doesn't provide the hosts that the nodes do. We could maybe come up with some pretend host that applies the url generation rules when the domain is building it's model based on which node is running the composite being processed but that's not what happens at the moment. 2. The endpoint information is changed by changes in the domain, for example, a wire is added or removed. If we can't find a reference binding and update it and we were to rely on the domain calculating all of the endpoints then each affected node would have to be restarted whenever such a change is made. The code that finds and updates binding information is coming together in updateComposite in nodeImpl(). It looks across all references and compares the bindings against the new composite being provided. As per the subject of this mail the hard part is working out which binding is which. Currently it only updates the binding URI which is not enough in some cases but I'm just trying this out at the moment. Simon [1] http://www.mail-archive.com/[email protected]/msg26102.html
