ant elder wrote:
On 8/15/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.
Default values for service binding URIs are now initialized by
CompositeBuilder, so binding extensions do not have to repeat that logic
anymore.
Service binding extensions can now call binding.getURI() and get:
- binding/@uri if it the specified URI is absolute
- component URI + binding/@uri if the specified URI is relative
../ ./ etc. are supported as supported by java.net.URI
for a domain level composite service, component URI is empty
for a service on a domain level component, component URI is the
component name
for a nested component, component URI is the sum of the names of the
nested components separated by '/'
- component URI / binding/@name if no URI is specified on the binding
- component URI / service/@name if no binding name is specified
Binding extensions are still responsible for determining the effective
URI, choosing their specific protocol scheme, or applying any other
binding-specific precedence rules (for example the Web Service binding
needs to consider the URI specified in a WSDL port or WSDL endpoint).
Why is component URI empty for a service on a domain level component? Is
that in the spec somewhere?
...ant
Not for a domain level component, but for a domain level composite service.
From my original description:
"for a domain level composite service, component URI is empty"
From the assembly spec:
2380 Services deployed into the Domain (as opposed to services of
components) have a URI that does
2381 not include a component name
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
