Tomcat and the new distributed domain modules

[ant elder <an...@gmail.com>]

I've been trying to use the new distributed domain stuff - domain-manager
and node2* etc - to get Tomcat as a domain manager with SCA webapps being
individual nodes, but not really making much progress getting it to work so
asking here to see if there are any suggestions - mainly from you Sebastien
as you've written most of those new modules :-)

What i'd like is for during Tomcat startup to create a domain manager and
then as each webapp is initialized create a new node for each webapp and
register it with the domain, and to do that registration with in-JVM calls.
Right now the domain manger needs to know about all the nodes before the
domain can be started (i think?) but thats problematic in this scenario as
the webapps are initialized one by one and its hard to batch all those up
and then initialize the domain and then correctly insert the node into the
webapps context. This is discussed in a bit more detail in the thread at
[1].

I wondered about enhancing the domain manager so that it can be created
"empty" and then create/register nodes one-by-one and then activate the
domain once thats done (which probably would require the more dynamic
endpoint stuff being talked about in [2]), but I'm not sure that approach
really fits in with the current design of the distributed domain support?

WDYT, any comments or suggestions?

   ...ant

[1] http://apache.markmail.org/message/2i6gtkveapk3n4nr
[2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30314.html

Re: Tomcat and the new distributed domain modules

[ant elder <an...@gmail.com>]

On Fri, May 9, 2008 at 9:51 AM, Simon Laws <si...@googlemail.com>
wrote:

>
>
> On Fri, May 9, 2008 at 7:23 AM, ant elder <an...@apache.org> wrote:
>
>> On Thu, May 8, 2008 at 9:40 PM, Simon Laws <si...@googlemail.com>
>> wrote:
>>
>> <snip>
>>
>> If you are up for adding a bit of dynamic behaviour we could extend the
>> > domain manager to provide a feed of the services that are currently
>> > available in the domain and then use this in conjunction with the
>> dynamic
>> > binding stuff I'm currently working on to allow references to be
>> resolved
>> > at
>> > point of time after composite start. Quite a bit of work there though.
>> >
>> >
>> That approach sounds interesting, though I don't need a feed as this is in
>> the same JVM so just a service to call to get the available services. The
>> feed could be from another app that exposes the service to external
>> clients.
>>
>>
>> Could you say a bit more about what is the dynamic binding stuff you're
>> currently working on?
>>
>>   ...ant
>>
>
> Sure, I just posted some more thoughts here [1]
>
> In summary, some reference targets may not be resolved at build time if the
> domain is not completely configured at that point. I recently put a change
> in to create an SCA binding to represent unresolved targets the
> understanding being that the SCA Binding could perform some magic at a later
> stage to try again to locate the target service.
>
> I'm now proposing to change the use of a sca binding in this case for a
> special binding, called Enpoint,  to provide this feature. The thought being
> that in the future we will make some breaking changes where Endpoint becomes
> a first class citizen in the model. This is motivated by a few things.
> Firstly I want to make the code that extracts target names from model
> binding URIs more generic, I now think using the SCA binding in this role is
> confusing and I also want to reuse as much of the builder target service
> matching code as possible in both early and late binding cases.
>
> Hope that helps
>
>
That does help, i don't fully understand the details but it sounds about
perfect for whats needed in this Tomcat scenario.

With that in place it should be possible to have the domain start up "empty"
without having to know about any nodes, then new nodes be created or
registered with the domain and any cross node endpoints only get resolved
the first time they're invoked. Does that sound right?

How will the endpoint binding do the actual resolution - by asking the
domain?

   ...ant

Re: Tomcat and the new distributed domain modules

[Simon Laws <si...@googlemail.com>]

On Fri, May 9, 2008 at 7:23 AM, ant elder <an...@apache.org> wrote:

> On Thu, May 8, 2008 at 9:40 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
> <snip>
>
> If you are up for adding a bit of dynamic behaviour we could extend the
> > domain manager to provide a feed of the services that are currently
> > available in the domain and then use this in conjunction with the dynamic
> > binding stuff I'm currently working on to allow references to be resolved
> > at
> > point of time after composite start. Quite a bit of work there though.
> >
> >
> That approach sounds interesting, though I don't need a feed as this is in
> the same JVM so just a service to call to get the available services. The
> feed could be from another app that exposes the service to external
> clients.
>
>
> Could you say a bit more about what is the dynamic binding stuff you're
> currently working on?
>
>   ...ant
>

Sure, I just posted some more thoughts here [1]

In summary, some reference targets may not be resolved at build time if the
domain is not completely configured at that point. I recently put a change
in to create an SCA binding to represent unresolved targets the
understanding being that the SCA Binding could perform some magic at a later
stage to try again to locate the target service.

I'm now proposing to change the use of a sca binding in this case for a
special binding, called Enpoint,  to provide this feature. The thought being
that in the future we will make some breaking changes where Endpoint becomes
a first class citizen in the model. This is motivated by a few things.
Firstly I want to make the code that extracts target names from model
binding URIs more generic, I now think using the SCA binding in this role is
confusing and I also want to reuse as much of the builder target service
matching code as possible in both early and late binding cases.

Hope that helps

Simon

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg31331.html

Re: Tomcat and the new distributed domain modules

[ant elder <an...@apache.org>]

On Thu, May 8, 2008 at 9:40 PM, Simon Laws <si...@googlemail.com>
wrote:

<snip>

If you are up for adding a bit of dynamic behaviour we could extend the
> domain manager to provide a feed of the services that are currently
> available in the domain and then use this in conjunction with the dynamic
> binding stuff I'm currently working on to allow references to be resolved
> at
> point of time after composite start. Quite a bit of work there though.
>
>
That approach sounds interesting, though I don't need a feed as this is in
the same JVM so just a service to call to get the available services. The
feed could be from another app that exposes the service to external clients.


Could you say a bit more about what is the dynamic binding stuff you're
currently working on?

   ...ant

Re: Tomcat and the new distributed domain modules

[ant elder <an...@apache.org>]

On Thu, May 8, 2008 at 9:40 PM, Simon Laws <si...@googlemail.com>
wrote:

<snip>


> It doesn't seem a big burden to assume that the domain manager would always
> be running separately.


This DOES seem like a big burden to me and I'd _really_ like to try to avoid
having to do that.

   ...ant

Re: Tomcat and the new distributed domain modules

[Simon Laws <si...@googlemail.com>]

On Thu, May 8, 2008 at 8:19 PM, ant elder <an...@gmail.com> wrote:

> I've been trying to use the new distributed domain stuff - domain-manager
> and node2* etc - to get Tomcat as a domain manager with SCA webapps being
> individual nodes, but not really making much progress getting it to work so
> asking here to see if there are any suggestions - mainly from you Sebastien
> as you've written most of those new modules :-)
>
> What i'd like is for during Tomcat startup to create a domain manager and
> then as each webapp is initialized create a new node for each webapp and
> register it with the domain, and to do that registration with in-JVM calls.
> Right now the domain manger needs to know about all the nodes before the
> domain can be started (i think?) but thats problematic in this scenario as
> the webapps are initialized one by one and its hard to batch all those up
> and then initialize the domain and then correctly insert the node into the
> webapps context. This is discussed in a bit more detail in the thread at
> [1].
>
> I wondered about enhancing the domain manager so that it can be created
> "empty" and then create/register nodes one-by-one and then activate the
> domain once thats done (which probably would require the more dynamic
> endpoint stuff being talked about in [2]), but I'm not sure that approach
> really fits in with the current design of the distributed domain support?
>
> WDYT, any comments or suggestions?
>
>   ...ant
>
> [1] http://apache.markmail.org/message/2i6gtkveapk3n4nr
> [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30314.html
>

I'm sure Sebastien will jump in with a completely different scheme but I'll
have a stab at explaining my mental model of what has been built;-)

I guess the first question is why does Tomcat have to run the domain
manager. Is the assumption here that the scope of a domain is restricted to
a single instance?

It doesn't seem a big burden to assume that the domain manager would always
be running separately. Looking at the code in trunk is seems that there is
some generic webapp launcher code that supports this scenario. I haven't
tried it though so Sebastien would have to explain it.

I know there has been some discussion of these kinds of scenarios on the
user list so lets assume that you do want to have this restriction and that
you want the user experience of adding SCA webapp contributions directly to
Tomcat (by dropping them in the webapps directory).

The domain manager is a stateless app. As you prod it to ask it for details
of, say, a configured composite it fluffs up all the information it needs
from the files on disc (workspace.xml, domain.composite, cloud.composite)
for each request. This is important because while, at the moment, the domain
manager web GUI is used to update these files as new things are added in
reality, of course, anything can update them.

So, for example, you could have a piece of code that runs in your container
play the role of the domain manager and update these files. Sounds like it
would require some deep integration. You can then reuse all the code that
does useful things with the information to get the nodes running. So you
could imagine this new piece of code doing the following;

1 - notice that a webapp has been started (and that webapp is an SCA
contribution)
2 - update the files to add a new node associated with a composite from the
new webapp contribution
3 - provide to the new webapp a configured composite based on configuration
now in the files.

There is the problem here though that you pointed out. All webapps would
have to be processed for steps 1 and 2 before step 3 could be performed. The
domain manager logic assumes this is the case. This is because to fully
resolve a composite you will need endpoint information for all of the
services it references. These could be in any of the webapps that are added
to Tomcat.

Without changing this static configuration scheme a couple of strategies
come to mind.

Calculate the composites for all webapps each time a webapp contribution is
added. For any composite that has changed since last time it was generate
restart its node. Sounds like it would be awfully slow.

Or

Only fire up the node in the webapp when the composite for that webapp is
know to be fully resolved. I like this better but there are some wrinkles as
if you have references with multiplicity  > 1 you can't tell when the're
fully resolved.

If you are up for adding a bit of dynamic behaviour we could extend the
domain manager to provide a feed of the services that are currently
available in the domain and then use this in conjunction with the dynamic
binding stuff I'm currently working on to allow references to be resolved at
point of time after composite start. Quite a bit of work there though.

Simon

Re: Tomcat and the new distributed domain modules

[ant elder <an...@gmail.com>]

On Thu, May 15, 2008 at 6:16 PM, Simon Laws <si...@googlemail.com>
wrote:

> On Thu, May 15, 2008 at 2:28 AM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
> > ant elder wrote:
> >
> >> On Tue, May 13, 2008 at 7:50 AM, Jean-Sebastien Delfino <
> >> jsdelfino@apache.org> wrote:
> >>
> >>
> >>>  - create a domain manager (did u mean create an domain? deploy a
> >>>>> domain
> >>>>> manager as a web app? start an instance of a domain manager?)
> >>>>>
> >>>>>
> >>>>>  You tell me, I'm trying to understand how to use all this
> distributed
> >>>> domain
> >>>> stuff you've written to support the scenario described above.
> >>>>
> >>>>  Well, I'm not sure what to tell you unless I understand what you
> meant
> >>> by
> >>> 'create a domain manager' before Tomcat starts deploying webapps and
> what
> >>> the purpose would be.
> >>>
> >>>
> >> This is like pulling teeth.
> >>
> >> Over in the email where you describe how to use a webapp with the
> >> standalone
> >> domain one of the first steps is "Start the domain manager app", so
> given
> >> whats been described previously in this thread we will need to do
> >> something
> >> similar within Tomcat right?
> >>
> >>   ...ant
> >>
> >>
> > Not necessarily, I was starting the domain manager app in that scenario
> > mainly for people to see how to contribute to the SCA domain and also use
> > the manager app capability to start nodes.
> >
> > Tuscany standalone nodes can also be started from the command line (use
> > tuscany-node2-launcher directly from the command line instead of clicking
> > Start in the domain manager app UI). You don't need to use the domain
> > manager app then.
> >
> > I also said in that email that nodes could be started in different
> orders.
> > That applies to the domain manager app too but obviously you need to
> start
> > it if you want to use its UI to inspect and manage your nodes.
> >
> > I'm still trying to understand your user scenario so it's really
> difficult
> > to say if I'm missing the point here or not, but here are a few more
> > thoughts:
> >
> > - If your nodes are Webapps on Tomcat then you can just deploy them and
> > start them using the Tomcat manager, or some of the Tomcat admin tasks
> for
> > example.
> >
> > - You don't need to start the SCA domain manager before deploying your
> > Webapp to Tomcat.
> >
> > - When you start the Webapp, it'll need SCA metadata, the SCA composite
> to
> > use and a list of SCA contributions. There are many ways to provide that
> > information:
> >
> > - You can provide that information using the APIs/SPIs like shown in the
> > domain-management sample.
> >
> > - You can use similar code to build that information, save it to an XML
> > file (an ATOM feed with one entry for the composite and one entry per
> > contribution) and have your Webapp pick up that file.
> >
> > - You can also use the domain manager app to get that info. To do that
> just
> > click on the Node Config column for the Node you're interested in, save
> that
> > doc to a file, then have your Webapp pick it up as above (and the domain
> > manager app does not have to be running at all at that time).
> >
> > - You can also have the Webapp pick up its config info from a running
> > instance of the domain manager app. That's what I've been doing usually
> at
> > development time to have a quick debug/fix/try-again turn around, but I
> > don't think that it's really what you'll want to do in production.
> >
> > I hope this helps, but again it would be really good if we could look at
> > the user scenario that you have in mind together. It would help put the
> > technical questions in context, as I'm still trying to guess what you're
> > after but don't seem to be able to grasp it.
> > --
> > Jean-Sebastien
> >
>
> I'm going to have a go at articulating the scenarios I think are being
> discussed on this thread. Hope these reads clearly in the first instance
> but
> let iterate around these until we agree what we are trying to achieve and
> which ones are valid. You may of course want to add other scenarios;-)
>
> 1. User experience A
>
> 1.1 The user builds contributionA/compositeA and obtains
> contributionB/compositeB from a friend.
> 1.2 The user intends to run composite A and compositeB on separate nodes
> [a]
>
> 1.3 The user configures the composites to run on the chosen nodes using a
> domain tool [b]
> 1.4 The user starts the nodes that he intends to use and configures each
> with the composite he already knows he is going to run there and the
> contributions this composite depends on [c]
>
> 2. User experience B
>
> 2.1 The user builds contributionA/compositeA and obtains
> contributionB/compositeB from a friend. [d]
> 2.2 The user intends to run composite A and compositeB as webaps in a
> single
> web container [e]
> 2.3 The user copies the war files to the web app container. [f]
>
> Notes.
>
> [a] because isolation is require or different composited require different
> resources provided by different nodes or for performance reasons etc.
> [b] I'm not being precise here about the nature of this tool but it could
> be
> our domain manager tool which analyzes all the contributions and produces
> configured composites based on the information it finds.
> [c] the nodes are given the URLs of the contributions to load, The user may
> just have put them on a file system so file://.... will work. The
> configured
> composite is also provided to replace the original one that appears in the
> contribution.
>
> [d] Both contributions are packaged as war files in this case
> [e] This isn't a restriction but in this case the user just wants to test
> in
> a single container.
> [f] The domain processing required to resolve the composites in the context
> of the domain happens behind the scenes and no SCA specific deployment
> steps
> are required after each original contribution has been packaged as a war by
> the user or his friend.
>
> Do these capture the essence of what is being discussion?
>
> Simon
>

"2. User experience B" is the type of thing I've been talking about here and
is something I think would be useful to support.

   ...ant

Re: Tomcat and the new distributed domain modules

[Simon Laws <si...@googlemail.com>]

On Thu, May 15, 2008 at 2:28 AM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:

> ant elder wrote:
>
>> On Tue, May 13, 2008 at 7:50 AM, Jean-Sebastien Delfino <
>> jsdelfino@apache.org> wrote:
>>
>>
>>>  - create a domain manager (did u mean create an domain? deploy a
>>>>> domain
>>>>> manager as a web app? start an instance of a domain manager?)
>>>>>
>>>>>
>>>>>  You tell me, I'm trying to understand how to use all this distributed
>>>> domain
>>>> stuff you've written to support the scenario described above.
>>>>
>>>>  Well, I'm not sure what to tell you unless I understand what you meant
>>> by
>>> 'create a domain manager' before Tomcat starts deploying webapps and what
>>> the purpose would be.
>>>
>>>
>> This is like pulling teeth.
>>
>> Over in the email where you describe how to use a webapp with the
>> standalone
>> domain one of the first steps is "Start the domain manager app", so given
>> whats been described previously in this thread we will need to do
>> something
>> similar within Tomcat right?
>>
>>   ...ant
>>
>>
> Not necessarily, I was starting the domain manager app in that scenario
> mainly for people to see how to contribute to the SCA domain and also use
> the manager app capability to start nodes.
>
> Tuscany standalone nodes can also be started from the command line (use
> tuscany-node2-launcher directly from the command line instead of clicking
> Start in the domain manager app UI). You don't need to use the domain
> manager app then.
>
> I also said in that email that nodes could be started in different orders.
> That applies to the domain manager app too but obviously you need to start
> it if you want to use its UI to inspect and manage your nodes.
>
> I'm still trying to understand your user scenario so it's really difficult
> to say if I'm missing the point here or not, but here are a few more
> thoughts:
>
> - If your nodes are Webapps on Tomcat then you can just deploy them and
> start them using the Tomcat manager, or some of the Tomcat admin tasks for
> example.
>
> - You don't need to start the SCA domain manager before deploying your
> Webapp to Tomcat.
>
> - When you start the Webapp, it'll need SCA metadata, the SCA composite to
> use and a list of SCA contributions. There are many ways to provide that
> information:
>
> - You can provide that information using the APIs/SPIs like shown in the
> domain-management sample.
>
> - You can use similar code to build that information, save it to an XML
> file (an ATOM feed with one entry for the composite and one entry per
> contribution) and have your Webapp pick up that file.
>
> - You can also use the domain manager app to get that info. To do that just
> click on the Node Config column for the Node you're interested in, save that
> doc to a file, then have your Webapp pick it up as above (and the domain
> manager app does not have to be running at all at that time).
>
> - You can also have the Webapp pick up its config info from a running
> instance of the domain manager app. That's what I've been doing usually at
> development time to have a quick debug/fix/try-again turn around, but I
> don't think that it's really what you'll want to do in production.
>
> I hope this helps, but again it would be really good if we could look at
> the user scenario that you have in mind together. It would help put the
> technical questions in context, as I'm still trying to guess what you're
> after but don't seem to be able to grasp it.
> --
> Jean-Sebastien
>

I'm going to have a go at articulating the scenarios I think are being
discussed on this thread. Hope these reads clearly in the first instance but
let iterate around these until we agree what we are trying to achieve and
which ones are valid. You may of course want to add other scenarios;-)

1. User experience A

1.1 The user builds contributionA/compositeA and obtains
contributionB/compositeB from a friend.
1.2 The user intends to run composite A and compositeB on separate nodes [a]

1.3 The user configures the composites to run on the chosen nodes using a
domain tool [b]
1.4 The user starts the nodes that he intends to use and configures each
with the composite he already knows he is going to run there and the
contributions this composite depends on [c]

2. User experience B

2.1 The user builds contributionA/compositeA and obtains
contributionB/compositeB from a friend. [d]
2.2 The user intends to run composite A and compositeB as webaps in a single
web container [e]
2.3 The user copies the war files to the web app container. [f]

Notes.

[a] because isolation is require or different composited require different
resources provided by different nodes or for performance reasons etc.
[b] I'm not being precise here about the nature of this tool but it could be
our domain manager tool which analyzes all the contributions and produces
configured composites based on the information it finds.
[c] the nodes are given the URLs of the contributions to load, The user may
just have put them on a file system so file://.... will work. The configured
composite is also provided to replace the original one that appears in the
contribution.

[d] Both contributions are packaged as war files in this case
[e] This isn't a restriction but in this case the user just wants to test in
a single container.
[f] The domain processing required to resolve the composites in the context
of the domain happens behind the scenes and no SCA specific deployment steps
are required after each original contribution has been packaged as a war by
the user or his friend.

Do these capture the essence of what is being discussion?

Simon

Re: Tomcat and the new distributed domain modules

[Jean-Sebastien Delfino <js...@apache.org>]

ant elder wrote:
> On Tue, May 13, 2008 at 7:50 AM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
> 
>>
>>>> - create a domain manager (did u mean create an domain? deploy a
>>>> domain
>>>> manager as a web app? start an instance of a domain manager?)
>>>>
>>>>
>>> You tell me, I'm trying to understand how to use all this distributed
>>> domain
>>> stuff you've written to support the scenario described above.
>>>
>> Well, I'm not sure what to tell you unless I understand what you meant by
>> 'create a domain manager' before Tomcat starts deploying webapps and what
>> the purpose would be.
>>
> 
> This is like pulling teeth.
> 
> Over in the email where you describe how to use a webapp with the standalone
> domain one of the first steps is "Start the domain manager app", so given
> whats been described previously in this thread we will need to do something
> similar within Tomcat right?
> 
>    ...ant
> 

Not necessarily, I was starting the domain manager app in that scenario 
mainly for people to see how to contribute to the SCA domain and also 
use the manager app capability to start nodes.

Tuscany standalone nodes can also be started from the command line (use 
tuscany-node2-launcher directly from the command line instead of 
clicking Start in the domain manager app UI). You don't need to use the 
domain manager app then.

I also said in that email that nodes could be started in different 
orders. That applies to the domain manager app too but obviously you 
need to start it if you want to use its UI to inspect and manage your nodes.

I'm still trying to understand your user scenario so it's really 
difficult to say if I'm missing the point here or not, but here are a 
few more thoughts:

- If your nodes are Webapps on Tomcat then you can just deploy them and 
start them using the Tomcat manager, or some of the Tomcat admin tasks 
for example.

- You don't need to start the SCA domain manager before deploying your 
Webapp to Tomcat.

- When you start the Webapp, it'll need SCA metadata, the SCA composite 
to use and a list of SCA contributions. There are many ways to provide 
that information:

- You can provide that information using the APIs/SPIs like shown in the 
domain-management sample.

- You can use similar code to build that information, save it to an XML 
file (an ATOM feed with one entry for the composite and one entry per 
contribution) and have your Webapp pick up that file.

- You can also use the domain manager app to get that info. To do that 
just click on the Node Config column for the Node you're interested in, 
save that doc to a file, then have your Webapp pick it up as above (and 
the domain manager app does not have to be running at all at that time).

- You can also have the Webapp pick up its config info from a running 
instance of the domain manager app. That's what I've been doing usually 
at development time to have a quick debug/fix/try-again turn around, but 
I don't think that it's really what you'll want to do in production.

I hope this helps, but again it would be really good if we could look at 
the user scenario that you have in mind together. It would help put the 
technical questions in context, as I'm still trying to guess what you're 
after but don't seem to be able to grasp it.
-- 
Jean-Sebastien

Re: Tomcat and the new distributed domain modules

[ant elder <an...@gmail.com>]

On Tue, May 13, 2008 at 7:50 AM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:

>
>
> > > - create a domain manager (did u mean create an domain? deploy a
> > > domain
> > > manager as a web app? start an instance of a domain manager?)
> > >
> > >
> > You tell me, I'm trying to understand how to use all this distributed
> > domain
> > stuff you've written to support the scenario described above.
> >
>
> Well, I'm not sure what to tell you unless I understand what you meant by
> 'create a domain manager' before Tomcat starts deploying webapps and what
> the purpose would be.
>

This is like pulling teeth.

Over in the email where you describe how to use a webapp with the standalone
domain one of the first steps is "Start the domain manager app", so given
whats been described previously in this thread we will need to do something
similar within Tomcat right?

   ...ant

Re: Tomcat and the new distributed domain modules

[Jean-Sebastien Delfino <js...@apache.org>]

ant elder wrote:
> On Sun, May 11, 2008 at 7:34 PM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
> 
>> ant elder wrote:
>>
>>> I've been trying to use the new distributed domain stuff -
>>> domain-manager
>>> and node2* etc - to get Tomcat as a domain manager with SCA webapps
>>> being
>>> individual nodes, but not really making much progress getting it to work
>>> so
>>> asking here to see if there are any suggestions - mainly from you
>>> Sebastien
>>> as you've written most of those new modules :-)
>>>
>> I'm going to send steps to show how to run an SCA node as a web app in a
>> different email.
>>
>>  What i'd like is for during Tomcat startup to create a domain manager and
>>> then as each webapp is initialized create a new node for each webapp and
>>> register it with the domain, and to do that registration with in-JVM
>>> calls.
>>> Right now the domain manger needs to know about all the nodes before the
>>> domain can be started (i think?) but thats problematic in this scenario
>>> as
>>> the webapps are initialized one by one and its hard to batch all those
>>> up
>>> and then initialize the domain and then correctly insert the node into
>>> the
>>> webapps context. This is discussed in a bit more detail in the thread at
>>> [1].
>>>
>>> I wondered about enhancing the domain manager so that it can be created
>>> "empty" and then create/register nodes one-by-one and then activate the
>>> domain once thats done (which probably would require the more dynamic
>>> endpoint stuff being talked about in [2]), but I'm not sure that
>>> approach
>>> really fits in with the current design of the distributed domain
>>> support?
>>>
>>> WDYT, any comments or suggestions?
>>>
>>>   ...ant
>>>
>>> [1] http://apache.markmail.org/message/2i6gtkveapk3n4nr
>>> [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30314.html
>>>
>>>
>> I'd like to make sure I understand your question and scenario correctly
>> before trying answering the wrong question.
>>
>> Here are the parts that I'm not following:
>>
>> - create a domain manager (did u mean create an domain? deploy a domain
>> manager as a web app? start an instance of a domain manager?)
>>
> 
> You tell me, I'm trying to understand how to use all this distributed domain
> stuff you've written to support the scenario described above.

Well, I'm not sure what to tell you unless I understand what you meant 
by 'create a domain manager' before Tomcat starts deploying webapps and 
what the purpose would be.

Some of those
> distributed domain classes need to created/initialized/started before Tomcat
> starts deploying webapps

No not really, you don't need to create/initialize/start anything before 
deploying a webapp to Tomcat.

I posted a description of a scenario to this thread earlier today, and 
it doesn't require to start anything before deploying the tutorial 
webapp to Tomcat.

You need to have the configuration of the application (resolved and 
configured composite) before starting it, but not before deploying it 
(actually I think you can deploy the app with nothing started, not even 
Tomcat). Also even though the configuration of the application can be 
generated on the fly using the domain manager application, you don't 
have to do that, you could just provide it as a file on disk, or just 
use give it programmatically (a composite and a set of contributions) to 
the SCANode using one of the SCANodeFactory.create methods.

Maybe you can look at the samples under samples/domain-management, they 
show how to bootstrap things using the various SPIs and APIs.

  - is that the domain-manger? the domain-impl? Some
> combination? Something else?
> 

> 
>> - there is no such thing as 'start a domain',
> 
> 
> Well, the SCADomain interface does have a start method...

If I understand correctly, the SCADomain class represents the 
combination of a view of an SCA domain, and a runtime instance capable 
of running a set of components belonging to the domain (which I prefer 
to call an SCA node).

SCADomain.start() starts that view and runtime instance. This is 
different from starting an SCA administration domain.

I think you can start an SCA node, start an administration/manager 
application that gives you access to an SCA domain, but starting an SCA 
domain does not make sense IMHO.

does it help if its
> "Right now the domain manger needs to know about all the nodes before all
> the services in the domain can be started (I think?)"?

No it doesn't, and I think that it would be pretty inconvenient if it 
id. The requirement at the moment is the following: The domain manager 
app needs to know the endpoints of the targets of service references to 
be able to provide that information in a resolved composite.

If the target endpoint is available then you'll get it. Note that it 
doesn't mean that the target service is started or even deployed to a 
node, it just means that the target service appears with an endpoint in 
an SCA composite included in the SCA domain composite.

If the target service endpoint is not known when you ask the domain 
manager app to resolve a reference, then the reference will remain 
unresolved, and then the logic that Simon Laws described earlier in this 
thread (IIRC) can apply, and let the particular SCA binding 
implementation code do last minute resolution if you really want that.

> 
> why did you think that the domain manager needed to know all the nodes
>> before 'starting the domain'? what did you mean by 'starting the domain'?
>>
> 
> See [1] and the reply to that email. It does have "i think?" in brackets
> above, if thats not the case then great.

That's not the case, I think I covered this above.


How do you add or register a node?
> 

Nodes are described with SCA components of type implementation.node. 
These SCA components can be contributed to the domain using the normal 
SCA contribution mechanism or just placed in composite files under the 
cloud/ directory under the domain root directory, and included using a 
regular SCA <include> by cloud.composite. There's a complete example 
under tutorial/domain. There's also sample code showing how to do this 
with SPIs under samples/domain-management.

> 
>> - 'as each webapp is initialized', did you mean 'installed' or 'started'?
> 
> 
> The node for the webapp needs to be available to use when the "init" method
> is called on any of the webapp Servlets and similar classes. To create that
> node we can intercept and do things at various points during the deployment
> of the webapp depending on the requirements of the distributed domain
> modules and classes.

I'm lost here, sorry. Did you mean create an instance of an SCANode 
object? or did you mean dynamically add a node declaration and 
configuration to the SCA domain that you Web container belongs to??

> 
>> do you have the requirement to know about the existence of a webapp (node)
>> in an SCA domain before it's started?
>>
> 
> No
> 

I think that there's a disconnect here, I don't understand that part 
either. This is like saying that you don't need to know the existence of 
the Webapp before starting it. Also an SCA domain is a domain of 
administration, used to start/stop nodes etc. I'm not sure how you can 
start and administer a node from the domain if you don't know about it. 
I had asked that question to see if I was following what you were after, 
but I'm not, I'm probably missing something obvious.


>> - 'insert the node in the webapp context' what did you mean by that?
>>
> 
> Put whatever is the node or domain Java object which clients are supposed to
> use into the ServletContext object of the webapp. Ideally all our existing
> webapp samples will continue to work with minimal changes when running in
> this new deep integration approach.

Another mis-understanding, probably from my part. I don't understand 
what putting a node in the servlet context has to do with the 'new deep 
integration approach'. We were talking about shallow integration and 
deep integration last year, but AFAIK the code that works with the 
ServletContext at the moment is what we used to call shallow 
integration. Could you please say a bit more about this?

> 
>    ...ant
> 
> [1] http://apache.markmail.org/message/zhoclft2wrvypyys
> 

-- 
Jean-Sebastien

Re: How to deploy standalone and webapp nodes in an SCA domain, was: Tomcat and the new distributed domain modules

[ant elder <an...@gmail.com>]

On Tue, May 13, 2008 at 2:25 AM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:

> ant elder wrote:
>
> > On Sun, May 11, 2008 at 7:34 PM, Jean-Sebastien Delfino <
> > jsdelfino@apache.org> wrote:
> >
> >  ant elder wrote:
> > >
> > >  I've been trying to use the new distributed domain stuff -
> > > > domain-manager
> > > > and node2* etc - to get Tomcat as a domain manager with SCA webapps
> > > > being
> > > > individual nodes, but not really making much progress getting it to
> > > > work
> > > > so
> > > > asking here to see if there are any suggestions - mainly from you
> > > > Sebastien
> > > > as you've written most of those new modules :-)
> > > >
> > > >  I'm going to send steps to show how to run an SCA node as a web app
> > > in a
> > > different email.
> > >
> > >
> Here's a scenario and detailed steps showing how to deploy and run the
> tutorial's catalog-webapp on Tomcat and integrate it with the other tutorial
> modules running on other nodes in the same SCA domain.
>
> Note: I had to fix PackageTypeDescriberImpl as its support for WARs was
> broken by a recent patch in SVN r641645 so these steps should work with the
> 1.2 release and trunk but won't work with r641645 <= SVN < r655704.
>
> First build a Tuscany distribution or just have Maven place all the
> required Tuscany dependency JARs in a directory as follows:
> cd tutorial/domain
> mvn dependency:copy-dependencies
> That will copy the required JARs to tutorial/domain/target/dependency.
>
> Start the domain manager app as follows:
> java -jar
> <Tuscany distribution root or location of the JARs>
> /tuscany-node2-launcher-2.0-incubating-SNAPSHOT.jar domain
>
> Browse http://localhost:9990/ui/workspace/
> You should see the tutorial contributions already deployed to the tutorial
> SCA domain.
>
> Browse http://localhost:9990/ui/cloud/ to see the SCA nodes declared in
> the tutorial.
>
> Check CurrencyNode and CatalogsNode
> Press Start, the two nodes should appear as started (clicking the started
> link shows their log).
>
> cd tutorial/store-eu
> Edit store-eu.composite and change:
>  <reference name="fruitsCatalog" target="FruitsCatalogWebService">
> to
>  <reference name="fruitsCatalog" target="WebFruitsCatalog">
> to make it use the catalog packaged in catalog-webapp.
>
> mvn clean install to rebuild store-eu
>
> Browse http://localhost:9990/ui/cloud/
> Check StoreEUNode, press Start to start the store application.
>
> Copy tutorial/catalog-webapp/target/tutorial-catalog-webapp.war to
> CatalogWebAppNode.war in some folder.
>
> If you open CatalogWebAppNode.war you'll see that it only contains a
> minimum of Tuscany runtime JARs (basically just the API JARs needed to
> compile application code like JSPs for example) and a Tuscany launcher JAR,
> responsible for launching the SCA node inside the Webapp.
>
> CatalogWebAppNode is the name of the SCA node allocated to the
> catalog-webapp composite. Having the Web context named CatalogWebAppNode
> tells the launcher that it's dealing with CatalogWebAppNode. It also makes
> it easy to find, manage, start/stop these Tomcat nodes using the Tomcat
> manager app.
>
> You can also deploy the same composite Webapp to multiple nodes this way,
> you just need to name use the proper Web context name when you're deploying
> the Webapp to the Web container.
>
> Note that other application servers like WebSphere or Geronimo (IIRC)
> allow you to set the Web context name without renaming the WAR. It may be
> possible to do the same with Tomcat too using a Tomcat deployment
> descriptor, I'm not sure but anyway I think that there's more power in being
> portable and Web server independent here, as an SCA domain can include many
> servers of different types.
>
> Configure environment variable TUSCANY_HOME=<location of the JARs used
> earlier> or <root of Tuscany distribution install>. This will tell the
> launcher where to find these JARs, as an alternative to shared libraries
> that are not supported by all servers.
>
> Start Tomcat
> Deploy CatalogWebAppNode.war to Tomcat, it should start right away.
>
> Browse http://localhost:8080/CatalogWebAppNode/
> You should see a catalog of fruits.
>
> Browse http://localhost:8104/ui/store-eu.html
> You should see the store catalog, listing some fruits and vegetables.
>
> Assuming that everything worked to this point, you've basically run 4 SCA
> nodes, 3 running as J2SE standalone nodes and one running as a webapp on
> Tomcat.
>
> Here are the details:
> - The store widget component runs in your Web browser;
> - The widget talks to the store components running on a 1st standalone SCA
> node;
> - The store components use two catalogs, a vegetables catalog running on a
> 2nd standalone SCA node and a fruits catalog running on a 3rd SCA node,
> configured as a Webapp on Tomcat;
> - Both catalogs use the same currency converter service running on a
> fourth standalong SCA node.
>
> In addition to Webapp deployment this scenario also showed the ability to
> start nodes in any order - you can try different sequences :) - and update
> and rewire a composite already deployed to the domain (store-eu was updated
> and rebuilt then changes were picked up without having to redeploy it).
>
> The same steps work with Geronimo and WebSphere. On WebSphere you just
> need to configure a shared library pointing to the Tuscany JARs and
> dependencies.
>
> Hope this helps.
>
> P.S. I'll try to send a variation of these steps later that show how you
> can run SCA nodes in Webapps without exposing any of the Webapp specifics to
> the application developer (basically you just work with plain contribution
> JARs). I meant to do that today but was just too busy to get to it.
> --
> Jean-Sebastien
>

Thanks for this. Though its not the same as the scenario being discussed
over on the Tomcat thread so i hope you can still find the time to answer
over there - http://apache.markmail.org/message/tim32bk7ijwszi2e

   ...ant

How to deploy standalone and webapp nodes in an SCA domain, was: Tomcat and the new distributed domain modules

[Jean-Sebastien Delfino <js...@apache.org>]

ant elder wrote:
> On Sun, May 11, 2008 at 7:34 PM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
> 
>> ant elder wrote:
>>
>>> I've been trying to use the new distributed domain stuff -
>>> domain-manager
>>> and node2* etc - to get Tomcat as a domain manager with SCA webapps
>>> being
>>> individual nodes, but not really making much progress getting it to work
>>> so
>>> asking here to see if there are any suggestions - mainly from you
>>> Sebastien
>>> as you've written most of those new modules :-)
>>>
>> I'm going to send steps to show how to run an SCA node as a web app in a
>> different email.
>>

Here's a scenario and detailed steps showing how to deploy and run the 
tutorial's catalog-webapp on Tomcat and integrate it with the other 
tutorial modules running on other nodes in the same SCA domain.

Note: I had to fix PackageTypeDescriberImpl as its support for WARs was 
broken by a recent patch in SVN r641645 so these steps should work with 
the 1.2 release and trunk but won't work with r641645 <= SVN < r655704.

First build a Tuscany distribution or just have Maven place all the 
required Tuscany dependency JARs in a directory as follows:
cd tutorial/domain
mvn dependency:copy-dependencies
That will copy the required JARs to tutorial/domain/target/dependency.

Start the domain manager app as follows:
java -jar
<Tuscany distribution root or location of the JARs> 
/tuscany-node2-launcher-2.0-incubating-SNAPSHOT.jar domain

Browse http://localhost:9990/ui/workspace/
You should see the tutorial contributions already deployed to the 
tutorial SCA domain.

Browse http://localhost:9990/ui/cloud/ to see the SCA nodes declared in 
the tutorial.

Check CurrencyNode and CatalogsNode
Press Start, the two nodes should appear as started (clicking the 
started link shows their log).

cd tutorial/store-eu
Edit store-eu.composite and change:
   <reference name="fruitsCatalog" target="FruitsCatalogWebService">
to
   <reference name="fruitsCatalog" target="WebFruitsCatalog">
to make it use the catalog packaged in catalog-webapp.

mvn clean install to rebuild store-eu

Browse http://localhost:9990/ui/cloud/
Check StoreEUNode, press Start to start the store application.

Copy tutorial/catalog-webapp/target/tutorial-catalog-webapp.war to 
CatalogWebAppNode.war in some folder.

If you open CatalogWebAppNode.war you'll see that it only contains a 
minimum of Tuscany runtime JARs (basically just the API JARs needed to 
compile application code like JSPs for example) and a Tuscany launcher 
JAR, responsible for launching the SCA node inside the Webapp.

CatalogWebAppNode is the name of the SCA node allocated to the 
catalog-webapp composite. Having the Web context named CatalogWebAppNode 
tells the launcher that it's dealing with CatalogWebAppNode. It also 
makes it easy to find, manage, start/stop these Tomcat nodes using the 
Tomcat manager app.

You can also deploy the same composite Webapp to multiple nodes this 
way, you just need to name use the proper Web context name when you're 
deploying the Webapp to the Web container.

Note that other application servers like WebSphere or Geronimo (IIRC) 
allow you to set the Web context name without renaming the WAR. It may 
be possible to do the same with Tomcat too using a Tomcat deployment 
descriptor, I'm not sure but anyway I think that there's more power in 
being portable and Web server independent here, as an SCA domain can 
include many servers of different types.

Configure environment variable TUSCANY_HOME=<location of the JARs used 
earlier> or <root of Tuscany distribution install>. This will tell the 
launcher where to find these JARs, as an alternative to shared libraries 
that are not supported by all servers.

Start Tomcat
Deploy CatalogWebAppNode.war to Tomcat, it should start right away.

Browse http://localhost:8080/CatalogWebAppNode/
You should see a catalog of fruits.

Browse http://localhost:8104/ui/store-eu.html
You should see the store catalog, listing some fruits and vegetables.

Assuming that everything worked to this point, you've basically run 4 
SCA nodes, 3 running as J2SE standalone nodes and one running as a 
webapp on Tomcat.

Here are the details:
- The store widget component runs in your Web browser;
- The widget talks to the store components running on a 1st standalone 
SCA node;
- The store components use two catalogs, a vegetables catalog running on 
a 2nd standalone SCA node and a fruits catalog running on a 3rd SCA 
node, configured as a Webapp on Tomcat;
- Both catalogs use the same currency converter service running on a 
fourth standalong SCA node.

In addition to Webapp deployment this scenario also showed the ability 
to start nodes in any order - you can try different sequences :) - and 
update and rewire a composite already deployed to the domain (store-eu 
was updated and rebuilt then changes were picked up without having to 
redeploy it).

The same steps work with Geronimo and WebSphere. On WebSphere you just 
need to configure a shared library pointing to the Tuscany JARs and 
dependencies.

Hope this helps.

P.S. I'll try to send a variation of these steps later that show how you 
can run SCA nodes in Webapps without exposing any of the Webapp 
specifics to the application developer (basically you just work with 
plain contribution JARs). I meant to do that today but was just too busy 
to get to it.
-- 
Jean-Sebastien

Re: Tomcat and the new distributed domain modules

[ant elder <an...@gmail.com>]

On Sun, May 11, 2008 at 7:34 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:

> ant elder wrote:
>
> > I've been trying to use the new distributed domain stuff -
> > domain-manager
> > and node2* etc - to get Tomcat as a domain manager with SCA webapps
> > being
> > individual nodes, but not really making much progress getting it to work
> > so
> > asking here to see if there are any suggestions - mainly from you
> > Sebastien
> > as you've written most of those new modules :-)
> >
>
> I'm going to send steps to show how to run an SCA node as a web app in a
> different email.
>
>  What i'd like is for during Tomcat startup to create a domain manager and
> > then as each webapp is initialized create a new node for each webapp and
> > register it with the domain, and to do that registration with in-JVM
> > calls.
> > Right now the domain manger needs to know about all the nodes before the
> > domain can be started (i think?) but thats problematic in this scenario
> > as
> > the webapps are initialized one by one and its hard to batch all those
> > up
> > and then initialize the domain and then correctly insert the node into
> > the
> > webapps context. This is discussed in a bit more detail in the thread at
> > [1].
> >
> > I wondered about enhancing the domain manager so that it can be created
> > "empty" and then create/register nodes one-by-one and then activate the
> > domain once thats done (which probably would require the more dynamic
> > endpoint stuff being talked about in [2]), but I'm not sure that
> > approach
> > really fits in with the current design of the distributed domain
> > support?
> >
> > WDYT, any comments or suggestions?
> >
> >   ...ant
> >
> > [1] http://apache.markmail.org/message/2i6gtkveapk3n4nr
> > [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30314.html
> >
> >
> I'd like to make sure I understand your question and scenario correctly
> before trying answering the wrong question.
>
> Here are the parts that I'm not following:
>
> - create a domain manager (did u mean create an domain? deploy a domain
> manager as a web app? start an instance of a domain manager?)
>

You tell me, I'm trying to understand how to use all this distributed domain
stuff you've written to support the scenario described above. Some of those
distributed domain classes need to created/initialized/started before Tomcat
starts deploying webapps - is that the domain-manger? the domain-impl? Some
combination? Something else?


>
> - there is no such thing as 'start a domain',


Well, the SCADomain interface does have a start method...does it help if its
"Right now the domain manger needs to know about all the nodes before all
the services in the domain can be started (I think?)"?

why did you think that the domain manager needed to know all the nodes
> before 'starting the domain'? what did you mean by 'starting the domain'?
>

See [1] and the reply to that email. It does have "i think?" in brackets
above, if thats not the case then great. How do you add or register a node?


>
> - 'as each webapp is initialized', did you mean 'installed' or 'started'?


The node for the webapp needs to be available to use when the "init" method
is called on any of the webapp Servlets and similar classes. To create that
node we can intercept and do things at various points during the deployment
of the webapp depending on the requirements of the distributed domain
modules and classes.


> do you have the requirement to know about the existence of a webapp (node)
> in an SCA domain before it's started?
>

No



> - 'insert the node in the webapp context' what did you mean by that?
>

Put whatever is the node or domain Java object which clients are supposed to
use into the ServletContext object of the webapp. Ideally all our existing
webapp samples will continue to work with minimal changes when running in
this new deep integration approach.

   ...ant

[1] http://apache.markmail.org/message/zhoclft2wrvypyys

Re: Tomcat and the new distributed domain modules

[Jean-Sebastien Delfino <js...@apache.org>]

ant elder wrote:
> I've been trying to use the new distributed domain stuff - domain-manager
> and node2* etc - to get Tomcat as a domain manager with SCA webapps being
> individual nodes, but not really making much progress getting it to work so
> asking here to see if there are any suggestions - mainly from you Sebastien
> as you've written most of those new modules :-)

I'm going to send steps to show how to run an SCA node as a web app in a 
different email.

> What i'd like is for during Tomcat startup to create a domain manager and
> then as each webapp is initialized create a new node for each webapp and
> register it with the domain, and to do that registration with in-JVM calls.
> Right now the domain manger needs to know about all the nodes before the
> domain can be started (i think?) but thats problematic in this scenario as
> the webapps are initialized one by one and its hard to batch all those up
> and then initialize the domain and then correctly insert the node into the
> webapps context. This is discussed in a bit more detail in the thread at
> [1].
> 
> I wondered about enhancing the domain manager so that it can be created
> "empty" and then create/register nodes one-by-one and then activate the
> domain once thats done (which probably would require the more dynamic
> endpoint stuff being talked about in [2]), but I'm not sure that approach
> really fits in with the current design of the distributed domain support?
> 
> WDYT, any comments or suggestions?
> 
>    ...ant
> 
> [1] http://apache.markmail.org/message/2i6gtkveapk3n4nr
> [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30314.html
> 

I'd like to make sure I understand your question and scenario correctly 
before trying answering the wrong question.

Here are the parts that I'm not following:

- create a domain manager (did u mean create an domain? deploy a domain 
manager as a web app? start an instance of a domain manager?)

- there is no such thing as 'start a domain', why did you think that the 
domain manager needed to know all the nodes before 'starting the 
domain'? what did you mean by 'starting the domain'?

- 'as each webapp is initialized', did you mean 'installed' or 
'started'? do you have the requirement to know about the existence of a 
webapp (node) in an SCA domain before it's started?

- 'insert the node in the webapp context' what did you mean by that?

-- 
Jean-Sebastien