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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
