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 Nash (JIRA)" <tu...@ws.apache.org> on 2007/08/01 00:12:53 UTC
[jira] Created: (TUSCANY-1499) Core wiring framework should create
pseudo-services and pseudo-references for callbacks
Core wiring framework should create pseudo-services and pseudo-references for callbacks
---------------------------------------------------------------------------------------
Key: TUSCANY-1499
URL: https://issues.apache.org/jira/browse/TUSCANY-1499
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
Environment: Windows XP
Reporter: Simon Nash
Assignee: Simon Nash
Fix For: Java-SCA-Next
As proposed in [1], there are many benefits in allowing bindings to treat callbacks like regular calls rather than having to add special code to every binding to support callbacks.
The core wiring framework should be changed as described in [1] to enable this. See also the comments in [2].
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20497.html
[2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20556.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Resolved: (TUSCANY-1499) Core wiring framework should create
pseudo-services and pseudo-references for callbacks
Posted by "Raymond Feng (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Raymond Feng resolved TUSCANY-1499.
-----------------------------------
Resolution: Duplicate
Duplicate as TUSCANY-1496
> Core wiring framework should create pseudo-services and pseudo-references for callbacks
> ---------------------------------------------------------------------------------------
>
> Key: TUSCANY-1499
> URL: https://issues.apache.org/jira/browse/TUSCANY-1499
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Core Runtime
> Affects Versions: Java-SCA-Next
> Environment: Windows XP
> Reporter: Simon Nash
> Assignee: Simon Nash
> Fix For: Java-SCA-Next
>
>
> As proposed in [1], there are many benefits in allowing bindings to treat callbacks like regular calls rather than having to add special code to every binding to support callbacks.
> The core wiring framework should be changed as described in [1] to enable this. See also the comments in [2].
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20497.html
> [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20556.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should
create pseudo-services and pseudo-references for callbacks
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
>
> Simon Nash wrote:
>
>> (cut)
>>
>>> Instead of trying to establish callback wires all over the place,
>>> which will not fly anyway as soon as 2 references with callback are
>>> wired to a single service, flow the endpoint reference of the
>>> callback service representing the client in the SCA request message
>>> and use it to direct the callback.... "in context" as suggested by
>>> Raymond in thread [1].
>>>
>> These callback wires are already being established and AFAIK this
>> does work
>> in the case you describe. The callback wire is selected based on the
>> forward wire that was used. I'll write an itest to verify that this is
>> working correctly.
>>
> I created this itest and verified that it runs correctly. I have
> attached
> it to TUSCANY-1503 as a patch.
>
> Simon
>
Ok, this works now, but this JIRA is talking about a different design where:
- callbacks will be represented as (almost) regular services and references
- there will be no special processing anymore for callback wires in the
core runtime.
That's why I said in my comment "will not fly" instead of "does not fly"
:) Will this particular configuration still work with the new design,
and without all the special processing we currently have for callback wires?
In particular, with the new proposed design, a service with a callback
will be represented as a reference, if the service was wired to by
multiple clients, the reference representing the callback will have to
be wired to these multiple clients (and on them the services that
represent callbacks). This looks like a reference with multiplicity > 0,
and it doesn't look to me like the proper way to represent this wiring.
At least that alone won't allow us to select the correct client to callback.
So I think we should at least evaluate both options (establish regular
wires vs flowing endpoint references) in the context of this new design.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should
create pseudo-services and pseudo-references for callbacks
Posted by Simon Nash <na...@hursley.ibm.com>.
Simon Nash wrote:
> (cut)
>
>> Instead of trying to establish callback wires all over the place,
>> which will not fly anyway as soon as 2 references with callback are
>> wired to a single service, flow the endpoint reference of the callback
>> service representing the client in the SCA request message and use it
>> to direct the callback.... "in context" as suggested by Raymond in
>> thread [1].
>>
> These callback wires are already being established and AFAIK this does work
> in the case you describe. The callback wire is selected based on the
> forward wire that was used. I'll write an itest to verify that this is
> working correctly.
>
I created this itest and verified that it runs correctly. I have attached
it to TUSCANY-1503 as a patch.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should
create pseudo-services and pseudo-references for callbacks
Posted by Simon Nash <na...@hursley.ibm.com>.
See inline.
Simon
Jean-Sebastien Delfino wrote:
> Simon Nash wrote:
>
>> I think it would be good to step back from details of which characters
>> are
>> usable in URIs and look at the bigger picture.
>
>
> Right :)
>
>> The major question we have
>> to decide is whether the pseudo-services used by callbacks are to be
>> treated
>> from the user's perspective
>> a. exactly like SCA services in every respect
>
>
> +1
>
>> b. exactly like SCA services except for a very small number of
>> differences
>> c. as a different thing from an SCA service with its own set of rules
>> for
>> how it is used
>>
>> By treating these exactly like SCA services, I mean doing the following
>> things with them:
>> 1. Specifying as a target of a reference wire
>> 2. Specifying a callback interface and binding in addition to a forward
>> interface and binding
>> 3. Creating a ServiceReference that can be passed to setCallback()
>> 4. Creating a ServiceReference that can be used for normal forward
>> invocations
>> 5. Mapping to an endpoint URI using the standard algorithm defined in
>> the SCA assembly spec
>> 6. Enforcing name uniqueness rules with respect to other services
>> 7. Including in the calculation of whether a component only has a single
>> service so that its default URI need not include the service name
>> 8. Automatically creating an exposed endpoint on a configured host
>> server
>> There could be other aspects that I have overlooked. Please send your
>> additions to this list.
>
>
> +1 for 1 through 8
>
> I'm assuming that this is symmetric and that a callback on a service
> will work like a reference.
>
> The reference representing the callback will have its target endpoint
> configured at the time a request is received with the endpoint of the
> originator of the request. The ability to configure the endpoint of a
> reference at run-time is actually a core function of service references,
> not specific to callbacks. Although, the Java SCA API does not expose
> that capability yet, the BPEL programming model does, for regular
> references as well.
>
> Conclusion:
> - service/callback works like a regular reference
> - reference/callback works like a regular service
>
I am +1 with nearly all of this but I want to dig deeper into your
statement that the target endpoint of the callback is configured
"at the time a request is received". This is a tricky area and I am
part way through writing a post that goes into considerable detail
about exactly when the target endpoint should be configured in order
to correctly support various scenarios. I'll complete this and post
it in the next day or so for review and comment.
Simon
>>
>> As a simple solution I'd like to propose that a callback reference
>> defines
>> an SCA service with the same name as the reference, and that this service
>> can be used exactly like an SCA service except for points 1 and 2 above,
>> which are explicitly precluded by the SCA assembly spec. This callback
>> service would support all the other points on the list above and any
>> other
>> properties of SCA services that I may have overlooked in the above list.
>>
>> The soundbite version is: "Callbacks are full SCA services that can't be
>> wired and can't themselves have callbacks."
>
>
> +1 that looks like a clean and simple design to me, I also like the fact
> that the service is named exactly like the callback reference.
>
>>
>> Any thoughts or comments on this, or other suggestions?
>>
>> Simon
>>
>> Simon Nash wrote:
>>
>>> See inline.
>>>
>>> Simon
>>>
>>> Jean-Sebastien Delfino wrote:
>>>
>>> (cut)
>>>
>>>>
>>>> The # symbol has a special meaning in URIs as it separates a URI
>>>> from a fragment id. This form of URI will prevent bindings to use
>>>> fragment ids to identify the target operation or to append some
>>>> context to the URI for example.
>>>>
>>>> RFC 2396 [1], section 4.1 clearly states this:
>>>> "When a URI reference is used to perform a retrieval action on the
>>>> identified resource, the optional fragment identifier, separated from
>>>> the URI by a crosshatch ("#") character, consists of additional
>>>> reference information to be interpreted *BY THE USER AGENT* after the
>>>> retrieval action has been successfully completed. As such, *IT IS NOT
>>>> PART OF A URI*, but is often used in conjunction with a URI."
>>>>
>>>> So I don't think that using '#' is a good idea. It may work with
>>>> some bindings, will break others.
>>>>
>>>> [1] http://www.ietf.org/rfc/rfc2396.txt
>>>>
>>>>
>>> Thanks for explaining the issues with "#". There were other questions
>>> in my last post concerning the use of "/" as the separator. Since you
>>> didn't comment on these, I'm assuming that I have correctly captured
>>> the scenario that causes you concerns with this.
>>>
>>> The reference to RFC2396 is extremely helpful and provides (I think)
>>> the necessary information to come up with a good solution to your
>>> "challenge". From this document, we have a few options for the
>>> separator character.
>>>
>>> Option 1: Use semicolon (;). In section 3.3 of RFC 2394 this is defined
>>> as delimiting a parameter or parameters that are part of a path
>>> component. It seems quite appropriate to use a ";callback" suffix in
>>> the last path segment of a URI to represent a "callback" parameter.
>>>
>>> Option 2: Use any character that's legal within a path component but
>>> not legal in an NCName (used for SCA service and reference names).
>>> The possible characters are
>>> path segment characters in section 3.3:
>>> ":" | "@" | "&" | "=" | "+" | "$" | ","
>>> unreserved characters in section 2.3:
>>> "!" | "~" | "*" | "'" | "(" | ")"
>>> I don't have a strong preference here, but ":" and "@" look good to
>>> me, with "!" as a possible alternative.
>>>
>>> With any of these approaches, some kind of "callback" suffix appears
>>> explicitly in the URI, rather than relying on a SCDL naming uniqueness
>>> rule and having a URI that doesn't indicate that it's for a callback.
>>> I think having an explicit "callback" indication in the name is helpful
>>> for users, assuming that we can pick a convenient and robust syntax
>>> for this. I hope that one of the above options will satisfy this
>>> requirement.
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: [jira] Commented: (TUSCANY-1499) Core wiring framework should
create pseudo-services and pseudo-references for callbacks
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
> I think it would be good to step back from details of which characters
> are
> usable in URIs and look at the bigger picture.
Right :)
> The major question we have
> to decide is whether the pseudo-services used by callbacks are to be
> treated
> from the user's perspective
> a. exactly like SCA services in every respect
+1
> b. exactly like SCA services except for a very small number of
> differences
> c. as a different thing from an SCA service with its own set of rules
> for
> how it is used
>
> By treating these exactly like SCA services, I mean doing the following
> things with them:
> 1. Specifying as a target of a reference wire
> 2. Specifying a callback interface and binding in addition to a forward
> interface and binding
> 3. Creating a ServiceReference that can be passed to setCallback()
> 4. Creating a ServiceReference that can be used for normal forward
> invocations
> 5. Mapping to an endpoint URI using the standard algorithm defined in
> the SCA assembly spec
> 6. Enforcing name uniqueness rules with respect to other services
> 7. Including in the calculation of whether a component only has a single
> service so that its default URI need not include the service name
> 8. Automatically creating an exposed endpoint on a configured host
> server
> There could be other aspects that I have overlooked. Please send your
> additions to this list.
+1 for 1 through 8
I'm assuming that this is symmetric and that a callback on a service
will work like a reference.
The reference representing the callback will have its target endpoint
configured at the time a request is received with the endpoint of the
originator of the request. The ability to configure the endpoint of a
reference at run-time is actually a core function of service references,
not specific to callbacks. Although, the Java SCA API does not expose
that capability yet, the BPEL programming model does, for regular
references as well.
Conclusion:
- service/callback works like a regular reference
- reference/callback works like a regular service
>
> As a simple solution I'd like to propose that a callback reference
> defines
> an SCA service with the same name as the reference, and that this service
> can be used exactly like an SCA service except for points 1 and 2 above,
> which are explicitly precluded by the SCA assembly spec. This callback
> service would support all the other points on the list above and any
> other
> properties of SCA services that I may have overlooked in the above list.
>
> The soundbite version is: "Callbacks are full SCA services that can't be
> wired and can't themselves have callbacks."
+1 that looks like a clean and simple design to me, I also like the fact
that the service is named exactly like the callback reference.
>
> Any thoughts or comments on this, or other suggestions?
>
> Simon
>
> Simon Nash wrote:
>> See inline.
>>
>> Simon
>>
>> Jean-Sebastien Delfino wrote:
>>
>> (cut)
>>>
>>> The # symbol has a special meaning in URIs as it separates a URI
>>> from a fragment id. This form of URI will prevent bindings to use
>>> fragment ids to identify the target operation or to append some
>>> context to the URI for example.
>>>
>>> RFC 2396 [1], section 4.1 clearly states this:
>>> "When a URI reference is used to perform a retrieval action on the
>>> identified resource, the optional fragment identifier, separated from
>>> the URI by a crosshatch ("#") character, consists of additional
>>> reference information to be interpreted *BY THE USER AGENT* after the
>>> retrieval action has been successfully completed. As such, *IT IS NOT
>>> PART OF A URI*, but is often used in conjunction with a URI."
>>>
>>> So I don't think that using '#' is a good idea. It may work with
>>> some bindings, will break others.
>>>
>>> [1] http://www.ietf.org/rfc/rfc2396.txt
>>>
>>>
>> Thanks for explaining the issues with "#". There were other questions
>> in my last post concerning the use of "/" as the separator. Since you
>> didn't comment on these, I'm assuming that I have correctly captured
>> the scenario that causes you concerns with this.
>>
>> The reference to RFC2396 is extremely helpful and provides (I think)
>> the necessary information to come up with a good solution to your
>> "challenge". From this document, we have a few options for the
>> separator character.
>>
>> Option 1: Use semicolon (;). In section 3.3 of RFC 2394 this is defined
>> as delimiting a parameter or parameters that are part of a path
>> component. It seems quite appropriate to use a ";callback" suffix in
>> the last path segment of a URI to represent a "callback" parameter.
>>
>> Option 2: Use any character that's legal within a path component but
>> not legal in an NCName (used for SCA service and reference names).
>> The possible characters are
>> path segment characters in section 3.3:
>> ":" | "@" | "&" | "=" | "+" | "$" | ","
>> unreserved characters in section 2.3:
>> "!" | "~" | "*" | "'" | "(" | ")"
>> I don't have a strong preference here, but ":" and "@" look good to
>> me, with "!" as a possible alternative.
>>
>> With any of these approaches, some kind of "callback" suffix appears
>> explicitly in the URI, rather than relying on a SCDL naming uniqueness
>> rule and having a URI that doesn't indicate that it's for a callback.
>> I think having an explicit "callback" indication in the name is helpful
>> for users, assuming that we can pick a convenient and robust syntax
>> for this. I hope that one of the above options will satisfy this
>> requirement.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should
create pseudo-services and pseudo-references for callbacks
Posted by Simon Nash <na...@hursley.ibm.com>.
I think it would be good to step back from details of which characters are
usable in URIs and look at the bigger picture. The major question we have
to decide is whether the pseudo-services used by callbacks are to be treated
from the user's perspective
a. exactly like SCA services in every respect
b. exactly like SCA services except for a very small number of differences
c. as a different thing from an SCA service with its own set of rules for
how it is used
By treating these exactly like SCA services, I mean doing the following
things with them:
1. Specifying as a target of a reference wire
2. Specifying a callback interface and binding in addition to a forward
interface and binding
3. Creating a ServiceReference that can be passed to setCallback()
4. Creating a ServiceReference that can be used for normal forward
invocations
5. Mapping to an endpoint URI using the standard algorithm defined in
the SCA assembly spec
6. Enforcing name uniqueness rules with respect to other services
7. Including in the calculation of whether a component only has a single
service so that its default URI need not include the service name
8. Automatically creating an exposed endpoint on a configured host server
There could be other aspects that I have overlooked. Please send your
additions to this list.
As a simple solution I'd like to propose that a callback reference defines
an SCA service with the same name as the reference, and that this service
can be used exactly like an SCA service except for points 1 and 2 above,
which are explicitly precluded by the SCA assembly spec. This callback
service would support all the other points on the list above and any other
properties of SCA services that I may have overlooked in the above list.
The soundbite version is: "Callbacks are full SCA services that can't be
wired and can't themselves have callbacks."
Any thoughts or comments on this, or other suggestions?
Simon
Simon Nash wrote:
> See inline.
>
> Simon
>
> Jean-Sebastien Delfino wrote:
>
> (cut)
>>
>> The # symbol has a special meaning in URIs as it separates a URI from
>> a fragment id. This form of URI will prevent bindings to use fragment
>> ids to identify the target operation or to append some context to the
>> URI for example.
>>
>> RFC 2396 [1], section 4.1 clearly states this:
>> "When a URI reference is used to perform a retrieval action on the
>> identified resource, the optional fragment identifier, separated from
>> the URI by a crosshatch ("#") character, consists of additional
>> reference information to be interpreted *BY THE USER AGENT* after the
>> retrieval action has been successfully completed. As such, *IT IS NOT
>> PART OF A URI*, but is often used in conjunction with a URI."
>>
>> So I don't think that using '#' is a good idea. It may work with some
>> bindings, will break others.
>>
>> [1] http://www.ietf.org/rfc/rfc2396.txt
>>
>>
> Thanks for explaining the issues with "#". There were other questions
> in my last post concerning the use of "/" as the separator. Since you
> didn't comment on these, I'm assuming that I have correctly captured
> the scenario that causes you concerns with this.
>
> The reference to RFC2396 is extremely helpful and provides (I think)
> the necessary information to come up with a good solution to your
> "challenge". From this document, we have a few options for the
> separator character.
>
> Option 1: Use semicolon (;). In section 3.3 of RFC 2394 this is defined
> as delimiting a parameter or parameters that are part of a path
> component. It seems quite appropriate to use a ";callback" suffix in
> the last path segment of a URI to represent a "callback" parameter.
>
> Option 2: Use any character that's legal within a path component but
> not legal in an NCName (used for SCA service and reference names).
> The possible characters are
> path segment characters in section 3.3:
> ":" | "@" | "&" | "=" | "+" | "$" | ","
> unreserved characters in section 2.3:
> "!" | "~" | "*" | "'" | "(" | ")"
> I don't have a strong preference here, but ":" and "@" look good to
> me, with "!" as a possible alternative.
>
> With any of these approaches, some kind of "callback" suffix appears
> explicitly in the URI, rather than relying on a SCDL naming uniqueness
> rule and having a URI that doesn't indicate that it's for a callback.
> I think having an explicit "callback" indication in the name is helpful
> for users, assuming that we can pick a convenient and robust syntax
> for this. I hope that one of the above options will satisfy this
> requirement.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should
create pseudo-services and pseudo-references for callbacks
Posted by Simon Nash <na...@hursley.ibm.com>.
See inline.
Simon
Jean-Sebastien Delfino wrote:
> Simon Nash wrote:
>
>> Sorry for the delay in replying. I was away with no access to email.
>> Comments inline.
>>
>> Simon
>>
>> Jean-Sebastien Delfino wrote:
>>
>>> Simon Nash wrote:
>>>
>>>> See inline.
>>>>
>>>> Simon
>>>>
>>>> Jean-Sebastien Delfino wrote:
>>>>
>>>>> Simon Nash wrote:
>>>>>
>>>>>>
>>>>>> Jean-Sebastien Delfino wrote:
>>>>>>
>>>>>>> Simon Nash wrote:
>>>>>>>
>>>>>>>> Sorry that I missed this the first time round. See inline.
>>>>>>>>
>>>>>>>> Simon
>>>>>>>>
>>>>>>>> Jean-Sebastien Delfino wrote:
>>>>>>>>
>>>>>>>>> [snip]
>>>>>>>>>
>>>>>>>>> The important part in what I was proposing was: "and will save
>>>>>>>>> the application developer to have to understand it." ... I
>>>>>>>>> don't want the application developer to have to understand a
>>>>>>>>> Tuscany specific naming convention like $callback.Abc for
>>>>>>>>> endpoint URIs used by callbacks.
>>>>>>>>>
>>>>>>>> Where is this exposed to the application developer? The developer
>>>>>>>> does not wire callbacks or specify an explicit URI for them.
>>>>>>>> The creation
>>>>>>>> and usage of the special name should be entirely confined to the
>>>>>>>> runtime.
>>>>>>>>
>>>>>>>
>>>>>>> This is the URI where the service is available, where as an
>>>>>>> application developer, I'm going to point my TCP/IP monitor, my
>>>>>>> Web Browser, or my Web Services explorer to test the service...
>>>>>>> so I better know where it is. We've seen recurring questions and
>>>>>>> discussions on this list where it was not clear to people which
>>>>>>> URI was actually used to expose a service (as it was not explicit
>>>>>>> in the SCA assembly XML), same here for callbacks, those "special
>>>>>>> names" will come back hunt app developers every day.
>>>>>>>
>>>>>> Thanks, this helps me to understand the scenarios. I was thinking in
>>>>>> terms of service and reference names, which would not be exposed
>>>>>> (like
>>>>>> the current "$self$"." and "$promoted$." names that the runtime
>>>>>> uses).
>>>>>> The issue is when the service or reference name is used to form the
>>>>>> externally visible URI for the callback endpoint.
>>>>>>
>>>>>> If we want to do something in the spec group to address this, I think
>>>>>> the best thing to do would be to add a rule to the spec for how a URI
>>>>>> should be constructed for the endpoint that represents a callback
>>>>>> reference. This needs to be done in a way that won't collide with
>>>>>> URIs for SCDL services on the same component.
>>>>>>
>>>>>> One way to ensure that the endpoint names don't collide is to say
>>>>>> (as you have proposed):
>>>>>> 1. The name of the callback endpoint is derived from the SCDL
>>>>>> reference
>>>>>> name using the same algorithm that is currently used for services.
>>>>>> 2. Reference and service names must never be the same.
>>>>>>
>>>>>> Another way to ensure that the endpoint names don't collide is to
>>>>>> say:
>>>>>> 1. The name of the callback endpoint is derived from the SCDL
>>>>>> reference
>>>>>> name using a different algorithm than the one that is currently
>>>>>> used
>>>>>> for services. For example, it could be something like
>>>>>> <componentname>/<referencename>-callback
>>>>>> My preference would be for something like this because it makes it
>>>>>> very easy to see which URIs are for callbacks and which are for
>>>>>> "real" services.
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>
>>>>> Will that work?
>>>>>
>>>>> <component name="foo">
>>>>> <service name="bar"/> <-- this one has a callback
>>>>> <reference name="bar-callback">
>>>>> </component>
>>>>>
>>>> On the service side there is no problem, as no external endpoint URI is
>>>> created for the pseudo-reference, and I am not proposing that we change
>>>> the internal Tuscany model names from the "$callback$." scheme.
>>>>
>>>> The case that would have a problem is on the reference side:
>>>> <component name="foo">
>>>> <service name="bar-callback"/>
>>>> <reference name="bar"> <-- this one has a callback
>>>> </component>
>>>>
>>>> I was only using the "-callback" suffix is as an example to get the
>>>> discussion started. If we are trying to ensure guaranteed uniqueness
>>>> in all cases, then we need a different separator from "-" that isn't
>>>> legal for service names but is legal for URIs. What about using "/"?
>>>> The above example would then translate to:
>>>> <base-uri>/foo/bar-callback <-- the real SCDL service
>>>> <base-uri>/foo/bar/callback <-- the callback pseudo-service
>>>> As long as there is no possibility of having a SCDL service named
>>>> "bar/callback" then this will not break.
>>>>
>>>
>>> Sure it was an example, and I just gave an example of why it wouldn't
>>> work :)
>>>
>>> But remember, the main reason why I don't like that approach is that
>>> I think that make it work we'll need to come up with an ugly naming
>>> convention, and place that ugly naming convention in the face of all
>>> application developers.
>>>
>>> foo/bar/callback doesn't work either, if you have a component bar
>>> inside a (composite) component foo (as with nested composition you
>>> can't really use the component name, you have to use the component
>>> URI instead).
>>>
>> Please can you explain this in a little more detail, preferably with an
>> example. I believe you're talking about SCDL like the following:
>>
>> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
>> targetNamespace="http://sample"
>> xmlns:sample="http://sample"
>> name="OuterComposite">
>>
>> <component name="SourceComponent">
>> <implementation.composite name="sample:InnerComposite"/>
>> <reference name="targetComponentRef2"
>> target="TargetComponent2/InnerTargetService"/>
>> </component>
>>
>> <component name="TargetComponent2">
>> <implementation.composite name="sample:InnerComposite2"/>
>> </component>
>> </composite>
>>
>> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
>> targetNamespace="http://sample"
>> xmlns:sample="http://sample"
>> name="InnerComposite">
>>
>> <service name="InnerSourceService" promote="InnerSourceComponent">
>> <interface.java interface="composite.Source"/>
>> </service>
>>
>> <component name="InnerSourceComponent">
>> <implementation.java class="composite.SourceImpl"/>
>> </component>
>> <reference name="targetComponentRef2"
>> promote="InnerSourceComponent/targetReference2">
>> <interface.java interface="composite.Target"
>> callbackInterface="composite.SourceCallback"/>
>> </reference>
>> </composite>
>>
>> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
>> targetNamespace="http://sample"
>> xmlns:sample="http://sample"
>> name="InnerComposite2">
>>
>> <service name="InnerTargetService" promote="InnerTargetComponent">
>> <interface.java interface="composite.Target"
>> callbackInterface="composite.SourceCallback"/>
>> </service>
>>
>> <component name="InnerTargetComponent">
>> <implementation.java class="composite.TargetImpl"/>
>> </component>
>> </composite>
>>
>> With the "/callback" suffix approach, the URIs for the callback
>> pseudo-services
>> created for the above SCDL would be
>> <base-uri>/SourceComponent/targetComponentRef2/callback
>>
>> <base-uri>/SourceComponent/InnerSourceComponent/targetReference2/callback
>> What is the problem with non-uniqueness of these names? Are you
>> concerned
>> about having a service named "callback" within a nested component called
>> "targetCompomentRef2"? If so, the suffix for callback URIs could be
>> changed
>> to "#callback" instead of "/callback" in line with the convention
>> suggested
>> by Raymond in
>>
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Service+References
>> This would give us
>> <base-uri>/SourceComponent/targetComponentRef2#callback
>>
>> <base-uri>/SourceComponent/InnerSourceComponent/targetReference2#callback
>>
>> Does this work? If not, please be specific about the case where the
>> names
>> are not unique.
>>
>
> The # symbol has a special meaning in URIs as it separates a URI from a
> fragment id. This form of URI will prevent bindings to use fragment ids
> to identify the target operation or to append some context to the URI
> for example.
>
> RFC 2396 [1], section 4.1 clearly states this:
> "When a URI reference is used to perform a retrieval action on the
> identified resource, the optional fragment identifier, separated from
> the URI by a crosshatch ("#") character, consists of additional
> reference information to be interpreted *BY THE USER AGENT* after the
> retrieval action has been successfully completed. As such, *IT IS NOT
> PART OF A URI*, but is often used in conjunction with a URI."
>
> So I don't think that using '#' is a good idea. It may work with some
> bindings, will break others.
>
> [1] http://www.ietf.org/rfc/rfc2396.txt
>
>
Thanks for explaining the issues with "#". There were other questions
in my last post concerning the use of "/" as the separator. Since you
didn't comment on these, I'm assuming that I have correctly captured
the scenario that causes you concerns with this.
The reference to RFC2396 is extremely helpful and provides (I think)
the necessary information to come up with a good solution to your
"challenge". From this document, we have a few options for the
separator character.
Option 1: Use semicolon (;). In section 3.3 of RFC 2394 this is defined
as delimiting a parameter or parameters that are part of a path
component. It seems quite appropriate to use a ";callback" suffix in
the last path segment of a URI to represent a "callback" parameter.
Option 2: Use any character that's legal within a path component but
not legal in an NCName (used for SCA service and reference names).
The possible characters are
path segment characters in section 3.3:
":" | "@" | "&" | "=" | "+" | "$" | ","
unreserved characters in section 2.3:
"!" | "~" | "*" | "'" | "(" | ")"
I don't have a strong preference here, but ":" and "@" look good to
me, with "!" as a possible alternative.
With any of these approaches, some kind of "callback" suffix appears
explicitly in the URI, rather than relying on a SCDL naming uniqueness
rule and having a URI that doesn't indicate that it's for a callback.
I think having an explicit "callback" indication in the name is helpful
for users, assuming that we can pick a convenient and robust syntax
for this. I hope that one of the above options will satisfy this
requirement.
>>> All interested in this little challenge, please bring your proposals,
>>> prove me wrong, come up with a nice convention that works... and I'll
>>> be happy to change my position on this :)
>>>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should
create pseudo-services and pseudo-references for callbacks
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
> Sorry for the delay in replying. I was away with no access to email.
> Comments inline.
>
> Simon
>
> Jean-Sebastien Delfino wrote:
>
>> Simon Nash wrote:
>>
>>> See inline.
>>>
>>> Simon
>>>
>>> Jean-Sebastien Delfino wrote:
>>>
>>>> Simon Nash wrote:
>>>>
>>>>>
>>>>> Jean-Sebastien Delfino wrote:
>>>>>
>>>>>> Simon Nash wrote:
>>>>>>
>>>>>>> Sorry that I missed this the first time round. See inline.
>>>>>>>
>>>>>>> Simon
>>>>>>>
>>>>>>> Jean-Sebastien Delfino wrote:
>>>>>>>
>>>>>>>> [snip]
>>>>>>>>
>>>>>>>> The important part in what I was proposing was: "and will save
>>>>>>>> the application developer to have to understand it." ... I
>>>>>>>> don't want the application developer to have to understand a
>>>>>>>> Tuscany specific naming convention like $callback.Abc for
>>>>>>>> endpoint URIs used by callbacks.
>>>>>>>>
>>>>>>> Where is this exposed to the application developer? The developer
>>>>>>> does not wire callbacks or specify an explicit URI for them.
>>>>>>> The creation
>>>>>>> and usage of the special name should be entirely confined to the
>>>>>>> runtime.
>>>>>>>
>>>>>>
>>>>>> This is the URI where the service is available, where as an
>>>>>> application developer, I'm going to point my TCP/IP monitor, my
>>>>>> Web Browser, or my Web Services explorer to test the service...
>>>>>> so I better know where it is. We've seen recurring questions and
>>>>>> discussions on this list where it was not clear to people which
>>>>>> URI was actually used to expose a service (as it was not explicit
>>>>>> in the SCA assembly XML), same here for callbacks, those "special
>>>>>> names" will come back hunt app developers every day.
>>>>>>
>>>>> Thanks, this helps me to understand the scenarios. I was thinking in
>>>>> terms of service and reference names, which would not be exposed
>>>>> (like
>>>>> the current "$self$"." and "$promoted$." names that the runtime
>>>>> uses).
>>>>> The issue is when the service or reference name is used to form the
>>>>> externally visible URI for the callback endpoint.
>>>>>
>>>>> If we want to do something in the spec group to address this, I think
>>>>> the best thing to do would be to add a rule to the spec for how a URI
>>>>> should be constructed for the endpoint that represents a callback
>>>>> reference. This needs to be done in a way that won't collide with
>>>>> URIs for SCDL services on the same component.
>>>>>
>>>>> One way to ensure that the endpoint names don't collide is to say
>>>>> (as you have proposed):
>>>>> 1. The name of the callback endpoint is derived from the SCDL
>>>>> reference
>>>>> name using the same algorithm that is currently used for services.
>>>>> 2. Reference and service names must never be the same.
>>>>>
>>>>> Another way to ensure that the endpoint names don't collide is to
>>>>> say:
>>>>> 1. The name of the callback endpoint is derived from the SCDL
>>>>> reference
>>>>> name using a different algorithm than the one that is currently
>>>>> used
>>>>> for services. For example, it could be something like
>>>>> <componentname>/<referencename>-callback
>>>>> My preference would be for something like this because it makes it
>>>>> very easy to see which URIs are for callbacks and which are for
>>>>> "real" services.
>>>>>
>>>>> Simon
>>>>>
>>>>
>>>> Will that work?
>>>>
>>>> <component name="foo">
>>>> <service name="bar"/> <-- this one has a callback
>>>> <reference name="bar-callback">
>>>> </component>
>>>>
>>> On the service side there is no problem, as no external endpoint URI is
>>> created for the pseudo-reference, and I am not proposing that we change
>>> the internal Tuscany model names from the "$callback$." scheme.
>>>
>>> The case that would have a problem is on the reference side:
>>> <component name="foo">
>>> <service name="bar-callback"/>
>>> <reference name="bar"> <-- this one has a callback
>>> </component>
>>>
>>> I was only using the "-callback" suffix is as an example to get the
>>> discussion started. If we are trying to ensure guaranteed uniqueness
>>> in all cases, then we need a different separator from "-" that isn't
>>> legal for service names but is legal for URIs. What about using "/"?
>>> The above example would then translate to:
>>> <base-uri>/foo/bar-callback <-- the real SCDL service
>>> <base-uri>/foo/bar/callback <-- the callback pseudo-service
>>> As long as there is no possibility of having a SCDL service named
>>> "bar/callback" then this will not break.
>>>
>>
>> Sure it was an example, and I just gave an example of why it wouldn't
>> work :)
>>
>> But remember, the main reason why I don't like that approach is that
>> I think that make it work we'll need to come up with an ugly naming
>> convention, and place that ugly naming convention in the face of all
>> application developers.
>>
>> foo/bar/callback doesn't work either, if you have a component bar
>> inside a (composite) component foo (as with nested composition you
>> can't really use the component name, you have to use the component
>> URI instead).
>>
> Please can you explain this in a little more detail, preferably with an
> example. I believe you're talking about SCDL like the following:
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
> targetNamespace="http://sample"
> xmlns:sample="http://sample"
> name="OuterComposite">
>
> <component name="SourceComponent">
> <implementation.composite name="sample:InnerComposite"/>
> <reference name="targetComponentRef2"
> target="TargetComponent2/InnerTargetService"/>
> </component>
>
> <component name="TargetComponent2">
> <implementation.composite name="sample:InnerComposite2"/>
> </component>
> </composite>
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
> targetNamespace="http://sample"
> xmlns:sample="http://sample"
> name="InnerComposite">
>
> <service name="InnerSourceService" promote="InnerSourceComponent">
> <interface.java interface="composite.Source"/>
> </service>
>
> <component name="InnerSourceComponent">
> <implementation.java class="composite.SourceImpl"/>
> </component>
>
> <reference name="targetComponentRef2"
> promote="InnerSourceComponent/targetReference2">
> <interface.java interface="composite.Target"
> callbackInterface="composite.SourceCallback"/>
> </reference>
> </composite>
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
> targetNamespace="http://sample"
> xmlns:sample="http://sample"
> name="InnerComposite2">
>
> <service name="InnerTargetService" promote="InnerTargetComponent">
> <interface.java interface="composite.Target"
> callbackInterface="composite.SourceCallback"/>
> </service>
>
> <component name="InnerTargetComponent">
> <implementation.java class="composite.TargetImpl"/>
> </component>
> </composite>
>
> With the "/callback" suffix approach, the URIs for the callback
> pseudo-services
> created for the above SCDL would be
> <base-uri>/SourceComponent/targetComponentRef2/callback
>
> <base-uri>/SourceComponent/InnerSourceComponent/targetReference2/callback
> What is the problem with non-uniqueness of these names? Are you
> concerned
> about having a service named "callback" within a nested component called
> "targetCompomentRef2"? If so, the suffix for callback URIs could be
> changed
> to "#callback" instead of "/callback" in line with the convention
> suggested
> by Raymond in
>
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Service+References
> This would give us
> <base-uri>/SourceComponent/targetComponentRef2#callback
>
> <base-uri>/SourceComponent/InnerSourceComponent/targetReference2#callback
>
> Does this work? If not, please be specific about the case where the
> names
> are not unique.
>
The # symbol has a special meaning in URIs as it separates a URI from a
fragment id. This form of URI will prevent bindings to use fragment ids
to identify the target operation or to append some context to the URI
for example.
RFC 2396 [1], section 4.1 clearly states this:
"When a URI reference is used to perform a retrieval action on the
identified resource, the optional fragment identifier, separated from
the URI by a crosshatch ("#") character, consists of additional
reference information to be interpreted *BY THE USER AGENT* after the
retrieval action has been successfully completed. As such, *IT IS NOT
PART OF A URI*, but is often used in conjunction with a URI."
So I don't think that using '#' is a good idea. It may work with some
bindings, will break others.
[1] http://www.ietf.org/rfc/rfc2396.txt
>> All interested in this little challenge, please bring your proposals,
>> prove me wrong, come up with a nice convention that works... and I'll
>> be happy to change my position on this :)
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should
create pseudo-services and pseudo-references for callbacks
Posted by Simon Nash <na...@hursley.ibm.com>.
Sorry for the delay in replying. I was away with no access to email.
Comments inline.
Simon
Jean-Sebastien Delfino wrote:
> Simon Nash wrote:
>
>> See inline.
>>
>> Simon
>>
>> Jean-Sebastien Delfino wrote:
>>
>>> Simon Nash wrote:
>>>
>>>>
>>>> Jean-Sebastien Delfino wrote:
>>>>
>>>>> Simon Nash wrote:
>>>>>
>>>>>> Sorry that I missed this the first time round. See inline.
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>> Jean-Sebastien Delfino wrote:
>>>>>>
>>>>>>> [snip]
>>>>>>>
>>>>>>> The important part in what I was proposing was: "and will save
>>>>>>> the application developer to have to understand it." ... I don't
>>>>>>> want the application developer to have to understand a Tuscany
>>>>>>> specific naming convention like $callback.Abc for endpoint URIs
>>>>>>> used by callbacks.
>>>>>>>
>>>>>> Where is this exposed to the application developer? The developer
>>>>>> does not wire callbacks or specify an explicit URI for them. The
>>>>>> creation
>>>>>> and usage of the special name should be entirely confined to the
>>>>>> runtime.
>>>>>>
>>>>>
>>>>> This is the URI where the service is available, where as an
>>>>> application developer, I'm going to point my TCP/IP monitor, my Web
>>>>> Browser, or my Web Services explorer to test the service... so I
>>>>> better know where it is. We've seen recurring questions and
>>>>> discussions on this list where it was not clear to people which URI
>>>>> was actually used to expose a service (as it was not explicit in
>>>>> the SCA assembly XML), same here for callbacks, those "special
>>>>> names" will come back hunt app developers every day.
>>>>>
>>>> Thanks, this helps me to understand the scenarios. I was thinking in
>>>> terms of service and reference names, which would not be exposed (like
>>>> the current "$self$"." and "$promoted$." names that the runtime uses).
>>>> The issue is when the service or reference name is used to form the
>>>> externally visible URI for the callback endpoint.
>>>>
>>>> If we want to do something in the spec group to address this, I think
>>>> the best thing to do would be to add a rule to the spec for how a URI
>>>> should be constructed for the endpoint that represents a callback
>>>> reference. This needs to be done in a way that won't collide with
>>>> URIs for SCDL services on the same component.
>>>>
>>>> One way to ensure that the endpoint names don't collide is to say
>>>> (as you have proposed):
>>>> 1. The name of the callback endpoint is derived from the SCDL reference
>>>> name using the same algorithm that is currently used for services.
>>>> 2. Reference and service names must never be the same.
>>>>
>>>> Another way to ensure that the endpoint names don't collide is to say:
>>>> 1. The name of the callback endpoint is derived from the SCDL reference
>>>> name using a different algorithm than the one that is currently used
>>>> for services. For example, it could be something like
>>>> <componentname>/<referencename>-callback
>>>> My preference would be for something like this because it makes it
>>>> very easy to see which URIs are for callbacks and which are for
>>>> "real" services.
>>>>
>>>> Simon
>>>>
>>>
>>> Will that work?
>>>
>>> <component name="foo">
>>> <service name="bar"/> <-- this one has a callback
>>> <reference name="bar-callback">
>>> </component>
>>>
>> On the service side there is no problem, as no external endpoint URI is
>> created for the pseudo-reference, and I am not proposing that we change
>> the internal Tuscany model names from the "$callback$." scheme.
>>
>> The case that would have a problem is on the reference side:
>> <component name="foo">
>> <service name="bar-callback"/>
>> <reference name="bar"> <-- this one has a callback
>> </component>
>>
>> I was only using the "-callback" suffix is as an example to get the
>> discussion started. If we are trying to ensure guaranteed uniqueness
>> in all cases, then we need a different separator from "-" that isn't
>> legal for service names but is legal for URIs. What about using "/"?
>> The above example would then translate to:
>> <base-uri>/foo/bar-callback <-- the real SCDL service
>> <base-uri>/foo/bar/callback <-- the callback pseudo-service
>> As long as there is no possibility of having a SCDL service named
>> "bar/callback" then this will not break.
>>
>
> Sure it was an example, and I just gave an example of why it wouldn't
> work :)
>
> But remember, the main reason why I don't like that approach is that I
> think that make it work we'll need to come up with an ugly naming
> convention, and place that ugly naming convention in the face of all
> application developers.
>
> foo/bar/callback doesn't work either, if you have a component bar inside
> a (composite) component foo (as with nested composition you can't really
> use the component name, you have to use the component URI instead).
>
Please can you explain this in a little more detail, preferably with an
example. I believe you're talking about SCDL like the following:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
targetNamespace="http://sample"
xmlns:sample="http://sample"
name="OuterComposite">
<component name="SourceComponent">
<implementation.composite name="sample:InnerComposite"/>
<reference name="targetComponentRef2" target="TargetComponent2/InnerTargetService"/>
</component>
<component name="TargetComponent2">
<implementation.composite name="sample:InnerComposite2"/>
</component>
</composite>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
targetNamespace="http://sample"
xmlns:sample="http://sample"
name="InnerComposite">
<service name="InnerSourceService" promote="InnerSourceComponent">
<interface.java interface="composite.Source"/>
</service>
<component name="InnerSourceComponent">
<implementation.java class="composite.SourceImpl"/>
</component>
<reference name="targetComponentRef2" promote="InnerSourceComponent/targetReference2">
<interface.java interface="composite.Target" callbackInterface="composite.SourceCallback"/>
</reference>
</composite>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
targetNamespace="http://sample"
xmlns:sample="http://sample"
name="InnerComposite2">
<service name="InnerTargetService" promote="InnerTargetComponent">
<interface.java interface="composite.Target" callbackInterface="composite.SourceCallback"/>
</service>
<component name="InnerTargetComponent">
<implementation.java class="composite.TargetImpl"/>
</component>
</composite>
With the "/callback" suffix approach, the URIs for the callback pseudo-services
created for the above SCDL would be
<base-uri>/SourceComponent/targetComponentRef2/callback
<base-uri>/SourceComponent/InnerSourceComponent/targetReference2/callback
What is the problem with non-uniqueness of these names? Are you concerned
about having a service named "callback" within a nested component called
"targetCompomentRef2"? If so, the suffix for callback URIs could be changed
to "#callback" instead of "/callback" in line with the convention suggested
by Raymond in
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Service+References
This would give us
<base-uri>/SourceComponent/targetComponentRef2#callback
<base-uri>/SourceComponent/InnerSourceComponent/targetReference2#callback
Does this work? If not, please be specific about the case where the names
are not unique.
> All interested in this little challenge, please bring your proposals,
> prove me wrong, come up with a nice convention that works... and I'll be
> happy to change my position on this :)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should
create pseudo-services and pseudo-references for callbacks
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
> See inline.
>
> Simon
>
> Jean-Sebastien Delfino wrote:
>> Simon Nash wrote:
>>
>>>
>>> Jean-Sebastien Delfino wrote:
>>>
>>>> Simon Nash wrote:
>>>>
>>>>> Sorry that I missed this the first time round. See inline.
>>>>>
>>>>> Simon
>>>>>
>>>>> Jean-Sebastien Delfino wrote:
>>>>>
>>>>>> [snip]
>>>>>>
>>>>>> The important part in what I was proposing was: "and will save
>>>>>> the application developer to have to understand it." ... I don't
>>>>>> want the application developer to have to understand a Tuscany
>>>>>> specific naming convention like $callback.Abc for endpoint URIs
>>>>>> used by callbacks.
>>>>>>
>>>>> Where is this exposed to the application developer? The developer
>>>>> does not wire callbacks or specify an explicit URI for them. The
>>>>> creation
>>>>> and usage of the special name should be entirely confined to the
>>>>> runtime.
>>>>>
>>>>
>>>> This is the URI where the service is available, where as an
>>>> application developer, I'm going to point my TCP/IP monitor, my Web
>>>> Browser, or my Web Services explorer to test the service... so I
>>>> better know where it is. We've seen recurring questions and
>>>> discussions on this list where it was not clear to people which URI
>>>> was actually used to expose a service (as it was not explicit in
>>>> the SCA assembly XML), same here for callbacks, those "special
>>>> names" will come back hunt app developers every day.
>>>>
>>> Thanks, this helps me to understand the scenarios. I was thinking in
>>> terms of service and reference names, which would not be exposed (like
>>> the current "$self$"." and "$promoted$." names that the runtime uses).
>>> The issue is when the service or reference name is used to form the
>>> externally visible URI for the callback endpoint.
>>>
>>> If we want to do something in the spec group to address this, I think
>>> the best thing to do would be to add a rule to the spec for how a URI
>>> should be constructed for the endpoint that represents a callback
>>> reference. This needs to be done in a way that won't collide with
>>> URIs for SCDL services on the same component.
>>>
>>> One way to ensure that the endpoint names don't collide is to say
>>> (as you have proposed):
>>> 1. The name of the callback endpoint is derived from the SCDL reference
>>> name using the same algorithm that is currently used for services.
>>> 2. Reference and service names must never be the same.
>>>
>>> Another way to ensure that the endpoint names don't collide is to say:
>>> 1. The name of the callback endpoint is derived from the SCDL reference
>>> name using a different algorithm than the one that is currently used
>>> for services. For example, it could be something like
>>> <componentname>/<referencename>-callback
>>> My preference would be for something like this because it makes it
>>> very easy to see which URIs are for callbacks and which are for
>>> "real" services.
>>>
>>> Simon
>>>
>>
>> Will that work?
>>
>> <component name="foo">
>> <service name="bar"/> <-- this one has a callback
>> <reference name="bar-callback">
>> </component>
>>
> On the service side there is no problem, as no external endpoint URI is
> created for the pseudo-reference, and I am not proposing that we change
> the internal Tuscany model names from the "$callback$." scheme.
>
> The case that would have a problem is on the reference side:
> <component name="foo">
> <service name="bar-callback"/>
> <reference name="bar"> <-- this one has a callback
> </component>
>
> I was only using the "-callback" suffix is as an example to get the
> discussion started. If we are trying to ensure guaranteed uniqueness
> in all cases, then we need a different separator from "-" that isn't
> legal for service names but is legal for URIs. What about using "/"?
> The above example would then translate to:
> <base-uri>/foo/bar-callback <-- the real SCDL service
> <base-uri>/foo/bar/callback <-- the callback pseudo-service
> As long as there is no possibility of having a SCDL service named
> "bar/callback" then this will not break.
>
Sure it was an example, and I just gave an example of why it wouldn't
work :)
But remember, the main reason why I don't like that approach is that I
think that make it work we'll need to come up with an ugly naming
convention, and place that ugly naming convention in the face of all
application developers.
foo/bar/callback doesn't work either, if you have a component bar inside
a (composite) component foo (as with nested composition you can't really
use the component name, you have to use the component URI instead).
All interested in this little challenge, please bring your proposals,
prove me wrong, come up with a nice convention that works... and I'll be
happy to change my position on this :)
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should
create pseudo-services and pseudo-references for callbacks
Posted by Simon Nash <na...@hursley.ibm.com>.
See inline.
Simon
Jean-Sebastien Delfino wrote:
> Simon Nash wrote:
>
>>
>> Jean-Sebastien Delfino wrote:
>>
>>> Simon Nash wrote:
>>>
>>>> Sorry that I missed this the first time round. See inline.
>>>>
>>>> Simon
>>>>
>>>> Jean-Sebastien Delfino wrote:
>>>>
>>>>> [snip]
>>>>>
>>>>> The important part in what I was proposing was: "and will save the
>>>>> application developer to have to understand it." ... I don't want
>>>>> the application developer to have to understand a Tuscany specific
>>>>> naming convention like $callback.Abc for endpoint URIs used by
>>>>> callbacks.
>>>>>
>>>> Where is this exposed to the application developer? The developer
>>>> does not wire callbacks or specify an explicit URI for them. The
>>>> creation
>>>> and usage of the special name should be entirely confined to the
>>>> runtime.
>>>>
>>>
>>> This is the URI where the service is available, where as an
>>> application developer, I'm going to point my TCP/IP monitor, my Web
>>> Browser, or my Web Services explorer to test the service... so I
>>> better know where it is. We've seen recurring questions and
>>> discussions on this list where it was not clear to people which URI
>>> was actually used to expose a service (as it was not explicit in the
>>> SCA assembly XML), same here for callbacks, those "special names"
>>> will come back hunt app developers every day.
>>>
>> Thanks, this helps me to understand the scenarios. I was thinking in
>> terms of service and reference names, which would not be exposed (like
>> the current "$self$"." and "$promoted$." names that the runtime uses).
>> The issue is when the service or reference name is used to form the
>> externally visible URI for the callback endpoint.
>>
>> If we want to do something in the spec group to address this, I think
>> the best thing to do would be to add a rule to the spec for how a URI
>> should be constructed for the endpoint that represents a callback
>> reference. This needs to be done in a way that won't collide with
>> URIs for SCDL services on the same component.
>>
>> One way to ensure that the endpoint names don't collide is to say
>> (as you have proposed):
>> 1. The name of the callback endpoint is derived from the SCDL reference
>> name using the same algorithm that is currently used for services.
>> 2. Reference and service names must never be the same.
>>
>> Another way to ensure that the endpoint names don't collide is to say:
>> 1. The name of the callback endpoint is derived from the SCDL reference
>> name using a different algorithm than the one that is currently used
>> for services. For example, it could be something like
>> <componentname>/<referencename>-callback
>> My preference would be for something like this because it makes it
>> very easy to see which URIs are for callbacks and which are for
>> "real" services.
>>
>> Simon
>>
>
> Will that work?
>
> <component name="foo">
> <service name="bar"/> <-- this one has a callback
> <reference name="bar-callback">
> </component>
>
On the service side there is no problem, as no external endpoint URI is
created for the pseudo-reference, and I am not proposing that we change
the internal Tuscany model names from the "$callback$." scheme.
The case that would have a problem is on the reference side:
<component name="foo">
<service name="bar-callback"/>
<reference name="bar"> <-- this one has a callback
</component>
I was only using the "-callback" suffix is as an example to get the
discussion started. If we are trying to ensure guaranteed uniqueness
in all cases, then we need a different separator from "-" that isn't
legal for service names but is legal for URIs. What about using "/"?
The above example would then translate to:
<base-uri>/foo/bar-callback <-- the real SCDL service
<base-uri>/foo/bar/callback <-- the callback pseudo-service
As long as there is no possibility of having a SCDL service named
"bar/callback" then this will not break.
> If I understood what you proposed correctly, the service's callback and
> the reference will end up with the same URI.
>
> I really don't know what kind of convention we could use here. Can
> anyone think of an automatic naming convention that won't break and will
> still be obvious to the app developer?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should
create pseudo-services and pseudo-references for callbacks
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
>
> Jean-Sebastien Delfino wrote:
>
>> Simon Nash wrote:
>>
>>> Sorry that I missed this the first time round. See inline.
>>>
>>> Simon
>>>
>>> Jean-Sebastien Delfino wrote:
>>>
>>>> [snip]
>>>>
>>>> The important part in what I was proposing was: "and will save the
>>>> application developer to have to understand it." ... I don't want
>>>> the application developer to have to understand a Tuscany specific
>>>> naming convention like $callback.Abc for endpoint URIs used by
>>>> callbacks.
>>>>
>>> Where is this exposed to the application developer? The developer
>>> does not wire callbacks or specify an explicit URI for them. The
>>> creation
>>> and usage of the special name should be entirely confined to the
>>> runtime.
>>>
>>
>> This is the URI where the service is available, where as an
>> application developer, I'm going to point my TCP/IP monitor, my Web
>> Browser, or my Web Services explorer to test the service... so I
>> better know where it is. We've seen recurring questions and
>> discussions on this list where it was not clear to people which URI
>> was actually used to expose a service (as it was not explicit in the
>> SCA assembly XML), same here for callbacks, those "special names"
>> will come back hunt app developers every day.
>>
> Thanks, this helps me to understand the scenarios. I was thinking in
> terms of service and reference names, which would not be exposed (like
> the current "$self$"." and "$promoted$." names that the runtime uses).
> The issue is when the service or reference name is used to form the
> externally visible URI for the callback endpoint.
>
> If we want to do something in the spec group to address this, I think
> the best thing to do would be to add a rule to the spec for how a URI
> should be constructed for the endpoint that represents a callback
> reference. This needs to be done in a way that won't collide with
> URIs for SCDL services on the same component.
>
> One way to ensure that the endpoint names don't collide is to say
> (as you have proposed):
> 1. The name of the callback endpoint is derived from the SCDL reference
> name using the same algorithm that is currently used for services.
> 2. Reference and service names must never be the same.
>
> Another way to ensure that the endpoint names don't collide is to say:
> 1. The name of the callback endpoint is derived from the SCDL reference
> name using a different algorithm than the one that is currently used
> for services. For example, it could be something like
> <componentname>/<referencename>-callback
> My preference would be for something like this because it makes it
> very easy to see which URIs are for callbacks and which are for
> "real" services.
>
> Simon
>
Will that work?
<component name="foo">
<service name="bar"/> <-- this one has a callback
<reference name="bar-callback">
</component>
If I understood what you proposed correctly, the service's callback and
the reference will end up with the same URI.
I really don't know what kind of convention we could use here. Can
anyone think of an automatic naming convention that won't break and will
still be obvious to the app developer?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should
create pseudo-services and pseudo-references for callbacks
Posted by Simon Nash <na...@hursley.ibm.com>.
Jean-Sebastien Delfino wrote:
> Simon Nash wrote:
>
>> Sorry that I missed this the first time round. See inline.
>>
>> Simon
>>
>> Jean-Sebastien Delfino wrote:
>>
>>> [snip]
>>>
>>> The important part in what I was proposing was: "and will save the
>>> application developer to have to understand it." ... I don't want the
>>> application developer to have to understand a Tuscany specific naming
>>> convention like $callback.Abc for endpoint URIs used by callbacks.
>>>
>> Where is this exposed to the application developer? The developer
>> does not wire callbacks or specify an explicit URI for them. The
>> creation
>> and usage of the special name should be entirely confined to the runtime.
>>
>
> This is the URI where the service is available, where as an application
> developer, I'm going to point my TCP/IP monitor, my Web Browser, or my
> Web Services explorer to test the service... so I better know where it
> is. We've seen recurring questions and discussions on this list where it
> was not clear to people which URI was actually used to expose a service
> (as it was not explicit in the SCA assembly XML), same here for
> callbacks, those "special names" will come back hunt app developers
> every day.
>
Thanks, this helps me to understand the scenarios. I was thinking in
terms of service and reference names, which would not be exposed (like
the current "$self$"." and "$promoted$." names that the runtime uses).
The issue is when the service or reference name is used to form the
externally visible URI for the callback endpoint.
If we want to do something in the spec group to address this, I think
the best thing to do would be to add a rule to the spec for how a URI
should be constructed for the endpoint that represents a callback
reference. This needs to be done in a way that won't collide with
URIs for SCDL services on the same component.
One way to ensure that the endpoint names don't collide is to say
(as you have proposed):
1. The name of the callback endpoint is derived from the SCDL reference
name using the same algorithm that is currently used for services.
2. Reference and service names must never be the same.
Another way to ensure that the endpoint names don't collide is to say:
1. The name of the callback endpoint is derived from the SCDL reference
name using a different algorithm than the one that is currently used
for services. For example, it could be something like
<componentname>/<referencename>-callback
My preference would be for something like this because it makes it
very easy to see which URIs are for callbacks and which are for
"real" services.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should
create pseudo-services and pseudo-references for callbacks
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
> Sorry that I missed this the first time round. See inline.
>
> Simon
>
> Jean-Sebastien Delfino wrote:
>
>> [snip]
>> Simon Nash wrote:
>>
>>> See inline.
>>>
>>> Simon
>>>
>>> Jean-Sebastien Delfino (JIRA) wrote:
>>>
>>>> [
>>>> https://issues.apache.org/jira/browse/TUSCANY-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516845
>>>> ]
>>>> Jean-Sebastien Delfino commented on TUSCANY-1499:
>>>> -------------------------------------------------
>>>>
>>>> I'd suggest the following to further simplify this:
>>>>
>>>> State that a reference with a callback cannot be named like a
>>>> service State that a service with a callback cannot be named like a
>>>> reference
>>>> Take these statements as proposals to the SCA spec workgroup.
>>>>
>>>> This will save us from having to implement a complicated naming
>>>> convention for the derived callback services and callback
>>>> references, and will save the application developer to have to
>>>> understand it. I think that this is a reasonable approach for now,
>>>> as Java components for example will typically name a reference foo
>>>> and a service Foo, and as another example BPEL components already
>>>> have this naming limitation as well if I understand BPEL and WSDL
>>>> correctly.
>>>>
>>> I don't think convenience of the runtime (one particular runtime)
>>> should
>>> be made visible at the spec level. We should take the spec as is
>>> and do
>>> what we need to support it. This won't be very difficult.
>>
>>
>> The important part in what I was proposing was: "and will save the
>> application developer to have to understand it." ... I don't want the
>> application developer to have to understand a Tuscany specific naming
>> convention like $callback.Abc for endpoint URIs used by callbacks.
>>
> Where is this exposed to the application developer? The developer
> does not wire callbacks or specify an explicit URI for them. The
> creation
> and usage of the special name should be entirely confined to the runtime.
>
This is the URI where the service is available, where as an application
developer, I'm going to point my TCP/IP monitor, my Web Browser, or my
Web Services explorer to test the service... so I better know where it
is. We've seen recurring questions and discussions on this list where it
was not clear to people which URI was actually used to expose a service
(as it was not explicit in the SCA assembly XML), same here for
callbacks, those "special names" will come back hunt app developers
every day.
>> On the other hand, I'm observing that:
>> - 99% of Java components name their services and references
>> differently (actually 100% of the ones I've seen implemented so far)
>> - (unless i'm mistaken about BPEL) 100% of BPEL components will name
>> them differently
>> - and IIRC earlier versions of the SCA assembly spec had this rule as
>> well, at least in composite implementations (before the
>> service/reference promotion mechanism was introduced).
>>
>> So instead of implementing an ugly naming convention (necessarily
>> ugly to avoid naming collisions), and exposing it to application
>> developers... I'd rather go with an acceptable limitation, which may
>> actually make it back to the spec.
>>
>> I'll raise this as as an issue to the SCA assembly spec work group.
>>
>>>
>>>> Define marker interfaces ComponentCallbackService extends
>>>> ComponentService and ComponentCallbackReference extends Reference
>>>> to allow code like domain.locateService to filter out these
>>>> callback services/references and not allow them to be located
>>>> explicitly.
>>>>
>>> I'd be more inclined to do this using a method isCallback() on the
>>> Contract interface from which services and references inherit.
>>>
>>
>> +1
>>
>>>> Instead of trying to establish callback wires all over the place,
>>>> which will not fly anyway as soon as 2 references with callback are
>>>> wired to a single service, flow the endpoint reference of the
>>>> callback service representing the client in the SCA request message
>>>> and use it to direct the callback.... "in context" as suggested by
>>>> Raymond in thread [1].
>>>>
>>> These callback wires are already being established and AFAIK this
>>> does work
>>> in the case you describe. The callback wire is selected based on the
>>> forward wire that was used. I'll write an itest to verify that this is
>>> working correctly.
>>>
>>
>> Already covered in this thread:
>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21065.html
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should
create pseudo-services and pseudo-references for callbacks
Posted by Simon Nash <na...@hursley.ibm.com>.
Sorry that I missed this the first time round. See inline.
Simon
Jean-Sebastien Delfino wrote:
> [snip]
> Simon Nash wrote:
>
>> See inline.
>>
>> Simon
>>
>> Jean-Sebastien Delfino (JIRA) wrote:
>>
>>> [
>>> https://issues.apache.org/jira/browse/TUSCANY-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516845
>>> ]
>>> Jean-Sebastien Delfino commented on TUSCANY-1499:
>>> -------------------------------------------------
>>>
>>> I'd suggest the following to further simplify this:
>>>
>>> State that a reference with a callback cannot be named like a service
>>> State that a service with a callback cannot be named like a reference
>>> Take these statements as proposals to the SCA spec workgroup.
>>>
>>> This will save us from having to implement a complicated naming
>>> convention for the derived callback services and callback references,
>>> and will save the application developer to have to understand it. I
>>> think that this is a reasonable approach for now, as Java components
>>> for example will typically name a reference foo and a service Foo,
>>> and as another example BPEL components already have this naming
>>> limitation as well if I understand BPEL and WSDL correctly.
>>>
>> I don't think convenience of the runtime (one particular runtime) should
>> be made visible at the spec level. We should take the spec as is and do
>> what we need to support it. This won't be very difficult.
>
>
> The important part in what I was proposing was: "and will save the
> application developer to have to understand it." ... I don't want the
> application developer to have to understand a Tuscany specific naming
> convention like $callback.Abc for endpoint URIs used by callbacks.
>
Where is this exposed to the application developer? The developer
does not wire callbacks or specify an explicit URI for them. The creation
and usage of the special name should be entirely confined to the runtime.
> On the other hand, I'm observing that:
> - 99% of Java components name their services and references differently
> (actually 100% of the ones I've seen implemented so far)
> - (unless i'm mistaken about BPEL) 100% of BPEL components will name
> them differently
> - and IIRC earlier versions of the SCA assembly spec had this rule as
> well, at least in composite implementations (before the
> service/reference promotion mechanism was introduced).
>
> So instead of implementing an ugly naming convention (necessarily ugly
> to avoid naming collisions), and exposing it to application
> developers... I'd rather go with an acceptable limitation, which may
> actually make it back to the spec.
>
> I'll raise this as as an issue to the SCA assembly spec work group.
>
>>
>>> Define marker interfaces ComponentCallbackService extends
>>> ComponentService and ComponentCallbackReference extends Reference to
>>> allow code like domain.locateService to filter out these callback
>>> services/references and not allow them to be located explicitly.
>>>
>> I'd be more inclined to do this using a method isCallback() on the
>> Contract interface from which services and references inherit.
>>
>
> +1
>
>>> Instead of trying to establish callback wires all over the place,
>>> which will not fly anyway as soon as 2 references with callback are
>>> wired to a single service, flow the endpoint reference of the
>>> callback service representing the client in the SCA request message
>>> and use it to direct the callback.... "in context" as suggested by
>>> Raymond in thread [1].
>>>
>> These callback wires are already being established and AFAIK this does
>> work
>> in the case you describe. The callback wire is selected based on the
>> forward wire that was used. I'll write an itest to verify that this is
>> working correctly.
>>
>
> Already covered in this thread:
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21065.html
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should
create pseudo-services and pseudo-references for callbacks
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Simon Nash wrote:
> See inline.
>
> Simon
>
> Jean-Sebastien Delfino (JIRA) wrote:
>
>> [
>> https://issues.apache.org/jira/browse/TUSCANY-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516845
>> ]
>> Jean-Sebastien Delfino commented on TUSCANY-1499:
>> -------------------------------------------------
>>
>> I'd suggest the following to further simplify this:
>>
>> State that a reference with a callback cannot be named like a service
>> State that a service with a callback cannot be named like a reference
>> Take these statements as proposals to the SCA spec workgroup.
>>
>> This will save us from having to implement a complicated naming
>> convention for the derived callback services and callback references,
>> and will save the application developer to have to understand it. I
>> think that this is a reasonable approach for now, as Java components
>> for example will typically name a reference foo and a service Foo,
>> and as another example BPEL components already have this naming
>> limitation as well if I understand BPEL and WSDL correctly.
>>
> I don't think convenience of the runtime (one particular runtime) should
> be made visible at the spec level. We should take the spec as is and do
> what we need to support it. This won't be very difficult.
The important part in what I was proposing was: "and will save the
application developer to have to understand it." ... I don't want the
application developer to have to understand a Tuscany specific naming
convention like $callback.Abc for endpoint URIs used by callbacks.
On the other hand, I'm observing that:
- 99% of Java components name their services and references differently
(actually 100% of the ones I've seen implemented so far)
- (unless i'm mistaken about BPEL) 100% of BPEL components will name
them differently
- and IIRC earlier versions of the SCA assembly spec had this rule as
well, at least in composite implementations (before the
service/reference promotion mechanism was introduced).
So instead of implementing an ugly naming convention (necessarily ugly
to avoid naming collisions), and exposing it to application
developers... I'd rather go with an acceptable limitation, which may
actually make it back to the spec.
I'll raise this as as an issue to the SCA assembly spec work group.
>
>> Define marker interfaces ComponentCallbackService extends
>> ComponentService and ComponentCallbackReference extends Reference to
>> allow code like domain.locateService to filter out these callback
>> services/references and not allow them to be located explicitly.
>>
> I'd be more inclined to do this using a method isCallback() on the
> Contract interface from which services and references inherit.
>
+1
>> Instead of trying to establish callback wires all over the place,
>> which will not fly anyway as soon as 2 references with callback are
>> wired to a single service, flow the endpoint reference of the
>> callback service representing the client in the SCA request message
>> and use it to direct the callback.... "in context" as suggested by
>> Raymond in thread [1].
>>
> These callback wires are already being established and AFAIK this does
> work
> in the case you describe. The callback wire is selected based on the
> forward wire that was used. I'll write an itest to verify that this is
> working correctly.
>
Already covered in this thread:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21065.html
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should
create pseudo-services and pseudo-references for callbacks
Posted by Simon Nash <na...@hursley.ibm.com>.
See inline.
Simon
Jean-Sebastien Delfino (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/TUSCANY-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516845 ]
>
> Jean-Sebastien Delfino commented on TUSCANY-1499:
> -------------------------------------------------
>
> I'd suggest the following to further simplify this:
>
> State that a reference with a callback cannot be named like a service
> State that a service with a callback cannot be named like a reference
> Take these statements as proposals to the SCA spec workgroup.
>
> This will save us from having to implement a complicated naming convention for the derived callback services and callback references, and will save the application developer to have to understand it. I think that this is a reasonable approach for now, as Java components for example will typically name a reference foo and a service Foo, and as another example BPEL components already have this naming limitation as well if I understand BPEL and WSDL correctly.
>
I don't think convenience of the runtime (one particular runtime) should
be made visible at the spec level. We should take the spec as is and do
what we need to support it. This won't be very difficult.
> Define marker interfaces ComponentCallbackService extends ComponentService and ComponentCallbackReference extends Reference to allow code like domain.locateService to filter out these callback services/references and not allow them to be located explicitly.
>
I'd be more inclined to do this using a method isCallback() on the
Contract interface from which services and references inherit.
> Instead of trying to establish callback wires all over the place, which will not fly anyway as soon as 2 references with callback are wired to a single service, flow the endpoint reference of the callback service representing the client in the SCA request message and use it to direct the callback.... "in context" as suggested by Raymond in thread [1].
>
These callback wires are already being established and AFAIK this does work
in the case you describe. The callback wire is selected based on the
forward wire that was used. I'll write an itest to verify that this is
working correctly.
>
>
>>Core wiring framework should create pseudo-services and pseudo-references for callbacks
>>---------------------------------------------------------------------------------------
>>
>> Key: TUSCANY-1499
>> URL: https://issues.apache.org/jira/browse/TUSCANY-1499
>> Project: Tuscany
>> Issue Type: Bug
>> Components: Java SCA Core Runtime
>> Affects Versions: Java-SCA-Next
>> Environment: Windows XP
>> Reporter: Simon Nash
>> Assignee: Simon Nash
>> Fix For: Java-SCA-Next
>>
>>
>>As proposed in [1], there are many benefits in allowing bindings to treat callbacks like regular calls rather than having to add special code to every binding to support callbacks.
>>The core wiring framework should be changed as described in [1] to enable this. See also the comments in [2].
>>[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20497.html
>>[2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20556.html
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-1499) Core wiring framework should
create pseudo-services and pseudo-references for callbacks
Posted by "Jean-Sebastien Delfino (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516845 ]
Jean-Sebastien Delfino commented on TUSCANY-1499:
-------------------------------------------------
I'd suggest the following to further simplify this:
State that a reference with a callback cannot be named like a service
State that a service with a callback cannot be named like a reference
Take these statements as proposals to the SCA spec workgroup.
This will save us from having to implement a complicated naming convention for the derived callback services and callback references, and will save the application developer to have to understand it. I think that this is a reasonable approach for now, as Java components for example will typically name a reference foo and a service Foo, and as another example BPEL components already have this naming limitation as well if I understand BPEL and WSDL correctly.
Define marker interfaces ComponentCallbackService extends ComponentService and ComponentCallbackReference extends Reference to allow code like domain.locateService to filter out these callback services/references and not allow them to be located explicitly.
Instead of trying to establish callback wires all over the place, which will not fly anyway as soon as 2 references with callback are wired to a single service, flow the endpoint reference of the callback service representing the client in the SCA request message and use it to direct the callback.... "in context" as suggested by Raymond in thread [1].
> Core wiring framework should create pseudo-services and pseudo-references for callbacks
> ---------------------------------------------------------------------------------------
>
> Key: TUSCANY-1499
> URL: https://issues.apache.org/jira/browse/TUSCANY-1499
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Core Runtime
> Affects Versions: Java-SCA-Next
> Environment: Windows XP
> Reporter: Simon Nash
> Assignee: Simon Nash
> Fix For: Java-SCA-Next
>
>
> As proposed in [1], there are many benefits in allowing bindings to treat callbacks like regular calls rather than having to add special code to every binding to support callbacks.
> The core wiring framework should be changed as described in [1] to enable this. See also the comments in [2].
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20497.html
> [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20556.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org