You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Scott Kurz <sc...@gmail.com> on 2008/03/17 21:53:52 UTC
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
Re: real basic question on Composite impl (recursion)
Posted by Raymond Feng <en...@gmail.com>.
Here is the page:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Multiple+bindings+and+reference+multiplicity
Thanks,
Raymond
--------------------------------------------------
From: "scabooz" <sc...@gmail.com>
Sent: Wednesday, March 19, 2008 11:20 AM
To: <tu...@ws.apache.org>
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" <en...@gmail.com>
> To: <tu...@ws.apache.org>
> 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" <sc...@gmail.com>
>> Sent: Wednesday, March 19, 2008 5:28 AM
>> To: <tu...@ws.apache.org>
>> 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 <en...@gmail.com>
>>> 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" <sc...@gmail.com>
>>>> Sent: Monday, March 17, 2008 1:53 PM
>>>> To: <tu...@ws.apache.org>
>>>> 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: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: real basic question on Composite impl (recursion)
Posted by scabooz <sc...@gmail.com>.
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" <en...@gmail.com>
To: <tu...@ws.apache.org>
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" <sc...@gmail.com>
> Sent: Wednesday, March 19, 2008 5:28 AM
> To: <tu...@ws.apache.org>
> 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 <en...@gmail.com>
>> 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" <sc...@gmail.com>
>>> Sent: Monday, March 17, 2008 1:53 PM
>>> To: <tu...@ws.apache.org>
>>> 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: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: real basic question on Composite impl (recursion)
Posted by Raymond Feng <en...@gmail.com>.
Let's agree (or disagree) on the following statements one by one.
1) We'll have two component services C1/svc1 and C2/innerService.
2) C2/innerService is configured with binding.ws.
3) C2/innerService is available on a web service endpoint, the uri of the
endpoint depends on how the binding.ws is declared.
4) C1/svc1 inherits the binding.ws from C2/innerService.
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.
If C1/svc1 only has the @promote attribute without child elements for
bindings, it becomes a bit tricky to me.
* 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.
* 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. I think we need some clarification from the SCA spec to
well define the promotion rules.
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>
Thanks,
Raymond
--------------------------------------------------
From: "Scott Kurz" <sc...@gmail.com>
Sent: Wednesday, March 19, 2008 5:28 AM
To: <tu...@ws.apache.org>
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 <en...@gmail.com> 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" <sc...@gmail.com>
>> Sent: Monday, March 17, 2008 1:53 PM
>> To: <tu...@ws.apache.org>
>> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: real basic question on Composite impl (recursion)
Posted by Scott Kurz <sc...@gmail.com>.
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 <en...@gmail.com> 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" <sc...@gmail.com>
> Sent: Monday, March 17, 2008 1:53 PM
> To: <tu...@ws.apache.org>
> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: real basic question on Composite impl (recursion)
Posted by Raymond Feng <en...@gmail.com>.
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" <sc...@gmail.com>
Sent: Monday, March 17, 2008 1:53 PM
To: <tu...@ws.apache.org>
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org