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
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, November 28, 2006 8:14 AM
Subject: Re: Pass-by-value support for remotable interfaces
On Nov 28, 2006, at 4:38 AM, scabooz wrote:
Hi guys,
Only one comment on #7 below.
Dave
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, November 27, 2006 6:43 PM
Subject: Re: Pass-by-value support for remotable interfaces
On Nov 27, 2006, at 2:58 PM, Raymond Feng wrote:
Hi,
The SCA spec says "Independent of whether the remotable service is
called remotely from outside the process where the service runs or
from another component running in the same process, the data exchange
semantics are by-value."
I plan to add this support. To trigger more discussions, here are
some points to brainstorm.
1) It will apply to a wire with remotable interfaces for the source
and target.
2) We need to take "AllowsPassByReference" into consideration in the
ServiceContract
3) An interceptor will be added to the invocation chain to enforce
the "pass-by-value" semantics by data transformation if necessary
4) How we copy the value depends on the databinding for the given
argument or return value of an operation. A databinding provider can
implement the "copy" method to control how the copy will be made.
We should find a way to not make this necessary in the programming
model except for maybe a few edge cases. This was related to the
discussion a while back about not having to specify the data binding
type as annotations. Like you mention below, in addition to cloning
and serializable (maybe without the need to marshall class
descriptors) we could support XStream for POJOs? I think the end user
experience should be really simple and this copy will hopefully in 90%
of the cases transparent. Also, we should probably tell people that
they should use @AllowsByReference in all cases possible since
performance of the copy will introduce significant overhead for
remotable services.
Object copy(Object source, TransformationContext context);
5) For objects without exlicit databinding (in which case, we assume
it's plain java databinding), we'll use techniques:
* Serilization followed by a deserialization (Serialize the data
in source context and deserialize it in target context)
* Cloning? (If the object is Cloneable, can we use the clone () to
make the copy?)
6) Some optimaization can be applied, for example, for immutable jdk
classes such as "java.lang.String" we don't have to make a copy
As one thought, it would be an interesting experiment to see if a
copy-on-write strategy could be done and whether that would improve or
degrade performance. For example, any interface-based parameter could
have a proxy substituted. I'm not sure if this would degrade
performance or make any improvements.
7) For composite services/references with bindings, can we assume
that "pass-by-value" semantics will be automatically enforeced by the
protocol layer for inter-process calls?
I would say yes, we leave this to the binding.
When is this not the case? There is always a binding between
components, even components in the same composite where
the components use a local interface. This is just an optimized
form of binding.sca (aka the default binding). In reading
Raymond's email, I thought 1-6 were all things that you were
going to do in the default binding, until I hit this point #7.
Yes conceptually they go through a default binding but here we are
talking about implementation (for Java I would say the binding is "VM"
not binding.sca since it is conceptually what exists between interface
and implementation and is by-reference but that is a minor point). When
talking implementation, "implementation binding artifacts" for local
services don't exist in the runtime and I took "leave it to the bindings"
to refer to the the implementation artifacts that support composite
services and references.
Any thoughts?
Thanks,
Raymond
--------------------------------------------------------------------
-
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]
---------------------------------------------------------------------
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]
