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

Reply via email to