You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2007/11/30 14:52:31 UTC
Selection of default service URIs based on URIs from the composite
We have discussed this behaviour before and I was sort of convinced last
time but now I'm playing with the store sample I'm not so sure. This
features comes about because of the store composite, for example,
<component name="Store">
<t:implementation.widget location="uiservices/store.html"/>
<service name="Widget">
<t:binding.http uri="http://localhost:8101/ui"/>
</service>
<reference name="catalog" target="Catalog">
<t:binding.jsonrpc/>
</reference>
<reference name="shoppingCart" target="ShoppingCart/Cart">
<t:binding.atom/>
</reference>
<reference name="shoppingTotal" target="ShoppingCart/Total">
<t:binding.jsonrpc/>
</reference>
</component>
To keep the composite tidy many of the URIs are omitted and they rely on the
default value. However the URI for one of the bindings is provided so that
the node will detect this and use this as the default for all service
bindings (where this kind of URI is applicable). All the bindings must be
the same here as store.html relies on the services being accessible from the
same root.
There are several places that the default port for the servlet host comes
from when setting up the SCA runtime.
1. The web app container. In this case no matter how you configure SCA you
will get whatever the web app container gives you
2. Node URI. This is used to tell what endpoints SCA should use by default
and also as a unique ID for the node. When running inside a web app this
must be the host/port you expect the web app to expose your services on.
Otherwise SCA can't tell what values the web app container is going to use
and hence can't register services with the domain. In the case that SCA
starts Tomcat/Jetty itself then the Node URI is just the default value that
will be used if a URI is not provided explicitly on a binding.
3. Binding uri attribute. If SCA is running inside a web app container this
value is ignored and Node URI is used (see 2). If SCA has started
Tomcat/Jetty itself this value will be used to configure the endpoint of the
service. If no value is provided then the default value is used (see 1 and
2).
So what's the drawback of using
<component name="Store">
<t:implementation.widget location="uiservices/store.html"/>
<service name="Widget">
<t:binding.http uri="/ui"/>
</service>
<reference name="catalog" target="Catalog">
<t:binding.jsonrpc/>
</reference>
<reference name="shoppingCart" target="ShoppingCart/Cart">
<t:binding.atom/>
</reference>
<reference name="shoppingTotal" target="ShoppingCart/Total">
<t:binding.jsonrpc/>
</reference>
</component>
And setting Node URI = http://localhost:8101
I'm uncomfortable about the current feature because I could easily include a
component in front of the existing component, e.g.
<component name"SomeComponent"
<implementation .../>
<service name="SomeService">
<binding.ws url="http://localhost:8100/SomeService"/>
</service>
</component>
<component name="Store">
<t:implementation.widget location="uiservices/store.html"/>
<service name="Widget">
<t:binding.http uri="http://localhost:8101/ui"/>
</service>
<reference name="catalog" target="Catalog">
<t:binding.jsonrpc/>
</reference>
<reference name="shoppingCart" target="ShoppingCart/Cart">
<t:binding.atom/>
</reference>
<reference name="shoppingTotal" target="ShoppingCart/Total">
<t:binding.jsonrpc/>
</reference>
</component>
And mess it up as now the majority services in the composite are at 8100 and
not 8101 where store.html expects them to be.
Regards
Simon
Re: What is this base domain URI about? was: Selection of default
service URIs based on URIs from the composite
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
>>>
>> I thought that the scenarios I described earlier helped describe the
>> problem, which boils down to:
>> domain != node
>> so domain URI != node URI
>> trying to make them equal is just wrong, and will break as soon as
>> there's 2 nodes in a domain.
>>
>
> Ok but in the non-distributed case with just a single standalone node then
> domain is the same as node isn't it, so domain uri could be the same as node
> uri?
That can only be a coincidence when there's only 1 node, I can only
repeat what I said above, sorry: that's wrong as soon as there's 2 nodes
in the domain.
>
> The specs don't mention nodes, maybe what we need is to do 1.7.2 for nodes
> and have a node base URI, i think that at least would help with all the WS
> endpoint problems we keep getting.
I think [1] is going in the same direction with a more general and
cleaner approach.
[1] http://marc.info/?l=tuscany-dev&m=119810821012389
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What is this base domain URI about? was: Selection of default service URIs based on URIs from the composite
Posted by Simon Laws <si...@googlemail.com>.
On Jan 4, 2008 3:18 PM, ant elder <an...@gmail.com> wrote:
> On Jan 4, 2008 3:02 PM, Simon Nash <na...@hursley.ibm.com> wrote:
>
> > Comments inline.
> >
> > Simon
> >
> > ant elder wrote:
> > > On Dec 13, 2007 5:22 PM, Jean-Sebastien Delfino <js...@apache.org>
> > > wrote:
> > >
> > (cut)
> > >>
> > >>I thought that the scenarios I described earlier helped describe the
> > >>problem, which boils down to:
> > >>domain != node
> > >>so domain URI != node URI
> > >>trying to make them equal is just wrong, and will break as soon as
> > >>there's 2 nodes in a domain.
> > >>
> > >
> > >
> > > Ok but in the non-distributed case with just a single standalone node
> > then
> > > domain is the same as node isn't it, so domain uri could be the same
> as
> > node
> > > uri?
> > >
> > Yes, I think it would be the same in this case. But this case is not
> > very "interesting" in the broader scheme of things. And to make special
> > use of the domain URI for this case only seems wrong to me.
> >
>
> Its the way just about all the users posting to the user list seem to be
> using Tuscany and its the way about 99% of the Tuscany samples and tests
> run! That makes it at least a little bit interesting doesn't it ;-) Also,
> if
> we do whats below then its not really making a special case for this
> standalone case.
>
>
> > > The specs don't mention nodes, maybe what we need is to do 1.7.2 for
> > nodes
> > > and have a node base URI, i think that at least would help with all
> the
> > WS
> > > endpoint problems we keep getting.
> > >
> > This seems a more useful path to follow. I'd like to understand in more
>
> > detail what you have in mind. Would services (potentially) be exposed
> on
> > two different endpoints (aliases), one with a node URI and another with
> a
> > domain URI?
> >
>
> Have to admit I'm still struggling to understand how the domain and
> multiple
> nodes is really supposed to be working so not sure i can answer that yet.
> Don't we have that issue today whether or not nodes have an explicit base
> uri?
>
> ...ant
Reading back through this mail it seems that we are discussing two,
potentially related, things.
A. How we form URLs for the services that an SCA application exposes
B. What do we do with the base domain URI scheme as described in the
specification.
There are many complexities in A spread around the specs. We have made
several starts at trying to document the algorithm [1][2][3]. So can we
discuss A without discussing B? Section 1.7.2 doesn't talk about a "domain
URI" but does talk about a "base domain URI for a scheme". The spec
describes only one of these for each scheme used in the SCA domain. This
implies to me that either the base domain URI for a scheme:
cannot be used as the base of the URI for the physical service URI as that
will differ from node to node. It probably means it should provide a virtual
set of endpoints for services in a similar way that a gateway/proxy would
provide access to an organizations services at some externally recognizable
endpoints. I think this is Sebastien's scenario2
OR
is used in some way TBD to form the base URI that each service is exposed
at. This is is Sebastien's scenario1 I think. Maybe the TBD is just to
specify it on a node by node basis and take the spec with a pinch of salt.
I don't think any of this differs based on the number of nodes we have (I am
considering here that a single node is a domain with one node in it). To put
it another way. It's complicated enough already so I would like it not to
matter.
Another issue that's bugging me is where these URI are calculated. The logic
is spread around the code and currently depends on activating an assembly
model. How about we develop an algorithm that is independent of binding
activation that the bindings can contribute to so that the domain can know
what the URIs will be without having to start each assembly.
Simon
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Multiple+bindings+and+reference+multiplicity
[2] Ant started a page somewhere but I can't find it now
[3]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Binding+URI+Construction
Re: What is this base domain URI about? was: Selection of default service URIs based on URIs from the composite
Posted by ant elder <an...@gmail.com>.
On Jan 4, 2008 3:02 PM, Simon Nash <na...@hursley.ibm.com> wrote:
> Comments inline.
>
> Simon
>
> ant elder wrote:
> > On Dec 13, 2007 5:22 PM, Jean-Sebastien Delfino <js...@apache.org>
> > wrote:
> >
> (cut)
> >>
> >>I thought that the scenarios I described earlier helped describe the
> >>problem, which boils down to:
> >>domain != node
> >>so domain URI != node URI
> >>trying to make them equal is just wrong, and will break as soon as
> >>there's 2 nodes in a domain.
> >>
> >
> >
> > Ok but in the non-distributed case with just a single standalone node
> then
> > domain is the same as node isn't it, so domain uri could be the same as
> node
> > uri?
> >
> Yes, I think it would be the same in this case. But this case is not
> very "interesting" in the broader scheme of things. And to make special
> use of the domain URI for this case only seems wrong to me.
>
Its the way just about all the users posting to the user list seem to be
using Tuscany and its the way about 99% of the Tuscany samples and tests
run! That makes it at least a little bit interesting doesn't it ;-) Also, if
we do whats below then its not really making a special case for this
standalone case.
> > The specs don't mention nodes, maybe what we need is to do 1.7.2 for
> nodes
> > and have a node base URI, i think that at least would help with all the
> WS
> > endpoint problems we keep getting.
> >
> This seems a more useful path to follow. I'd like to understand in more
> detail what you have in mind. Would services (potentially) be exposed on
> two different endpoints (aliases), one with a node URI and another with a
> domain URI?
>
Have to admit I'm still struggling to understand how the domain and multiple
nodes is really supposed to be working so not sure i can answer that yet.
Don't we have that issue today whether or not nodes have an explicit base
uri?
...ant
Re: What is this base domain URI about? was: Selection of default
service URIs based on URIs from the composite
Posted by Simon Nash <na...@hursley.ibm.com>.
Comments inline.
Simon
ant elder wrote:
> On Dec 13, 2007 5:22 PM, Jean-Sebastien Delfino <js...@apache.org>
> wrote:
>
(cut)
>>
>>I thought that the scenarios I described earlier helped describe the
>>problem, which boils down to:
>>domain != node
>>so domain URI != node URI
>>trying to make them equal is just wrong, and will break as soon as
>>there's 2 nodes in a domain.
>>
>
>
> Ok but in the non-distributed case with just a single standalone node then
> domain is the same as node isn't it, so domain uri could be the same as node
> uri?
>
Yes, I think it would be the same in this case. But this case is not
very "interesting" in the broader scheme of things. And to make special
use of the domain URI for this case only seems wrong to me.
> The specs don't mention nodes, maybe what we need is to do 1.7.2 for nodes
> and have a node base URI, i think that at least would help with all the WS
> endpoint problems we keep getting.
>
This seems a more useful path to follow. I'd like to understand in more
detail what you have in mind. Would services (potentially) be exposed on
two different endpoints (aliases), one with a node URI and another with a
domain URI?
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What is this base domain URI about? was: Selection of default service URIs based on URIs from the composite
Posted by ant elder <an...@gmail.com>.
On Dec 13, 2007 5:22 PM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> ant elder wrote:
> > On Nov 30, 2007 9:06 PM, Jean-Sebastien Delfino <js...@apache.org>
> > wrote:
> >
> >> Jean-Sebastien Delfino wrote:
> >>> ant elder wrote:
> >>>> On Nov 30, 2007 5:19 PM, Jean-Sebastien Delfino <jsdelfino@apache.org
> >
> >>>> wrote:
> >>>>
> >>>>> ant elder wrote:
> >>>>>> On Nov 30, 2007 1:52 PM, Simon Laws <si...@googlemail.com>
> >> wrote:
> >>>>>>> We have discussed this behaviour before and I was sort of
> convinced
> >>>>> last
> >>>>>>> time but now I'm playing with the store sample I'm not so sure.
> This
> >>>>>>> features comes about because of the store composite, for example,
> >>>>>>>
> >>>>>>> <component name="Store">
> >>>>>>> <t:implementation.widget location="uiservices/store.html"/>
> >>>>>>> <service name="Widget">
> >>>>>>> <t:binding.http uri="http://localhost:8101/ui"/>
> >>>>>>> </service>
> >>>>>>> <reference name="catalog" target="Catalog">
> >>>>>>> <t:binding.jsonrpc/>
> >>>>>>> </reference>
> >>>>>>> <reference name="shoppingCart" target="ShoppingCart/Cart">
> >>>>>>> <t:binding.atom/>
> >>>>>>> </reference>
> >>>>>>> <reference name="shoppingTotal"
> target="ShoppingCart/Total">
> >>>>>>> <t:binding.jsonrpc/>
> >>>>>>> </reference>
> >>>>>>> </component>
> >>>>>>>
> >>>>>>> To keep the composite tidy many of the URIs are omitted and they
> >> rely
> >>>>> on
> >>>>>>> the
> >>>>>>> default value. However the URI for one of the bindings is provided
> >> so
> >>>>> that
> >>>>>>> the node will detect this and use this as the default for all
> >> service
> >>>>>>> bindings (where this kind of URI is applicable). All the bindings
> >> must
> >>>>> be
> >>>>>>> the same here as store.html relies on the services being
> accessible
> >>>>> from
> >>>>>>> the
> >>>>>>> same root.
> >>>>>>>
> >>>>>>> There are several places that the default port for the servlet
> host
> >>>>> comes
> >>>>>>> from when setting up the SCA runtime.
> >>>>>>>
> >>>>>>> 1. The web app container. In this case no matter how you configure
> >> SCA
> >>>>> you
> >>>>>>> will get whatever the web app container gives you
> >>>>>>> 2. Node URI. This is used to tell what endpoints SCA should use by
> >>>>> default
> >>>>>>> and also as a unique ID for the node. When running inside a web
> app
> >>>>> this
> >>>>>>> must be the host/port you expect the web app to expose your
> services
> >>>>> on.
> >>>>>>> Otherwise SCA can't tell what values the web app container is
> going
> >> to
> >>>>> use
> >>>>>>> and hence can't register services with the domain. In the case
> that
> >>>>>>> SCA
> >>>>>>> starts Tomcat/Jetty itself then the Node URI is just the default
> >> value
> >>>>>>> that
> >>>>>>> will be used if a URI is not provided explicitly on a binding.
> >>>>>>> 3. Binding uri attribute. If SCA is running inside a web app
> >> container
> >>>>>>> this
> >>>>>>> value is ignored and Node URI is used (see 2). If SCA has started
> >>>>>>> Tomcat/Jetty itself this value will be used to configure the
> >> endpoint
> >>>>> of
> >>>>>>> the
> >>>>>>> service. If no value is provided then the default value is used
> >>>>>>> (see 1
> >>>>>>> and
> >>>>>>> 2).
> >>>>>>>
> >>>>>>> So what's the drawback of using
> >>>>>>>
> >>>>>>> <component name="Store">
> >>>>>>> <t:implementation.widget location="uiservices/store.html"/>
> >>>>>>> <service name="Widget">
> >>>>>>> <t:binding.http uri="/ui"/>
> >>>>>>> </service>
> >>>>>>> <reference name="catalog" target="Catalog">
> >>>>>>> <t:binding.jsonrpc/>
> >>>>>>> </reference>
> >>>>>>> <reference name="shoppingCart" target="ShoppingCart/Cart">
> >>>>>>> <t:binding.atom/>
> >>>>>>> </reference>
> >>>>>>> <reference name="shoppingTotal"
> target="ShoppingCart/Total">
> >>>>>>> <t:binding.jsonrpc/>
> >>>>>>> </reference>
> >>>>>>> </component>
> >>>>>>>
> >>>>>>> And setting Node URI = http://localhost:8101
> >>>>>>>
> >>>>>>> I'm uncomfortable about the current feature because I could easily
> >>>>> include
> >>>>>>> a
> >>>>>>> component in front of the existing component, e.g.
> >>>>>>>
> >>>>>>> <component name"SomeComponent"
> >>>>>>> <implementation .../>
> >>>>>>> <service name="SomeService">
> >>>>>>> <binding.ws url="http://localhost:8100/SomeService"/>
> >>>>>>> </service>
> >>>>>>> </component>
> >>>>>>>
> >>>>>>>
> >>>>>>> <component name="Store">
> >>>>>>> <t:implementation.widget location="uiservices/store.html"/>
> >>>>>>> <service name="Widget">
> >>>>>>> <t:binding.http uri="http://localhost:8101/ui"/>
> >>>>>>> </service>
> >>>>>>> <reference name="catalog" target="Catalog">
> >>>>>>> <t:binding.jsonrpc/>
> >>>>>>> </reference>
> >>>>>>> <reference name="shoppingCart" target="ShoppingCart/Cart">
> >>>>>>> <t:binding.atom/>
> >>>>>>> </reference>
> >>>>>>> <reference name="shoppingTotal"
> target="ShoppingCart/Total">
> >>>>>>> <t:binding.jsonrpc/>
> >>>>>>> </reference>
> >>>>>>> </component>
> >>>>>>>
> >>>>>>> And mess it up as now the majority services in the composite are
> at
> >>>>> 8100
> >>>>>>> and
> >>>>>>> not 8101 where store.html expects them to be.
> >>>>>>>
> >>>>>>> Regards
> >>>>>>>
> >>>>>>> Simon
> >>>>>>>
> >>>>>> I agree. We've never come up with a very consistent story about
> >> default
> >>>>> URLs
> >>>>>> that works well everywhere, would be great if we could as its
> always
> >>>>> causing
> >>>>>> problems with getting all the runtimes and nodes and service
> >> endpoints
> >>>>>> working consistently everywhere.
> >>>>>>
> >>>>>> Can we change so that the ServletHost implementation controls the
> >>>>> default
> >>>>>> base URL and have everything tries to use relative URLs with that?
> >>>>>>
> >>>>>> ...ant
> >>>>>>
> >>>>> IMHO the URI info should come from an SCA composite. Any departure
> >> from
> >>>>> that will lead to the definition of a new configuration model for
> >> these
> >>>>> things, stranger to SCA.
> >>>>>
> >>>> Could you explain this a bit more?
> >>>>
> >>>> Would that mean composites MUST include an absolute URI as in the
> >>>> example at
> >>>> the start of this thread?
> >>>>
> >>>> How does that relate to line 2357 of the assembly spec that says "An
> >> SCA
> >>>> domain should define a base URI for each 2358 hierarchical URI scheme
> >> on
> >>>> which it intends to provide services."?
> >>>>
> >>>> ...ant
> >>>>
> >>> Line 2357 is interesting. Let me try to describe (with two use cases)
> >>> how I envision that domain base URI being used.
> >>>
> >>> 1. Mycompany.com is a medium size business and has defined one SCA
> >>> domain (an SCA domain being a domain of administration, and the
> company
> >>> is not big, they have one administrator managing one SCA domain).
> >>>
> >>> Mycompany sells stuff online and offers Catalog and Shoppingcart
> >>> services at http://www.mycompany.com.
> >>>
> >>> To not have to repeat in all their service URIs http://www.company.com
> ,
> >>> they configure the domain base URI to http://www.company.com, and
> >>> configure their service URIs to "catalog" and "shopping". The
> effective
> >>> service URIs become http://www.mycompany.com/catalog and
> >>> http://www.mycompany.com/shopping.
> >>>
> >>> Now the company also has internal services not exposed to the external
> >>> world, like their accounting department for example on
> >>> intranet.mycompany.com.
> >>>
> >>> The beginning of the URI is different here so they're going to have to
> >>> specify absolute URIs for these services, like
> >>> http://intranet.mycompany.com/accounting for example.
> >>>
> >>> They can also do it the other way around, use a base URI for all the
> >>> internal services, and specific absolute URIs for the service URIs
> >>> published to the outside world, which is actually probably better.
> >>>
> >>> 2. Bigbank.com is a big bank, with multiple divisions, and multiple
> >>> administration domains. The bank is the result of a merger of 3
> >>> companies, a banking, a mortgage and an investment company, and for
> the
> >>> next few years the administration domains are going to stay separate
> to
> >>> keep people happy.
> >>>
> >>> The three admin domains are going to use three different URIs:
> >>> http://www.bigbank.com/banking
> >>> http://www.bigbank.com/loans
> >>> http://www.bigbank.com/invest
> >>>
> >>> In our big bank each domain consists of the description of about 150
> >>> services, running on 10 different servers and service containers of
> >>> various kinds, all at different IP addresses and port numbers
> obviously.
> >>>
> >>> So there's a little gap here between the
> http://www.bigbank.com/banking
> >>> domain base URI, which is supposed to be the default base for the
> whole
> >>> domain, and the http://192.168.1.2:8080 URL of one of the 10 servers
> :)
> >>>
> >>> In my view, the domain base URI mechanism is interesting, but it's not
> >>> meant to bind a Web service under "http://192.168.1.2:8080/war context
> >>> root in Tomcat" or configure the default port number of a Tuscany node
> >>> running on localhost.
> >>>
> >>> Sorry for such a long email (as I hate long emails too) but we've been
> >>> turning around this mysterious domain base URI for a while now so it's
> >>> about time to try to clarify how it is meant to be used. Hopefully
> this
> >>> will help fuel a discussion to clarify it.
> >>>
> >>> I'd be interested in the views of people more involved in the spec on
> >>> this, in particular on whether the use cases I just described make
> sense
> >>> to them or not :)
> >> One more thing :) I forgot to add that there's also the possibility
> that
> >> we conclude that this base domain URI mechanism is not really useful,
> as
> >> in the real world, except for the internet domain name part of the URI,
> >> I'm not sure that it's so simple or realistic to bind all your services
> >> to a common base URI scheme...
> >>
> >> Thoughts? opinions? clarifications?
> >>
> >
> > But what is the alternative?
> >
> > When running in containers like Tomcat or Geronimo we can only use the
> > container base URI.
> >
> > Various places in section 1.7.2 of the assembly spec use a base URI (eg
> > lines 2377 and 2382).
> >
> > So whats the problem with using the Tomcat/Geronimo container base URI
> as
> > desacribed in 1.7.2 and also changing our other runtimes to also have
> one
> > and work the same consistent way?
> >
> > ..ant
> >
>
> I thought that the scenarios I described earlier helped describe the
> problem, which boils down to:
> domain != node
> so domain URI != node URI
> trying to make them equal is just wrong, and will break as soon as
> there's 2 nodes in a domain.
>
Ok but in the non-distributed case with just a single standalone node then
domain is the same as node isn't it, so domain uri could be the same as node
uri?
The specs don't mention nodes, maybe what we need is to do 1.7.2 for nodes
and have a node base URI, i think that at least would help with all the WS
endpoint problems we keep getting.
...ant
Re: What is this base domain URI about? was: Selection of default
service URIs based on URIs from the composite
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On Nov 30, 2007 9:06 PM, Jean-Sebastien Delfino <js...@apache.org>
> wrote:
>
>> Jean-Sebastien Delfino wrote:
>>> ant elder wrote:
>>>> On Nov 30, 2007 5:19 PM, Jean-Sebastien Delfino <js...@apache.org>
>>>> wrote:
>>>>
>>>>> ant elder wrote:
>>>>>> On Nov 30, 2007 1:52 PM, Simon Laws <si...@googlemail.com>
>> wrote:
>>>>>>> We have discussed this behaviour before and I was sort of convinced
>>>>> last
>>>>>>> time but now I'm playing with the store sample I'm not so sure. This
>>>>>>> features comes about because of the store composite, for example,
>>>>>>>
>>>>>>> <component name="Store">
>>>>>>> <t:implementation.widget location="uiservices/store.html"/>
>>>>>>> <service name="Widget">
>>>>>>> <t:binding.http uri="http://localhost:8101/ui"/>
>>>>>>> </service>
>>>>>>> <reference name="catalog" target="Catalog">
>>>>>>> <t:binding.jsonrpc/>
>>>>>>> </reference>
>>>>>>> <reference name="shoppingCart" target="ShoppingCart/Cart">
>>>>>>> <t:binding.atom/>
>>>>>>> </reference>
>>>>>>> <reference name="shoppingTotal" target="ShoppingCart/Total">
>>>>>>> <t:binding.jsonrpc/>
>>>>>>> </reference>
>>>>>>> </component>
>>>>>>>
>>>>>>> To keep the composite tidy many of the URIs are omitted and they
>> rely
>>>>> on
>>>>>>> the
>>>>>>> default value. However the URI for one of the bindings is provided
>> so
>>>>> that
>>>>>>> the node will detect this and use this as the default for all
>> service
>>>>>>> bindings (where this kind of URI is applicable). All the bindings
>> must
>>>>> be
>>>>>>> the same here as store.html relies on the services being accessible
>>>>> from
>>>>>>> the
>>>>>>> same root.
>>>>>>>
>>>>>>> There are several places that the default port for the servlet host
>>>>> comes
>>>>>>> from when setting up the SCA runtime.
>>>>>>>
>>>>>>> 1. The web app container. In this case no matter how you configure
>> SCA
>>>>> you
>>>>>>> will get whatever the web app container gives you
>>>>>>> 2. Node URI. This is used to tell what endpoints SCA should use by
>>>>> default
>>>>>>> and also as a unique ID for the node. When running inside a web app
>>>>> this
>>>>>>> must be the host/port you expect the web app to expose your services
>>>>> on.
>>>>>>> Otherwise SCA can't tell what values the web app container is going
>> to
>>>>> use
>>>>>>> and hence can't register services with the domain. In the case that
>>>>>>> SCA
>>>>>>> starts Tomcat/Jetty itself then the Node URI is just the default
>> value
>>>>>>> that
>>>>>>> will be used if a URI is not provided explicitly on a binding.
>>>>>>> 3. Binding uri attribute. If SCA is running inside a web app
>> container
>>>>>>> this
>>>>>>> value is ignored and Node URI is used (see 2). If SCA has started
>>>>>>> Tomcat/Jetty itself this value will be used to configure the
>> endpoint
>>>>> of
>>>>>>> the
>>>>>>> service. If no value is provided then the default value is used
>>>>>>> (see 1
>>>>>>> and
>>>>>>> 2).
>>>>>>>
>>>>>>> So what's the drawback of using
>>>>>>>
>>>>>>> <component name="Store">
>>>>>>> <t:implementation.widget location="uiservices/store.html"/>
>>>>>>> <service name="Widget">
>>>>>>> <t:binding.http uri="/ui"/>
>>>>>>> </service>
>>>>>>> <reference name="catalog" target="Catalog">
>>>>>>> <t:binding.jsonrpc/>
>>>>>>> </reference>
>>>>>>> <reference name="shoppingCart" target="ShoppingCart/Cart">
>>>>>>> <t:binding.atom/>
>>>>>>> </reference>
>>>>>>> <reference name="shoppingTotal" target="ShoppingCart/Total">
>>>>>>> <t:binding.jsonrpc/>
>>>>>>> </reference>
>>>>>>> </component>
>>>>>>>
>>>>>>> And setting Node URI = http://localhost:8101
>>>>>>>
>>>>>>> I'm uncomfortable about the current feature because I could easily
>>>>> include
>>>>>>> a
>>>>>>> component in front of the existing component, e.g.
>>>>>>>
>>>>>>> <component name"SomeComponent"
>>>>>>> <implementation .../>
>>>>>>> <service name="SomeService">
>>>>>>> <binding.ws url="http://localhost:8100/SomeService"/>
>>>>>>> </service>
>>>>>>> </component>
>>>>>>>
>>>>>>>
>>>>>>> <component name="Store">
>>>>>>> <t:implementation.widget location="uiservices/store.html"/>
>>>>>>> <service name="Widget">
>>>>>>> <t:binding.http uri="http://localhost:8101/ui"/>
>>>>>>> </service>
>>>>>>> <reference name="catalog" target="Catalog">
>>>>>>> <t:binding.jsonrpc/>
>>>>>>> </reference>
>>>>>>> <reference name="shoppingCart" target="ShoppingCart/Cart">
>>>>>>> <t:binding.atom/>
>>>>>>> </reference>
>>>>>>> <reference name="shoppingTotal" target="ShoppingCart/Total">
>>>>>>> <t:binding.jsonrpc/>
>>>>>>> </reference>
>>>>>>> </component>
>>>>>>>
>>>>>>> And mess it up as now the majority services in the composite are at
>>>>> 8100
>>>>>>> and
>>>>>>> not 8101 where store.html expects them to be.
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Simon
>>>>>>>
>>>>>> I agree. We've never come up with a very consistent story about
>> default
>>>>> URLs
>>>>>> that works well everywhere, would be great if we could as its always
>>>>> causing
>>>>>> problems with getting all the runtimes and nodes and service
>> endpoints
>>>>>> working consistently everywhere.
>>>>>>
>>>>>> Can we change so that the ServletHost implementation controls the
>>>>> default
>>>>>> base URL and have everything tries to use relative URLs with that?
>>>>>>
>>>>>> ...ant
>>>>>>
>>>>> IMHO the URI info should come from an SCA composite. Any departure
>> from
>>>>> that will lead to the definition of a new configuration model for
>> these
>>>>> things, stranger to SCA.
>>>>>
>>>> Could you explain this a bit more?
>>>>
>>>> Would that mean composites MUST include an absolute URI as in the
>>>> example at
>>>> the start of this thread?
>>>>
>>>> How does that relate to line 2357 of the assembly spec that says "An
>> SCA
>>>> domain should define a base URI for each 2358 hierarchical URI scheme
>> on
>>>> which it intends to provide services."?
>>>>
>>>> ...ant
>>>>
>>> Line 2357 is interesting. Let me try to describe (with two use cases)
>>> how I envision that domain base URI being used.
>>>
>>> 1. Mycompany.com is a medium size business and has defined one SCA
>>> domain (an SCA domain being a domain of administration, and the company
>>> is not big, they have one administrator managing one SCA domain).
>>>
>>> Mycompany sells stuff online and offers Catalog and Shoppingcart
>>> services at http://www.mycompany.com.
>>>
>>> To not have to repeat in all their service URIs http://www.company.com,
>>> they configure the domain base URI to http://www.company.com, and
>>> configure their service URIs to "catalog" and "shopping". The effective
>>> service URIs become http://www.mycompany.com/catalog and
>>> http://www.mycompany.com/shopping.
>>>
>>> Now the company also has internal services not exposed to the external
>>> world, like their accounting department for example on
>>> intranet.mycompany.com.
>>>
>>> The beginning of the URI is different here so they're going to have to
>>> specify absolute URIs for these services, like
>>> http://intranet.mycompany.com/accounting for example.
>>>
>>> They can also do it the other way around, use a base URI for all the
>>> internal services, and specific absolute URIs for the service URIs
>>> published to the outside world, which is actually probably better.
>>>
>>> 2. Bigbank.com is a big bank, with multiple divisions, and multiple
>>> administration domains. The bank is the result of a merger of 3
>>> companies, a banking, a mortgage and an investment company, and for the
>>> next few years the administration domains are going to stay separate to
>>> keep people happy.
>>>
>>> The three admin domains are going to use three different URIs:
>>> http://www.bigbank.com/banking
>>> http://www.bigbank.com/loans
>>> http://www.bigbank.com/invest
>>>
>>> In our big bank each domain consists of the description of about 150
>>> services, running on 10 different servers and service containers of
>>> various kinds, all at different IP addresses and port numbers obviously.
>>>
>>> So there's a little gap here between the http://www.bigbank.com/banking
>>> domain base URI, which is supposed to be the default base for the whole
>>> domain, and the http://192.168.1.2:8080 URL of one of the 10 servers :)
>>>
>>> In my view, the domain base URI mechanism is interesting, but it's not
>>> meant to bind a Web service under "http://192.168.1.2:8080/war context
>>> root in Tomcat" or configure the default port number of a Tuscany node
>>> running on localhost.
>>>
>>> Sorry for such a long email (as I hate long emails too) but we've been
>>> turning around this mysterious domain base URI for a while now so it's
>>> about time to try to clarify how it is meant to be used. Hopefully this
>>> will help fuel a discussion to clarify it.
>>>
>>> I'd be interested in the views of people more involved in the spec on
>>> this, in particular on whether the use cases I just described make sense
>>> to them or not :)
>> One more thing :) I forgot to add that there's also the possibility that
>> we conclude that this base domain URI mechanism is not really useful, as
>> in the real world, except for the internet domain name part of the URI,
>> I'm not sure that it's so simple or realistic to bind all your services
>> to a common base URI scheme...
>>
>> Thoughts? opinions? clarifications?
>>
>
> But what is the alternative?
>
> When running in containers like Tomcat or Geronimo we can only use the
> container base URI.
>
> Various places in section 1.7.2 of the assembly spec use a base URI (eg
> lines 2377 and 2382).
>
> So whats the problem with using the Tomcat/Geronimo container base URI as
> desacribed in 1.7.2 and also changing our other runtimes to also have one
> and work the same consistent way?
>
> ..ant
>
I thought that the scenarios I described earlier helped describe the
problem, which boils down to:
domain != node
so domain URI != node URI
trying to make them equal is just wrong, and will break as soon as
there's 2 nodes in a domain.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: What is this base domain URI about? was: Selection of default service URIs based on URIs from the composite
Posted by ant elder <an...@gmail.com>.
On Nov 30, 2007 9:06 PM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> Jean-Sebastien Delfino wrote:
> > ant elder wrote:
> >> On Nov 30, 2007 5:19 PM, Jean-Sebastien Delfino <js...@apache.org>
> >> wrote:
> >>
> >>> ant elder wrote:
> >>>> On Nov 30, 2007 1:52 PM, Simon Laws <si...@googlemail.com>
> wrote:
> >>>>
> >>>>> We have discussed this behaviour before and I was sort of convinced
> >>> last
> >>>>> time but now I'm playing with the store sample I'm not so sure. This
> >>>>> features comes about because of the store composite, for example,
> >>>>>
> >>>>> <component name="Store">
> >>>>> <t:implementation.widget location="uiservices/store.html"/>
> >>>>> <service name="Widget">
> >>>>> <t:binding.http uri="http://localhost:8101/ui"/>
> >>>>> </service>
> >>>>> <reference name="catalog" target="Catalog">
> >>>>> <t:binding.jsonrpc/>
> >>>>> </reference>
> >>>>> <reference name="shoppingCart" target="ShoppingCart/Cart">
> >>>>> <t:binding.atom/>
> >>>>> </reference>
> >>>>> <reference name="shoppingTotal" target="ShoppingCart/Total">
> >>>>> <t:binding.jsonrpc/>
> >>>>> </reference>
> >>>>> </component>
> >>>>>
> >>>>> To keep the composite tidy many of the URIs are omitted and they
> rely
> >>> on
> >>>>> the
> >>>>> default value. However the URI for one of the bindings is provided
> so
> >>> that
> >>>>> the node will detect this and use this as the default for all
> service
> >>>>> bindings (where this kind of URI is applicable). All the bindings
> must
> >>> be
> >>>>> the same here as store.html relies on the services being accessible
> >>> from
> >>>>> the
> >>>>> same root.
> >>>>>
> >>>>> There are several places that the default port for the servlet host
> >>> comes
> >>>>> from when setting up the SCA runtime.
> >>>>>
> >>>>> 1. The web app container. In this case no matter how you configure
> SCA
> >>> you
> >>>>> will get whatever the web app container gives you
> >>>>> 2. Node URI. This is used to tell what endpoints SCA should use by
> >>> default
> >>>>> and also as a unique ID for the node. When running inside a web app
> >>> this
> >>>>> must be the host/port you expect the web app to expose your services
> >>> on.
> >>>>> Otherwise SCA can't tell what values the web app container is going
> to
> >>> use
> >>>>> and hence can't register services with the domain. In the case that
> >>>>> SCA
> >>>>> starts Tomcat/Jetty itself then the Node URI is just the default
> value
> >>>>> that
> >>>>> will be used if a URI is not provided explicitly on a binding.
> >>>>> 3. Binding uri attribute. If SCA is running inside a web app
> container
> >>>>> this
> >>>>> value is ignored and Node URI is used (see 2). If SCA has started
> >>>>> Tomcat/Jetty itself this value will be used to configure the
> endpoint
> >>> of
> >>>>> the
> >>>>> service. If no value is provided then the default value is used
> >>>>> (see 1
> >>>>> and
> >>>>> 2).
> >>>>>
> >>>>> So what's the drawback of using
> >>>>>
> >>>>> <component name="Store">
> >>>>> <t:implementation.widget location="uiservices/store.html"/>
> >>>>> <service name="Widget">
> >>>>> <t:binding.http uri="/ui"/>
> >>>>> </service>
> >>>>> <reference name="catalog" target="Catalog">
> >>>>> <t:binding.jsonrpc/>
> >>>>> </reference>
> >>>>> <reference name="shoppingCart" target="ShoppingCart/Cart">
> >>>>> <t:binding.atom/>
> >>>>> </reference>
> >>>>> <reference name="shoppingTotal" target="ShoppingCart/Total">
> >>>>> <t:binding.jsonrpc/>
> >>>>> </reference>
> >>>>> </component>
> >>>>>
> >>>>> And setting Node URI = http://localhost:8101
> >>>>>
> >>>>> I'm uncomfortable about the current feature because I could easily
> >>> include
> >>>>> a
> >>>>> component in front of the existing component, e.g.
> >>>>>
> >>>>> <component name"SomeComponent"
> >>>>> <implementation .../>
> >>>>> <service name="SomeService">
> >>>>> <binding.ws url="http://localhost:8100/SomeService"/>
> >>>>> </service>
> >>>>> </component>
> >>>>>
> >>>>>
> >>>>> <component name="Store">
> >>>>> <t:implementation.widget location="uiservices/store.html"/>
> >>>>> <service name="Widget">
> >>>>> <t:binding.http uri="http://localhost:8101/ui"/>
> >>>>> </service>
> >>>>> <reference name="catalog" target="Catalog">
> >>>>> <t:binding.jsonrpc/>
> >>>>> </reference>
> >>>>> <reference name="shoppingCart" target="ShoppingCart/Cart">
> >>>>> <t:binding.atom/>
> >>>>> </reference>
> >>>>> <reference name="shoppingTotal" target="ShoppingCart/Total">
> >>>>> <t:binding.jsonrpc/>
> >>>>> </reference>
> >>>>> </component>
> >>>>>
> >>>>> And mess it up as now the majority services in the composite are at
> >>> 8100
> >>>>> and
> >>>>> not 8101 where store.html expects them to be.
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>> Simon
> >>>>>
> >>>> I agree. We've never come up with a very consistent story about
> default
> >>> URLs
> >>>> that works well everywhere, would be great if we could as its always
> >>> causing
> >>>> problems with getting all the runtimes and nodes and service
> endpoints
> >>>> working consistently everywhere.
> >>>>
> >>>> Can we change so that the ServletHost implementation controls the
> >>> default
> >>>> base URL and have everything tries to use relative URLs with that?
> >>>>
> >>>> ...ant
> >>>>
> >>> IMHO the URI info should come from an SCA composite. Any departure
> from
> >>> that will lead to the definition of a new configuration model for
> these
> >>> things, stranger to SCA.
> >>>
> >>
> >> Could you explain this a bit more?
> >>
> >> Would that mean composites MUST include an absolute URI as in the
> >> example at
> >> the start of this thread?
> >>
> >> How does that relate to line 2357 of the assembly spec that says "An
> SCA
> >> domain should define a base URI for each 2358 hierarchical URI scheme
> on
> >> which it intends to provide services."?
> >>
> >> ...ant
> >>
> >
> > Line 2357 is interesting. Let me try to describe (with two use cases)
> > how I envision that domain base URI being used.
> >
> > 1. Mycompany.com is a medium size business and has defined one SCA
> > domain (an SCA domain being a domain of administration, and the company
> > is not big, they have one administrator managing one SCA domain).
> >
> > Mycompany sells stuff online and offers Catalog and Shoppingcart
> > services at http://www.mycompany.com.
> >
> > To not have to repeat in all their service URIs http://www.company.com,
> > they configure the domain base URI to http://www.company.com, and
> > configure their service URIs to "catalog" and "shopping". The effective
> > service URIs become http://www.mycompany.com/catalog and
> > http://www.mycompany.com/shopping.
> >
> > Now the company also has internal services not exposed to the external
> > world, like their accounting department for example on
> > intranet.mycompany.com.
> >
> > The beginning of the URI is different here so they're going to have to
> > specify absolute URIs for these services, like
> > http://intranet.mycompany.com/accounting for example.
> >
> > They can also do it the other way around, use a base URI for all the
> > internal services, and specific absolute URIs for the service URIs
> > published to the outside world, which is actually probably better.
> >
> > 2. Bigbank.com is a big bank, with multiple divisions, and multiple
> > administration domains. The bank is the result of a merger of 3
> > companies, a banking, a mortgage and an investment company, and for the
> > next few years the administration domains are going to stay separate to
> > keep people happy.
> >
> > The three admin domains are going to use three different URIs:
> > http://www.bigbank.com/banking
> > http://www.bigbank.com/loans
> > http://www.bigbank.com/invest
> >
> > In our big bank each domain consists of the description of about 150
> > services, running on 10 different servers and service containers of
> > various kinds, all at different IP addresses and port numbers obviously.
> >
> > So there's a little gap here between the http://www.bigbank.com/banking
> > domain base URI, which is supposed to be the default base for the whole
> > domain, and the http://192.168.1.2:8080 URL of one of the 10 servers :)
> >
> > In my view, the domain base URI mechanism is interesting, but it's not
> > meant to bind a Web service under "http://192.168.1.2:8080/war context
> > root in Tomcat" or configure the default port number of a Tuscany node
> > running on localhost.
> >
> > Sorry for such a long email (as I hate long emails too) but we've been
> > turning around this mysterious domain base URI for a while now so it's
> > about time to try to clarify how it is meant to be used. Hopefully this
> > will help fuel a discussion to clarify it.
> >
> > I'd be interested in the views of people more involved in the spec on
> > this, in particular on whether the use cases I just described make sense
> > to them or not :)
>
> One more thing :) I forgot to add that there's also the possibility that
> we conclude that this base domain URI mechanism is not really useful, as
> in the real world, except for the internet domain name part of the URI,
> I'm not sure that it's so simple or realistic to bind all your services
> to a common base URI scheme...
>
> Thoughts? opinions? clarifications?
>
But what is the alternative?
When running in containers like Tomcat or Geronimo we can only use the
container base URI.
Various places in section 1.7.2 of the assembly spec use a base URI (eg
lines 2377 and 2382).
So whats the problem with using the Tomcat/Geronimo container base URI as
desacribed in 1.7.2 and also changing our other runtimes to also have one
and work the same consistent way?
..ant
Re: What is this base domain URI about? was: Selection of default
service URIs based on URIs from the composite
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> ant elder wrote:
>> On Nov 30, 2007 5:19 PM, Jean-Sebastien Delfino <js...@apache.org>
>> wrote:
>>
>>> ant elder wrote:
>>>> On Nov 30, 2007 1:52 PM, Simon Laws <si...@googlemail.com> wrote:
>>>>
>>>>> We have discussed this behaviour before and I was sort of convinced
>>> last
>>>>> time but now I'm playing with the store sample I'm not so sure. This
>>>>> features comes about because of the store composite, for example,
>>>>>
>>>>> <component name="Store">
>>>>> <t:implementation.widget location="uiservices/store.html"/>
>>>>> <service name="Widget">
>>>>> <t:binding.http uri="http://localhost:8101/ui"/>
>>>>> </service>
>>>>> <reference name="catalog" target="Catalog">
>>>>> <t:binding.jsonrpc/>
>>>>> </reference>
>>>>> <reference name="shoppingCart" target="ShoppingCart/Cart">
>>>>> <t:binding.atom/>
>>>>> </reference>
>>>>> <reference name="shoppingTotal" target="ShoppingCart/Total">
>>>>> <t:binding.jsonrpc/>
>>>>> </reference>
>>>>> </component>
>>>>>
>>>>> To keep the composite tidy many of the URIs are omitted and they rely
>>> on
>>>>> the
>>>>> default value. However the URI for one of the bindings is provided so
>>> that
>>>>> the node will detect this and use this as the default for all service
>>>>> bindings (where this kind of URI is applicable). All the bindings must
>>> be
>>>>> the same here as store.html relies on the services being accessible
>>> from
>>>>> the
>>>>> same root.
>>>>>
>>>>> There are several places that the default port for the servlet host
>>> comes
>>>>> from when setting up the SCA runtime.
>>>>>
>>>>> 1. The web app container. In this case no matter how you configure SCA
>>> you
>>>>> will get whatever the web app container gives you
>>>>> 2. Node URI. This is used to tell what endpoints SCA should use by
>>> default
>>>>> and also as a unique ID for the node. When running inside a web app
>>> this
>>>>> must be the host/port you expect the web app to expose your services
>>> on.
>>>>> Otherwise SCA can't tell what values the web app container is going to
>>> use
>>>>> and hence can't register services with the domain. In the case that
>>>>> SCA
>>>>> starts Tomcat/Jetty itself then the Node URI is just the default value
>>>>> that
>>>>> will be used if a URI is not provided explicitly on a binding.
>>>>> 3. Binding uri attribute. If SCA is running inside a web app container
>>>>> this
>>>>> value is ignored and Node URI is used (see 2). If SCA has started
>>>>> Tomcat/Jetty itself this value will be used to configure the endpoint
>>> of
>>>>> the
>>>>> service. If no value is provided then the default value is used
>>>>> (see 1
>>>>> and
>>>>> 2).
>>>>>
>>>>> So what's the drawback of using
>>>>>
>>>>> <component name="Store">
>>>>> <t:implementation.widget location="uiservices/store.html"/>
>>>>> <service name="Widget">
>>>>> <t:binding.http uri="/ui"/>
>>>>> </service>
>>>>> <reference name="catalog" target="Catalog">
>>>>> <t:binding.jsonrpc/>
>>>>> </reference>
>>>>> <reference name="shoppingCart" target="ShoppingCart/Cart">
>>>>> <t:binding.atom/>
>>>>> </reference>
>>>>> <reference name="shoppingTotal" target="ShoppingCart/Total">
>>>>> <t:binding.jsonrpc/>
>>>>> </reference>
>>>>> </component>
>>>>>
>>>>> And setting Node URI = http://localhost:8101
>>>>>
>>>>> I'm uncomfortable about the current feature because I could easily
>>> include
>>>>> a
>>>>> component in front of the existing component, e.g.
>>>>>
>>>>> <component name"SomeComponent"
>>>>> <implementation .../>
>>>>> <service name="SomeService">
>>>>> <binding.ws url="http://localhost:8100/SomeService"/>
>>>>> </service>
>>>>> </component>
>>>>>
>>>>>
>>>>> <component name="Store">
>>>>> <t:implementation.widget location="uiservices/store.html"/>
>>>>> <service name="Widget">
>>>>> <t:binding.http uri="http://localhost:8101/ui"/>
>>>>> </service>
>>>>> <reference name="catalog" target="Catalog">
>>>>> <t:binding.jsonrpc/>
>>>>> </reference>
>>>>> <reference name="shoppingCart" target="ShoppingCart/Cart">
>>>>> <t:binding.atom/>
>>>>> </reference>
>>>>> <reference name="shoppingTotal" target="ShoppingCart/Total">
>>>>> <t:binding.jsonrpc/>
>>>>> </reference>
>>>>> </component>
>>>>>
>>>>> And mess it up as now the majority services in the composite are at
>>> 8100
>>>>> and
>>>>> not 8101 where store.html expects them to be.
>>>>>
>>>>> Regards
>>>>>
>>>>> Simon
>>>>>
>>>> I agree. We've never come up with a very consistent story about default
>>> URLs
>>>> that works well everywhere, would be great if we could as its always
>>> causing
>>>> problems with getting all the runtimes and nodes and service endpoints
>>>> working consistently everywhere.
>>>>
>>>> Can we change so that the ServletHost implementation controls the
>>> default
>>>> base URL and have everything tries to use relative URLs with that?
>>>>
>>>> ...ant
>>>>
>>> IMHO the URI info should come from an SCA composite. Any departure from
>>> that will lead to the definition of a new configuration model for these
>>> things, stranger to SCA.
>>>
>>
>> Could you explain this a bit more?
>>
>> Would that mean composites MUST include an absolute URI as in the
>> example at
>> the start of this thread?
>>
>> How does that relate to line 2357 of the assembly spec that says "An SCA
>> domain should define a base URI for each 2358 hierarchical URI scheme on
>> which it intends to provide services."?
>>
>> ...ant
>>
>
> Line 2357 is interesting. Let me try to describe (with two use cases)
> how I envision that domain base URI being used.
>
> 1. Mycompany.com is a medium size business and has defined one SCA
> domain (an SCA domain being a domain of administration, and the company
> is not big, they have one administrator managing one SCA domain).
>
> Mycompany sells stuff online and offers Catalog and Shoppingcart
> services at http://www.mycompany.com.
>
> To not have to repeat in all their service URIs http://www.company.com,
> they configure the domain base URI to http://www.company.com, and
> configure their service URIs to "catalog" and "shopping". The effective
> service URIs become http://www.mycompany.com/catalog and
> http://www.mycompany.com/shopping.
>
> Now the company also has internal services not exposed to the external
> world, like their accounting department for example on
> intranet.mycompany.com.
>
> The beginning of the URI is different here so they're going to have to
> specify absolute URIs for these services, like
> http://intranet.mycompany.com/accounting for example.
>
> They can also do it the other way around, use a base URI for all the
> internal services, and specific absolute URIs for the service URIs
> published to the outside world, which is actually probably better.
>
> 2. Bigbank.com is a big bank, with multiple divisions, and multiple
> administration domains. The bank is the result of a merger of 3
> companies, a banking, a mortgage and an investment company, and for the
> next few years the administration domains are going to stay separate to
> keep people happy.
>
> The three admin domains are going to use three different URIs:
> http://www.bigbank.com/banking
> http://www.bigbank.com/loans
> http://www.bigbank.com/invest
>
> In our big bank each domain consists of the description of about 150
> services, running on 10 different servers and service containers of
> various kinds, all at different IP addresses and port numbers obviously.
>
> So there's a little gap here between the http://www.bigbank.com/banking
> domain base URI, which is supposed to be the default base for the whole
> domain, and the http://192.168.1.2:8080 URL of one of the 10 servers :)
>
> In my view, the domain base URI mechanism is interesting, but it's not
> meant to bind a Web service under "http://192.168.1.2:8080/war context
> root in Tomcat" or configure the default port number of a Tuscany node
> running on localhost.
>
> Sorry for such a long email (as I hate long emails too) but we've been
> turning around this mysterious domain base URI for a while now so it's
> about time to try to clarify how it is meant to be used. Hopefully this
> will help fuel a discussion to clarify it.
>
> I'd be interested in the views of people more involved in the spec on
> this, in particular on whether the use cases I just described make sense
> to them or not :)
One more thing :) I forgot to add that there's also the possibility that
we conclude that this base domain URI mechanism is not really useful, as
in the real world, except for the internet domain name part of the URI,
I'm not sure that it's so simple or realistic to bind all your services
to a common base URI scheme...
Thoughts? opinions? clarifications?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
What is this base domain URI about? was: Selection of default service
URIs based on URIs from the composite
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On Nov 30, 2007 5:19 PM, Jean-Sebastien Delfino <js...@apache.org>
> wrote:
>
>> ant elder wrote:
>>> On Nov 30, 2007 1:52 PM, Simon Laws <si...@googlemail.com> wrote:
>>>
>>>> We have discussed this behaviour before and I was sort of convinced
>> last
>>>> time but now I'm playing with the store sample I'm not so sure. This
>>>> features comes about because of the store composite, for example,
>>>>
>>>> <component name="Store">
>>>> <t:implementation.widget location="uiservices/store.html"/>
>>>> <service name="Widget">
>>>> <t:binding.http uri="http://localhost:8101/ui"/>
>>>> </service>
>>>> <reference name="catalog" target="Catalog">
>>>> <t:binding.jsonrpc/>
>>>> </reference>
>>>> <reference name="shoppingCart" target="ShoppingCart/Cart">
>>>> <t:binding.atom/>
>>>> </reference>
>>>> <reference name="shoppingTotal" target="ShoppingCart/Total">
>>>> <t:binding.jsonrpc/>
>>>> </reference>
>>>> </component>
>>>>
>>>> To keep the composite tidy many of the URIs are omitted and they rely
>> on
>>>> the
>>>> default value. However the URI for one of the bindings is provided so
>> that
>>>> the node will detect this and use this as the default for all service
>>>> bindings (where this kind of URI is applicable). All the bindings must
>> be
>>>> the same here as store.html relies on the services being accessible
>> from
>>>> the
>>>> same root.
>>>>
>>>> There are several places that the default port for the servlet host
>> comes
>>>> from when setting up the SCA runtime.
>>>>
>>>> 1. The web app container. In this case no matter how you configure SCA
>> you
>>>> will get whatever the web app container gives you
>>>> 2. Node URI. This is used to tell what endpoints SCA should use by
>> default
>>>> and also as a unique ID for the node. When running inside a web app
>> this
>>>> must be the host/port you expect the web app to expose your services
>> on.
>>>> Otherwise SCA can't tell what values the web app container is going to
>> use
>>>> and hence can't register services with the domain. In the case that SCA
>>>> starts Tomcat/Jetty itself then the Node URI is just the default value
>>>> that
>>>> will be used if a URI is not provided explicitly on a binding.
>>>> 3. Binding uri attribute. If SCA is running inside a web app container
>>>> this
>>>> value is ignored and Node URI is used (see 2). If SCA has started
>>>> Tomcat/Jetty itself this value will be used to configure the endpoint
>> of
>>>> the
>>>> service. If no value is provided then the default value is used (see 1
>>>> and
>>>> 2).
>>>>
>>>> So what's the drawback of using
>>>>
>>>> <component name="Store">
>>>> <t:implementation.widget location="uiservices/store.html"/>
>>>> <service name="Widget">
>>>> <t:binding.http uri="/ui"/>
>>>> </service>
>>>> <reference name="catalog" target="Catalog">
>>>> <t:binding.jsonrpc/>
>>>> </reference>
>>>> <reference name="shoppingCart" target="ShoppingCart/Cart">
>>>> <t:binding.atom/>
>>>> </reference>
>>>> <reference name="shoppingTotal" target="ShoppingCart/Total">
>>>> <t:binding.jsonrpc/>
>>>> </reference>
>>>> </component>
>>>>
>>>> And setting Node URI = http://localhost:8101
>>>>
>>>> I'm uncomfortable about the current feature because I could easily
>> include
>>>> a
>>>> component in front of the existing component, e.g.
>>>>
>>>> <component name"SomeComponent"
>>>> <implementation .../>
>>>> <service name="SomeService">
>>>> <binding.ws url="http://localhost:8100/SomeService"/>
>>>> </service>
>>>> </component>
>>>>
>>>>
>>>> <component name="Store">
>>>> <t:implementation.widget location="uiservices/store.html"/>
>>>> <service name="Widget">
>>>> <t:binding.http uri="http://localhost:8101/ui"/>
>>>> </service>
>>>> <reference name="catalog" target="Catalog">
>>>> <t:binding.jsonrpc/>
>>>> </reference>
>>>> <reference name="shoppingCart" target="ShoppingCart/Cart">
>>>> <t:binding.atom/>
>>>> </reference>
>>>> <reference name="shoppingTotal" target="ShoppingCart/Total">
>>>> <t:binding.jsonrpc/>
>>>> </reference>
>>>> </component>
>>>>
>>>> And mess it up as now the majority services in the composite are at
>> 8100
>>>> and
>>>> not 8101 where store.html expects them to be.
>>>>
>>>> Regards
>>>>
>>>> Simon
>>>>
>>> I agree. We've never come up with a very consistent story about default
>> URLs
>>> that works well everywhere, would be great if we could as its always
>> causing
>>> problems with getting all the runtimes and nodes and service endpoints
>>> working consistently everywhere.
>>>
>>> Can we change so that the ServletHost implementation controls the
>> default
>>> base URL and have everything tries to use relative URLs with that?
>>>
>>> ...ant
>>>
>> IMHO the URI info should come from an SCA composite. Any departure from
>> that will lead to the definition of a new configuration model for these
>> things, stranger to SCA.
>>
>
> Could you explain this a bit more?
>
> Would that mean composites MUST include an absolute URI as in the example at
> the start of this thread?
>
> How does that relate to line 2357 of the assembly spec that says "An SCA
> domain should define a base URI for each 2358 hierarchical URI scheme on
> which it intends to provide services."?
>
> ...ant
>
Line 2357 is interesting. Let me try to describe (with two use cases)
how I envision that domain base URI being used.
1. Mycompany.com is a medium size business and has defined one SCA
domain (an SCA domain being a domain of administration, and the company
is not big, they have one administrator managing one SCA domain).
Mycompany sells stuff online and offers Catalog and Shoppingcart
services at http://www.mycompany.com.
To not have to repeat in all their service URIs http://www.company.com,
they configure the domain base URI to http://www.company.com, and
configure their service URIs to "catalog" and "shopping". The effective
service URIs become http://www.mycompany.com/catalog and
http://www.mycompany.com/shopping.
Now the company also has internal services not exposed to the external
world, like their accounting department for example on
intranet.mycompany.com.
The beginning of the URI is different here so they're going to have to
specify absolute URIs for these services, like
http://intranet.mycompany.com/accounting for example.
They can also do it the other way around, use a base URI for all the
internal services, and specific absolute URIs for the service URIs
published to the outside world, which is actually probably better.
2. Bigbank.com is a big bank, with multiple divisions, and multiple
administration domains. The bank is the result of a merger of 3
companies, a banking, a mortgage and an investment company, and for the
next few years the administration domains are going to stay separate to
keep people happy.
The three admin domains are going to use three different URIs:
http://www.bigbank.com/banking
http://www.bigbank.com/loans
http://www.bigbank.com/invest
In our big bank each domain consists of the description of about 150
services, running on 10 different servers and service containers of
various kinds, all at different IP addresses and port numbers obviously.
So there's a little gap here between the http://www.bigbank.com/banking
domain base URI, which is supposed to be the default base for the whole
domain, and the http://192.168.1.2:8080 URL of one of the 10 servers :)
In my view, the domain base URI mechanism is interesting, but it's not
meant to bind a Web service under "http://192.168.1.2:8080/war context
root in Tomcat" or configure the default port number of a Tuscany node
running on localhost.
Sorry for such a long email (as I hate long emails too) but we've been
turning around this mysterious domain base URI for a while now so it's
about time to try to clarify how it is meant to be used. Hopefully this
will help fuel a discussion to clarify it.
I'd be interested in the views of people more involved in the spec on
this, in particular on whether the use cases I just described make sense
to them or not :)
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Selection of default service URIs based on URIs from the composite
Posted by ant elder <an...@gmail.com>.
On Nov 30, 2007 5:19 PM, Jean-Sebastien Delfino <js...@apache.org>
wrote:
> ant elder wrote:
> > On Nov 30, 2007 1:52 PM, Simon Laws <si...@googlemail.com> wrote:
> >
> >> We have discussed this behaviour before and I was sort of convinced
> last
> >> time but now I'm playing with the store sample I'm not so sure. This
> >> features comes about because of the store composite, for example,
> >>
> >> <component name="Store">
> >> <t:implementation.widget location="uiservices/store.html"/>
> >> <service name="Widget">
> >> <t:binding.http uri="http://localhost:8101/ui"/>
> >> </service>
> >> <reference name="catalog" target="Catalog">
> >> <t:binding.jsonrpc/>
> >> </reference>
> >> <reference name="shoppingCart" target="ShoppingCart/Cart">
> >> <t:binding.atom/>
> >> </reference>
> >> <reference name="shoppingTotal" target="ShoppingCart/Total">
> >> <t:binding.jsonrpc/>
> >> </reference>
> >> </component>
> >>
> >> To keep the composite tidy many of the URIs are omitted and they rely
> on
> >> the
> >> default value. However the URI for one of the bindings is provided so
> that
> >> the node will detect this and use this as the default for all service
> >> bindings (where this kind of URI is applicable). All the bindings must
> be
> >> the same here as store.html relies on the services being accessible
> from
> >> the
> >> same root.
> >>
> >> There are several places that the default port for the servlet host
> comes
> >> from when setting up the SCA runtime.
> >>
> >> 1. The web app container. In this case no matter how you configure SCA
> you
> >> will get whatever the web app container gives you
> >> 2. Node URI. This is used to tell what endpoints SCA should use by
> default
> >> and also as a unique ID for the node. When running inside a web app
> this
> >> must be the host/port you expect the web app to expose your services
> on.
> >> Otherwise SCA can't tell what values the web app container is going to
> use
> >> and hence can't register services with the domain. In the case that SCA
> >> starts Tomcat/Jetty itself then the Node URI is just the default value
> >> that
> >> will be used if a URI is not provided explicitly on a binding.
> >> 3. Binding uri attribute. If SCA is running inside a web app container
> >> this
> >> value is ignored and Node URI is used (see 2). If SCA has started
> >> Tomcat/Jetty itself this value will be used to configure the endpoint
> of
> >> the
> >> service. If no value is provided then the default value is used (see 1
> >> and
> >> 2).
> >>
> >> So what's the drawback of using
> >>
> >> <component name="Store">
> >> <t:implementation.widget location="uiservices/store.html"/>
> >> <service name="Widget">
> >> <t:binding.http uri="/ui"/>
> >> </service>
> >> <reference name="catalog" target="Catalog">
> >> <t:binding.jsonrpc/>
> >> </reference>
> >> <reference name="shoppingCart" target="ShoppingCart/Cart">
> >> <t:binding.atom/>
> >> </reference>
> >> <reference name="shoppingTotal" target="ShoppingCart/Total">
> >> <t:binding.jsonrpc/>
> >> </reference>
> >> </component>
> >>
> >> And setting Node URI = http://localhost:8101
> >>
> >> I'm uncomfortable about the current feature because I could easily
> include
> >> a
> >> component in front of the existing component, e.g.
> >>
> >> <component name"SomeComponent"
> >> <implementation .../>
> >> <service name="SomeService">
> >> <binding.ws url="http://localhost:8100/SomeService"/>
> >> </service>
> >> </component>
> >>
> >>
> >> <component name="Store">
> >> <t:implementation.widget location="uiservices/store.html"/>
> >> <service name="Widget">
> >> <t:binding.http uri="http://localhost:8101/ui"/>
> >> </service>
> >> <reference name="catalog" target="Catalog">
> >> <t:binding.jsonrpc/>
> >> </reference>
> >> <reference name="shoppingCart" target="ShoppingCart/Cart">
> >> <t:binding.atom/>
> >> </reference>
> >> <reference name="shoppingTotal" target="ShoppingCart/Total">
> >> <t:binding.jsonrpc/>
> >> </reference>
> >> </component>
> >>
> >> And mess it up as now the majority services in the composite are at
> 8100
> >> and
> >> not 8101 where store.html expects them to be.
> >>
> >> Regards
> >>
> >> Simon
> >>
> >
> > I agree. We've never come up with a very consistent story about default
> URLs
> > that works well everywhere, would be great if we could as its always
> causing
> > problems with getting all the runtimes and nodes and service endpoints
> > working consistently everywhere.
> >
> > Can we change so that the ServletHost implementation controls the
> default
> > base URL and have everything tries to use relative URLs with that?
> >
> > ...ant
> >
>
> IMHO the URI info should come from an SCA composite. Any departure from
> that will lead to the definition of a new configuration model for these
> things, stranger to SCA.
>
Could you explain this a bit more?
Would that mean composites MUST include an absolute URI as in the example at
the start of this thread?
How does that relate to line 2357 of the assembly spec that says "An SCA
domain should define a base URI for each 2358 hierarchical URI scheme on
which it intends to provide services."?
...ant
Re: Selection of default service URIs based on URIs from the composite
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On Nov 30, 2007 1:52 PM, Simon Laws <si...@googlemail.com> wrote:
>
>> We have discussed this behaviour before and I was sort of convinced last
>> time but now I'm playing with the store sample I'm not so sure. This
>> features comes about because of the store composite, for example,
>>
>> <component name="Store">
>> <t:implementation.widget location="uiservices/store.html"/>
>> <service name="Widget">
>> <t:binding.http uri="http://localhost:8101/ui"/>
>> </service>
>> <reference name="catalog" target="Catalog">
>> <t:binding.jsonrpc/>
>> </reference>
>> <reference name="shoppingCart" target="ShoppingCart/Cart">
>> <t:binding.atom/>
>> </reference>
>> <reference name="shoppingTotal" target="ShoppingCart/Total">
>> <t:binding.jsonrpc/>
>> </reference>
>> </component>
>>
>> To keep the composite tidy many of the URIs are omitted and they rely on
>> the
>> default value. However the URI for one of the bindings is provided so that
>> the node will detect this and use this as the default for all service
>> bindings (where this kind of URI is applicable). All the bindings must be
>> the same here as store.html relies on the services being accessible from
>> the
>> same root.
>>
>> There are several places that the default port for the servlet host comes
>> from when setting up the SCA runtime.
>>
>> 1. The web app container. In this case no matter how you configure SCA you
>> will get whatever the web app container gives you
>> 2. Node URI. This is used to tell what endpoints SCA should use by default
>> and also as a unique ID for the node. When running inside a web app this
>> must be the host/port you expect the web app to expose your services on.
>> Otherwise SCA can't tell what values the web app container is going to use
>> and hence can't register services with the domain. In the case that SCA
>> starts Tomcat/Jetty itself then the Node URI is just the default value
>> that
>> will be used if a URI is not provided explicitly on a binding.
>> 3. Binding uri attribute. If SCA is running inside a web app container
>> this
>> value is ignored and Node URI is used (see 2). If SCA has started
>> Tomcat/Jetty itself this value will be used to configure the endpoint of
>> the
>> service. If no value is provided then the default value is used (see 1
>> and
>> 2).
>>
>> So what's the drawback of using
>>
>> <component name="Store">
>> <t:implementation.widget location="uiservices/store.html"/>
>> <service name="Widget">
>> <t:binding.http uri="/ui"/>
>> </service>
>> <reference name="catalog" target="Catalog">
>> <t:binding.jsonrpc/>
>> </reference>
>> <reference name="shoppingCart" target="ShoppingCart/Cart">
>> <t:binding.atom/>
>> </reference>
>> <reference name="shoppingTotal" target="ShoppingCart/Total">
>> <t:binding.jsonrpc/>
>> </reference>
>> </component>
>>
>> And setting Node URI = http://localhost:8101
>>
>> I'm uncomfortable about the current feature because I could easily include
>> a
>> component in front of the existing component, e.g.
>>
>> <component name"SomeComponent"
>> <implementation .../>
>> <service name="SomeService">
>> <binding.ws url="http://localhost:8100/SomeService"/>
>> </service>
>> </component>
>>
>>
>> <component name="Store">
>> <t:implementation.widget location="uiservices/store.html"/>
>> <service name="Widget">
>> <t:binding.http uri="http://localhost:8101/ui"/>
>> </service>
>> <reference name="catalog" target="Catalog">
>> <t:binding.jsonrpc/>
>> </reference>
>> <reference name="shoppingCart" target="ShoppingCart/Cart">
>> <t:binding.atom/>
>> </reference>
>> <reference name="shoppingTotal" target="ShoppingCart/Total">
>> <t:binding.jsonrpc/>
>> </reference>
>> </component>
>>
>> And mess it up as now the majority services in the composite are at 8100
>> and
>> not 8101 where store.html expects them to be.
>>
>> Regards
>>
>> Simon
>>
>
> I agree. We've never come up with a very consistent story about default URLs
> that works well everywhere, would be great if we could as its always causing
> problems with getting all the runtimes and nodes and service endpoints
> working consistently everywhere.
>
> Can we change so that the ServletHost implementation controls the default
> base URL and have everything tries to use relative URLs with that?
>
> ...ant
>
IMHO the URI info should come from an SCA composite. Any departure from
that will lead to the definition of a new configuration model for these
things, stranger to SCA.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Selection of default service URIs based on URIs from the composite
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On Nov 30, 2007 4:44 PM, Simon Laws <si...@googlemail.com> wrote:
>
>>
>> On Nov 30, 2007 4:38 PM, ant elder <an...@apache.org> wrote:
>>
>>> On Nov 30, 2007 2:46 PM, Simon Laws <si...@googlemail.com> wrote:
>>>
>>>> On Nov 30, 2007 2:09 PM, ant elder < ant.elder@gmail.com> wrote:
>>>>
>>>>> On Nov 30, 2007 1:52 PM, Simon Laws <si...@googlemail.com>
>>> wrote:
>>>>>> We have discussed this behaviour before and I was sort of
>>> convinced
>>>> last
>>>>>> time but now I'm playing with the store sample I'm not so sure.
>>> This
>>>>>> features comes about because of the store composite, for example,
>>>>>>
>>>>>> <component name="Store">
>>>>>> <t:implementation.widget location="uiservices/store.html"/>
>>>>>> <service name="Widget">
>>>>>> <t:binding.http uri=" http://localhost:8101/ui"/>
>>>>>> </service>
>>>>>> <reference name="catalog" target="Catalog">
>>>>>> <t:binding.jsonrpc/>
>>>>>> </reference>
>>>>>> <reference name="shoppingCart" target="ShoppingCart/Cart">
>>>>>> <t: binding.atom/>
>>>>>> </reference>
>>>>>> <reference name="shoppingTotal"
>>> target="ShoppingCart/Total">
>>>>>> <t:binding.jsonrpc />
>>>>>> </reference>
>>>>>> </component>
>>>>>>
>>>>>> To keep the composite tidy many of the URIs are omitted and they
>>> rely
>>>> on
>>>>>> the
>>>>>> default value. However the URI for one of the bindings is provided
>>> so
>>>>> that
>>>>>> the node will detect this and use this as the default for all
>>> service
>>>>>> bindings (where this kind of URI is applicable). All the bindings
>>> must
>>>>> be
>>>>>> the same here as store.html relies on the services being
>>> accessible
>>>> from
>>>>>> the
>>>>>> same root.
>>>>>>
>>>>>> There are several places that the default port for the servlet
>>> host
>>>>> comes
>>>>>> from when setting up the SCA runtime.
>>>>>>
>>>>>> 1. The web app container. In this case no matter how you configure
>>> SCA
>>>>> you
>>>>>> will get whatever the web app container gives you
>>>>>> 2. Node URI. This is used to tell what endpoints SCA should use by
>>>>> default
>>>>>> and also as a unique ID for the node. When running inside a web
>>> app
>>>> this
>>>>>> must be the host/port you expect the web app to expose your
>>> services
>>>> on.
>>>>>> Otherwise SCA can't tell what values the web app container is
>>> going to
>>>>> use
>>>>>> and hence can't register services with the domain. In the case
>>> that
>>>> SCA
>>>>>> starts Tomcat/Jetty itself then the Node URI is just the default
>>> value
>>>>>> that
>>>>>> will be used if a URI is not provided explicitly on a binding.
>>>>>> 3. Binding uri attribute. If SCA is running inside a web app
>>> container
>>>>>> this
>>>>>> value is ignored and Node URI is used (see 2). If SCA has started
>>>>>> Tomcat/Jetty itself this value will be used to configure the
>>> endpoint
>>>> of
>>>>>> the
>>>>>> service. If no value is provided then the default value is used
>>> (see
>>>> 1
>>>>>> and
>>>>>> 2).
>>>>>>
>>>>>> So what's the drawback of using
>>>>>>
>>>>>> <component name="Store">
>>>>>> <t:implementation.widget location="uiservices/store.html"/>
>>>>>> <service name="Widget">
>>>>>> <t:binding.http uri="/ui"/>
>>>>>> </service>
>>>>>> <reference name="catalog" target="Catalog">
>>>>>> <t: binding.jsonrpc/>
>>>>>> </reference>
>>>>>> <reference name="shoppingCart" target="ShoppingCart/Cart">
>>>>>> <t:binding.atom />
>>>>>> </reference>
>>>>>> <reference name="shoppingTotal"
>>> target="ShoppingCart/Total">
>>>>>> <t:binding.jsonrpc/>
>>>>>> </reference>
>>>>>> </component>
>>>>>>
>>>>>> And setting Node URI = http://localhost:8101
>>>>>>
>>>>>> I'm uncomfortable about the current feature because I could easily
>>>>> include
>>>>>> a
>>>>>> component in front of the existing component, e.g.
>>>>>>
>>>>>> <component name"SomeComponent"
>>>>>> <implementation .../>
>>>>>> <service name="SomeService">
>>>>>> < binding.ws url="http://localhost:8100/SomeService"/>
>>>>>> </service>
>>>>>> </component>
>>>>>>
>>>>>>
>>>>>> <component name="Store">
>>>>>> <t:implementation.widget location="uiservices/store.html"/>
>>>>>> <service name="Widget">
>>>>>> <t:binding.http uri="http://localhost:8101/ui"/>
>>>>>> </service>
>>>>>> <reference name="catalog" target="Catalog">
>>>>>> <t:binding.jsonrpc/>
>>>>>> </reference>
>>>>>> <reference name="shoppingCart" target="ShoppingCart/Cart">
>>>>>> <t: binding.atom/>
>>>>>> </reference>
>>>>>> <reference name="shoppingTotal"
>>> target="ShoppingCart/Total">
>>>>>> <t:binding.jsonrpc />
>>>>>> </reference>
>>>>>> </component>
>>>>>>
>>>>>> And mess it up as now the majority services in the composite are
>>> at
>>>> 8100
>>>>>> and
>>>>>> not 8101 where store.html expects them to be.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Simon
>>>>>>
>>>>> I agree. We've never come up with a very consistent story about
>>> default
>>>>> URLs
>>>>> that works well everywhere, would be great if we could as its always
>>>>> causing
>>>>> problems with getting all the runtimes and nodes and service
>>> endpoints
>>>>> working consistently everywhere.
>>>>>
>>>>> Can we change so that the ServletHost implementation controls the
>>>> default
>>>>> base URL and have everything tries to use relative URLs with that?
>>>>>
>>>>> ...ant
>>>>>
>>>> I think we can be relatively consistent using the three sources of
>>>> endpoint
>>>> information I put in the original mail.Now I think about it there is a
>>>> number 4 that I didn't include so the list would be.
>>>>
>>>> 1. The web app container. In this case no matter how you configure SCA
>>> you
>>>> will get whatever the web app container gives you
>>>> 2. Node URI. This is used to tell what endpoints SCA should use by
>>> default
>>>> and also as a unique ID for the node. When running inside a web app
>>> this
>>>> must be the host/port you expect the web app to expose your services
>>> on.
>>>> Otherwise SCA can't tell what values the web app container is going to
>>> use
>>>> and hence can't register services with the domain. In the case that
>>> SCA
>>>> starts Tomcat/Jetty itself then the Node URI is just the default value
>>>> that
>>>> will be used if a URI is not provided explicitly on a binding.
>>>> 3. Binding uri attribute. If SCA is running inside a web app container
>>>> this
>>>> value is ignored and Node URI is used (see 2). If SCA has started
>>>> Tomcat/Jetty itself this value will be used to configure the endpoint
>>> of
>>>> the
>>>> service. If no value is provided then the default value is used (see
>>> 1
>>>> and
>>>> 2).
>>>> 4. Free port. If not running inside a web app container and no Node
>>> URI is
>>>> provided then a free port is selected automatically as the default
>>> port
>>>> The default is set into the servlet host when the node starts and the
>>>> bindings which use servlet host tend to use the servlet host interface
>>> to
>>>> calculate their endpoint. So we are pretty close to what you suggest
>>> but
>>>> we
>>>> need to check that it is applied everywhere.
>>>>
>>>> I tried to represent the algorithm in psuedo code (
>>>>
>>>>
>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Binding+URI+Construction
>>>> )
>>>> is this correct?
>>>>
>>>> Simon
>>>>
>>> If (1) is made to be generic instead of webapp container specific, eg
>>> "the
>>> default from the ServletHost" then (4) could be dropped as it can be
>>> done by
>>> the ServletHost impl if it chooses as part of (1).
>>>
>>> I'm still not really clear why (2) must be an absolute URI instead of
>>> just a
>>> relative one (ie just the Node name) and be relative to the absolute URI
>>> from (1)? To me that seems simpler to understand and would then always
>>> work
>>> the same way no matter what the environment. I'm just trying to
>>> understand
>>> the options, I guess it doesn't make so much difference.
>>>
>> As a servlet running in a servlet container, for example, how do you get
>> the host and port on which you are running?
>>
>>>
>>> ...ant
>>
>
> The HttpServletRequest includes all that information i think.
>
> ...ant
>
Only on a request, not at startup.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Selection of default service URIs based on URIs from the composite
Posted by ant elder <an...@gmail.com>.
On Nov 30, 2007 4:44 PM, Simon Laws <si...@googlemail.com> wrote:
>
>
> On Nov 30, 2007 4:38 PM, ant elder <an...@apache.org> wrote:
>
> > On Nov 30, 2007 2:46 PM, Simon Laws <si...@googlemail.com> wrote:
> >
> > > On Nov 30, 2007 2:09 PM, ant elder < ant.elder@gmail.com> wrote:
> > >
> > > > On Nov 30, 2007 1:52 PM, Simon Laws <si...@googlemail.com>
> > wrote:
> > > >
> > > > > We have discussed this behaviour before and I was sort of
> > convinced
> > > last
> > > > > time but now I'm playing with the store sample I'm not so sure.
> > This
> > > > > features comes about because of the store composite, for example,
> > > > >
> > > > > <component name="Store">
> > > > > <t:implementation.widget location="uiservices/store.html"/>
> > > > > <service name="Widget">
> > > > > <t:binding.http uri=" http://localhost:8101/ui"/>
> > > > > </service>
> > > > > <reference name="catalog" target="Catalog">
> > > > > <t:binding.jsonrpc/>
> > > > > </reference>
> > > > > <reference name="shoppingCart" target="ShoppingCart/Cart">
> > > > > <t: binding.atom/>
> > > > > </reference>
> > > > > <reference name="shoppingTotal"
> > target="ShoppingCart/Total">
> > > > > <t:binding.jsonrpc />
> > > > > </reference>
> > > > > </component>
> > > > >
> > > > > To keep the composite tidy many of the URIs are omitted and they
> > rely
> > > on
> > > > > the
> > > > > default value. However the URI for one of the bindings is provided
> > so
> > > > that
> > > > > the node will detect this and use this as the default for all
> > service
> > > > > bindings (where this kind of URI is applicable). All the bindings
> > must
> > > > be
> > > > > the same here as store.html relies on the services being
> > accessible
> > > from
> > > > > the
> > > > > same root.
> > > > >
> > > > > There are several places that the default port for the servlet
> > host
> > > > comes
> > > > > from when setting up the SCA runtime.
> > > > >
> > > > > 1. The web app container. In this case no matter how you configure
> > SCA
> > > > you
> > > > > will get whatever the web app container gives you
> > > > > 2. Node URI. This is used to tell what endpoints SCA should use by
> > > > default
> > > > > and also as a unique ID for the node. When running inside a web
> > app
> > > this
> > > > > must be the host/port you expect the web app to expose your
> > services
> > > on.
> > > > > Otherwise SCA can't tell what values the web app container is
> > going to
> > > > use
> > > > > and hence can't register services with the domain. In the case
> > that
> > > SCA
> > > > > starts Tomcat/Jetty itself then the Node URI is just the default
> > value
> > > > > that
> > > > > will be used if a URI is not provided explicitly on a binding.
> > > > > 3. Binding uri attribute. If SCA is running inside a web app
> > container
> > > > > this
> > > > > value is ignored and Node URI is used (see 2). If SCA has started
> > > > > Tomcat/Jetty itself this value will be used to configure the
> > endpoint
> > > of
> > > > > the
> > > > > service. If no value is provided then the default value is used
> > (see
> > > 1
> > > > > and
> > > > > 2).
> > > > >
> > > > > So what's the drawback of using
> > > > >
> > > > > <component name="Store">
> > > > > <t:implementation.widget location="uiservices/store.html"/>
> > > > > <service name="Widget">
> > > > > <t:binding.http uri="/ui"/>
> > > > > </service>
> > > > > <reference name="catalog" target="Catalog">
> > > > > <t: binding.jsonrpc/>
> > > > > </reference>
> > > > > <reference name="shoppingCart" target="ShoppingCart/Cart">
> > > > > <t:binding.atom />
> > > > > </reference>
> > > > > <reference name="shoppingTotal"
> > target="ShoppingCart/Total">
> > > > > <t:binding.jsonrpc/>
> > > > > </reference>
> > > > > </component>
> > > > >
> > > > > And setting Node URI = http://localhost:8101
> > > > >
> > > > > I'm uncomfortable about the current feature because I could easily
> > > > include
> > > > > a
> > > > > component in front of the existing component, e.g.
> > > > >
> > > > > <component name"SomeComponent"
> > > > > <implementation .../>
> > > > > <service name="SomeService">
> > > > > < binding.ws url="http://localhost:8100/SomeService"/>
> > > > > </service>
> > > > > </component>
> > > > >
> > > > >
> > > > > <component name="Store">
> > > > > <t:implementation.widget location="uiservices/store.html"/>
> > > > > <service name="Widget">
> > > > > <t:binding.http uri="http://localhost:8101/ui"/>
> > > > > </service>
> > > > > <reference name="catalog" target="Catalog">
> > > > > <t:binding.jsonrpc/>
> > > > > </reference>
> > > > > <reference name="shoppingCart" target="ShoppingCart/Cart">
> > > > > <t: binding.atom/>
> > > > > </reference>
> > > > > <reference name="shoppingTotal"
> > target="ShoppingCart/Total">
> > > > > <t:binding.jsonrpc />
> > > > > </reference>
> > > > > </component>
> > > > >
> > > > > And mess it up as now the majority services in the composite are
> > at
> > > 8100
> > > > > and
> > > > > not 8101 where store.html expects them to be.
> > > > >
> > > > > Regards
> > > > >
> > > > > Simon
> > > > >
> > > >
> > > > I agree. We've never come up with a very consistent story about
> > default
> > > > URLs
> > > > that works well everywhere, would be great if we could as its always
> > > > causing
> > > > problems with getting all the runtimes and nodes and service
> > endpoints
> > > > working consistently everywhere.
> > > >
> > > > Can we change so that the ServletHost implementation controls the
> > > default
> > > > base URL and have everything tries to use relative URLs with that?
> > > >
> > > > ...ant
> > > >
> > > I think we can be relatively consistent using the three sources of
> > > endpoint
> > > information I put in the original mail.Now I think about it there is a
> > > number 4 that I didn't include so the list would be.
> > >
> > > 1. The web app container. In this case no matter how you configure SCA
> > you
> > > will get whatever the web app container gives you
> > > 2. Node URI. This is used to tell what endpoints SCA should use by
> > default
> > > and also as a unique ID for the node. When running inside a web app
> > this
> > > must be the host/port you expect the web app to expose your services
> > on.
> > > Otherwise SCA can't tell what values the web app container is going to
> > use
> > > and hence can't register services with the domain. In the case that
> > SCA
> > > starts Tomcat/Jetty itself then the Node URI is just the default value
> > > that
> > > will be used if a URI is not provided explicitly on a binding.
> > > 3. Binding uri attribute. If SCA is running inside a web app container
> > > this
> > > value is ignored and Node URI is used (see 2). If SCA has started
> > > Tomcat/Jetty itself this value will be used to configure the endpoint
> > of
> > > the
> > > service. If no value is provided then the default value is used (see
> > 1
> > > and
> > > 2).
> > > 4. Free port. If not running inside a web app container and no Node
> > URI is
> > > provided then a free port is selected automatically as the default
> > port
> > >
> > > The default is set into the servlet host when the node starts and the
> > > bindings which use servlet host tend to use the servlet host interface
> > to
> > > calculate their endpoint. So we are pretty close to what you suggest
> > but
> > > we
> > > need to check that it is applied everywhere.
> > >
> > > I tried to represent the algorithm in psuedo code (
> > >
> > >
> > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Binding+URI+Construction
> > > )
> > > is this correct?
> > >
> > > Simon
> > >
> >
> > If (1) is made to be generic instead of webapp container specific, eg
> > "the
> > default from the ServletHost" then (4) could be dropped as it can be
> > done by
> > the ServletHost impl if it chooses as part of (1).
> >
> > I'm still not really clear why (2) must be an absolute URI instead of
> > just a
> > relative one (ie just the Node name) and be relative to the absolute URI
> > from (1)? To me that seems simpler to understand and would then always
> > work
> > the same way no matter what the environment. I'm just trying to
> > understand
> > the options, I guess it doesn't make so much difference.
> >
> As a servlet running in a servlet container, for example, how do you get
> the host and port on which you are running?
>
> >
> >
> > ...ant
>
>
The HttpServletRequest includes all that information i think.
...ant
Re: Selection of default service URIs based on URIs from the composite
Posted by Simon Laws <si...@googlemail.com>.
On Nov 30, 2007 4:38 PM, ant elder <an...@apache.org> wrote:
> On Nov 30, 2007 2:46 PM, Simon Laws <si...@googlemail.com> wrote:
>
> > On Nov 30, 2007 2:09 PM, ant elder <an...@gmail.com> wrote:
> >
> > > On Nov 30, 2007 1:52 PM, Simon Laws <si...@googlemail.com> wrote:
> > >
> > > > We have discussed this behaviour before and I was sort of convinced
> > last
> > > > time but now I'm playing with the store sample I'm not so sure. This
> > > > features comes about because of the store composite, for example,
> > > >
> > > > <component name="Store">
> > > > <t:implementation.widget location="uiservices/store.html"/>
> > > > <service name="Widget">
> > > > <t:binding.http uri="http://localhost:8101/ui"/>
> > > > </service>
> > > > <reference name="catalog" target="Catalog">
> > > > <t:binding.jsonrpc/>
> > > > </reference>
> > > > <reference name="shoppingCart" target="ShoppingCart/Cart">
> > > > <t:binding.atom/>
> > > > </reference>
> > > > <reference name="shoppingTotal" target="ShoppingCart/Total">
> > > > <t:binding.jsonrpc/>
> > > > </reference>
> > > > </component>
> > > >
> > > > To keep the composite tidy many of the URIs are omitted and they
> rely
> > on
> > > > the
> > > > default value. However the URI for one of the bindings is provided
> so
> > > that
> > > > the node will detect this and use this as the default for all
> service
> > > > bindings (where this kind of URI is applicable). All the bindings
> must
> > > be
> > > > the same here as store.html relies on the services being accessible
> > from
> > > > the
> > > > same root.
> > > >
> > > > There are several places that the default port for the servlet host
> > > comes
> > > > from when setting up the SCA runtime.
> > > >
> > > > 1. The web app container. In this case no matter how you configure
> SCA
> > > you
> > > > will get whatever the web app container gives you
> > > > 2. Node URI. This is used to tell what endpoints SCA should use by
> > > default
> > > > and also as a unique ID for the node. When running inside a web app
> > this
> > > > must be the host/port you expect the web app to expose your services
> > on.
> > > > Otherwise SCA can't tell what values the web app container is going
> to
> > > use
> > > > and hence can't register services with the domain. In the case that
> > SCA
> > > > starts Tomcat/Jetty itself then the Node URI is just the default
> value
> > > > that
> > > > will be used if a URI is not provided explicitly on a binding.
> > > > 3. Binding uri attribute. If SCA is running inside a web app
> container
> > > > this
> > > > value is ignored and Node URI is used (see 2). If SCA has started
> > > > Tomcat/Jetty itself this value will be used to configure the
> endpoint
> > of
> > > > the
> > > > service. If no value is provided then the default value is used
> (see
> > 1
> > > > and
> > > > 2).
> > > >
> > > > So what's the drawback of using
> > > >
> > > > <component name="Store">
> > > > <t:implementation.widget location="uiservices/store.html"/>
> > > > <service name="Widget">
> > > > <t:binding.http uri="/ui"/>
> > > > </service>
> > > > <reference name="catalog" target="Catalog">
> > > > <t:binding.jsonrpc/>
> > > > </reference>
> > > > <reference name="shoppingCart" target="ShoppingCart/Cart">
> > > > <t:binding.atom/>
> > > > </reference>
> > > > <reference name="shoppingTotal" target="ShoppingCart/Total">
> > > > <t:binding.jsonrpc/>
> > > > </reference>
> > > > </component>
> > > >
> > > > And setting Node URI = http://localhost:8101
> > > >
> > > > I'm uncomfortable about the current feature because I could easily
> > > include
> > > > a
> > > > component in front of the existing component, e.g.
> > > >
> > > > <component name"SomeComponent"
> > > > <implementation .../>
> > > > <service name="SomeService">
> > > > <binding.ws url="http://localhost:8100/SomeService"/>
> > > > </service>
> > > > </component>
> > > >
> > > >
> > > > <component name="Store">
> > > > <t:implementation.widget location="uiservices/store.html"/>
> > > > <service name="Widget">
> > > > <t:binding.http uri="http://localhost:8101/ui"/>
> > > > </service>
> > > > <reference name="catalog" target="Catalog">
> > > > <t:binding.jsonrpc/>
> > > > </reference>
> > > > <reference name="shoppingCart" target="ShoppingCart/Cart">
> > > > <t:binding.atom/>
> > > > </reference>
> > > > <reference name="shoppingTotal" target="ShoppingCart/Total">
> > > > <t:binding.jsonrpc/>
> > > > </reference>
> > > > </component>
> > > >
> > > > And mess it up as now the majority services in the composite are at
> > 8100
> > > > and
> > > > not 8101 where store.html expects them to be.
> > > >
> > > > Regards
> > > >
> > > > Simon
> > > >
> > >
> > > I agree. We've never come up with a very consistent story about
> default
> > > URLs
> > > that works well everywhere, would be great if we could as its always
> > > causing
> > > problems with getting all the runtimes and nodes and service endpoints
> > > working consistently everywhere.
> > >
> > > Can we change so that the ServletHost implementation controls the
> > default
> > > base URL and have everything tries to use relative URLs with that?
> > >
> > > ...ant
> > >
> > I think we can be relatively consistent using the three sources of
> > endpoint
> > information I put in the original mail.Now I think about it there is a
> > number 4 that I didn't include so the list would be.
> >
> > 1. The web app container. In this case no matter how you configure SCA
> you
> > will get whatever the web app container gives you
> > 2. Node URI. This is used to tell what endpoints SCA should use by
> default
> > and also as a unique ID for the node. When running inside a web app this
> > must be the host/port you expect the web app to expose your services on.
> > Otherwise SCA can't tell what values the web app container is going to
> use
> > and hence can't register services with the domain. In the case that SCA
> > starts Tomcat/Jetty itself then the Node URI is just the default value
> > that
> > will be used if a URI is not provided explicitly on a binding.
> > 3. Binding uri attribute. If SCA is running inside a web app container
> > this
> > value is ignored and Node URI is used (see 2). If SCA has started
> > Tomcat/Jetty itself this value will be used to configure the endpoint of
> > the
> > service. If no value is provided then the default value is used (see 1
> > and
> > 2).
> > 4. Free port. If not running inside a web app container and no Node URI
> is
> > provided then a free port is selected automatically as the default port
> >
> > The default is set into the servlet host when the node starts and the
> > bindings which use servlet host tend to use the servlet host interface
> to
> > calculate their endpoint. So we are pretty close to what you suggest
> but
> > we
> > need to check that it is applied everywhere.
> >
> > I tried to represent the algorithm in psuedo code (
> >
> >
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Binding+URI+Construction
> > )
> > is this correct?
> >
> > Simon
> >
>
> If (1) is made to be generic instead of webapp container specific, eg "the
> default from the ServletHost" then (4) could be dropped as it can be done
> by
> the ServletHost impl if it chooses as part of (1).
>
> I'm still not really clear why (2) must be an absolute URI instead of just
> a
> relative one (ie just the Node name) and be relative to the absolute URI
> from (1)? To me that seems simpler to understand and would then always
> work
> the same way no matter what the environment. I'm just trying to understand
> the options, I guess it doesn't make so much difference.
>
As a servlet running in a servlet container, for example, how do you get the
host and port on which you are running?
>
>
> ...ant
>
Re: Selection of default service URIs based on URIs from the composite
Posted by ant elder <an...@apache.org>.
On Nov 30, 2007 2:46 PM, Simon Laws <si...@googlemail.com> wrote:
> On Nov 30, 2007 2:09 PM, ant elder <an...@gmail.com> wrote:
>
> > On Nov 30, 2007 1:52 PM, Simon Laws <si...@googlemail.com> wrote:
> >
> > > We have discussed this behaviour before and I was sort of convinced
> last
> > > time but now I'm playing with the store sample I'm not so sure. This
> > > features comes about because of the store composite, for example,
> > >
> > > <component name="Store">
> > > <t:implementation.widget location="uiservices/store.html"/>
> > > <service name="Widget">
> > > <t:binding.http uri="http://localhost:8101/ui"/>
> > > </service>
> > > <reference name="catalog" target="Catalog">
> > > <t:binding.jsonrpc/>
> > > </reference>
> > > <reference name="shoppingCart" target="ShoppingCart/Cart">
> > > <t:binding.atom/>
> > > </reference>
> > > <reference name="shoppingTotal" target="ShoppingCart/Total">
> > > <t:binding.jsonrpc/>
> > > </reference>
> > > </component>
> > >
> > > To keep the composite tidy many of the URIs are omitted and they rely
> on
> > > the
> > > default value. However the URI for one of the bindings is provided so
> > that
> > > the node will detect this and use this as the default for all service
> > > bindings (where this kind of URI is applicable). All the bindings must
> > be
> > > the same here as store.html relies on the services being accessible
> from
> > > the
> > > same root.
> > >
> > > There are several places that the default port for the servlet host
> > comes
> > > from when setting up the SCA runtime.
> > >
> > > 1. The web app container. In this case no matter how you configure SCA
> > you
> > > will get whatever the web app container gives you
> > > 2. Node URI. This is used to tell what endpoints SCA should use by
> > default
> > > and also as a unique ID for the node. When running inside a web app
> this
> > > must be the host/port you expect the web app to expose your services
> on.
> > > Otherwise SCA can't tell what values the web app container is going to
> > use
> > > and hence can't register services with the domain. In the case that
> SCA
> > > starts Tomcat/Jetty itself then the Node URI is just the default value
> > > that
> > > will be used if a URI is not provided explicitly on a binding.
> > > 3. Binding uri attribute. If SCA is running inside a web app container
> > > this
> > > value is ignored and Node URI is used (see 2). If SCA has started
> > > Tomcat/Jetty itself this value will be used to configure the endpoint
> of
> > > the
> > > service. If no value is provided then the default value is used (see
> 1
> > > and
> > > 2).
> > >
> > > So what's the drawback of using
> > >
> > > <component name="Store">
> > > <t:implementation.widget location="uiservices/store.html"/>
> > > <service name="Widget">
> > > <t:binding.http uri="/ui"/>
> > > </service>
> > > <reference name="catalog" target="Catalog">
> > > <t:binding.jsonrpc/>
> > > </reference>
> > > <reference name="shoppingCart" target="ShoppingCart/Cart">
> > > <t:binding.atom/>
> > > </reference>
> > > <reference name="shoppingTotal" target="ShoppingCart/Total">
> > > <t:binding.jsonrpc/>
> > > </reference>
> > > </component>
> > >
> > > And setting Node URI = http://localhost:8101
> > >
> > > I'm uncomfortable about the current feature because I could easily
> > include
> > > a
> > > component in front of the existing component, e.g.
> > >
> > > <component name"SomeComponent"
> > > <implementation .../>
> > > <service name="SomeService">
> > > <binding.ws url="http://localhost:8100/SomeService"/>
> > > </service>
> > > </component>
> > >
> > >
> > > <component name="Store">
> > > <t:implementation.widget location="uiservices/store.html"/>
> > > <service name="Widget">
> > > <t:binding.http uri="http://localhost:8101/ui"/>
> > > </service>
> > > <reference name="catalog" target="Catalog">
> > > <t:binding.jsonrpc/>
> > > </reference>
> > > <reference name="shoppingCart" target="ShoppingCart/Cart">
> > > <t:binding.atom/>
> > > </reference>
> > > <reference name="shoppingTotal" target="ShoppingCart/Total">
> > > <t:binding.jsonrpc/>
> > > </reference>
> > > </component>
> > >
> > > And mess it up as now the majority services in the composite are at
> 8100
> > > and
> > > not 8101 where store.html expects them to be.
> > >
> > > Regards
> > >
> > > Simon
> > >
> >
> > I agree. We've never come up with a very consistent story about default
> > URLs
> > that works well everywhere, would be great if we could as its always
> > causing
> > problems with getting all the runtimes and nodes and service endpoints
> > working consistently everywhere.
> >
> > Can we change so that the ServletHost implementation controls the
> default
> > base URL and have everything tries to use relative URLs with that?
> >
> > ...ant
> >
> I think we can be relatively consistent using the three sources of
> endpoint
> information I put in the original mail.Now I think about it there is a
> number 4 that I didn't include so the list would be.
>
> 1. The web app container. In this case no matter how you configure SCA you
> will get whatever the web app container gives you
> 2. Node URI. This is used to tell what endpoints SCA should use by default
> and also as a unique ID for the node. When running inside a web app this
> must be the host/port you expect the web app to expose your services on.
> Otherwise SCA can't tell what values the web app container is going to use
> and hence can't register services with the domain. In the case that SCA
> starts Tomcat/Jetty itself then the Node URI is just the default value
> that
> will be used if a URI is not provided explicitly on a binding.
> 3. Binding uri attribute. If SCA is running inside a web app container
> this
> value is ignored and Node URI is used (see 2). If SCA has started
> Tomcat/Jetty itself this value will be used to configure the endpoint of
> the
> service. If no value is provided then the default value is used (see 1
> and
> 2).
> 4. Free port. If not running inside a web app container and no Node URI is
> provided then a free port is selected automatically as the default port
>
> The default is set into the servlet host when the node starts and the
> bindings which use servlet host tend to use the servlet host interface to
> calculate their endpoint. So we are pretty close to what you suggest but
> we
> need to check that it is applied everywhere.
>
> I tried to represent the algorithm in psuedo code (
>
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Binding+URI+Construction
> )
> is this correct?
>
> Simon
>
If (1) is made to be generic instead of webapp container specific, eg "the
default from the ServletHost" then (4) could be dropped as it can be done by
the ServletHost impl if it chooses as part of (1).
I'm still not really clear why (2) must be an absolute URI instead of just a
relative one (ie just the Node name) and be relative to the absolute URI
from (1)? To me that seems simpler to understand and would then always work
the same way no matter what the environment. I'm just trying to understand
the options, I guess it doesn't make so much difference.
...ant
Re: Selection of default service URIs based on URIs from the composite
Posted by Simon Laws <si...@googlemail.com>.
On Nov 30, 2007 2:09 PM, ant elder <an...@gmail.com> wrote:
> On Nov 30, 2007 1:52 PM, Simon Laws <si...@googlemail.com> wrote:
>
> > We have discussed this behaviour before and I was sort of convinced last
> > time but now I'm playing with the store sample I'm not so sure. This
> > features comes about because of the store composite, for example,
> >
> > <component name="Store">
> > <t:implementation.widget location="uiservices/store.html"/>
> > <service name="Widget">
> > <t:binding.http uri="http://localhost:8101/ui"/>
> > </service>
> > <reference name="catalog" target="Catalog">
> > <t:binding.jsonrpc/>
> > </reference>
> > <reference name="shoppingCart" target="ShoppingCart/Cart">
> > <t:binding.atom/>
> > </reference>
> > <reference name="shoppingTotal" target="ShoppingCart/Total">
> > <t:binding.jsonrpc/>
> > </reference>
> > </component>
> >
> > To keep the composite tidy many of the URIs are omitted and they rely on
> > the
> > default value. However the URI for one of the bindings is provided so
> that
> > the node will detect this and use this as the default for all service
> > bindings (where this kind of URI is applicable). All the bindings must
> be
> > the same here as store.html relies on the services being accessible from
> > the
> > same root.
> >
> > There are several places that the default port for the servlet host
> comes
> > from when setting up the SCA runtime.
> >
> > 1. The web app container. In this case no matter how you configure SCA
> you
> > will get whatever the web app container gives you
> > 2. Node URI. This is used to tell what endpoints SCA should use by
> default
> > and also as a unique ID for the node. When running inside a web app this
> > must be the host/port you expect the web app to expose your services on.
> > Otherwise SCA can't tell what values the web app container is going to
> use
> > and hence can't register services with the domain. In the case that SCA
> > starts Tomcat/Jetty itself then the Node URI is just the default value
> > that
> > will be used if a URI is not provided explicitly on a binding.
> > 3. Binding uri attribute. If SCA is running inside a web app container
> > this
> > value is ignored and Node URI is used (see 2). If SCA has started
> > Tomcat/Jetty itself this value will be used to configure the endpoint of
> > the
> > service. If no value is provided then the default value is used (see 1
> > and
> > 2).
> >
> > So what's the drawback of using
> >
> > <component name="Store">
> > <t:implementation.widget location="uiservices/store.html"/>
> > <service name="Widget">
> > <t:binding.http uri="/ui"/>
> > </service>
> > <reference name="catalog" target="Catalog">
> > <t:binding.jsonrpc/>
> > </reference>
> > <reference name="shoppingCart" target="ShoppingCart/Cart">
> > <t:binding.atom/>
> > </reference>
> > <reference name="shoppingTotal" target="ShoppingCart/Total">
> > <t:binding.jsonrpc/>
> > </reference>
> > </component>
> >
> > And setting Node URI = http://localhost:8101
> >
> > I'm uncomfortable about the current feature because I could easily
> include
> > a
> > component in front of the existing component, e.g.
> >
> > <component name"SomeComponent"
> > <implementation .../>
> > <service name="SomeService">
> > <binding.ws url="http://localhost:8100/SomeService"/>
> > </service>
> > </component>
> >
> >
> > <component name="Store">
> > <t:implementation.widget location="uiservices/store.html"/>
> > <service name="Widget">
> > <t:binding.http uri="http://localhost:8101/ui"/>
> > </service>
> > <reference name="catalog" target="Catalog">
> > <t:binding.jsonrpc/>
> > </reference>
> > <reference name="shoppingCart" target="ShoppingCart/Cart">
> > <t:binding.atom/>
> > </reference>
> > <reference name="shoppingTotal" target="ShoppingCart/Total">
> > <t:binding.jsonrpc/>
> > </reference>
> > </component>
> >
> > And mess it up as now the majority services in the composite are at 8100
> > and
> > not 8101 where store.html expects them to be.
> >
> > Regards
> >
> > Simon
> >
>
> I agree. We've never come up with a very consistent story about default
> URLs
> that works well everywhere, would be great if we could as its always
> causing
> problems with getting all the runtimes and nodes and service endpoints
> working consistently everywhere.
>
> Can we change so that the ServletHost implementation controls the default
> base URL and have everything tries to use relative URLs with that?
>
> ...ant
>
I think we can be relatively consistent using the three sources of endpoint
information I put in the original mail.Now I think about it there is a
number 4 that I didn't include so the list would be.
1. The web app container. In this case no matter how you configure SCA you
will get whatever the web app container gives you
2. Node URI. This is used to tell what endpoints SCA should use by default
and also as a unique ID for the node. When running inside a web app this
must be the host/port you expect the web app to expose your services on.
Otherwise SCA can't tell what values the web app container is going to use
and hence can't register services with the domain. In the case that SCA
starts Tomcat/Jetty itself then the Node URI is just the default value that
will be used if a URI is not provided explicitly on a binding.
3. Binding uri attribute. If SCA is running inside a web app container this
value is ignored and Node URI is used (see 2). If SCA has started
Tomcat/Jetty itself this value will be used to configure the endpoint of the
service. If no value is provided then the default value is used (see 1 and
2).
4. Free port. If not running inside a web app container and no Node URI is
provided then a free port is selected automatically as the default port
The default is set into the servlet host when the node starts and the
bindings which use servlet host tend to use the servlet host interface to
calculate their endpoint. So we are pretty close to what you suggest but we
need to check that it is applied everywhere.
I tried to represent the algorithm in psuedo code (
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Binding+URI+Construction)
is this correct?
Simon
Re: Selection of default service URIs based on URIs from the composite
Posted by ant elder <an...@gmail.com>.
On Nov 30, 2007 1:52 PM, Simon Laws <si...@googlemail.com> wrote:
> We have discussed this behaviour before and I was sort of convinced last
> time but now I'm playing with the store sample I'm not so sure. This
> features comes about because of the store composite, for example,
>
> <component name="Store">
> <t:implementation.widget location="uiservices/store.html"/>
> <service name="Widget">
> <t:binding.http uri="http://localhost:8101/ui"/>
> </service>
> <reference name="catalog" target="Catalog">
> <t:binding.jsonrpc/>
> </reference>
> <reference name="shoppingCart" target="ShoppingCart/Cart">
> <t:binding.atom/>
> </reference>
> <reference name="shoppingTotal" target="ShoppingCart/Total">
> <t:binding.jsonrpc/>
> </reference>
> </component>
>
> To keep the composite tidy many of the URIs are omitted and they rely on
> the
> default value. However the URI for one of the bindings is provided so that
> the node will detect this and use this as the default for all service
> bindings (where this kind of URI is applicable). All the bindings must be
> the same here as store.html relies on the services being accessible from
> the
> same root.
>
> There are several places that the default port for the servlet host comes
> from when setting up the SCA runtime.
>
> 1. The web app container. In this case no matter how you configure SCA you
> will get whatever the web app container gives you
> 2. Node URI. This is used to tell what endpoints SCA should use by default
> and also as a unique ID for the node. When running inside a web app this
> must be the host/port you expect the web app to expose your services on.
> Otherwise SCA can't tell what values the web app container is going to use
> and hence can't register services with the domain. In the case that SCA
> starts Tomcat/Jetty itself then the Node URI is just the default value
> that
> will be used if a URI is not provided explicitly on a binding.
> 3. Binding uri attribute. If SCA is running inside a web app container
> this
> value is ignored and Node URI is used (see 2). If SCA has started
> Tomcat/Jetty itself this value will be used to configure the endpoint of
> the
> service. If no value is provided then the default value is used (see 1
> and
> 2).
>
> So what's the drawback of using
>
> <component name="Store">
> <t:implementation.widget location="uiservices/store.html"/>
> <service name="Widget">
> <t:binding.http uri="/ui"/>
> </service>
> <reference name="catalog" target="Catalog">
> <t:binding.jsonrpc/>
> </reference>
> <reference name="shoppingCart" target="ShoppingCart/Cart">
> <t:binding.atom/>
> </reference>
> <reference name="shoppingTotal" target="ShoppingCart/Total">
> <t:binding.jsonrpc/>
> </reference>
> </component>
>
> And setting Node URI = http://localhost:8101
>
> I'm uncomfortable about the current feature because I could easily include
> a
> component in front of the existing component, e.g.
>
> <component name"SomeComponent"
> <implementation .../>
> <service name="SomeService">
> <binding.ws url="http://localhost:8100/SomeService"/>
> </service>
> </component>
>
>
> <component name="Store">
> <t:implementation.widget location="uiservices/store.html"/>
> <service name="Widget">
> <t:binding.http uri="http://localhost:8101/ui"/>
> </service>
> <reference name="catalog" target="Catalog">
> <t:binding.jsonrpc/>
> </reference>
> <reference name="shoppingCart" target="ShoppingCart/Cart">
> <t:binding.atom/>
> </reference>
> <reference name="shoppingTotal" target="ShoppingCart/Total">
> <t:binding.jsonrpc/>
> </reference>
> </component>
>
> And mess it up as now the majority services in the composite are at 8100
> and
> not 8101 where store.html expects them to be.
>
> Regards
>
> Simon
>
I agree. We've never come up with a very consistent story about default URLs
that works well everywhere, would be great if we could as its always causing
problems with getting all the runtimes and nodes and service endpoints
working consistently everywhere.
Can we change so that the ServletHost implementation controls the default
base URL and have everything tries to use relative URLs with that?
...ant