On 8/15/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > 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 >
The page i've started is at http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+binding+endpoints So the idea was just add a bunch more examples of different configurations and the resulting endpoints, maybe also adding a sentence or two saying how the endpoint is arrived at for each example. Does that sound ok / useful? Feel free to suggest alternative approaches , add different examples or more description etc. ...ant
