On 8/15/07, ant elder <[EMAIL PROTECTED]> wrote: > > On 8/15/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > 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 > > > Ok i see, thanks for the line numbers. > > The website page on binding.ws describes this a bit but i think I'm going > to > a new page on the website just about how binding uri's work and link to > that > from the other binding pages. Anyone feel free to help out and make it as > clear as possible. > > ...ant > I'd like to make sure this is absolutely clear in my mind (if no one else's). What would you like me to do?
Simon
