You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2007/12/13 18:22:24 UTC
Re: What is this base domain URI about? was: Selection of default
service URIs based on URIs from the composite
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 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