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/[email protected]/msg21065.html
---------------------------------------------------------------------
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]
