You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2007/09/10 01:03:13 UTC
Domain changes
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.
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?
I have used the interfaces Node and Domain currently should this be SCANode
and SCADomain?
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.
Simon
Re: Domain changes
Posted by ant elder <an...@gmail.com>.
On 9/10/07, Simon Laws <si...@googlemail.com> wrote:
<snip>
I have used the interfaces Node and Domain currently should this be SCANode
> and SCADomain?
I like SCANode and SCADomain.
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.
+1 to rationalizing all the domain impls.
...ant
Re: Domain changes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino 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 :)
>
>> 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.
>
>> 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.
>
>> Simon
>
On top of what you already have, I'd like to be able to describe Nodes
with something like follows:
<composite name="MyNodes">
<component name="NodeA">
<implementation.node composite="bb:BigbankAccount"/>
</component>
<component name="NodeB">
<implementation.node composite="bb:BigbankCalculator"/>
</component>
</composite>
allowing, as a next step, to do something like follows:
<composite name="MyNodes">
<component name="NodeA">
<service name="ContributionManager>
<binding.ws/>
</service>
<service name="ComponentManager>
<binding.ws/>
</service>
<implementation.node composite="bb:BigbankAccount"/>
</component>
or for example
<component name="NodeB">
<service name="ContributionManager>
<binding.atom/>
</service>
<service name="ComponentManager>
<binding.jsonrpc/>
</service>
<implementation.node composite="bb:BigbankCalculator"/>
</component>
</composite>
I'm starting on working on an implementation-node module to support that.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Domain changes
Posted by Simon Laws <si...@googlemail.com>.
On 9/13/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > On 9/12/07, Simon Laws <si...@googlemail.com> wrote:
> >
> >> On 9/12/07, Simon Nash <na...@hursley.ibm.com> wrote:
> >>
> >>> Comments inline.
> >>>
> >>> Simon
> >>>
> >>> Simon Laws wrote:
> >>>
> >>>
> >>>> Thanks for the reply Sebastien
> >>>>
> >>>> A few more comments below...
> >>>>
> >>>> On 9/12/07, Jean-Sebastien Delfino <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>
> >>> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> OK, I can't live with that. I'll make the change.
Simon
Re: Domain changes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 9/12/07, Simon Laws <si...@googlemail.com> wrote:
>
>> On 9/12/07, Simon Nash <na...@hursley.ibm.com> wrote:
>>
>>> Comments inline.
>>>
>>> Simon
>>>
>>> Simon Laws wrote:
>>>
>>>
>>>> Thanks for the reply Sebastien
>>>>
>>>> A few more comments below...
>>>>
>>>> On 9/12/07, Jean-Sebastien Delfino <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Domain changes
Posted by ant elder <an...@gmail.com>.
On 9/12/07, Simon Laws <si...@googlemail.com> wrote:
>
> On 9/12/07, Simon Nash <na...@hursley.ibm.com> wrote:
> >
> > Comments inline.
> >
> > Simon
> >
> > Simon Laws wrote:
> >
> > > Thanks for the reply Sebastien
> > >
> > > A few more comments below...
> > >
> > > On 9/12/07, Jean-Sebastien Delfino <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > 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
Re: Domain changes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
>
> Simon Laws wrote:
>
>> On 9/12/07, Simon Nash <na...@hursley.ibm.com> wrote:
>>
>> (cut)
>>>
>>> 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 think this is better. I would see the TuscanyDomain as Tuscany's
> implementation of SCA's Domain concept. In that correct?
>
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
So I thought a little bit more about that and I think I prefer:
org.apache.tuscany.sca.Domain
instead of:
org.apache.tuscany.sca.SCADomain
or org.apache.tuscany.sca.TuscanyDomain.
This is similar to:
org.osoa.sca.ComponentContext
org.osoa.sca.ServiceReference
commonj.sdo.DataObject
which are not named:
org.osoa.sca.SCAComponentContext
org.osoa.sca.SCAServiceReference
commonj.sdo.SDODataObject
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Domain changes
Posted by Simon Nash <na...@hursley.ibm.com>.
Simon Laws wrote:
> On 9/12/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
>(cut)
>>
>>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 think this is better. I would see the TuscanyDomain as Tuscany's
implementation of SCA's Domain concept. In that correct?
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Domain changes
Posted by Simon Laws <si...@googlemail.com>.
On 9/12/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
> Comments inline.
>
> Simon
>
> Simon Laws wrote:
>
> > Thanks for the reply Sebastien
> >
> > A few more comments below...
> >
> > On 9/12/07, Jean-Sebastien Delfino <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> 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?
Simon
Re: Domain changes
Posted by Simon Nash <na...@hursley.ibm.com>.
Comments inline.
Simon
Simon Laws wrote:
> Thanks for the reply Sebastien
>
> A few more comments below...
>
> On 9/12/07, Jean-Sebastien Delfino <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Domain changes
Posted by Simon Laws <si...@googlemail.com>.
Thanks for the reply Sebastien
A few more comments below...
On 9/12/07, Jean-Sebastien Delfino <js...@apache.org> 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
> 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.
> Simon
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Domain changes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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 :)
> 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.
> 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.
> Simon
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org