Hi, I think Scott is on the right point here when he broadened the question. The underlying question is whether or not annotations are required to make this work. I would assert that they should not be. A component can be defined such that the fwd/callback pair is made known to the runtime without modifying the Intf Def (ID) itself. The whole point is that there are times when the ID source cannot be modified. The WSDL->Java case that Scott describes is one such case, but it's not the strongest argument. Often, IDs are put under strict governance control which is intended to reduce the rate of change introduced to the ID, and thus improve stability and consistency.
There are some who believe that annotations create an undesirable form of tight coupling, and as a result forbid their use. I have some sympathy with that argument, though the value of annotations is sometimes worth the cost. The trade-off depends on the anticipated lifetime of the project, the degree of re-use that is expected, etc. We have tried, in the specs, to respect this view of the world. Dave ----- Original Message ----- From: Scott Kurz To: [email protected] Sent: Wednesday, October 29, 2008 11:14 AM Subject: Re: question on @Callback reference from forward interface OK, I see that the annotation is helpful especially from the client side to deduce the Java class of the callback interface (on the service/target side we have the type of the @Callback to guide us). If we were able to pursue my idea (and we decided we wanted to), then from the perspective of a client component we could start from the callbackInterface on the component reference interface definition and look at what interfaces the client implements (one of which should be the callback). ---- I realize I should broaden my question a bit... it's not strictly speaking the top-down case I'm asking about but more generally the case in which the component definition explicitly connects the forward/callback interfaces on the component reference definition. On Wed, Oct 29, 2008 at 10:07 AM, Simon Laws <[EMAIL PROTECTED]> wrote: On Wed, Oct 29, 2008 at 1:35 PM, Scott Kurz <[EMAIL PROTECTED]> wrote: Hi Simon, So from the client-side I have a reference configured with a bidirectional interface (forward/callback pair). So the runtime should know to which client component direct the callback from this config (I'm just talking about which component not which component instance). If that resolves to another Java impl in the domain, that impl has an @Callback-annotated field/setter, which seems to fulfill the purpose you described. So it seems there must be some other reason. On Wed, Oct 29, 2008 at 8:12 AM, Simon Laws <[EMAIL PROTECTED]> wrote: On Tue, Oct 28, 2008 at 2:35 PM, Scott Kurz <[EMAIL PROTECTED]> wrote: I noticed an annoyance in the scenario that we are developing in a top-down style, starting with two WSDL interfaces, which we wish to use as a forward/callback pair. Since this is top-down, we generate Java interfaces from each WSDL using something like wsimport. The annoyance is that I have to go and add an @Callback(MyCallbackIntf.class) to the generated forward interface, to link the two interfaces together. In a quick test it seemed that if I didn't do that I had problems (maybe I should try another test, but wanted to throw this out for discussion first...) Strikes me as ugly to have to add an SCA intf to generated code.... Now, I realize the OSOA Java annotations/apis implies that you need to do this. But I was wondering, if the component configures an <interface.wsdl ... interface=".." callbackInterface".."> then shouldn't that be enough to link the two? Or is there some need for the runtime to be able to look at the forward intf Class object and determine the callback intf Class that I'm not seeing, (perhaps for some particular API I'm not paying attention to)? Any thoughts? Thanks, Scott Hi Scott I haven't looked at the details of the code on this but I imagine the runtime needs some help in deciding where to inject the callback reference, assuming that injection is required. If it only had a WSDL document as a guide to the type of the callback reference for a given service interface then it wouldn't necessarily be able to map from the WSDL to the Java type. For example, in the case where you have mapped from WSDL to Java manually. Sound plausible? Simon But can it deduce the java type of the callback interface? You're right I was using the implementation.java case to justify why this is important. Simon
