You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2011/08/25 16:50:49 UTC
Callback endpoints in the distributed domain
I've come across an interested collection of interconnected issues
while looking at callbacks in the distributed domain (TUSCANY-3932).
While we've done plenty of testing of this feature in the single node
domain it's not had much exercise in the distributed domain. This is a
little involved so bear with me.
When we detect that a reference is described by an interface with a
callback we fluff up a service endpoint, at the component with the
reference, in order to receive any callbacks. This endpoint is added
to the registry like any other endpoint is and it's indistinguishable
from any other endpoint (I think). For a wire where no callback
binding is configured at the service or reference we assume that the
callback adopts the binding from the forward wire. When binding.sca is
used we delegate to a suitable remote binding in the distributed
domain case. However we need to ensure that both the forward and
callback endpoints can come up successfully on different nodes but
potentially in the same JVM.
Issue 1: To allow this to happen we have to be able to configure the
default binding with a base URI as we do with any other binding.
I've put in a fix for issue 1 which involved making a small fix to
binding.hazelcast but apart from that was straightforward. The
implication of this fix though is that binding.sca adopts an absolute
binding URL when a remote delegate binding is in use. The forward call
will transmit the URI of the callback endpoint binding in a protocol
specific way. Before this change this was always the structural URI of
the callback endpoint. The target service would then use this to
lookup the endpoint in the registry so maintaining a certain symmetry
of operation in the binding.sca case.
Issue 2: The assumption that the target service can look up a callback
endpoint in the registry based on the URI passed with the forward
message is flawed now (and was probably before in the case of
explicitly configured bindings).
I have a partial fix for this which assumes that the callback endpoint
is already resolved and fluffs up an endpoint with the appropriate
binding and the URL it received on the forward call. This needs more
work to make sure that policy is set correctly. Am leaving this until
the other issues are solved.
Issues 3: Given that callback endpoints are put into the registry
there is a danger that they will be mistakenly matched for forward
endpoint when just the component name is provided as input to the
match.
We should at least filter the endpoints put we currently can't
identify the difference between forward and callback endpoints. I'm
tempted to exclude callback endpoints from the registry altogether
based on the solution to Issue 2 as I don't think they are used if we
proceed with this approach. This is to TBD.
Issue 4: IMO the target service side callback infrastructure is very
confusing at the moment with number classes involved in the process
(I'm sure I made some of this b.t.w). It needs simplifying to aid
maintenance. Haven't done anything yet but I'd like to and this will
have an impact on Issues 2 and 3.
I've have fixes for the code to get distributed callback tests passing
which I will check in so we can apply a test driven approach to
solving these issues.
I'll give a little time for comments and then raise JIRA as appropriate.
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Callback endpoints in the distributed domain
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Aug 25, 2011 at 5:50 PM, Simon Laws <si...@googlemail.com> wrote:
>>>
>>
>> A lot of the these other issues follow on from this issue so I'd like
>
> I think we need to solve the other issues regardless of issues1 as
> it's possible to use interoperable bindings in both the forward and
> callback wires.
>
>> to understand if this is really the case, so could you explain what
>> you mean in more detail, perhaps showing some message flows to
>> illustrate?
>>
>> I'm asking because isn't the point of binding.sca that it doesn't need
>> a base or absolute URI
>
> Not from a user point of view but from an infrastructure point of view
> we need to be able to configure the delegate bindings in a suitable
> way. When we use an interoperable binding such as binding.ws to
> support remote calls over the default binding then we have, to date,
> adopted the web services approach for passing callback information.
> This is convenient as we don't have to create a special case for any
> bindings that we happen to choose to underpin binding.sca. The
> drawback is the issue that I've presented in that interoperable
> bindings tend to deal in absolute URLs as network protocols don't tend
> to know anything about SCA structural URIs. We could try passing the
> callback structural URI in a Tuscany specific header so it can be
> pulled out and used as appropriate. I'm more than happy to take a look
> at that. We do though still need to ask appropriate questions at the
> service about whether that is available and treat non default bindings
> in an appropriate way.
>
> it just has the service structural URI, and its
>> down to the runtime infrastructure to use that uri to work out how to
>> find the service. I'm wondering if it might be better to have the
>> runtime able to find the base uri for remote nodes and use that with
>> the service structural uri might be a better approach and that if we
>> use an absolute URI then we might lose flexibility in a dynamic
>> environment. i think thats how the hazelcast sca binding was intended
>> to work, i know you said it didn't work with callbacks but that was
>> just due to the callback headers not being flowed and if that was
>> fixed it would have worked ok wouldn't it?
>
> Right, hazelcast binding lack of callback support is unrelated. I'm
> using the web services delegate for testing.
>>
>> ...ant
>>
>
>
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
I've been thinking about this overnight and a drawback of changing the
default binding URI is that the built composite can't be re-written
maintaining it's original form. We could hold a deployedURI field (or
similar) on the default binding for this purpose and allow this to be
passed down to the delegate binding. It's still the case though that..
- the ERP structural URI should be the source of the reference URI
for matching purposed. The default binding URI feeds into this in the
case that no reference target is specified.
- the delegate binding protocol header will need to be extended to
carry the structural URI in an SCA specific way to allow for callback
reference matching
Also
- to maintain the callback endpoint in the registry for matching
purposes we'll have to add some meta-data to allow use to
differentiate if from forward endpoints to solve issue 3
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Callback endpoints in the distributed domain
Posted by Simon Laws <si...@googlemail.com>.
>>
>
> A lot of the these other issues follow on from this issue so I'd like
I think we need to solve the other issues regardless of issues1 as
it's possible to use interoperable bindings in both the forward and
callback wires.
> to understand if this is really the case, so could you explain what
> you mean in more detail, perhaps showing some message flows to
> illustrate?
>
> I'm asking because isn't the point of binding.sca that it doesn't need
> a base or absolute URI
Not from a user point of view but from an infrastructure point of view
we need to be able to configure the delegate bindings in a suitable
way. When we use an interoperable binding such as binding.ws to
support remote calls over the default binding then we have, to date,
adopted the web services approach for passing callback information.
This is convenient as we don't have to create a special case for any
bindings that we happen to choose to underpin binding.sca. The
drawback is the issue that I've presented in that interoperable
bindings tend to deal in absolute URLs as network protocols don't tend
to know anything about SCA structural URIs. We could try passing the
callback structural URI in a Tuscany specific header so it can be
pulled out and used as appropriate. I'm more than happy to take a look
at that. We do though still need to ask appropriate questions at the
service about whether that is available and treat non default bindings
in an appropriate way.
it just has the service structural URI, and its
> down to the runtime infrastructure to use that uri to work out how to
> find the service. I'm wondering if it might be better to have the
> runtime able to find the base uri for remote nodes and use that with
> the service structural uri might be a better approach and that if we
> use an absolute URI then we might lose flexibility in a dynamic
> environment. i think thats how the hazelcast sca binding was intended
> to work, i know you said it didn't work with callbacks but that was
> just due to the callback headers not being flowed and if that was
> fixed it would have worked ok wouldn't it?
Right, hazelcast binding lack of callback support is unrelated. I'm
using the web services delegate for testing.
>
> ...ant
>
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Callback endpoints in the distributed domain
Posted by ant elder <an...@gmail.com>.
On Thu, Aug 25, 2011 at 3:50 PM, Simon Laws <si...@googlemail.com> wrote:
> I've come across an interested collection of interconnected issues
> while looking at callbacks in the distributed domain (TUSCANY-3932).
> While we've done plenty of testing of this feature in the single node
> domain it's not had much exercise in the distributed domain. This is a
> little involved so bear with me.
>
> When we detect that a reference is described by an interface with a
> callback we fluff up a service endpoint, at the component with the
> reference, in order to receive any callbacks. This endpoint is added
> to the registry like any other endpoint is and it's indistinguishable
> from any other endpoint (I think). For a wire where no callback
> binding is configured at the service or reference we assume that the
> callback adopts the binding from the forward wire. When binding.sca is
> used we delegate to a suitable remote binding in the distributed
> domain case. However we need to ensure that both the forward and
> callback endpoints can come up successfully on different nodes but
> potentially in the same JVM.
>
> Issue 1: To allow this to happen we have to be able to configure the
> default binding with a base URI as we do with any other binding.
>
A lot of the these other issues follow on from this issue so I'd like
to understand if this is really the case, so could you explain what
you mean in more detail, perhaps showing some message flows to
illustrate?
I'm asking because isn't the point of binding.sca that it doesn't need
a base or absolute URI it just has the service structural URI, and its
down to the runtime infrastructure to use that uri to work out how to
find the service. I'm wondering if it might be better to have the
runtime able to find the base uri for remote nodes and use that with
the service structural uri might be a better approach and that if we
use an absolute URI then we might lose flexibility in a dynamic
environment. i think thats how the hazelcast sca binding was intended
to work, i know you said it didn't work with callbacks but that was
just due to the callback headers not being flowed and if that was
fixed it would have worked ok wouldn't it?
...ant
Re: Callback endpoints in the distributed domain
Posted by Mike Edwards <mi...@gmail.com>.
On 23/09/2011 17:06, ant elder wrote:
> On Fri, Sep 23, 2011 at 3:41 PM, Simon Nash<na...@apache.org> wrote:
>> Simon Laws wrote:
>>>
>>> snip....
>>>
>>>> 1) Supporting different binding types for the request and callback
>>>> messages is currently not supported by Tuscany, should it be?
>>>>
>>>> Not supporting this makes things much simpler so unless there is a
>>>> compelling use case for needing mixed bindings I'd like to say mixing
>>>> binding types is not supported.
>>>>
>>>
>>> While the spec doesn't outlaw it my "keep it simple" reaction would be
>>> to agree. However this would be different from what we did in 1.x so
>>> I'd like to understand the various scenarios when people might use
>>> manually configured callback bindings and see whether taking this
>>> simplification is really practical.
>>>
>>> Regards
>>>
>>> Simon
>>>
>> I'm not sure if this exactly fits, but I do recall some discussions
>> in the OASIS TC about the caller being behind a firewall and able
>> to send SOAP/HTTP requests but not able to receive SOAP/HTTP callback
>> requests.
>>
>
> That sounds reasonable in theory but in practice i wonder if there are
> actually bindings we have in Tuscany which could open up an accessible
> service endpoint if HTTP isn't possible? I'd guess JMS or RMI probably
> wouldn't work either if the firewall is blocking HTTP. An alternative
> could be the polling approach the specs describe with the noListener
> intent, we don't have support for that yet either but i wonder if that
> might be more useful to implement than to try to get multiple binding
> types working.
>
> ...ant
>
I think the discussions in the Bindings TC related to the use of WS-MakeConnection, which is the
more general mechanism provided to deal with components which are unable to offer web service
endpoints due to trivialities like firewalls. This is in effect the "polling mechanism" that Ant
describes - but it has the advantage of being a fully general spec which can be used in a variety of
cases.
I don't think that diving into the complexities of different forward & callback bindings is
justified by this usecase. Do we have any real examples where the forward call would be binding.ws
(say) and the callback binding HAS to be something else - binding.jms, say??
I understand that we don't support WS Make-Connection at the moment. If we get demand for the
capability, I think it would be better to look at adding WS-MakeConnection support.
Yours, Mike.
Re: Callback endpoints in the distributed domain
Posted by ant elder <an...@gmail.com>.
On Fri, Sep 23, 2011 at 3:41 PM, Simon Nash <na...@apache.org> wrote:
> Simon Laws wrote:
>>
>> snip....
>>
>>> 1) Supporting different binding types for the request and callback
>>> messages is currently not supported by Tuscany, should it be?
>>>
>>> Not supporting this makes things much simpler so unless there is a
>>> compelling use case for needing mixed bindings I'd like to say mixing
>>> binding types is not supported.
>>>
>>
>> While the spec doesn't outlaw it my "keep it simple" reaction would be
>> to agree. However this would be different from what we did in 1.x so
>> I'd like to understand the various scenarios when people might use
>> manually configured callback bindings and see whether taking this
>> simplification is really practical.
>>
>> Regards
>>
>> Simon
>>
> I'm not sure if this exactly fits, but I do recall some discussions
> in the OASIS TC about the caller being behind a firewall and able
> to send SOAP/HTTP requests but not able to receive SOAP/HTTP callback
> requests.
>
That sounds reasonable in theory but in practice i wonder if there are
actually bindings we have in Tuscany which could open up an accessible
service endpoint if HTTP isn't possible? I'd guess JMS or RMI probably
wouldn't work either if the firewall is blocking HTTP. An alternative
could be the polling approach the specs describe with the noListener
intent, we don't have support for that yet either but i wonder if that
might be more useful to implement than to try to get multiple binding
types working.
...ant
Re: Callback endpoints in the distributed domain
Posted by Simon Nash <na...@apache.org>.
Simon Laws wrote:
> snip....
>
>> 1) Supporting different binding types for the request and callback
>> messages is currently not supported by Tuscany, should it be?
>>
>> Not supporting this makes things much simpler so unless there is a
>> compelling use case for needing mixed bindings I'd like to say mixing
>> binding types is not supported.
>>
>
> While the spec doesn't outlaw it my "keep it simple" reaction would be
> to agree. However this would be different from what we did in 1.x so
> I'd like to understand the various scenarios when people might use
> manually configured callback bindings and see whether taking this
> simplification is really practical.
>
> Regards
>
> Simon
>
I'm not sure if this exactly fits, but I do recall some discussions
in the OASIS TC about the caller being behind a firewall and able
to send SOAP/HTTP requests but not able to receive SOAP/HTTP callback
requests.
Simon
Re: Callback endpoints in the distributed domain
Posted by Simon Laws <si...@googlemail.com>.
snip....
> 1) Supporting different binding types for the request and callback
> messages is currently not supported by Tuscany, should it be?
>
> Not supporting this makes things much simpler so unless there is a
> compelling use case for needing mixed bindings I'd like to say mixing
> binding types is not supported.
>
While the spec doesn't outlaw it my "keep it simple" reaction would be
to agree. However this would be different from what we did in 1.x so
I'd like to understand the various scenarios when people might use
manually configured callback bindings and see whether taking this
simplification is really practical.
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Fwd: Callback endpoints in the distributed domain
Posted by ant elder <an...@gmail.com>.
Following on from the thread forwarded below i've been looking at
whats presently supported for callbacks and adding some tests in the
callback-two-nodes itest and from that have some questions we need to
answer to decide what should be supported. The spec defines how you
can configure a callback binding on both a reference and a service.
The spec says nothing about how the service and reference config
should match or what to do if they don't, and this means in theory you
may have different binding types used for the request and callbacks,
and that you could define some config on the service callback and also
define some different possibly conflicting config on the reference
callback.
So the first question is:
1) Supporting different binding types for the request and callback
messages is currently not supported by Tuscany, should it be?
Not supporting this makes things much simpler so unless there is a
compelling use case for needing mixed bindings I'd like to say mixing
binding types is not supported.
...ant
---------- Forwarded message ----------
From: Simon Laws <si...@googlemail.com>
Date: Thu, Aug 25, 2011 at 3:50 PM
Subject: Callback endpoints in the distributed domain
To: tuscany-dev <de...@tuscany.apache.org>
I've come across an interested collection of interconnected issues
while looking at callbacks in the distributed domain (TUSCANY-3932).
While we've done plenty of testing of this feature in the single node
domain it's not had much exercise in the distributed domain. This is a
little involved so bear with me.
When we detect that a reference is described by an interface with a
callback we fluff up a service endpoint, at the component with the
reference, in order to receive any callbacks. This endpoint is added
to the registry like any other endpoint is and it's indistinguishable
from any other endpoint (I think). For a wire where no callback
binding is configured at the service or reference we assume that the
callback adopts the binding from the forward wire. When binding.sca is
used we delegate to a suitable remote binding in the distributed
domain case. However we need to ensure that both the forward and
callback endpoints can come up successfully on different nodes but
potentially in the same JVM.
Issue 1: To allow this to happen we have to be able to configure the
default binding with a base URI as we do with any other binding.
I've put in a fix for issue 1 which involved making a small fix to
binding.hazelcast but apart from that was straightforward. The
implication of this fix though is that binding.sca adopts an absolute
binding URL when a remote delegate binding is in use. The forward call
will transmit the URI of the callback endpoint binding in a protocol
specific way. Before this change this was always the structural URI of
the callback endpoint. The target service would then use this to
lookup the endpoint in the registry so maintaining a certain symmetry
of operation in the binding.sca case.
Issue 2: The assumption that the target service can look up a callback
endpoint in the registry based on the URI passed with the forward
message is flawed now (and was probably before in the case of
explicitly configured bindings).
I have a partial fix for this which assumes that the callback endpoint
is already resolved and fluffs up an endpoint with the appropriate
binding and the URL it received on the forward call. This needs more
work to make sure that policy is set correctly. Am leaving this until
the other issues are solved.
Issues 3: Given that callback endpoints are put into the registry
there is a danger that they will be mistakenly matched for forward
endpoint when just the component name is provided as input to the
match.
We should at least filter the endpoints put we currently can't
identify the difference between forward and callback endpoints. I'm
tempted to exclude callback endpoints from the registry altogether
based on the solution to Issue 2 as I don't think they are used if we
proceed with this approach. This is to TBD.
Issue 4: IMO the target service side callback infrastructure is very
confusing at the moment with number classes involved in the process
(I'm sure I made some of this b.t.w). It needs simplifying to aid
maintenance. Haven't done anything yet but I'd like to and this will
have an impact on Issues 2 and 3.
I've have fixes for the code to get distributed callback tests passing
which I will check in so we can apply a test driven approach to
solving these issues.
I'll give a little time for comments and then raise JIRA as appropriate.
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Callback endpoints in the distributed domain
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Aug 26, 2011 at 10:46 AM, Simon Laws <si...@googlemail.com> wrote:
> On Fri, Aug 26, 2011 at 10:25 AM, ant elder <an...@apache.org> wrote:
>> On Fri, Aug 26, 2011 at 9:35 AM, Simon Laws <si...@googlemail.com> wrote:
>>> On Fri, Aug 26, 2011 at 9:31 AM, ant elder <an...@gmail.com> wrote:
>>>> On Thu, Aug 25, 2011 at 3:50 PM, Simon Laws <si...@googlemail.com> wrote:
>>>>
>>>>> Issues 3: Given that callback endpoints are put into the registry
>>>>> there is a danger that they will be mistakenly matched for forward
>>>>> endpoint when just the component name is provided as input to the
>>>>> match.
>>>>
>>>> For issue 3 about callback endpoints getting found in the registry by
>>>> accident how about instead of tacking "Callback" on the service name
>>>> put it on the component name?
>>>>
>>>> ...ant
>>>>
>>>
>>> Do you mean in the xml that fluffed up when an endpoint is serialized?
>>> If so yes, I agree, something like that would work.
>>>
>>
>> Thats not quite what i meant but i've just had a look and the code
>> doesn't work the way it used to now so what i was thinking wont help.
>> If we did more complete interface matching when picking an endpoint
>> instead of just picking the first one would this issue go away? Didn't
>> Greg raise a JIRA or post to the ML about doing that a little while
>> back?
>>
>> ...ant
>>
>
> The problem with relying on remote interface matching is that it's
> difficult to be absolutely sure that two interfaces don't match, In
> some cases we'll have to defer to the runtime. For example, some Java
> types can't be converted to XML by JAXB so trying to match XML types
> will fail. Now I admit you'd have to be pretty unlucky to have you're
> callback interface match your forward interface in everything but type
> details. However I'm becoming increasingly skeptical about the
> performance of remote interface matching. You may have noticed I've
> turned if off temporarily. There seem to be several situations where
> it doesn't work properly which I don't understand well enough to
> articulate in a post yet. It's likely this is just lack of databinding
> understanding on my part. We'll see.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Although, looking at it, it does seem a shame to have to clutter the
endpoint resolution mechanism with callback discrimination code. Hmmm.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Callback endpoints in the distributed domain
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Aug 26, 2011 at 4:06 PM, ant elder <an...@apache.org> wrote:
> On Fri, Aug 26, 2011 at 10:46 AM, Simon Laws <si...@googlemail.com> wrote:
>
>> However I'm becoming increasingly skeptical about the
>> performance of remote interface matching. You may have noticed I've
>> turned if off temporarily.
>
> Yes I have noticed that now as i was using it to validate the changes
> i was doing for TUSCANY-3931 and TUSCANY-3934 but now after an svn
> update that no longer works. So whats the plan for this, is there
> going to be endpoint wsdl in the registry?
>
> ...ant
>
Ah sorry about that. Long and short is I'm looking to turn it back on again.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Callback endpoints in the distributed domain
Posted by ant elder <an...@apache.org>.
On Fri, Aug 26, 2011 at 10:46 AM, Simon Laws <si...@googlemail.com> wrote:
> However I'm becoming increasingly skeptical about the
> performance of remote interface matching. You may have noticed I've
> turned if off temporarily.
Yes I have noticed that now as i was using it to validate the changes
i was doing for TUSCANY-3931 and TUSCANY-3934 but now after an svn
update that no longer works. So whats the plan for this, is there
going to be endpoint wsdl in the registry?
...ant
Re: Callback endpoints in the distributed domain
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Aug 26, 2011 at 10:25 AM, ant elder <an...@apache.org> wrote:
> On Fri, Aug 26, 2011 at 9:35 AM, Simon Laws <si...@googlemail.com> wrote:
>> On Fri, Aug 26, 2011 at 9:31 AM, ant elder <an...@gmail.com> wrote:
>>> On Thu, Aug 25, 2011 at 3:50 PM, Simon Laws <si...@googlemail.com> wrote:
>>>
>>>> Issues 3: Given that callback endpoints are put into the registry
>>>> there is a danger that they will be mistakenly matched for forward
>>>> endpoint when just the component name is provided as input to the
>>>> match.
>>>
>>> For issue 3 about callback endpoints getting found in the registry by
>>> accident how about instead of tacking "Callback" on the service name
>>> put it on the component name?
>>>
>>> ...ant
>>>
>>
>> Do you mean in the xml that fluffed up when an endpoint is serialized?
>> If so yes, I agree, something like that would work.
>>
>
> Thats not quite what i meant but i've just had a look and the code
> doesn't work the way it used to now so what i was thinking wont help.
> If we did more complete interface matching when picking an endpoint
> instead of just picking the first one would this issue go away? Didn't
> Greg raise a JIRA or post to the ML about doing that a little while
> back?
>
> ...ant
>
The problem with relying on remote interface matching is that it's
difficult to be absolutely sure that two interfaces don't match, In
some cases we'll have to defer to the runtime. For example, some Java
types can't be converted to XML by JAXB so trying to match XML types
will fail. Now I admit you'd have to be pretty unlucky to have you're
callback interface match your forward interface in everything but type
details. However I'm becoming increasingly skeptical about the
performance of remote interface matching. You may have noticed I've
turned if off temporarily. There seem to be several situations where
it doesn't work properly which I don't understand well enough to
articulate in a post yet. It's likely this is just lack of databinding
understanding on my part. We'll see.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Callback endpoints in the distributed domain
Posted by ant elder <an...@apache.org>.
On Fri, Aug 26, 2011 at 9:35 AM, Simon Laws <si...@googlemail.com> wrote:
> On Fri, Aug 26, 2011 at 9:31 AM, ant elder <an...@gmail.com> wrote:
>> On Thu, Aug 25, 2011 at 3:50 PM, Simon Laws <si...@googlemail.com> wrote:
>>
>>> Issues 3: Given that callback endpoints are put into the registry
>>> there is a danger that they will be mistakenly matched for forward
>>> endpoint when just the component name is provided as input to the
>>> match.
>>
>> For issue 3 about callback endpoints getting found in the registry by
>> accident how about instead of tacking "Callback" on the service name
>> put it on the component name?
>>
>> ...ant
>>
>
> Do you mean in the xml that fluffed up when an endpoint is serialized?
> If so yes, I agree, something like that would work.
>
Thats not quite what i meant but i've just had a look and the code
doesn't work the way it used to now so what i was thinking wont help.
If we did more complete interface matching when picking an endpoint
instead of just picking the first one would this issue go away? Didn't
Greg raise a JIRA or post to the ML about doing that a little while
back?
...ant
Re: Callback endpoints in the distributed domain
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Aug 26, 2011 at 9:31 AM, ant elder <an...@gmail.com> wrote:
> On Thu, Aug 25, 2011 at 3:50 PM, Simon Laws <si...@googlemail.com> wrote:
>
>> Issues 3: Given that callback endpoints are put into the registry
>> there is a danger that they will be mistakenly matched for forward
>> endpoint when just the component name is provided as input to the
>> match.
>
> For issue 3 about callback endpoints getting found in the registry by
> accident how about instead of tacking "Callback" on the service name
> put it on the component name?
>
> ...ant
>
Do you mean in the xml that fluffed up when an endpoint is serialized?
If so yes, I agree, something like that would work.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Callback endpoints in the distributed domain
Posted by ant elder <an...@gmail.com>.
On Thu, Aug 25, 2011 at 3:50 PM, Simon Laws <si...@googlemail.com> wrote:
> Issues 3: Given that callback endpoints are put into the registry
> there is a danger that they will be mistakenly matched for forward
> endpoint when just the component name is provided as input to the
> match.
For issue 3 about callback endpoints getting found in the registry by
accident how about instead of tacking "Callback" on the service name
put it on the component name?
...ant