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.
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]
