Here is the page:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Multiple+bindings+and+reference+multiplicity
Thanks,
Raymond
--------------------------------------------------
From: "scabooz" <[EMAIL PROTECTED]>
Sent: Wednesday, March 19, 2008 11:20 AM
To: <[email protected]>
Subject: Re: real basic question on Composite impl (recursion)
Hi Raymond,
We hashed this out once before and you recorded the results
on a wiki page, but I can't find it. Do you recall?
comments imbedded.
Dave
----- Original Message -----
From: "Raymond Feng" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, March 19, 2008 11:53 AM
Subject: Re: real basic question on Composite impl (recursion)
Let's agree (or disagree) on the following statements one by one.
1) We'll have two component services C1/svc1 and C2/innerService.
Yes
2) C2/innerService is configured with binding.ws.
Yes
3) C2/innerService is available on a web service endpoint, the uri of the
endpoint depends on how the binding.ws is declared.
No, depends on what the deployer does, but that's not important for this
discussion. What's important is that there is an endpoint created by
C2/innerService. This would be true regardless of the binding that was
present on C2/innerService, even binding.sca. We could consider not
deploying an endpoint for this service (as an optimization) if there's no
reference in the composite that references it, BUT that will get us into
trouble
when we start thinking about dynamic ways to find service endpoints.
4) C1/svc1 inherits the binding.ws from C2/innerService.
Yes. If C1 were to be deployed into the domain, there would need to be a
web service endpoint deployed for C1/svc1.
Now the question is if C1/svc1 share the same endpoint with
C2/innerService.
If C1/svc1 overrides C2/innerService's bindings, for example, specify a
new URI for binding.ws or a new binding, then C1/svc1 will have its own
endpoints.
It does anyway. The presence of a binding override just tells you which
binding
to use.
If C1/svc1 only has the @promote attribute without child elements for
bindings, it becomes a bit tricky to me.
binding.ws would be in effect for any components that used Composite1 as
an implementation.
* C2/innerService's binding.ws has an explicit endpoint URI from either
the soap:address or @uri. Then the service promotion will take the same
URI. In this case, I assume there is only one WS endpoint.
Ah, this is where we will start to part company. @uri on a service
binding is
dangerous business. We're in spec interpretation territory now because
there's
no words to address this. The specs do allow @uri on a binding service as
an
accelerator for someone to specify what URI they want to listen on, BUT it
has
to be true that a deployer ALWAYS has the last say and is therefore
allowed
to change that URI. One way to do that would be to wrap the composite in
a
component and then deploy this component to the domain, using the URI
construction rules (or providing his own URI) for the resulting services.
* C2/innerService has <binding.ws/> without explicit endpoint URI. Then
C1/svc1 will have <binding.ws/>. C2/innerService will be assigned a
default URI for the binding.ws. Will C1/svc1 takes the one from
C2/innerService or C1/svc1 will be assigned with a different URI for the
binding.ws as it's now in a different level of composition. If it's the
later, then we end up with two WS endpoints.
You can probably guess that I will assert it's the latter.
I think we need some clarification from the SCA spec to well define the
promotion rules.
+1. Turns out that OASIS is debating the URI construction rules and
these aspects of the discussion are already front and center.
Another interesting perspective is how to wire to C2/svc1:
<component name="C3">
<reference name="ref" target="C2/svc1">
<binding.ws .../> <!-- Do we need to provide a URI here for
binding.ws? -->
</reference>
...
</component>
No URI should be needed. @target should be sufficient.
Thanks,
Raymond
--------------------------------------------------
From: "Scott Kurz" <[EMAIL PROTECTED]>
Sent: Wednesday, March 19, 2008 5:28 AM
To: <[email protected]>
Subject: Re: real basic question on Composite impl (recursion)
Thanks for responding Raymond,
That's not what I envisioned, and I'm struggling to find more concrete
guidance in the OSOA specs.
Though closest guidance I saw in skimming the Assembly spec was on lines
1522-23:
. The bindings defined on the component service are still in effect for
local wires within the composite that target the component service
This, to me, suggests that you would only have one WS endpoint, as far
as
the non-SCA world is concerned, though you have multiple ways of
resolving
an SCA reference wire target pointing to this service, from other SCA
clients within the domain, depending on whether they are in the same
composite (Composite2) as C2 or not.
What are your reasons for understanding that there would be two web
services
here?
Thanks, Scott
On Mon, Mar 17, 2008 at 5:07 PM, Raymond Feng <[EMAIL PROTECTED]>
wrote:
Here is my understanding:
1) Component C1 has a service named as svc1 with binding.ws.
2) Component C2 has a service named as innerService with binding.ws.
I assume two web services (one for the innerService, the other for
svc1)
will be exposed when this composite is started. I don't think
binding.sca
plays a role in your scenario.
Thanks,
Raymond
--------------------------------------------------
From: "Scott Kurz" <[EMAIL PROTECTED]>
Sent: Monday, March 17, 2008 1:53 PM
To: <[email protected]>
Subject: real basic question on Composite impl (recursion)
> I think this has been discussed before on this list.. but I'm not
> sure
or
> forget where we ended up.
>
> In the case that you have a non-default binding on a component
> service
> defined with an inner composite which
> is in turn used as a component impl, what happens if the service is
> not
> re-defined overridden at the higher level?
>
> As an example, in the following case, does the service C1/svc1 have a
> WS
> binding or default binding (or both)?
>
> <composite name="Composite1" xmlns:ns="http://dummy";>
> <component name="C1">
> <implementation.composite name="ns:Composite2">
> </component>
> </composite>
>
> <composite name="Composite2" targetNamespace="http://dummy";
> xmlns:ns="
> http://dummy";>
> <component name="C2">
> <implementation.java class="my.C2Impl">
> <service name="innerService">
> <binding.ws .../>
> </service>
> </component>
> <!-- innerService of component C2 is promoted as svc1 -->
> <service name="svc1" promote="C2/innerService"/>
> </composite>
>
> Thanks,
> Scott
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
