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