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).
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...)
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]