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 > > -- > Jean-Sebastien > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Your comment "Binding extensions are still responsible for determining the effective URI," describes a Tuscany specific mechanism where by the URI determined using the algorithm you describe is turned into the "effective URI" required by each binding extension.
In the code today a number of bindings hardcode default endpoint information which is used to create the effective URI in the case where this information can't be extracted from binding.getURI() I would expect, at some point, to see a mechanism by which this hardcoded default information can be changed. From previously in this thread you do seem to be correct that this mechanism is not the "Base Domain URI for a scheme" which appears to be some logical URI for the entire domain. So another Tuscany specific mechanism is required. Simon
