On 8/6/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > On 8/6/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > Simon Laws wrote: > > > On 8/3/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > > >> ant elder wrote: > > >> > > >>> On 8/1/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. > > >>>>> > > >>>>> > > >>>>> > > >>>> After more reading of the various SCA specs, I think we should > > defer > > >>>> supporting a domain URI (or a set of domain URIs) until the specs > > >>>> clarify the use cases for it. Here are the issues I'm seeing: > > >>>> > > >>>> - Component URI is not clearly defined in the spec (there's an > > errata > > >>>> for this), the name of the component cannot be used alone for > > nested > > >>>> components, and concatenating names of nested components with a > > domain > > >>>> URI is likely to cause ambiguities and collisions. > > >>>> > > >>>> - Having a domain URI per node in a domain (proposed earlier in > > this > > >>>> thread) is not in line with the spec. > > >>>> > > >>>> - Also doing that will burn the node topology in the SCA domain > > logical > > >>>> assembly, as you'll see the addresses of your nodes in the URIs on > > your > > >>>> reference bindings, so the logical assembly won't be so "logical" > > >>>> > > >> anymore > > >> > > >>>> :) > > >>>> > > >>>> - We could say that the domain URI is just a logical URI, but then > > I > > >>>> don't understand why we would need it at all, as specifying > > >>>> domainURI/someURI in the URI of a reference binding would only > > compete > > >>>> with the target attribute of a reference or wire. > > >>>> > > >>>> - And if it was just a logical URI then I'm not sure why we'd need > > a > > >>>> different URI per protocol. > > >>>> > > >>>> So at this point I don't understand how this domain URI was > > intended to > > >>>> be used and I think we should keep things simple. I'd suggest to > > not > > >>>> > > >> try > > >> > > >>>> to use a domain URI to calculate any binding URIs for now, and ask > > >>>> application developers and assemblers to specify the URIs they want > > >>>> explicitly. > > >>>> > > >>>> If anyone out there has a requirement for domain URIs and can > > >>>> > > >> articulate > > >> > > >>>> the use case and how it should work, please shout :) > > >>>> > > >>>> Finally, the SCA assembly model is already able to store a single > > URI > > >>>> > > >> in > > >> > > >>>> the domain's Composite model object (see Composite.get/setURI()), > > so if > > >>>> people find a real use case and are OK to start with a single > > domain > > >>>> URI, they can just use that. > > >>>> > > >>>> Thoughts? > > >>>> > > >>>> > > >>> So what is the proposal exactly - "ask application developers and > > >>> > > >> assemblers > > >> > > >>> to specify the URIs they want explicitly" - could there be some > > examples > > >>> > > >> of > > >> > > >>> what that would mean for our various http based bindings? > > >>> > > >>> ...ant > > >>> > > >>> > > >>> > > >> I'm just proposing to continue to do what we already do today, > > without > > >> introducing a domain base URI configuration now as it's unclear at > > this > > >> point how it's going to be used and how it should work. > > >> > > >> Here are two sample composite files: > > >> > > >> > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-service/src/main/resources/helloworldws.composite > > >> > > >> > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/feed-aggregator/src/main/resources/FeedAggregator.composite > > >> > > >> I suggest to default the host to localhost, and the port to 8080 if > > they > > >> are not specified in the binding/@uri. This is what most bindings do > > >> today. We still need to make sure that all HTTP based bindings use > > the > > >> specified binding/@uri consistently, there's no question about that. > > >> > > >> -- > > >> Jean-Sebastien > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> This is a little problematic for the remote SCA Binding where we > > could > > >> > > > default to localhost:8080 but don't necessarily have the ability to > > define a > > > specific URL. We could ask that binding.sca appears explicitly > > whenever a > > > non default URL is required but in that case you are probably better > > off > > > using an explicit binding where you have control over the protocol. > > Can we > > > say that Tuscany will define base scheme URLs for each node so that we > > can > > > configure the default sca binding? > > > > > > Simon > > > > > > > > > > Can you describe how you would use base scheme URLs for each node and > > how it would help the SCA binding? > > > > From your other email about the SCA binding [1] I understand that a > > node will advertise (in some repository or directory?) which services it > > offers at which endpoint, so I'm still not sure what we'll do with a > > base scheme URL for each node. Won't the other nodes get the endpoint > > address of the services they need to talk to from that directory? > > > > [1] http://www.mail-archive.com/[email protected]/msg21171.html > > > > -- > > Jean-Sebastien > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > Yeah, this is separate from the exchange of endpoint information between > nodes. > > It's the case where we want to run up the SCA Binding to expose a service > remotely. Say the axis2 version of the SCA Binding is being used. If we are > running inside of some other container (Geronimo?) then I guess we get > whatever endpoint that container is configured to give us so as long as we > can work out what the resulting URL is then we are set. > > If however we a running an internal Tomcat/Jetty server and we go with the > hard coded defaults you suggest the we get our services at > http://localhost:8080 and again we are good to go. If we don't want this > address what do we do? > > Simon > > > Having spent a bit of time testing the sca binding it can be frustrating when you want to run more than one SCADomain within a VM or in separate VMs on the same machine when you are using the default HTTP support. Everything tries to come up on the same port and clashes unless you go round and configure each of your bindings for a separate port.
Simon
