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 :)
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
