You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2010/07/08 08:14:58 UTC
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
ant elder wrote:
> On Sun, Jul 4, 2010 at 9:19 PM, Jean-Sebastien Delfino
> <js...@apache.org> wrote:
>> ant elder wrote:
>>> On Fri, Jul 2, 2010 at 11:14 PM, Jean-Sebastien Delfino
>>> <js...@apache.org> wrote:
>>>> Hi all,
>>>>
>>>> I've committed a little program that I find useful to start and stop
>>>> Tuscany
>>>> nodes interactively under samples/launcher-shell.
>>>>
>>>> It just reads and executes commands from input. The following commands
>>>> are
>>>> supported:
>>>> start <node-name> <contrib-uri> <contrib-location>
>>>> stop <node-name>
>>>> status
>>>> history
>>>> bye to exit
>>>>
>>>> For details to build and run it, see the README [1].
>>>>
>>>> I've been thinking about adding a little more to it, like support for
>>>> multiple contributions, display the composites, or more node status info
>>>> for example.
>>>>
>>>> Hope this helps.
>>>> [1]
>>>>
>>>> http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/samples/launcher-shell/README
>>>> --
>>>> Jean-Sebastien
>>>>
>>> I like it. There are already some scripts in the binary distribution
>>> that run contributions, but its nicer to to run interactively like
>>> this does so we could update the distribution scripts to use this. It
>>> would be good to support all the other domain operations too so I'd
>>> like to help do that if thats ok with you.
>>>
>>> ...ant
>> Hi Ant,
>>
>> Thanks for volunteering. I'm glad you like it, I've been using this little
>> shell to start/stop my apps and found it quite easy to use so I thought it'd
>> help others too.
>>
>> If you want to help, I need more commands (to support apps made of multiple
>> contribs etc), illustrated by the following example script:
>>
>> => install c1 http://foo.org/c.jar
>>
>> => install c2 http://foo.org/d.jar
>>
>> => install c3 http://foo.org/e.jar
>>
>> => installed
>> c1 http://foo.org/c.jar http://myns foo
>> c2 http://foo.org/d.jar http://myns bar
>> c3 http://foo.org/e.jar
>>
>> => installed c1
>> c1 http://foo.org/c.jar http://myns foo
>>
>> => validate c1
>> resolved c3
>> missing http://otherns x4 (a namespace provided by c4)
>>
>> => install c4 http://foo.org/f.jar
>>
>> => start nodeA c1 http://myns foo
>>
>> => start nodeB c2 http://myns bar
>>
>> => status
>> nodeA c1 http://myns foo
>> nodeB c2 http://myns bar
>>
>> => status nodeA
>> nodeA c1 http://myns foo
>>
>> => stop nodeA
>>
>> => stop nodeB
>>
>> => bye
>>
>> In this example, c1 is a contribution URI, http://foo.org/c.jar its
>> location, nodeA is a node name, http://myns foo is a composite qname.
>>
>> I was going to code these commands myself as I'll need them mid of this
>> week, but I could use your help as I'm quite busy with other things too.
>>
>> So if you have time, do you think you could add the above commands sometime
>> this week? That would really help me a lot!
>>
>> Thanks!
>> --
>> Jean-Sebastien
>>
>
> I've been looking at this in the trunk module tuscany-shell (if you
> didn't see that from the commits), its not completely the same as what
> you've been doing as i wanted to be exercising the domain-node api,
> but it should be close enough that we should hopefully be able to get
> to something we all like. Its still work in progress but you can try
> it out by adding running the class org.apache.tuscany.shell.Shell and
> including the dependency tuscany-shell (and jline if you want to use
> that), or more simply by building shaded base-nodep and doing java
> -jar tuscany-base-nodep-2.0-SNAPSHOT.jar.
>
> ...ant
Thanks Ant, I have a few comments and questions.
I'm confused as you've switched o.a.t.node.NodeFactory to a different
o.a.t.node2.NodeFactory. I see 49 references to node.NodeFactory in the
source tree, everywhere people need to create nodes. node2.NodeFactory
looks like a parallel implementation, with only 3 references, if I'm not
mistaken only from this new shell. What happened?
I don't really understand the new implementation of start() which
initially just started a node, and now calls addToDomainLevelComposite()??
I'm puzzled as well with the logic in stop(), which now calls
node.stop() + factory.stop() + removeFromDomainLevelComposite(). For me
starting / stopping components in nodes is really orthogonal to adding /
removing composites to / from the domain.
I think we should revert back to specific parameters on the command
methods, like you still have on start() instead of just a list of toks
like you now have on stop(). Passing the list of toks defeats the
purpose of the eval() method.
Also this new shell seems to use a single node. It's fine with me if
that's what you want to do here, but that's not what I need. What I need
is a collection of independent nodes, each loaded with a deployable
composite, each with its own lifecycle, like I had in the original code.
I like the jline thing though. I guess for now I'll probably steal that
idea into the sample shell :) until your shell meets my needs. I'll be
happy to switch to using your new shell later when you support multiple
nodes again...
--
Jean-Sebastien
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> I'll respond to this in two separate replies as there are two things
> you're asking about.
>
> On Thu, Jul 8, 2010 at 7:14 AM, Jean-Sebastien Delfino
> <js...@apache.org> wrote:
>
> <snip>
>
>> I'm puzzled as well with the logic in stop(), which now calls node.stop() +
>> factory.stop() + removeFromDomainLevelComposite(). For me starting /
>> stopping components in nodes is really orthogonal to adding / removing
>> composites to / from the domain.
>>
>
> The stop command has three variations depending on the arguments:
>
> 1) stop contributionURI compositeURI
> 2) stop contributionURI
> 3) stop
>
> In (1) that will stop a running composite which is the same as the
> stop command you had with the difference that your original start
> command could give the deployed composite a label like "nodeA" and
> then use that label on the stop.
Right that label is the name of a node, I'd like to keep it to be able
to list nodes and their status, or stop or restart nodes without having
to remember what contribution and composite they're running.
The old start used the composite
> qname
I didn't have the composite qname in the old start, just node-name,
contribution uri, contribution location.
this one uses the composite uri and that matches the operations
> describe in the spec, and when using start contributionURI composite
> URI you don't really need another label for that.
Well, I do, like I said, that's a node name, and I want to use it to
control the node.
> We could add the
> other way too i guess, is that something you feel strongly about?
I like to have this node name. That's why I had put it there in the
first place.
>
> The (2) format stops a contribution and all its running composites,
> (3) stops everything and shuts down the shell which is the same as
> your 'bye' command, the bye command is still there doing the same as
> the noarg stop. Are you sayng you'd prefer the noarg stop command is
> removed and only have bye?
I don't understand why stop would exit the shell. In my view there can
be multiple nodes in a shell, you can start/stop them individually,
start/stop all of them, but that's different from exiting the shell.
I don't understand either why the stop command would call
removeFromDomainComposite... If stop just stops a runtime instance, it
shouldn't really affect the domain composition...
So there's a disconnect here... I'm starting to sense that your new
concept shell is actually very different from my original shell sample,
and perhaps this is the disconnect.
I had multiple runtime nodes in a shell, but no concept of a domain at all.
Your new shell is really a domain shell, attempting to support SCA
domain operations. Perhaps that's why your start / stop commands call
addToDomainComposite / removeFromDomainComposite, and also why you have
a single Node2 node from module domain-node...
Implementing an SCA domain shell, to allow an administrator to manage an
SCA domain, is a fine idea and something Tuscany should do IMO, but my
goal with the launcher shell was much less ambitious, and pretty
different too: just support starting / stopping runtime nodes, which
would just get the SCA contributions from an SCA domain managed separately.
In summary, my perception is that samples/launcher-shell was just a
runtime node launcher shell, and modules/shell is really an SCA domain
manager shell. Both should co-exist IMO, as separate tools, perhaps as
modules/domain-shell and modules/node-shell if people want to make these
tools mainstream in Tuscany.
>
>> I think we should revert back to specific parameters on the command methods,
>> like you still have on start() instead of just a list of toks like you now
>> have on stop(). Passing the list of toks defeats the purpose of the eval()
>> method.
>>
>
> Seems like an implementation detail but fine. Passing in toks made it
> easy to handle optional arguments but either approach is ok by me.
>
--
Jean-Sebastien
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by ant elder <an...@gmail.com>.
I'll respond to this in two separate replies as there are two things
you're asking about.
On Thu, Jul 8, 2010 at 7:14 AM, Jean-Sebastien Delfino
<js...@apache.org> wrote:
<snip>
> I'm puzzled as well with the logic in stop(), which now calls node.stop() +
> factory.stop() + removeFromDomainLevelComposite(). For me starting /
> stopping components in nodes is really orthogonal to adding / removing
> composites to / from the domain.
>
The stop command has three variations depending on the arguments:
1) stop contributionURI compositeURI
2) stop contributionURI
3) stop
In (1) that will stop a running composite which is the same as the
stop command you had with the difference that your original start
command could give the deployed composite a label like "nodeA" and
then use that label on the stop. The old start used the composite
qname this one uses the composite uri and that matches the operations
describe in the spec, and when using start contributionURI composite
URI you don't really need another label for that. We could add the
other way too i guess, is that something you feel strongly about?
The (2) format stops a contribution and all its running composites,
(3) stops everything and shuts down the shell which is the same as
your 'bye' command, the bye command is still there doing the same as
the noarg stop. Are you sayng you'd prefer the noarg stop command is
removed and only have bye?
> I think we should revert back to specific parameters on the command methods,
> like you still have on start() instead of just a list of toks like you now
> have on stop(). Passing the list of toks defeats the purpose of the eval()
> method.
>
Seems like an implementation detail but fine. Passing in toks made it
easy to handle optional arguments but either approach is ok by me.
...ant
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by ant elder <an...@gmail.com>.
On Thu, Jul 8, 2010 at 4:31 PM, Raymond Feng <en...@gmail.com> wrote:
> I think it would be a good idea to agree on the commands for shell. This
will help us understand how users use SCA. Then it can be translated into a
set of API/SPIs.
>
Here's what the shell module currently has:
(the easiest way right now to see it for yourself is by building
shades\base-nodep and doing java -jar
target\tuscany-base-nodep-2.0-SNAPSHOT.jar)
>java -jar target\tuscany-base-nodep-2.0-SNAPSHOT.jar
Apache Tuscany Shell (2.0-SNAPSHOT 961743 20100708-1353)
Commands:
help
install [<uri>] <contributionURL> [-norun -metadata <url> -duris
<uri,uri,...>]
installed [<contributionURI>]
remove <contributionURI>
addDeploymentComposite <contributionURI> <contentURL>
printDomainLevelComposite
start <curi> <compositeUri>
status [<curi> <compositeUri>]
stop [<curi> <compositeUri>]
Use Tab key for command and argument completion
For detailed help on each command do 'help <command>', for help of startup
options do 'help startup'
=> help install
install [<uri>] <contributionURL> [-norun -metadata <url> -duris
<uri,uri,...>]
Creates an installed contribution with a supplied root contribution,
installed at abase URI.
Arguments:
uri - (optional) the URI (name) to use for the contribution. When no
uri is specified
a default URI is used derived from the contribution URL
contributionURL - (required) the URL to the contribution to install
-norun - (optional) do not start any composites listed as deployable in
the sca-contribution.xml file
-metadata <url> - (optional) the URL to an external contribution meta
data document that should be
merged into any existing sca-contributions.xml file within the
contribution.
-duris <uri,uri,...> - (optional) specifies the URIs of contributions
that are used to resolve the
dependencies of the root contribution and other dependent
contributions.
When not specified all installed contributions are used to
resolve dependencies.
=> help installed
installed [<contributionURI>]
Shows information about the contributions installed on this node,
including the contribution URI and location along with the URI
and QName of any composites within the contribution
Arguments:
contributionURI - (optional) the URI of an installed contribution
=> help remove
remove <contributionURI>
Removes an installed contribution
Arguments:
contributionURI - (required) the URI of an installed contribution
=> help addDeploymentComposite
addDeploymentComposite <contributionURI> <contentURL>
Adds a deployment composite using a supplied composite ('composite by
value' - a data
structure, not an existing resource in the Domain) to the contribution
identified by a
supplied contribution URI. The added deployment composite is given a
relative URI that
matches the @name attribute of the composite, with a '.composite' suffix.
Since all composites
run within the context of an installed contribution (any component
implementations or other
definitions are resolved within that contribution), this functionality
makes it possible
for the deployer to create a composite with final configuration and wiring
decisions and add
it to an installed contribution without having to modify the contents of
the root contribution.
Arguments:
<contributionURI> - (required) the URI of an installed contribution
<contentURL> - (required) the location of the composite
=> help printDomainLevelComposite
printDomainLevelComposite
Not yet implemented
Arguments:
none
=> help start
start <curi> <compositeUri>
Starts a composite.
The composite is added to the domain composite with semantics that
correspond to the domain-level
composite having an <include> statement that references the supplied
composite. All of the composites
components become top-level components and the component services become
externally visible
services (eg. they would be present in a WSDL description of the Domain).
Arguments:
curi - (required) the URI of an installed contribution
compositeUri - (required) the URI of a composite
=> help status
status [<curi> <compositeUri>]
Shows the status of the Node, listing for each deployed composite its
contribution URI, the composite URI, and the composite QName.
Arguments:
curi - (optional) the URI of an installed contribution
compositeUri - (optional) the URI of a composite
=> help stop
stop [<curi> <compositeUri>]
Stops this Node or individual composites and contributions in the Node.
If a composite URI is specified then the composite is removed from the
Domain Level composite
This means that the removal of the components, wires, services and
references originally added
to the domain level composite by the identified composite. If a
contribution URI is specified
without a composite URI then all deployed composites composites in the
contribution are stopped.
If no contribution URI is specified then the entire Node is stopped and
the Shell exits.
Arguments:
curi - (optional) the URI of an installed contribution
compositeUri - (optional) the URI of a composite
=>
...ant
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by Simon Laws <si...@googlemail.com>.
>
>
> The 2.x Node is the execution environment for deployable composites within
> an SCA domain. The runtime does provide an endpoint registry that allows all
> nodes to share the endpoint descriptions for domain-level wiring. But this
> registry can be implemented using different ways:
> 1) A centralized registry
> 2) A p2p registry
> 3) Offline xml files
> We use the NodeConfiguration collects the information about the
> contributions, deployment composites and some other configurations. The
> NodeConfiguration can be created programmatically, loaded from an XML
> document or (potentially) provisioned from the SCA domain manager.
> AFAIK, I don't think we allow the contribution import/export to go beyond
> the node boundaries. Is it a new behavior in some other modules?
>
This is a key point that Raymond is making here. I'm going to repeat
it to see if I get is right but hopefully I'm saying the same thing
but with a few more words.
We've not designed the 2.x infrastructure with any strict domain
configuration architecture in mind other than that we've provided a
registry for exchanging information between the various points at
which composites from a domain are running (we happen to call these
points Nodes). How this registry is implemented and populated is an
exercise for the reader (actually the act of starting a composite does
populate the registry with endpoint information but I'm glossing over
that). The registry is really just an SPI. At the moment we have a
couple of shared cache implementations based on Hazelcast and Tribes.
In terms of exploiting this model initially we've focused on a peer to
peer model where nodes discover each other and exchange information,
via the registry, about the domain that they together describe. This
happens to be convenient for testing.
There are many other approaches that could be considered. For example,
here's two....
1/ when we embed Tuscany in an app server like Geronimo or Tomcat we
might expect some level of centralization of management of
contributions which are then run in separate parts of the app server
infrastructure. The registry model is the same though in that nodes
are configured with contributions and exchange domain information via
the registry. We may also expect the registry to exploit services
provided by the app server for sharing domain data.
2/ I'd like to make a file system based version where you can place
contributions in a set directory and have then form a domain. Again
the running nodes will exchange information via the registry. With
this approach you would either register the domain configuration
centrally using tools that's able to read the configuration and start
nodes on that basis or you could use a shared file system, start nodes
individually and have them populate the registry.
Having said all of this there is still work to do. The registry API
currently only deals with endpoint information. This is the basis of
all of our reference resolution logic and allows contributions to be
brought up at different times in different places. However it's not
currently able to pass information either about the service interface
or about policies that may be in action. Having just done some work on
normalizing interfaces I think we're in a position to fix the
interface deficiency. Haven't thought much about the policy issue yet.
The other thing that is lacking is any higher level domain information
exchange, such as information about contributions and composites. We
currently expect contributions to be delivered to Nodes out of band. I
think it would be useful to share a wider domain description via the
registry. We don't need to transport the contributions themselves via
the registry we just need to provide the URL of where they can be
obtained from. In this we we could achieve the goal of either
populating the registry and starting nodes based on the information
there or starting the nodes and having them populate the registry (or
a bit of both). Either way the end result is the same and tools that
are able to exploit the registry API get a full view of what's going
on.
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by Raymond Feng <en...@gmail.com>.
See my comments below.
Thanks,
Raymond
________________________________________________________________
Raymond Feng
rfeng@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
________________________________________________________________
On Jul 12, 2010, at 1:38 PM, ant elder wrote:
> On Sun, Jul 11, 2010 at 1:33 AM, Jean-Sebastien Delfino
> <js...@apache.org> wrote:
>> Raymond Feng wrote:
>>>
>>> Hi,
>>>
>>> We had a debate on this topic. See:
>>>
>>> http://osdir.com/ml/dev-tuscany.apache.org/2010-06/msg00164.html
>>>
>>> And apparently, we didn't reach agreement.
>>
>> It's probably a good idea to restart that discussion and find a consensus on
>> this. After having not looked at the Tuscany code for a while I must admit I
>> was a little confused by the multiple Node types.
>>
>> I'll try to participate in the discussion as much as I can, although I have
>> little spare time these days. In the meantime, I'd like to continue to use
>> the mainstream Node implementation for some time in samples/launcher-shell,
>> as it's what's working with webapps, all the test cases, samples etc.
>>
>>>
>>> I think it would be a good idea to agree on the commands for shell. This
>>> will help us understand how users use SCA. Then it can be translated into a
>>> set of API/SPIs. Mixing different steps into one layer could prevent us from
>>> seeing the complete user story.
>>
>> And like I tried to say in another email in this thread, I think we should
>> distinguish:
>> - Domain management, assembling components in a domain;
>> and
>> - Runtime instance configuration and management, loading a contribution in a
>> runtime instance and starting/stopping it.
>>
>> They are really different IMHO, for example an SCA domain administrator can
>> spend a day assembling components in a domain before starting a single
>> runtime instance, and stopping a server doesn't mean that he's removing a
>> composite from the SCA domain...
>>
>> --
>> Jean-Sebastien
>>
>
> I'm out till Wednesday so will comment more on this and the previous
> email when i'm back, but its worth pointing out now that the 2.x Nodes
> are different than the old 1.x ones - the 2.x o.a.t.s.node API makes
> Nodes that _are_ part of a domain not isolated standalone Node
> instances. So for example when you use the sample shell and you start
> Nodes they are all part of a domain named "default" and you can wire
> from references in one Node to services in another Node and exports
> from one Node are used by imports in another Node, and if you start a
> component that has the same component name as an existing one it will
> overwrite the old one. There is not currently a way with the 2.x APIs
> to create a Node that is not part of a domain and is isolated from all
> other Nodes.
>
The 2.x Node is the execution environment for deployable composites within an SCA domain. The runtime does provide an endpoint registry that allows all nodes to share the endpoint descriptions for domain-level wiring. But this registry can be implemented using different ways:
1) A centralized registry
2) A p2p registry
3) Offline xml files
We use the NodeConfiguration collects the information about the contributions, deployment composites and some other configurations. The NodeConfiguration can be created programmatically, loaded from an XML document or (potentially) provisioned from the SCA domain manager.
AFAIK, I don't think we allow the contribution import/export to go beyond the node boundaries. Is it a new behavior in some other modules?
> ...ant
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by ant elder <an...@gmail.com>.
On Sun, Jul 11, 2010 at 1:33 AM, Jean-Sebastien Delfino
<js...@apache.org> wrote:
> Raymond Feng wrote:
>>
>> Hi,
>>
>> We had a debate on this topic. See:
>>
>> http://osdir.com/ml/dev-tuscany.apache.org/2010-06/msg00164.html
>>
>> And apparently, we didn't reach agreement.
>
> It's probably a good idea to restart that discussion and find a consensus on
> this. After having not looked at the Tuscany code for a while I must admit I
> was a little confused by the multiple Node types.
>
> I'll try to participate in the discussion as much as I can, although I have
> little spare time these days. In the meantime, I'd like to continue to use
> the mainstream Node implementation for some time in samples/launcher-shell,
> as it's what's working with webapps, all the test cases, samples etc.
>
>>
>> I think it would be a good idea to agree on the commands for shell. This
>> will help us understand how users use SCA. Then it can be translated into a
>> set of API/SPIs. Mixing different steps into one layer could prevent us from
>> seeing the complete user story.
>
> And like I tried to say in another email in this thread, I think we should
> distinguish:
> - Domain management, assembling components in a domain;
> and
> - Runtime instance configuration and management, loading a contribution in a
> runtime instance and starting/stopping it.
>
> They are really different IMHO, for example an SCA domain administrator can
> spend a day assembling components in a domain before starting a single
> runtime instance, and stopping a server doesn't mean that he's removing a
> composite from the SCA domain...
>
> --
> Jean-Sebastien
>
I'm out till Wednesday so will comment more on this and the previous
email when i'm back, but its worth pointing out now that the 2.x Nodes
are different than the old 1.x ones - the 2.x o.a.t.s.node API makes
Nodes that _are_ part of a domain not isolated standalone Node
instances. So for example when you use the sample shell and you start
Nodes they are all part of a domain named "default" and you can wire
from references in one Node to services in another Node and exports
from one Node are used by imports in another Node, and if you start a
component that has the same component name as an existing one it will
overwrite the old one. There is not currently a way with the 2.x APIs
to create a Node that is not part of a domain and is isolated from all
other Nodes.
...ant
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by Florian MOGA <mo...@gmail.com>.
Hi,
I've been checking out the shell module as it seems a useful tool to have
and I'm also a fan of command line tools :). Considering the fact that it is
still a work in progress I can say i found it really nice as a general
impression. Here are some observations I made while using it:
- haven't been able to *install* any contributions... i always got some
validation error, either xml schema or class not found. i've tried
installing samples from trunk either packaged (in war or jar format) either
by passing the directory of the sample
- at first sight i had a hard time making distinction between *install*and
*start*, probably because the *help install *description was quite vague
- "*Creates an installed contribution with a supplied root contribution,
installed at abase URI". *What is installed contribution? Checking help
start I could deduce from "*The second form of the start command starts
in standalone mode not part of any SCA domain." *that the first form is
probably used in conjunction with a domain and probably i could use *
install* to add contributions to the domain.
- performing *install* on a contribution folder which was previously
built throws a validation exception stating that there are duplicate
contributions. this is probably due to the fact that it can find the
contribution in *src/* as well as in *target/*. When I'm running install
on the folder i'm expecting to install from src which is the most
up-to-date. If i wanted the built artifact i could pass the path to it
directly or to the *target/ *directory.
- i'm familiar with tuscany for a few months now and i still get confused
by all the different type of uris you have to take into account when
developing/deploying an sca contribution. If we're targeting this shell also
for people just wanting to give tuscany a try and will probably use the
shell, we might need to somehow get the terms like contribution uri, domain
uri, composite uri and the relation between them explained very clearly
either in the documentation on the site or in the shell hints or help.
Just as a short disclaimer, I might not be familiar enough with all the
sca/tuscany terms so read the above comments with this in mind.
Thinking of enhancements for the shell, I believe supporting the ability to
have the shell start logging the commands which were entered and running
tuscany shell scripts by passing a file as a parameter will bring
considerable advantages. This will enable automating complex sca deployments
simply by running a script. Choosing the embedded container when running
start will also be a plus.
This module makes me think of Spring Roo [0]. This tool has a different
purpose but check out this presentation at Google I/O [1] and then the list
of technologies it integrates with [2]. This is quite impressive and it
hasn't started for a long time. Haven't followed any trends but i believe
this will gain much popularity from now on and I find it a good step forward
for Tuscany and Tuscany popularity if we can contribute a Tuscany
integration in there. From what I've read Spring Roo is based on AOP and is
monitoring the filesystem for the automatically Roo annotated classes. At a
first glance I don't find it extremely complex to be generating and updating
the composite dynamically when a class is modified. Thoughts? Not having
that much experience with AOP...
Florian
[0] http://www.springsource.org/roo/
[1] http://www.youtube.com/watch?v=GQHlhIIxCIc&feature=channel
[2] http://www.springsource.org/roo/why
On Thu, Aug 19, 2010 at 8:41 AM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> Simon Nash wrote:
>
>> Raymond Feng wrote:
>>
>>> Sorry for the late reply. The message skipped out of my attention.
>>>
>>> My understanding is that a domain is the administrative (governance)
>>> boundary for SCA composite applications. Why does the Shell needs to switch
>>> between multiple domains within the same session. Typically, most admin
>>> consoles connect to one "boundary" at a time. For example:
>>>
>>> * OSGi console connects to an instance of the OSGi runtime
>>> * WebSphere admin console talks to a ND manager for a cell
>>> * Telnet/SSH connects to a host
>>>
>>> Why cannot we have the Shell session be associated with one SCA domain at
>>> a time, for example:
>>>
>>> shell <domainURI>
>>> tuscany> (all the commands are within the domain)
>>> tuscany>
>>>
>> There are testing scenarios where it's necessary to bring up and run
>> multiple domains at the same time. I think it would be useful to be
>> able to do this from a single shell rather than needing to bring up
>> separate shells to control each of the domains.
>>
>>
> as well as multi-tenant configurations, where a runtime is used to host
> apps for multiple tenants, each tenant having his own admin domain.
>
> --
> Jean-Sebastien
>
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
> Raymond Feng wrote:
>> Sorry for the late reply. The message skipped out of my attention.
>>
>> My understanding is that a domain is the administrative (governance)
>> boundary for SCA composite applications. Why does the Shell needs to
>> switch between multiple domains within the same session. Typically,
>> most admin consoles connect to one "boundary" at a time. For example:
>>
>> * OSGi console connects to an instance of the OSGi runtime
>> * WebSphere admin console talks to a ND manager for a cell
>> * Telnet/SSH connects to a host
>>
>> Why cannot we have the Shell session be associated with one SCA domain
>> at a time, for example:
>>
>> shell <domainURI>
>> tuscany> (all the commands are within the domain)
>> tuscany>
> There are testing scenarios where it's necessary to bring up and run
> multiple domains at the same time. I think it would be useful to be
> able to do this from a single shell rather than needing to bring up
> separate shells to control each of the domains.
>
as well as multi-tenant configurations, where a runtime is used to host
apps for multiple tenants, each tenant having his own admin domain.
--
Jean-Sebastien
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by Simon Nash <na...@apache.org>.
Raymond Feng wrote:
> Sorry for the late reply. The message skipped out of my attention.
>
> My understanding is that a domain is the administrative (governance)
> boundary for SCA composite applications. Why does the Shell needs to
> switch between multiple domains within the same session. Typically, most
> admin consoles connect to one "boundary" at a time. For example:
>
> * OSGi console connects to an instance of the OSGi runtime
> * WebSphere admin console talks to a ND manager for a cell
> * Telnet/SSH connects to a host
>
> Why cannot we have the Shell session be associated with one SCA domain
> at a time, for example:
>
> shell <domainURI>
> tuscany> (all the commands are within the domain)
> tuscany>
>
There are testing scenarios where it's necessary to bring up and run
multiple domains at the same time. I think it would be useful to be
able to do this from a single shell rather than needing to bring up
separate shells to control each of the domains.
Simon
> Thanks,
> Raymond
> /________________________________________________________________
> Raymond Feng
> rfeng@apache.org <ma...@apache.org>
> /Apache Tuscany PMC member and committer: tuscany.apache.org
> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
> Personal Web Site: www.enjoyjava.com
> /
> ________________________________________________________________/
>
> On Jul 31, 2010, at 1:18 AM, ant elder wrote:
>
>> On Sun, Jul 25, 2010 at 10:25 AM, ant elder <antelder@apache.org
>> <ma...@apache.org>> wrote:
>>> On Sun, Jul 25, 2010 at 8:48 AM, ant elder <antelder@apache.org
>>> <ma...@apache.org>> wrote:
>>>> On Sun, Jul 25, 2010 at 4:02 AM, Luciano Resende
>>>> <luckbr1975@gmail.com <ma...@gmail.com>> wrote:
>>>>> On Fri, Jul 23, 2010 at 12:25 AM, ant elder <ant.elder@gmail.com
>>>>> <ma...@gmail.com>> wrote:
>>>>>>
>>>>>> Thats all very useful but i think its a slightly different topic - one
>>>>>> thing that was wanted here was a way to create an isolated Node
>>>>>> instance thats _not_ part of any domain, so yes there's lots of
>>>>>> different ways we can have for building a domain but don't have any
>>>>>> API for creating standalone Nodes.
>>>>>>
>>>>>> ...ant
>>>>>>
>>>>>
>>>>> What's the difference of a Domain with a single node and a standalone
>>>>> node that's _not_ part of any domain ?
>>>>>
>>>>>
>>>>
>>>> For practical purposes not so much. Each domain would need its own
>>>> unique name but if thats ok then it seems like a fine way to do it to
>>>> me. I don't yet quite really understand the purpose of the "node name"
>>>> label when starting composites as discussed in [1] but if each node is
>>>> really in its own domain i wonder if "node name" could be replaced
>>>> with "domain name" and then a user can have started composites each in
>>>> their own domain or have multiple composites in the same domain if
>>>> they choose.
>>>>
>>>> ...ant
>>>>
>>>> [1] http://apache.markmail.org/message/vznaimmhc7jfxtj2
>>>>
>>>
>>> So if we did do that the commands could be something like the following:
>>>
>>> help
>>> install <domain> [<uri>] <contributionURL> [-norun -metadata <url>
>>> -duris <uri,uri,...>]
>>> installed <domain> [<contributionURI>]
>>> remove <domain> <contributionURI>
>>> addDeploymentComposite <domain> <contributionURI> <contentURL>
>>> printDomainLevelComposite <domain>
>>> start <domain> <curi> <compositeUri>
>>> status <domain> [<curi> <compositeUri>]
>>> stop <domain> [<curi> <compositeUri>]
>>> bye
>>>
>>> Any comments/alternatives/updates on that?
>>>
>>> ...ant
>>>
>>
>> No comments after a week so i'll go start on it, can update as it goes
>> along if there are updates later.
>>
>> ...ant
>
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by ant elder <an...@gmail.com>.
On Mon, Aug 2, 2010 at 9:50 AM, ant elder <an...@gmail.com> wrote:
> On Sat, Jul 31, 2010 at 4:59 PM, Raymond Feng <en...@gmail.com> wrote:
>> Sorry for the late reply. The message skipped out of my attention.
>> My understanding is that a domain is the administrative (governance)
>> boundary for SCA composite applications. Why does the Shell needs to switch
>> between multiple domains within the same session. Typically, most admin
>> consoles connect to one "boundary" at a time. For example:
>> * OSGi console connects to an instance of the OSGi runtime
>> * WebSphere admin console talks to a ND manager for a cell
>> * Telnet/SSH connects to a host
>> Why cannot we have the Shell session be associated with one SCA domain at a
>> time, for example:
>> shell <domainURI>
>> tuscany> (all the commands are within the domain)
>> tuscany>
>
> That makes sense to me, although its slightly different from
> traditional admin console type apps in that a domain may also be quite
> tiny with multiple domains in a single runtime so how about having it
> work as just described but also support changing and listing domains
> within the Shell and have the prompt identify the current domain. Eg:
>
> shell <uri:myDomain?configParams...>
> myDomain> (all the commands are within the domain myDomain)
>
> and add commands such as "domains" and "domain [<domainName>]" that
> enable querying and switching domains.
>
I've committed some changes to tuscany-shell to start doing that. You
can use the 'domain domainURI' command to switch to different domains
or the noargs 'domain' to switch to standalone mode which allows using
the 'start' command to start nodes which are not part of any domain
but completely isolated with no sharing of anything from other nodes.
The prompt identifies what the current domain is. Some of the help and
JLine completors still need updating for this so aren't quite perfect
but thought i'd commit it now as it is so we can see how it works. I'm
not totally convinced yet that this is quite right, some commands not
feeling very elegant so i wonder if there might be some better ways to
support multiple domains and standalone nodes...if anyone has any
suggestions or comments...
...ant
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by ant elder <an...@gmail.com>.
On Sat, Jul 31, 2010 at 4:59 PM, Raymond Feng <en...@gmail.com> wrote:
> Sorry for the late reply. The message skipped out of my attention.
> My understanding is that a domain is the administrative (governance)
> boundary for SCA composite applications. Why does the Shell needs to switch
> between multiple domains within the same session. Typically, most admin
> consoles connect to one "boundary" at a time. For example:
> * OSGi console connects to an instance of the OSGi runtime
> * WebSphere admin console talks to a ND manager for a cell
> * Telnet/SSH connects to a host
> Why cannot we have the Shell session be associated with one SCA domain at a
> time, for example:
> shell <domainURI>
> tuscany> (all the commands are within the domain)
> tuscany>
That makes sense to me, although its slightly different from
traditional admin console type apps in that a domain may also be quite
tiny with multiple domains in a single runtime so how about having it
work as just described but also support changing and listing domains
within the Shell and have the prompt identify the current domain. Eg:
shell <uri:myDomain?configParams...>
myDomain> (all the commands are within the domain myDomain)
and add commands such as "domains" and "domain [<domainName>]" that
enable querying and switching domains.
...ant
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by Raymond Feng <en...@gmail.com>.
Sorry for the late reply. The message skipped out of my attention.
My understanding is that a domain is the administrative (governance) boundary for SCA composite applications. Why does the Shell needs to switch between multiple domains within the same session. Typically, most admin consoles connect to one "boundary" at a time. For example:
* OSGi console connects to an instance of the OSGi runtime
* WebSphere admin console talks to a ND manager for a cell
* Telnet/SSH connects to a host
Why cannot we have the Shell session be associated with one SCA domain at a time, for example:
shell <domainURI>
tuscany> (all the commands are within the domain)
tuscany>
Thanks,
Raymond
________________________________________________________________
Raymond Feng
rfeng@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
________________________________________________________________
On Jul 31, 2010, at 1:18 AM, ant elder wrote:
> On Sun, Jul 25, 2010 at 10:25 AM, ant elder <an...@apache.org> wrote:
>> On Sun, Jul 25, 2010 at 8:48 AM, ant elder <an...@apache.org> wrote:
>>> On Sun, Jul 25, 2010 at 4:02 AM, Luciano Resende <lu...@gmail.com> wrote:
>>>> On Fri, Jul 23, 2010 at 12:25 AM, ant elder <an...@gmail.com> wrote:
>>>>>
>>>>> Thats all very useful but i think its a slightly different topic - one
>>>>> thing that was wanted here was a way to create an isolated Node
>>>>> instance thats _not_ part of any domain, so yes there's lots of
>>>>> different ways we can have for building a domain but don't have any
>>>>> API for creating standalone Nodes.
>>>>>
>>>>> ...ant
>>>>>
>>>>
>>>> What's the difference of a Domain with a single node and a standalone
>>>> node that's _not_ part of any domain ?
>>>>
>>>>
>>>
>>> For practical purposes not so much. Each domain would need its own
>>> unique name but if thats ok then it seems like a fine way to do it to
>>> me. I don't yet quite really understand the purpose of the "node name"
>>> label when starting composites as discussed in [1] but if each node is
>>> really in its own domain i wonder if "node name" could be replaced
>>> with "domain name" and then a user can have started composites each in
>>> their own domain or have multiple composites in the same domain if
>>> they choose.
>>>
>>> ...ant
>>>
>>> [1] http://apache.markmail.org/message/vznaimmhc7jfxtj2
>>>
>>
>> So if we did do that the commands could be something like the following:
>>
>> help
>> install <domain> [<uri>] <contributionURL> [-norun -metadata <url>
>> -duris <uri,uri,...>]
>> installed <domain> [<contributionURI>]
>> remove <domain> <contributionURI>
>> addDeploymentComposite <domain> <contributionURI> <contentURL>
>> printDomainLevelComposite <domain>
>> start <domain> <curi> <compositeUri>
>> status <domain> [<curi> <compositeUri>]
>> stop <domain> [<curi> <compositeUri>]
>> bye
>>
>> Any comments/alternatives/updates on that?
>>
>> ...ant
>>
>
> No comments after a week so i'll go start on it, can update as it goes
> along if there are updates later.
>
> ...ant
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by ant elder <an...@apache.org>.
On Sun, Jul 25, 2010 at 10:25 AM, ant elder <an...@apache.org> wrote:
> On Sun, Jul 25, 2010 at 8:48 AM, ant elder <an...@apache.org> wrote:
>> On Sun, Jul 25, 2010 at 4:02 AM, Luciano Resende <lu...@gmail.com> wrote:
>>> On Fri, Jul 23, 2010 at 12:25 AM, ant elder <an...@gmail.com> wrote:
>>>>
>>>> Thats all very useful but i think its a slightly different topic - one
>>>> thing that was wanted here was a way to create an isolated Node
>>>> instance thats _not_ part of any domain, so yes there's lots of
>>>> different ways we can have for building a domain but don't have any
>>>> API for creating standalone Nodes.
>>>>
>>>> ...ant
>>>>
>>>
>>> What's the difference of a Domain with a single node and a standalone
>>> node that's _not_ part of any domain ?
>>>
>>>
>>
>> For practical purposes not so much. Each domain would need its own
>> unique name but if thats ok then it seems like a fine way to do it to
>> me. I don't yet quite really understand the purpose of the "node name"
>> label when starting composites as discussed in [1] but if each node is
>> really in its own domain i wonder if "node name" could be replaced
>> with "domain name" and then a user can have started composites each in
>> their own domain or have multiple composites in the same domain if
>> they choose.
>>
>> ...ant
>>
>> [1] http://apache.markmail.org/message/vznaimmhc7jfxtj2
>>
>
> So if we did do that the commands could be something like the following:
>
> help
> install <domain> [<uri>] <contributionURL> [-norun -metadata <url>
> -duris <uri,uri,...>]
> installed <domain> [<contributionURI>]
> remove <domain> <contributionURI>
> addDeploymentComposite <domain> <contributionURI> <contentURL>
> printDomainLevelComposite <domain>
> start <domain> <curi> <compositeUri>
> status <domain> [<curi> <compositeUri>]
> stop <domain> [<curi> <compositeUri>]
> bye
>
> Any comments/alternatives/updates on that?
>
> ...ant
>
No comments after a week so i'll go start on it, can update as it goes
along if there are updates later.
...ant
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by ant elder <an...@apache.org>.
On Sun, Jul 25, 2010 at 8:48 AM, ant elder <an...@apache.org> wrote:
> On Sun, Jul 25, 2010 at 4:02 AM, Luciano Resende <lu...@gmail.com> wrote:
>> On Fri, Jul 23, 2010 at 12:25 AM, ant elder <an...@gmail.com> wrote:
>>>
>>> Thats all very useful but i think its a slightly different topic - one
>>> thing that was wanted here was a way to create an isolated Node
>>> instance thats _not_ part of any domain, so yes there's lots of
>>> different ways we can have for building a domain but don't have any
>>> API for creating standalone Nodes.
>>>
>>> ...ant
>>>
>>
>> What's the difference of a Domain with a single node and a standalone
>> node that's _not_ part of any domain ?
>>
>>
>
> For practical purposes not so much. Each domain would need its own
> unique name but if thats ok then it seems like a fine way to do it to
> me. I don't yet quite really understand the purpose of the "node name"
> label when starting composites as discussed in [1] but if each node is
> really in its own domain i wonder if "node name" could be replaced
> with "domain name" and then a user can have started composites each in
> their own domain or have multiple composites in the same domain if
> they choose.
>
> ...ant
>
> [1] http://apache.markmail.org/message/vznaimmhc7jfxtj2
>
So if we did do that the commands could be something like the following:
help
install <domain> [<uri>] <contributionURL> [-norun -metadata <url>
-duris <uri,uri,...>]
installed <domain> [<contributionURI>]
remove <domain> <contributionURI>
addDeploymentComposite <domain> <contributionURI> <contentURL>
printDomainLevelComposite <domain>
start <domain> <curi> <compositeUri>
status <domain> [<curi> <compositeUri>]
stop <domain> [<curi> <compositeUri>]
bye
Any comments/alternatives/updates on that?
...ant
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by ant elder <an...@apache.org>.
On Sun, Jul 25, 2010 at 4:02 AM, Luciano Resende <lu...@gmail.com> wrote:
> On Fri, Jul 23, 2010 at 12:25 AM, ant elder <an...@gmail.com> wrote:
>>
>> Thats all very useful but i think its a slightly different topic - one
>> thing that was wanted here was a way to create an isolated Node
>> instance thats _not_ part of any domain, so yes there's lots of
>> different ways we can have for building a domain but don't have any
>> API for creating standalone Nodes.
>>
>> ...ant
>>
>
> What's the difference of a Domain with a single node and a standalone
> node that's _not_ part of any domain ?
>
>
For practical purposes not so much. Each domain would need its own
unique name but if thats ok then it seems like a fine way to do it to
me. I don't yet quite really understand the purpose of the "node name"
label when starting composites as discussed in [1] but if each node is
really in its own domain i wonder if "node name" could be replaced
with "domain name" and then a user can have started composites each in
their own domain or have multiple composites in the same domain if
they choose.
...ant
[1] http://apache.markmail.org/message/vznaimmhc7jfxtj2
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by Luciano Resende <lu...@gmail.com>.
On Fri, Jul 23, 2010 at 12:25 AM, ant elder <an...@gmail.com> wrote:
>
> Thats all very useful but i think its a slightly different topic - one
> thing that was wanted here was a way to create an isolated Node
> instance thats _not_ part of any domain, so yes there's lots of
> different ways we can have for building a domain but don't have any
> API for creating standalone Nodes.
>
> ...ant
>
What's the difference of a Domain with a single node and a standalone
node that's _not_ part of any domain ?
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by ant elder <an...@gmail.com>.
On Tue, Jul 13, 2010 at 5:56 PM, Simon Laws <si...@googlemail.com> wrote:
> Some more comments in line.
>
> To prevent this discussion being too theoretical and long winded it
> would possibly be appropriate for those of us who have been working on
> this stuff to try and phrase the scenarios that are important to us in
> terms of how existing (or possibly new) interfaces would be used. I'll
> have a go when I've got my act together.
>
> Simon
>
> On Sun, Jul 11, 2010 at 1:33 AM, Jean-Sebastien Delfino
> <js...@apache.org> wrote:
>> Raymond Feng wrote:
>>>
>>> Hi,
>>>
>>> We had a debate on this topic. See:
>>>
>>> http://osdir.com/ml/dev-tuscany.apache.org/2010-06/msg00164.html
>>>
>>> And apparently, we didn't reach agreement.
>>
>> It's probably a good idea to restart that discussion and find a consensus on
>> this. After having not looked at the Tuscany code for a while I must admit I
>> was a little confused by the multiple Node types.
>>
>> I'll try to participate in the discussion as much as I can, although I have
>> little spare time these days. In the meantime, I'd like to continue to use
>> the mainstream Node implementation for some time in samples/launcher-shell,
>> as it's what's working with webapps, all the test cases, samples etc.
>>
>
> I haven't got my head round these either yet, for which I apologize,
> but it seems sensible to try and support something that looks like the
> features that the spec describes. We do need to agree where it lives
> and how it enables us to populate our picture of the domain and
> subsequently how this gives rise to the running of configured nodes.
>
>>>
>>> I think it would be a good idea to agree on the commands for shell. This
>>> will help us understand how users use SCA. Then it can be translated into a
>>> set of API/SPIs. Mixing different steps into one layer could prevent us from
>>> seeing the complete user story.
>>
>> And like I tried to say in another email in this thread, I think we should
>> distinguish:
>> - Domain management, assembling components in a domain;
>> and
>> - Runtime instance configuration and management, loading a contribution in a
>> runtime instance and starting/stopping it.
>>
>> They are really different IMHO, for example an SCA domain administrator can
>> spend a day assembling components in a domain before starting a single
>> runtime instance, and stopping a server doesn't mean that he's removing a
>> composite from the SCA domain...
>
> There are two extremes here I think that we are touching on.
>
> 1/ The process of bringing all the contributions of the domain
> together is completely separate from the actual starting of the nodes
> that run the separate composites of the domain. In this case some tool
> (even csh or explorer or a gui tool) could be used to pull together
> the required contributions and ensure that everything is present. Once
> done someone will use a separate tool (the command line shell) to
> start the nodes to run the separate parts of this domain. I've
> purposely not defined here how the nodes are configured.
>
> 2/ The case where the domain is constructed on the fly by running
> sepearate nodes which "join" the domain and exchange information about
> the services they provide.
>
> You may actually consider that 1 and 2 are the same thing where in 2
> the process of readying the contributions for the domain is out of
> band and simply not discussed.
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Thats all very useful but i think its a slightly different topic - one
thing that was wanted here was a way to create an isolated Node
instance thats _not_ part of any domain, so yes there's lots of
different ways we can have for building a domain but don't have any
API for creating standalone Nodes.
...ant
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by Simon Laws <si...@googlemail.com>.
Some more comments in line.
To prevent this discussion being too theoretical and long winded it
would possibly be appropriate for those of us who have been working on
this stuff to try and phrase the scenarios that are important to us in
terms of how existing (or possibly new) interfaces would be used. I'll
have a go when I've got my act together.
Simon
On Sun, Jul 11, 2010 at 1:33 AM, Jean-Sebastien Delfino
<js...@apache.org> wrote:
> Raymond Feng wrote:
>>
>> Hi,
>>
>> We had a debate on this topic. See:
>>
>> http://osdir.com/ml/dev-tuscany.apache.org/2010-06/msg00164.html
>>
>> And apparently, we didn't reach agreement.
>
> It's probably a good idea to restart that discussion and find a consensus on
> this. After having not looked at the Tuscany code for a while I must admit I
> was a little confused by the multiple Node types.
>
> I'll try to participate in the discussion as much as I can, although I have
> little spare time these days. In the meantime, I'd like to continue to use
> the mainstream Node implementation for some time in samples/launcher-shell,
> as it's what's working with webapps, all the test cases, samples etc.
>
I haven't got my head round these either yet, for which I apologize,
but it seems sensible to try and support something that looks like the
features that the spec describes. We do need to agree where it lives
and how it enables us to populate our picture of the domain and
subsequently how this gives rise to the running of configured nodes.
>>
>> I think it would be a good idea to agree on the commands for shell. This
>> will help us understand how users use SCA. Then it can be translated into a
>> set of API/SPIs. Mixing different steps into one layer could prevent us from
>> seeing the complete user story.
>
> And like I tried to say in another email in this thread, I think we should
> distinguish:
> - Domain management, assembling components in a domain;
> and
> - Runtime instance configuration and management, loading a contribution in a
> runtime instance and starting/stopping it.
>
> They are really different IMHO, for example an SCA domain administrator can
> spend a day assembling components in a domain before starting a single
> runtime instance, and stopping a server doesn't mean that he's removing a
> composite from the SCA domain...
There are two extremes here I think that we are touching on.
1/ The process of bringing all the contributions of the domain
together is completely separate from the actual starting of the nodes
that run the separate composites of the domain. In this case some tool
(even csh or explorer or a gui tool) could be used to pull together
the required contributions and ensure that everything is present. Once
done someone will use a separate tool (the command line shell) to
start the nodes to run the separate parts of this domain. I've
purposely not defined here how the nodes are configured.
2/ The case where the domain is constructed on the fly by running
sepearate nodes which "join" the domain and exchange information about
the services they provide.
You may actually consider that 1 and 2 are the same thing where in 2
the process of readying the contributions for the domain is out of
band and simply not discussed.
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> We had a debate on this topic. See:
>
> http://osdir.com/ml/dev-tuscany.apache.org/2010-06/msg00164.html
>
> And apparently, we didn't reach agreement.
It's probably a good idea to restart that discussion and find a
consensus on this. After having not looked at the Tuscany code for a
while I must admit I was a little confused by the multiple Node types.
I'll try to participate in the discussion as much as I can, although I
have little spare time these days. In the meantime, I'd like to continue
to use the mainstream Node implementation for some time in
samples/launcher-shell, as it's what's working with webapps, all the
test cases, samples etc.
>
> I think it would be a good idea to agree on the commands for shell. This will help us understand how users use SCA. Then it can be translated into a set of API/SPIs. Mixing different steps into one layer could prevent us from seeing the complete user story.
And like I tried to say in another email in this thread, I think we
should distinguish:
- Domain management, assembling components in a domain;
and
- Runtime instance configuration and management, loading a contribution
in a runtime instance and starting/stopping it.
They are really different IMHO, for example an SCA domain administrator
can spend a day assembling components in a domain before starting a
single runtime instance, and stopping a server doesn't mean that he's
removing a composite from the SCA domain...
--
Jean-Sebastien
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by Raymond Feng <en...@gmail.com>.
Hi,
We had a debate on this topic. See:
http://osdir.com/ml/dev-tuscany.apache.org/2010-06/msg00164.html
And apparently, we didn't reach agreement.
I think it would be a good idea to agree on the commands for shell. This will help us understand how users use SCA. Then it can be translated into a set of API/SPIs. Mixing different steps into one layer could prevent us from seeing the complete user story.
Raymond Feng
Sent from my iPhone
On Jul 7, 2010, at 11:53 PM, ant elder <an...@gmail.com> wrote:
> On Thu, Jul 8, 2010 at 7:14 AM, Jean-Sebastien Delfino
> <js...@apache.org> wrote:
>
>>
>> I'm confused as you've switched o.a.t.node.NodeFactory to a different
>> o.a.t.node2.NodeFactory. I see 49 references to node.NodeFactory in the
>> source tree, everywhere people need to create nodes. node2.NodeFactory looks
>> like a parallel implementation, with only 3 references, if I'm not mistaken
>> only from this new shell. What happened?
>>
>
> The domain-node module is new is why its not used much yet and its
> based more closely on the operations described in the Assembly spec. I
> like it, and plan to start using it instead of the old Node APIs now.
> It also supports more than the old Node API so you can do things that
> you otherwise can't.
>
>> Also this new shell seems to use a single node. It's fine with me if that's
>> what you want to do here, but that's not what I need. What I need is a
>> collection of independent nodes, each loaded with a deployable composite,
>> each with its own lifecycle, like I had in the original code.
>>
>
> What is that you need a node for? This does give you independent
> deployable composites each with its own lifecycle so whats missing?
> I'm wondering if its just that the current commands and help
> information on them isn't very clear yet so its not so obvious to you
> what this is doing.
>
> ...ant
Re: Node2 vs Node, parallel universes? Sample tuscany launcher shell
Posted by ant elder <an...@gmail.com>.
On Thu, Jul 8, 2010 at 7:14 AM, Jean-Sebastien Delfino
<js...@apache.org> wrote:
>
> I'm confused as you've switched o.a.t.node.NodeFactory to a different
> o.a.t.node2.NodeFactory. I see 49 references to node.NodeFactory in the
> source tree, everywhere people need to create nodes. node2.NodeFactory looks
> like a parallel implementation, with only 3 references, if I'm not mistaken
> only from this new shell. What happened?
>
The domain-node module is new is why its not used much yet and its
based more closely on the operations described in the Assembly spec. I
like it, and plan to start using it instead of the old Node APIs now.
It also supports more than the old Node API so you can do things that
you otherwise can't.
> Also this new shell seems to use a single node. It's fine with me if that's
> what you want to do here, but that's not what I need. What I need is a
> collection of independent nodes, each loaded with a deployable composite,
> each with its own lifecycle, like I had in the original code.
>
What is that you need a node for? This does give you independent
deployable composites each with its own lifecycle so whats missing?
I'm wondering if its just that the current commands and help
information on them isn't very clear yet so its not so obvious to you
what this is doing.
...ant