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
