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