On Dec 13, 2007 5:22 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> ant elder wrote: > > On Nov 30, 2007 9:06 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> > > wrote: > > > >> Jean-Sebastien Delfino wrote: > >>> ant elder wrote: > >>>> On Nov 30, 2007 5:19 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED] > > > >>>> wrote: > >>>> > >>>>> ant elder wrote: > >>>>>> On Nov 30, 2007 1:52 PM, Simon Laws <[EMAIL PROTECTED]> > >> 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
