The problem is when the service is promoted the way the Tuscany runtime works is that the RuntimeComponent gets an additional service added (named with "$promoted$." prefix) so then at line 196 in the Axis2ServiceBindingProvider this is taken to mean the binding name should be added to the URI even though there really is only the one service. Seems a bit hacky for the Axis2 binding to ignore service names starting with "$promoted$." so how else could this be fixed? Should most of the code in the computeActualURI be moved to the runtime somewhere?
...ant On 5/30/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
My understanding of the spec is the following: - independent of whether or not a service is promoted, a service is offered by a component - if a component has only one service then the default URI is base domain URI / component-name - I haven't seen a statement in the spec saying that the service should also be available at base domain URI / component name / service name in this case. That leaves us with a single URI, which should be the same in both cases (whether the service is promoted or not): http://localhost:8080/HelloWorldServiceComponent ant elder wrote: > I'm not sure if you're saying its wrong or right that the endpoint is > changing in the helloworld example? > > ...ant > > On 5/25/07, Raymond Feng <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> Here is my understanding of the Spec about the URI for a service >> binding: >> >> Let's assume that we have the following declaration: >> >> component: c1 >> service: s1 >> binding: name="b1" uri="uri1" >> binding: name="b2" >> binding: >> >> If the base URI for http is " http://localhost:8080/";, the URIs for the >> three >> bindings for component c1 will be: >> >> http://localhost:8080/c1/uri1 (uri attr is used) >> http://localhost:8080/c1/b2 (uri is default to the name of the binding, >> I'm >> not sure why the spec says the name is a QName) >> http://localhost:8080/c1/s1 (uri is default to the name of the binding >> which >> is default to the name of service) >> >> If s1 is the only service for c1 and s1 only has one binding, I >> assume the >> following uri is also available (in addation to the explicit one): >> http://localhost:8080/c1 >> >> Do you agree? >> >> Thanks, >> Raymond >> >> ----- Original Message ----- >> From: "ant elder" <[EMAIL PROTECTED]> >> To: < tuscany-dev@ws.apache.org> >> Sent: Friday, May 25, 2007 3:34 AM >> Subject: Re: Promoting and configuring services in an SCA domain, was: A >> few >> issues with HelloWorld WS sample >> >> >> > On 5/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: >> >> >> >> Jean-Sebastien Delfino wrote: >> >> > scabooz wrote: >> >> >> Sebastien, >> >> >> >> >> >> I have a slightly different perspective, inline below. >> >> >> >> >> >> Dave >> >> >> >> >> >> <snip> >> >> >> >> >> >>>> 2) What is the point of promoting it anyway? It seems the >> only >> >> >>>> point of >> >> >>>> promoting it would be to allow this Composite to serve as the >> impl >> >> for >> >> >>>> another component. >> >> >>>> Since we don't do that in this simple sample, doesn't it just >> add >> >> >>>> confusion? >> >> >>>> >> >> >>>> It seems to be the SCDL should look something like this, >> ideally: >> >> >>>> >> >> >>>> <component name="HelloWorldServiceComponent"> >> >> >>>> <implementation.java >> >> >>>> class="helloworld.HelloWorldServiceComponent"/> >> >> >>>> <reference name="helloWorldService"> >> >> >>>> < binding.ws wsdlElement=" >> >> >>>> >> http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort) <http://helloworld#wsdl.port%28HelloWorldService/HelloWorldSoapPort%29> >> "/> >> >> >>>> </reference> >> >> >>>> </component> >> >> >>>> >> >> >>> >> >> >>> What you're proposing is correct, but I think that the best >> practice >> >> >>> should be to promote services and references that use bindings >> and >> >> >>> go out of an SCA domain, to allow their bindings and endpoints to >> be >> >> >>> reconfigured at deployment time, by using a deployment composite >> for >> >> >>> example. >> >> >>> >> >> >> The spec introduced the ability to put bindings on component >> services >> >> >> and references. For top level components, that's where the >> bindings >> >> >> should go (IMHO) as a best practice. Promoted services and >> >> >> references don't really have a meaning when a composite is >> included >> >> >> (which is what happens at deployment). Just seems like extra >> baggage >> >> >> to >> >> >> me. I think it will be clear when a composite is developed, >> whether >> >> >> or >> >> >> not it is intended to be deployed or used as an implementation. >> >> >> >> >> >> Your perspective makes the assumption that all composites might >> one >> >> >> day be used as an implementation. I am taking the opposite >> position. >> >> >> None of this is critical, as both are supported...just makes for >> good >> >> >> discussion. >> >> >> >> >> >> >> >> >> <snip> >> >> >> >> >> >> >> >> > >> >> > The initial intent was to allow services and references to be >> >> > reconfigured at deployment time. >> >> > >> >> > This confuses me a bit, but I think that there are multiple ways to >> do >> >> > this: >> >> > >> >> > (1) Initially declare composite services/references, and instead of >> >> > including the composite directly in the domain, use your >> composite as >> >> > the implementation of a component in another composite, and >> override >> >> > the service/reference configuration on that new component. >> >> > >> >> > (2) Initially specify the bindings directly on your component >> >> > services/references. To reconfigure them you'll need to include >> your >> >> > composite in another composite, and specify your service/reference >> >> > configuration in new composite services/references in that new >> >> composite. >> >> > >> >> > Option 1 has the side effect of hiding the internal structure of >> your >> >> > composite, but it may be OK in cases like HelloWorld or our >> Calculator >> >> > sample, where you would expose only the Calculator service and hide >> >> > the other service components. >> >> > >> >> > Option 2 allows you to keep all your components at the domain >> level, >> >> > but won't allow you to rewire a reference if it was wired in the >> >> > original composite (unless I'm missing something). >> >> > >> >> > The samples do not demonstrate any of this rewiring anyway, so >> we can >> >> > change: >> >> > >> >> > <composite xmlns=" http://www.osoa.org/xmlns/sca/1.0"; >> >> > targetNamespace="http://helloworld"; >> >> > xmlns:hw=" http://helloworld"; >> >> > name="helloworldws"> >> >> > >> >> > <service name="HelloWorldService" >> >> > promote="HelloWorldServiceComponent"> >> >> > <interface.wsdl >> >> > interface="http://helloworld#wsdl.interface(HelloWorld) <http://helloworld#wsdl.interface%28HelloWorld%29>" /> >> >> > <binding.ws /> >> >> > </service> >> >> > >> >> > <component name="HelloWorldServiceComponent"> >> >> > <implementation.java class="helloworld.HelloWorldImpl" /> >> >> > </component> >> >> > >> >> > </composite> >> >> > >> >> > to >> >> > >> >> > <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"; >> >> > targetNamespace="http://helloworld"; >> >> > xmlns:hw="http://helloworld"; >> >> > name="helloworldws"> >> >> > >> >> > <component name="HelloWorldServiceComponent"> >> >> > <service name="HelloWorldService"> >> >> > < interface.wsdl >> >> > interface="http://helloworld#wsdl.interface(HelloWorld)<http://helloworld#wsdl.interface%28HelloWorld%29>" /> >> >> > < binding.ws /> >> >> > </service> >> >> > <implementation.java class="helloworld.HelloWorldImpl" /> >> >> > </component> >> >> > >> >> > </composite> >> >> > >> >> > >> >> > ... which is slightly simpler. I made that change in revision >> r538384. >> >> > >> >> >> >> Dave, >> >> >> >> Going back to this.... This new form is slightly more compact as we >> save >> >> a promote="..." attribute, but we could also take a different view >> here >> >> and say: >> >> - HelloWorldService is made visible as a Web service outside the SCA >> >> domain, >> >> - So the best practice is to promote it outside of the domain >> composite, >> >> using a composite service. >> >> >> >> That's the initial form we had (see the assembly XML above), which >> >> triggered that discussion. >> >> >> >> The second form, with the Web Service binding on the >> component/service >> >> would be used to configure services used only inside the domain. >> >> >> >> HelloWorld can probably accomodate both :) and both forms work >> with the >> >> latest Tuscany runtime. >> >> >> >> I'd be interested to get thoughts on this, as I'd like our samples to >> >> help promote the best practices. >> >> >> >> -- >> >> Jean-Sebastien >> > >> > >> > One practical significance of this with the Tuscany runtime is that >> the >> > service endpoint url changes depending on which of these is used. >> The WS >> > endpoint url includes the Service Binding URI when there are multiple >> > services. When <service> is inside the <component> the component in >> > Tuscany >> > has just a single service but when <service> is outside then the >> component >> > also has a service using the SCA binding. >> > >> > So in the above example the WS endpoint is either >> > http://localhost:8080/HelloWorldServiceComponent/HelloWorldService or >> > http://localhost:8080/HelloWorldServiceComponent depending on if the >> > <service> is inside or outside the <component>. >> > >> > Is this the expected behaviour? >> > >> > ...ant >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
