On Nov 30, 2007 2:46 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
On Nov 30, 2007 2:09 PM, ant elder < [EMAIL PROTECTED]> 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
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.
