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: <tuscany-dev@ws.apache.org>
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]
