Re: node-manager questions
On Thu, May 12, 2011 at 5:13 PM, Simon Laws wrote:
> I think having a web page to access the domain is a great idea. I'd
> like to see a more comprehensive URL space support in the future. For
> example, this is what came to mind when I actually sat down and put
> pen to paper.
>
> http://somehost:someport/sca/
> {domainname}/ -> get the service document, i.e.
> links the following collections
> contribution/ -> get a list of installed
> contributions (atom/rss?)
> {contributionURI}/ -> get the contribution archive (or its URL?)
> relative/uri/of/artifact -> get the artifact (see section
> 10.4.1)
> ?artifact=artifact identifier -> get the artifact
> (identifier here could be, e.g. namespace item)
> composite/ -> list of all composites in the
> contribution (includes deployment time composites)
> composite/ -> get a list of available composites
> (atom/rss?)
> spec/ -> get the domain composite as per the
> spec with includes for deployed composites
> exploded/ -> get the exploded domain composite as XML
> {compositeQName} -> get the .composite file regardless
> of whether deployed or not. Could get the GSoC picture here
> ?element=xpath -> get that part of the domain
> composite as XML using XPath as per policy attachment
> node/ -> get the list of running nodes in
> the domain (atom/rss?)
> {node name} -> get the XML configuration for the named node
> endpoint/ -> get the list of all active
> endpoints (atom/rss?)
> {endpointURI} -> get the XML representation of the
> named endpoint
> policy/ -> TBD
>
> I don't really know if that's the optimal design, is complete or if
> all of these would be useful as I haven't actually tried it yet. I
> started playing in my sandbox and I'll stay there for the time being
> as I see that it's been suggested that GSoC pick up node-manager and
> I don't want to trample on that.
>
> My real objective for thinking these thoughts was to find out if I
> could extract this info from the domain registry. Even in simple
> testing it's encouraging to see endpoints, composites etc. coming and
> going as nodes are started and stopped.
>
> I note that a node activator extension has been added. What's the
> objective of that? I'm starting to think that it will be useful to
> have node information shared in the registry. It looks like this
> activator is an in-JVM thing though?
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
A newby jax-rs question related to this. With the Tuscany jax-rs
integration how can I get two components to be part of the same URL
space when there is a variable part in the URL, for example, the
domain example from my previous post. Let's say I want my URL to be
http://localhost:8080/sca/domain/{domainname}/XYZ
where XYX could be contribution, composite etc. In this case if I want
a domain component mapped to
http://localhost:8080/sca/domain/{domainname} and a composite
component mapped to
http://localhost:8080/sca/domain/{domainname}/composite is that
possible. Or would I have to do
http://localhost:8080/sca/domain/{domainname} and
http://localhost:8080/sca/domain/composite/{domainname} which doesn't
seem right.
This is where I ended up with me .composite.
I can of course make it work using a single component, which is where
I started, but I wanted to learn more about the jax-rs integration.
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: node-manager questions
On Thu, May 12, 2011 at 5:13 PM, Simon Laws wrote:
> I think having a web page to access the domain is a great idea. I'd
> like to see a more comprehensive URL space support in the future. For
> example, this is what came to mind when I actually sat down and put
> pen to paper.
>
> http://somehost:someport/sca/
> {domainname}/ -> get the service document, i.e.
> links the following collections
> contribution/ -> get a list of installed
> contributions (atom/rss?)
> {contributionURI}/ -> get the contribution archive (or its URL?)
> relative/uri/of/artifact -> get the artifact (see section
> 10.4.1)
> ?artifact=artifact identifier -> get the artifact
> (identifier here could be, e.g. namespace item)
> composite/ -> list of all composites in the
> contribution (includes deployment time composites)
> composite/ -> get a list of available composites
> (atom/rss?)
> spec/ -> get the domain composite as per the
> spec with includes for deployed composites
> exploded/ -> get the exploded domain composite as XML
> {compositeQName} -> get the .composite file regardless
> of whether deployed or not. Could get the GSoC picture here
> ?element=xpath -> get that part of the domain
> composite as XML using XPath as per policy attachment
> node/ -> get the list of running nodes in
> the domain (atom/rss?)
> {node name} -> get the XML configuration for the named node
> endpoint/ -> get the list of all active
> endpoints (atom/rss?)
> {endpointURI} -> get the XML representation of the
> named endpoint
> policy/ -> TBD
>
We already have other ways to get at this information with things like
the command line Shell, the programmatic DomainNode APIs, and the
Maven plugin. The JMX GSoC project will likely also provide another
way to get at the information. So it would be really good if where
possible they all worked in similar ways providing similar commands,
and also share as much code as possible.
What would be the best way to that? I think its good and useful to
have freedom to just play around experimenting with different commands
and that will lead to finding ones we think are useful, could we then
put those on a wiki page or something?
For example, it looks like getting installed contributions is already
on all of these, above you have:
contribution/ -> get a list of installed contributions (atom/rss?)
the Shell has a command "installed" which displays the installed
contribution URIs on the console, and on Node there is a method doing
similar: "List getInstalledContributionURIs()"
Can we come up with a set of commands that we all agree are useful?
...ant
Re: node-manager questions
On Thu, May 12, 2011 at 9:13 AM, Simon Laws wrote:
> I think having a web page to access the domain is a great idea. I'd
> like to see a more comprehensive URL space support in the future. For
> example, this is what came to mind when I actually sat down and put
> pen to paper.
>
+1, although the current version of node-manager is a strawman, this
is exactly the idea. I also have extra requirements to provide a
"service registry" and some minimal documentation to this layer to
allow other developers to easily identify what services are available
on the domain.
> http://somehost:someport/sca/
> {domainname}/ -> get the service document, i.e.
> links the following collections
> contribution/ -> get a list of installed
> contributions (atom/rss?)
> {contributionURI}/ -> get the contribution archive (or its URL?)
> relative/uri/of/artifact -> get the artifact (see section
> 10.4.1)
> ?artifact=artifact identifier -> get the artifact
> (identifier here could be, e.g. namespace item)
> composite/ -> list of all composites in the
> contribution (includes deployment time composites)
> composite/ -> get a list of available composites
> (atom/rss?)
> spec/ -> get the domain composite as per the
> spec with includes for deployed composites
> exploded/ -> get the exploded domain composite as XML
> {compositeQName} -> get the .composite file regardless
> of whether deployed or not. Could get the GSoC picture here
> ?element=xpath -> get that part of the domain
> composite as XML using XPath as per policy attachment
> node/ -> get the list of running nodes in
> the domain (atom/rss?)
> {node name} -> get the XML configuration for the named node
> endpoint/ -> get the list of all active
> endpoints (atom/rss?)
> {endpointURI} -> get the XML representation of the
> named endpoint
> policy/ -> TBD
>
+1
> I don't really know if that's the optimal design, is complete or if
> all of these would be useful as I haven't actually tried it yet. I
> started playing in my sandbox and I'll stay there for the time being
> as I see that it's been suggested that GSoC pick up node-manager and
> I don't want to trample on that.
>
I should be ok to have all of us contributing to the same node-manager location.
> My real objective for thinking these thoughts was to find out if I
> could extract this info from the domain registry. Even in simple
> testing it's encouraging to see endpoints, composites etc. coming and
> going as nodes are started and stopped.
>
> I note that a node activator extension has been added. What's the
> objective of that? I'm starting to think that it will be useful to
> have node information shared in the registry. It looks like this
> activator is an in-JVM thing though?
>
The idea of the activator was to be able to attach to the node
lifecycle and have a way to register the nodes to the node-manager and
then allow it to retrieve node information.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: node-manager questions
On Fri, May 13, 2011 at 7:18 AM, Simon Laws wrote:
>
> A newby jax-rs question related to this. With the Tuscany jax-rs
> integration how can I get two components to be part of the same URL
> space when there is a variable part in the URL, for example, the
> domain example from my previous post. Let's say I want my URL to be
>
> http://localhost:8080/sca/domain/{domainname}/XYZ
>
> where XYX could be contribution, composite etc. In this case if I want
> a domain component mapped to
> http://localhost:8080/sca/domain/{domainname} and a composite
> component mapped to
> http://localhost:8080/sca/domain/{domainname}/composite is that
> possible. Or would I have to do
> http://localhost:8080/sca/domain/{domainname} and
> http://localhost:8080/sca/domain/composite/{domainname} which doesn't
> seem right.
>
> This is where I ended up with me .composite.
>
>
>
>
>
>
>
>
>
>
>
>
> I can of course make it work using a single component, which is where
> I started, but I wanted to learn more about the jax-rs integration.
>
It looks like this fits very weel in the concept of JAX-RS resource/sub-resource
http://incubator.apache.org/wink/1.1.1/html/JAX-RS%20Resources,%20HTTP%20Methods,%20and%20Paths.html
The idea is that you define a top level resource, that "handles" the
"domain" path, then it could redirect the "domain/composite" path to a
different component.
Please let me know if this helps, if you want I can build an example
in the node-manager module.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: node-manager questions
> > We already have other ways to get at this information with things like > the command line Shell, the programmatic DomainNode APIs, and the > Maven plugin. The JMX GSoC project will likely also provide another > way to get at the information. So it would be really good if where > possible they all worked in similar ways providing similar commands, > and also share as much code as possible. +1 I've already stumbled across this and posted about it. I.e. there was some function (for getting the domain composite IIRC) that I just wanted to re-use. It was embedded in the DomainNode. Now we have two different node implementations which use the underlying Tuscany SPIs. It would be a shame to repeat this reporting type code in each of them > > What would be the best way to that? I think its good and useful to > have freedom to just play around experimenting with different commands > and that will lead to finding ones we think are useful, could we then > put those on a wiki page or something? Sounds OK to me. I really don't have a feel for what will and won't be useful. We've just go to try some things, be prepared to lets some die and support those that are useful. I'm sure the useful ones will find their ways into all of our various user interfaces eventually. > > For example, it looks like getting installed contributions is already > on all of these, above you have: > > contribution/ -> get a list of installed contributions (atom/rss?) > > the Shell has a command "installed" which displays the installed > contribution URIs on the console, and on Node there is a method doing > similar: "List getInstalledContributionURIs()" > > Can we come up with a set of commands that we all agree are useful? I think it we can come up with a common API/SPI the result can then be rendered in lots of ways. In the shell, on a web page, in a management tool. Part of the tension for me here comes from having two Node APIs. I don't mind as they do different things in as much as the original one is our atomic node which just runs a single composite while the domain node better reflects the OASIS spec domain APIs (can we though not call then both node as it confuses me). How about we look at providing some base where we can collect together any common reporting operations? > > ...ant > -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: node-manager questions
...snip
>
> It looks like this fits very weel in the concept of JAX-RS
> resource/sub-resource
> http://incubator.apache.org/wink/1.1.1/html/JAX-RS%20Resources,%20HTTP%20Methods,%20and%20Paths.html
>
> The idea is that you define a top level resource, that "handles" the
> "domain" path, then it could redirect the "domain/composite" path to a
> different component.
>
> Please let me know if this helps, if you want I can build an example
> in the node-manager module.
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
That does sound like the right sort of thing however it's still not
clear how the second component is configured from an SCA point of
view, e,g,
http://localhost/sca/domain/{domainid} -> ComponentA - binding url =
"http://localhost/sca/domain/";
http://localhost/sca/domain/{domainid}/composite -> ComponentB -
binding url = "http://localhost/sca/domain/";
So both SCA components have the same binding url because the next path
element is variable. Are there some smarts in the rest binding
implementation that allow this to happen? I haven't actually tried it
but I will when I get five minutes.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: node-manager questions
On Mon, May 16, 2011 at 11:12 AM, Simon Laws wrote:
> ...snip
>>
>> It looks like this fits very weel in the concept of JAX-RS
>> resource/sub-resource
>> http://incubator.apache.org/wink/1.1.1/html/JAX-RS%20Resources,%20HTTP%20Methods,%20and%20Paths.html
>>
>> The idea is that you define a top level resource, that "handles" the
>> "domain" path, then it could redirect the "domain/composite" path to a
>> different component.
>>
>> Please let me know if this helps, if you want I can build an example
>> in the node-manager module.
>>
>>
>> --
>> Luciano Resende
>> http://people.apache.org/~lresende
>> http://twitter.com/lresende1975
>> http://lresende.blogspot.com/
>>
>
> That does sound like the right sort of thing however it's still not
> clear how the second component is configured from an SCA point of
> view, e,g,
>
> http://localhost/sca/domain/{domainid} -> ComponentA - binding url =
> "http://localhost/sca/domain/";
> http://localhost/sca/domain/{domainid}/composite -> ComponentB -
> binding url = "http://localhost/sca/domain/";
>
> So both SCA components have the same binding url because the next path
> element is variable. Are there some smarts in the rest binding
> implementation that allow this to happen? I haven't actually tried it
> but I will when I get five minutes.
>
> Simon
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Re-reading this I wasn't very clear. I appreciate that within the Java
implementation you could have multiple Java classes and use the
sub-resource pattern you pointed at to direct requests accordingly.
What I was wondering though was whether the Tuscany REST binding had
any ability to do a similar job of partitioning a URL across multiple
components.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
