Simon Laws wrote:
On 8/3/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
ant elder wrote:
On 8/1/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
[snip]
Another problem is all our bindings work differently. So
<binding.ws/>, <
binding.rmi/> <binding.jms/> <binding.jsonrpc/> etc all result in
a
service
being available at a different endpoint. Also the uri attribute
on those
bindings all work differently so uri="foo" for some bindings
would be
treated as relative uri, for others an absolute one. What we need
is a
bit
of code that implements section 1.7.2.1 of the assembly spec
which all
bindings then use. (a generic version of
Axis2ServiceProvider.computeActualURI). Didn't this come up once
before
and
something was changing in the runtime binding for this?
I think that these URIs should be determined as part of the process
of combining wires and uris specified at different levels in the SCA
assembly. If the correct URIs are determined once as part of this
process, a binding provider should be able to just call
binding.getURI(), without having to calculate it at all, on its own
or even calling a central URI calculator method.
Before trying to implement a common algorithm for all bindings, I
thought I'd double check the various SCA spec docs. Here's what I
found:
- WebService binding
absolute URI specified in binding/@uri
or
base domain URI for http: + '/' + component URI + '/' + relative URI
specified in binding/@uri
or
absolute URI specified in WSDL
or
base domain URI for http: + '/' + component URI + '/' + relative URI
specified in WSDL
or
absolute URI specified in a wsa:Address
or
base domain URI for http: + '/' + component URI + '/' + relative URI
specified in a wsa:Address
- JMS binding
JMS specific URI specified in binding/@uri
or
no URI, combination of JMS specific attributes
- EJB binding
base domain URI for corba:iiop: + '#' + relative URI specified in
binding/@uri
or
base domain URI for corba:rir: + '#' + relative URI specified in
binding/@uri
or
absolute URI specified in binding/@uri
I think that other bindings introduced by Tuscany can follow similar
patterns:
- RMI binding
similar to EJB binding
- JSON, Ajax and Feed bindings
absolute URI specified in binding/@uri
or
base domain URI for http: + '/' + component URI + '/' + relative URI
specified in binding/@uri
Thoughts? could you guys please review to make sure I understood the
specs correctly? Thanks.
After more reading of the various SCA specs, I think we should defer
supporting a domain URI (or a set of domain URIs) until the specs
clarify the use cases for it. Here are the issues I'm seeing:
- Component URI is not clearly defined in the spec (there's an errata
for this), the name of the component cannot be used alone for nested
components, and concatenating names of nested components with a domain
URI is likely to cause ambiguities and collisions.
- Having a domain URI per node in a domain (proposed earlier in this
thread) is not in line with the spec.
- Also doing that will burn the node topology in the SCA domain logical
assembly, as you'll see the addresses of your nodes in the URIs on your
reference bindings, so the logical assembly won't be so "logical"
anymore
:)
- We could say that the domain URI is just a logical URI, but then I
don't understand why we would need it at all, as specifying
domainURI/someURI in the URI of a reference binding would only compete
with the target attribute of a reference or wire.
- And if it was just a logical URI then I'm not sure why we'd need a
different URI per protocol.
So at this point I don't understand how this domain URI was intended to
be used and I think we should keep things simple. I'd suggest to not
try
to use a domain URI to calculate any binding URIs for now, and ask
application developers and assemblers to specify the URIs they want
explicitly.
If anyone out there has a requirement for domain URIs and can
articulate
the use case and how it should work, please shout :)
Finally, the SCA assembly model is already able to store a single URI
in
the domain's Composite model object (see Composite.get/setURI()), so if
people find a real use case and are OK to start with a single domain
URI, they can just use that.
Thoughts?
So what is the proposal exactly - "ask application developers and
assemblers
to specify the URIs they want explicitly" - could there be some examples
of
what that would mean for our various http based bindings?
...ant
I'm just proposing to continue to do what we already do today, without
introducing a domain base URI configuration now as it's unclear at this
point how it's going to be used and how it should work.
Here are two sample composite files:
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-service/src/main/resources/helloworldws.composite
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/feed-aggregator/src/main/resources/FeedAggregator.composite
I suggest to default the host to localhost, and the port to 8080 if they
are not specified in the binding/@uri. This is what most bindings do
today. We still need to make sure that all HTTP based bindings use the
specified binding/@uri consistently, there's no question about that.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This is a little problematic for the remote SCA Binding where we could
default to localhost:8080 but don't necessarily have the ability to define a
specific URL. We could ask that binding.sca appears explicitly whenever a
non default URL is required but in that case you are probably better off
using an explicit binding where you have control over the protocol. Can we
say that Tuscany will define base scheme URLs for each node so that we can
configure the default sca binding?
Simon
Can you describe how you would use base scheme URLs for each node and
how it would help the SCA binding?
From your other email about the SCA binding [1] I understand that a
node will advertise (in some repository or directory?) which services it
offers at which endpoint, so I'm still not sure what we'll do with a
base scheme URL for each node. Won't the other nodes get the endpoint
address of the services they need to talk to from that directory?
[1] http://www.mail-archive.com/[email protected]/msg21171.html
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
