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