Service/Reference Endpoints and Request Response Binding

[Raymond Feng <en...@gmail.com>]

I'm wondering if we can combine the Endpoint and RRB efforts together. Here 
are some ideas:

1) An SCA service has a list of Endpoints representing the end point for 
each binding protocol.

2) An SCA reference has 0..N Endpoints depending on the multiplicity of the 
reference.

3) Each endpoint has a binding interface contract. If it's not known before 
the operation selector, then it's an "Any" interface with an "Any" 
operation.

4) There is one invocation chain for each endpoint (based on the binding 
interface contract) and one for the SCA service or reference. The two 
invocation chains are connected as we described on the wiki page. For a SCA 
service configured with multiple bindings, there will be multiple endpoint 
invocation chains connecting to the same service invocation chain. It's 
similar for SCA references.

Thanks,
Raymond

Re: Service/Reference Endpoints and Request Response Binding

[Simon Laws <si...@googlemail.com>]

On Mon, Oct 13, 2008 at 2:08 AM, Raymond Feng <en...@gmail.com> wrote:

> I'm wondering if we can combine the Endpoint and RRB efforts together. Here
> are some ideas:
>
> 1) An SCA service has a list of Endpoints representing the end point for
> each binding protocol.
>
> 2) An SCA reference has 0..N Endpoints depending on the multiplicity of the
> reference.
>
> 3) Each endpoint has a binding interface contract. If it's not known before
> the operation selector, then it's an "Any" interface with an "Any"
> operation.
>
> 4) There is one invocation chain for each endpoint (based on the binding
> interface contract) and one for the SCA service or reference. The two
> invocation chains are connected as we described on the wiki page. For a SCA
> service configured with multiple bindings, there will be multiple endpoint
> invocation chains connecting to the same service invocation chain. It's
> similar for SCA references.
>
> Thanks
> Raymond
>
>
Hi Raymond,

+1 from me.

Working with your list here are some more thoughts...

1) An SCA service has a list of Endpoints representing the end point for
each binding protocol.
  The builder can be extended to generate this list. Initially based on
configured bindings. Ultimately I'd like to see the list populated with
promoted endpoints as well rather than relying on $promoted$ services. Not
something for the first iteration though.

2) An SCA reference has 0..N Endpoints depending on the multiplicity of the
reference.
  This is already in place. The endpoints are currently created by the
builders and the output of the endpoint processing is used to
  populate the computed binding list. We need to remove this second stage
and updated the activators just to work off of Endpoints. Currently the
activators only work off Endpoints if the referenced service can't be found

3) Each endpoint has a binding interface contract. If it's not known before
the operation selector, then it's an "Any" interface with an "Any"
operation.
   In what situation isn't the binding interface contract known. It anything
I'd say it was a question of wireFormat rather than operationSelection but
I'm probably missing something here.

4) There is one invocation chain for each endpoint (based on the binding
interface contract)
  Can we merge the Endpoints we are discussing here with the EndpointRefs
that are held currently by wires?

4a) The endpoint model on the reference side should give rise to an
EndpointProvider (I'm probably convinced that we should change Resolver back
to Provider) which in turn gathers binding specific endpoint providers that
can be used to resolve the Endpoint (find the referenced service) in a
binding specific way if required.

4b) the endpoint model in the service side should also give rise to an
EndpointProvider. I can see that on the service side we can have the multple
endpoint invocation chains call into the single service invocation chain.
However on the reference side I don't think this is the case as a proxy will
be targeting a particular service over a specific binding. Hence we need to
associate the end of the reference chain with a specific binding invoker.
Won't it be better to stick with a full set of chains for each Endpoint?

I think we can leverage the endpoint idea to help us build out the RRB wires
without messing up the runtime in the mean time.

Regards

Simon

Re: Service/Reference Endpoints and Request Response Binding

[Simon Laws <si...@googlemail.com>]

On Mon, Oct 13, 2008 at 2:18 PM, Simon Laws <si...@googlemail.com>wrote:

>
>
> On Mon, Oct 13, 2008 at 2:10 PM, ant elder <an...@gmail.com> wrote:
>
>>
>>
>> On Mon, Oct 13, 2008 at 2:08 AM, Raymond Feng <en...@gmail.com>wrote:
>>
>>> I'm wondering if we can combine the Endpoint and RRB efforts together.
>>> Here are some ideas:
>>>
>>> 1) An SCA service has a list of Endpoints representing the end point for
>>> each binding protocol.
>>>
>>> 2) An SCA reference has 0..N Endpoints depending on the multiplicity of
>>> the reference.
>>>
>>> 3) Each endpoint has a binding interface contract. If it's not known
>>> before the operation selector, then it's an "Any" interface with an "Any"
>>> operation.
>>>
>>> 4) There is one invocation chain for each endpoint (based on the binding
>>> interface contract) and one for the SCA service or reference. The two
>>> invocation chains are connected as we described on the wiki page. For a SCA
>>> service configured with multiple bindings, there will be multiple endpoint
>>> invocation chains connecting to the same service invocation chain. It's
>>> similar for SCA references.
>>>
>>> Thanks,
>>> Raymond
>>>
>>>
>> From all the discussion I know what the RRB is but are there any emails or
>> doc you could point to saying what the endpoint effort is about? Or if there
>> are not yet could you give a quick summary?
>>
>>    ...ant
>>
>>
> Hi Ant
>
> Touche, you got this mail precisely the same time as I did:-) We talked
> about extending the endoint support a while back (It's on the roadmap page
> [1]) and it was discussed on the ML back in June [2]. Sebastien subsequently
> raised a JIRA and referenced the mail list [3]. I think it's a good idea to
> bring this up again now as it is related to the RRB work.
>
> Simon
>
> [1]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Roadmap+Discussion
> [2] http://marc.info/?l=tuscany-dev&m=121318046912690&w=2
> [3] http://issues.apache.org/jira/browse/TUSCANY-2382
>

And I managed to reply to your mail without giving a summary of what one of
the Endpoints we are talking about is. It's basically the result of
combining a reference with a binding or a service with a binding. It
describes the physical Endpoint (for want of a better word) that  produces
or consumes messages. Originally instigated to straighten out the
binding/reference multiplicity confusion but could be applied to services
also. Needs reviewing now in light of the RRB discussion, mainly because
wires also have endpoints but they are slightly different.

Hope that helps.

Simon

Re: Service/Reference Endpoints and Request Response Binding

[Simon Laws <si...@googlemail.com>]

On Mon, Oct 13, 2008 at 2:10 PM, ant elder <an...@gmail.com> wrote:

>
>
> On Mon, Oct 13, 2008 at 2:08 AM, Raymond Feng <en...@gmail.com> wrote:
>
>> I'm wondering if we can combine the Endpoint and RRB efforts together.
>> Here are some ideas:
>>
>> 1) An SCA service has a list of Endpoints representing the end point for
>> each binding protocol.
>>
>> 2) An SCA reference has 0..N Endpoints depending on the multiplicity of
>> the reference.
>>
>> 3) Each endpoint has a binding interface contract. If it's not known
>> before the operation selector, then it's an "Any" interface with an "Any"
>> operation.
>>
>> 4) There is one invocation chain for each endpoint (based on the binding
>> interface contract) and one for the SCA service or reference. The two
>> invocation chains are connected as we described on the wiki page. For a SCA
>> service configured with multiple bindings, there will be multiple endpoint
>> invocation chains connecting to the same service invocation chain. It's
>> similar for SCA references.
>>
>> Thanks,
>> Raymond
>>
>>
> From all the discussion I know what the RRB is but are there any emails or
> doc you could point to saying what the endpoint effort is about? Or if there
> are not yet could you give a quick summary?
>
>    ...ant
>
>
Hi Ant

Touche, you got this mail precisely the same time as I did:-) We talked
about extending the endoint support a while back (It's on the roadmap page
[1]) and it was discussed on the ML back in June [2]. Sebastien subsequently
raised a JIRA and referenced the mail list [3]. I think it's a good idea to
bring this up again now as it is related to the RRB work.

Simon

[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Roadmap+Discussion
[2] http://marc.info/?l=tuscany-dev&m=121318046912690&w=2
[3] http://issues.apache.org/jira/browse/TUSCANY-2382

Re: Service/Reference Endpoints and Request Response Binding

[ant elder <an...@gmail.com>]

On Mon, Oct 13, 2008 at 2:08 AM, Raymond Feng <en...@gmail.com> wrote:

> I'm wondering if we can combine the Endpoint and RRB efforts together. Here
> are some ideas:
>
> 1) An SCA service has a list of Endpoints representing the end point for
> each binding protocol.
>
> 2) An SCA reference has 0..N Endpoints depending on the multiplicity of the
> reference.
>
> 3) Each endpoint has a binding interface contract. If it's not known before
> the operation selector, then it's an "Any" interface with an "Any"
> operation.
>
> 4) There is one invocation chain for each endpoint (based on the binding
> interface contract) and one for the SCA service or reference. The two
> invocation chains are connected as we described on the wiki page. For a SCA
> service configured with multiple bindings, there will be multiple endpoint
> invocation chains connecting to the same service invocation chain. It's
> similar for SCA references.
>
> Thanks,
> Raymond
>
>
>From all the discussion I know what the RRB is but are there any emails or
doc you could point to saying what the endpoint effort is about? Or if there
are not yet could you give a quick summary?

   ...ant