On 9/13/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > ant elder wrote: > > On 9/12/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > >> On 9/12/07, Simon Nash <[EMAIL PROTECTED]> wrote: > >> > >>> Comments inline. > >>> > >>> Simon > >>> > >>> Simon Laws wrote: > >>> > >>> > >>>> Thanks for the reply Sebastien > >>>> > >>>> A few more comments below... > >>>> > >>>> On 9/12/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > >>>> > >>>> > >>>>> Simon Laws wrote: > >>>>> > >>>>> > >>>>>> There are some reorganized domain/node classes under > >>>>>> > >>> modules/distributed > >>> > >>>>> and > >>>>> > >>>>> > >>>>>> modules/distributed-impl dirs. Here the SCADomain is replaced by a > >>>>>> > >>>>> Node. A > >>>>> > >>>>> > >>>>>> node runs all or part of a domain. A Node has contributions added > and > >>>>>> removed and has components started/stoppped etc. If available (a > >>>>>> > >> domain > >> > >>>>> and > >>>>> > >>>>> > >>>>>> node name are provided and the domain is running) a Node registers > >>>>>> > >>> with > >>> > >>>>> a > >>>>> > >>>>> > >>>>>> DomainManager service and a ServiceDiscovery service. Here's what's > >>>>>> > >> in > >> > >>>>> the > >>>>> > >>>>> > >>>>>> new code > >>>>>> > >>>>>> Node > >>>>>> - A node implementation (NodeImpl) > >>>>>> - A contributions manager for adding/removing contributions > >>>>>> - A component manager > >>>>>> - A management SCA application that provides access to these > features > >>>>>> remotely > >>>>>> - a web page for looking at the node > >>>>>> > >>>>>> Domain > >>>>>> - A ServiceDiscovery service > >>>>>> - A domain manager service > >>>>>> - A sample domain application that pulls two together and includes > >>>>>> - A web page for looking at the domain and provides links to each > >>>>>> > >> nodes > >> > >>>>> web > >>>>> > >>>>> > >>>>>> page. > >>>>>> > >>>>>> > >>>>>> > >>>>> This looks pretty good to me! So far I've looked at the interfaces > and > >>>>> the implementation, and will try the web pages next :) > >>>>> > >>>>> > >>>> I'd like to make a proposal to change ServiceDiscovery a bit, but > I'll > >>>> > >>>> > >>>>> do that in a separate email. > >>>>> > >>>>> > >>>>> > >>>>>> You can try this by running the calculator distributed sample. This > >>>>>> > >>> runs > >>> > >>>>> and > >>>>> > >>>>> > >>>>>> exercises some distributed nodes as it always has but uses the new > >>>>>> > >>>>> classes > >>>>> > >>>>> > >>>>>> now. If you run the nodes independently from the command line they > >>>>>> > >> stay > >> > >>>>>> around long enough for you to point a browser at them. Try > >>>>>> htpp://localhost:8080/node/index.html (or whatever port the node > has > >>>>>> > >>>>> come > >>>>> > >>>>> > >>>>>> up on) and see the components in a node. > >>>>>> > >>>>>> > >>>>>> There is a new sample (sample-domain-webapp). The intention here is > >>>>>> > >> to > >> > >>>>>> provide a generic domain and a node so you can start the domain and > >>>>>> > >>> node > >>> > >>>>> and > >>>>> > >>>>> > >>>>>> then add contributions. Not complete yet as the "add contribution" > >>>>>> > >>>>> function > >>>>> > >>>>> > >>>>>> needs turning into a remote service but you can use the domain > >>>>>> implementation along with nodes from the distributed calculator > >>>>>> > >> sample > >> > >>>>> which > >>>>> > >>>>> > >>>>>> have hard coded contributions. > >>>>>> > >>>>>> Here are some todos > >>>>>> > >>>>>> I've copied all of the interfaces I need to make this work into > >>>>>> modules/distributed so there is code/interfaces here that is also > >>>>>> > >>>>> elsewhere, > >>>>> > >>>>> > >>>>>> for > >>>>>> example, the component manager classes. I would like to move the > new > >>>>>> > >>>>> code to > >>>>> > >>>>> > >>>>>> new modules > >>>>>> > >>>>>> modules/host-node - for the node related code? > >>>>>> modules/host-domain - for the domain related code? > >>>>>> > >>>>>> > >>>>> How about this? > >>>>> modules/node > >>>>> modules/domain > >>>>> > >>>>> IMO host-* is for the integration with hosting environments like > >>>>> > >> Tomcat, > >> > >>>>> Jetty, an HTTP or RMI server. > >>>>> And host-embedded should probably not be called host-embedded :) > >>>>> > >>>> > >>>> Sounds OK to me - I'll go ahead and split them out. > >>>> > >>>> > >>>> > >>>>> I have used the interfaces Node and Domain currently should this be > >>>>> SCANode > >>>>> > >>>>> > >>>>>> and SCADomain? > >>>>>> > >>>>>> > >>>>> I'm OK with both, not sure what others prefer. > >>>>> > >>>> > >>>> I'm ambivalent but we have one positive request for SCANode and > >>>> > >>> SCADomain so > >>> > >>>> I'll wait a little longer and probably change to that > >>>> > >>>> > >>> I don't think we need "SCA" in front of these names. After all, > >>> just about everything we are doing in Tuscany is to do with SCA, > >>> so if we go down this path we might see "SCA" name prefixes > >>> cropping up everywhere :-( > >>> > >>> Is there a reason why these two names would need "SCA" in front of > >>> them? Do we have any other "Node" or "Domain" concept in Tuscany > >>> that could be be confused with these? > >>> > >>> > >>>>> host-embedded can stay as it provides the runtime and embedded > support > >>>>> > >>> but > >>> > >>>>>> there are numerous domain implementations that we can remove > assuming > >>>>>> > >>> we > >>> > >>>>>> get to the stage where we are comfortable with Node. Ant has > already > >>>>>> > >>>>> ported > >>>>> > >>>>> > >>>>>> the hot update web app to use the new domain (currently working > >>>>>> > >> through > >> > >>>>>> an issue with uris) > >>>>>> > >>>>>> I'd like to start using the Node implementation in the samples. > I'll > >>>>>> > >>>>> have a > >>>>> > >>>>> > >>>>>> go at converting some and see how it goes. > >>>>>> > >>>>>> > >>>>> Great! > >>>>> > >>>>> I'd suggest to move the API methods (expected to be used in > >>>>> > >> application > >> > >>>>> business logic) like getService(), getServiceReference() and cast() > to > >>>>> > >> a > >> > >>>>> separate interface in a separate domain-api or node-api module. > >>>>> > >>>> > >>>> OK, i'll take a look at that. > >>>> > >>>> > >>> + 1 for this. I think the new module should include the API for > >>> > >> creating > >> > >>> a domain as well. > >>> > >>> Simon > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> I don't think we have more than one node or domain concept. These > words > >>> > >> are used elsewhere many times (outside of Tuscany) and it could be > useful > >> to > >> ensure that people understand that we are talking about the Tuscany > >> concept > >> of Node and Domain rather than anyone else's. The code at the moment > uses > >> Node and Domain. I raised the question as I felt there was scope for > >> confusion. I'm now thinking that the SCA prefix is too loose (and not > >> applicable in the Node code) so maybe TuscanyNode/TuscanyDomain would > fit > >> the bill? > >> > > > > > > I still prefer SCADomain out of all the suggestions :) For this > particular > > case i think its good to have the SCA suffix and that it makes it more > > intuitive what its about. > > > > ...ant > > > > > > OK then, I'm happy with SCADomain and SCANode too :) > > -- > Jean-Sebastien > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > OK, I can't live with that. I'll make the change.
Simon
