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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
