I guess for now I'll focus on the remotable interfaces first to apply
databinding transformations. Are any of you going to take the local
interface discussion to the spec group?
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Thursday, September 07, 2006 7:20 AM
Subject: Re: Update on the databinding integration and open issues for
discussion
I don't think i'm saying pass-by-value be the default for local
services,
what i'm asking is if operations are possible between local components
using
different data bindings, and if so then it seems more user friendly
that the
default be that it just works without having to define anything extra
to
make it work.
Sure if you can do the data transformation by-value which would be
really difficult to achieve with most databinding frameworks. Otherwise
the wire must be by-ref and the only way to do that is when the target
service contract explicitly declares its remotability. This is
extremely important to be declared in the contract, as opposed to being
the default, since the semantics of the data are affected and the
client cannot treat it as by-ref.
I think there are use cases where local pass-by-value makes sense. For
example, if the data is immutable then the framework can make a copy to
a different format and not break the semantic contract. Taking this
further, if the data is mutable but the target does not modify it then
we can again make a copy and still preserve the semantic.
One way to do this would be to support something like an @ReadOnly
annotation that the target can declare on a parameter. In the local
(by-ref) case this would allow the runtime to make copies to support
incompatible data types; in the remote (by-value) case this would allow
the runtime to avoid making a copy if it didn't need to. This could also
be done at the type level with an @Immutable annotation on the class.
Yea this like a good solution as since it forces that decision to be
explicit. The notion of read-only should probably be proposed to the spec
for local services. For the remotable case, we have the "allows by-ref"
marker. That means local service contracts must explicitly declare this,
and it is not the default. For remotable contracts, the default would
imply copying of params and nothing needs to be proposed I believe.
Jim makes a good point about not repeating the mistakes from earlier
frameworks. I think the biggest mistake that they made was to focus on
the "how" (as in by-ref, by-val) semantics rather than the "what"
(read-only, immuatable) characteristics of the interaction. I think if
we do that we can provide the function Ant would like.
That's why it is "allows" instead of "is" by reference ;-) Good point,
though.
--
Jeremy
---------------------------------------------------------------------
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]