[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ISSUE 4: Dynamic change of callbacks
http://www.osoa.org/jira/browse/ASSEMBLY-4 On Oct 3, 2007, at 12:09 PM, Peshev, Peter wrote: > > 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. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]