REPORTER: Peter Peshev (SAP)

http://lists.oasis-open.org/archives/sca-assembly/200710/msg00013.html


TARGET: Assembly spec - section 1.5.2 (Bidirectional Interfaces)

DESCRIPTION:
The assembly spec allows for some of the implementation types to have
advanced callback semantic which allows by dynamic usage of API to
redirect the callback to a different endpoint that would receive the
reply to the original request.
I.e. component A calls B, however the callback reply to this call is
sent directly to a component C
/*assuming the code inside has invoked -
setCallback(c_serviceReference); */)


Such "trio" of components introduces the following issues :

 - There are two components (C and A in the example) that communicate
directly without having wire in SCDL-s. That introduces hidden
dependencies to the administrator /assembler who is not familiar with
the implementation code.
For example changes in the policies / services of component C could lead
to runtime errors in the code of other working components, and there is
no good way to detect this at design\deploy time. /*I am assuming
setting a callback dynamically via API should still invoke the algorithm
in the policy framework for checking the validity of the wiring*/

 - some bindings may not be able to handle such "logical" reply-to-s
that are different than the "physical" one, for example in the
ws.binding the wsa:ReplyTo probably cannot be used to represent the
SCA callbackID defined in the java specs.
(issue #2 in the bindings TC)

 - It should be clarified when callbacks are dynamically set what are
the requirements in terms of policies (same as for static callbacks
?)and what should happen in case these are not fulfilled (raise an
exception after setCallback() ? or pass the calls to the target
component and raise exceptions when there is attempt to use the callback
channel ?)
 
 

PROPOSAL:
Drop this feature and ask Java and C++ TCs to adjust, alternative there
could be some way (new policy intent ?) to indicate whether a component
will use dynamic callbacks and whether binding / implementation types
can support it.