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)"/> >>>> </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)" /> > <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)" /> > <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
