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: <[email protected] > 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]
