On Sep 7, 2006, at 6:46 AM, Jim Marino wrote:
On Sep 7, 2006, at 6:35 AM, ant elder wrote:
On 9/7/06, Jim Marino <[EMAIL PROTECTED]> wrote:
On Sep 7, 2006, at 2:01 AM, ant elder wrote:
> On 9/7/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> 1) Define compatiblity of two service contracts that can be wired
>> together
>> and applicability of databinding transformations.
>>
>> * For local operations that require pass-by-reference semantics,
>> databinding
>> transformation cannot be applied because the source data and
>> transformed
>> result can run out of sync. If the two operations require
different
>> databindings, they are treated as incompatble.
>
>
> This is a bit sad. Couldn't there be some way to say pass-by-value
> is ok,
> something like the opposite of the @AllowsPassByReference
> annotation (and
> consider having this the default)?
>
We should not have pass-by-value as the default for wires between
local services since local services are the default type within a
composite mandated by the SCA spec. The notion of local services as
the default service type was put into the SCA spec to avoid the
mistake made with technologies such as early EJB where everything
was
remote. Data transformations should only occur when the target
service contract is remotable. If a target service is remotable,
allows pass-by-ref, and a data transform is required, the resulting
wire will be by-val.
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.
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.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
