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