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