Hi Raymond, Thanks. I have started with this and here are a couple of questions that I need help with.
I believe the PassByValue Interceptor is good to be on the Inbound Invocation chain of the server component. Accordingly I looked up the DataBindingWirePostProcessor's method - "public void process(OutboundWire source, InboundWire target)" to do this. Over here I added the PassbyValue interceptor to the 'target'. But this did not invoke the interceptor. If I added it to the source then the interceptor gets invoked. So, am I missing something here? I understand that the interceptor that you have attached is for the default Java binding case. I will work on the databinding dependent case once I get this default stuff working. Thanks - Venkat On 12/4/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, Venkat. Thank you for volunteering. I opened a JIRA http://issues.apache.org/jira/browse/TUSCANY-969 and attached some prototype code there. Hopefully it can get you started. Thanks, Raymond ----- Original Message ----- From: "Venkata Krishnan" <[EMAIL PROTECTED]> To: <tuscany-dev@ws.apache.org> Sent: Sunday, December 03, 2006 10:08 PM Subject: Re: Pass-by-value support for remotable interfaces > Hi Raymond, > > I'm interested in helping with this. It will give me a chance to work > with > the service invocation paths of the core. Let me know if there is > something > that I help with. > > Thanks. > > - Venkat > > On 11/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote: >> >> ----- Original Message ----- >> From: "Mike Edwards" <[EMAIL PROTECTED]> >> To: <tuscany-dev@ws.apache.org > >> Sent: Wednesday, November 29, 2006 7:07 AM >> Subject: Re: Pass-by-value support for remotable interfaces >> >> >> > Raymond, >> > >> > First point I need to make is that just because two components are in >> the >> > same composite does not mean that they are automatically running in the >> > same VM or even the same operating system process. Composites can span >> > components running on different nodes (node = machine and/or o/s >> process). >> > >> >> Good catch. >> >> > Consider a composite which had component A implemented in Java and >> > component B implemented in C++. Not likely that they would run in the >> > same runtime process (certainly not with the current Tuscany runtime). >> > This is perfectly OK as long as any interface between them is >> "remotable". >> > >> > Second, more general point to make, is that there may be implied >> semantics >> > for the interface that depend on the binding used to connect the >> reference >> > to the service. Consider the case where the interface involves an >> > operation with a message having two references to the same object. >> > When >> > this is sent from consumer to provider (say), does the provider receive >> 2 >> > separate copies of the object or just one - assuming the consumer >> started >> > with only 1. >> > >> > The answer is "it depends on the binding" - RMI-IIOP says there is only >> 1 >> > copy. Web Services says there are 2 copies... >> > >> > I don't think that SCA can hide these subtle differences, much though >> > we >> > may like to do so. However, what we must guarantee is that the >> behaviour >> > matches the binding type - if the internal wire uses binding.ws, for >> > example, then we provide Web services semantics. This must be true for >> > any optimisations we may like to use in the case where both ends of the >> > wire are in 1 process - since for a remotable interface this proximity >> is >> > "accidental" and could be changed by a subtle change in deployment. >> > >> > That leaves open what to do in the case of binding.ws. We may need a >> way >> > for the composition to indicate the type of semantics required - or we >> > could default to one form (eg Web services...) >> > >> >> Should this be clarified by the SCA spec on pass-by-value? >> >> > >> > Yours, Mike. >> > >> > Raymond Feng wrote: >> >> Hi, >> >> >> >> I'm talking about the following: >> >> >> >> componentA.reference --> componentB.service1 >> >> non-SCA client --> componentB.service1 >> >> >> >> In the cases above, componentA and componentB are in the same >> >> composite >> >> >> (in the same VM). Both the service and reference are declared with a >> >> remotable interface. We need to have an interceptor to deal with the >> >> pass-by-value. >> >> >> >> For the following wirings: >> >> >> >> .. --> composite.reference >> >> composite.service --> ... >> >> >> >> I assume the binding implementation for the composite >> >> reference/service >> >> will handle the pass-by-value naturally over the transport. >> >> >> >> Thanks, >> >> Raymond >> >> >> > <snip> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
