Folks,
I am happy with the general direction,
but there are questions about some of the details.
Comments inline
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email:
From:
Simon Nash <>
To:
OASIS Java <>
Date:
03/02/2009 11:35
Subject:
[sca-j] JAVA-6: Proposed direction
1. Extend the definition of @AllowsPassByReference
to make
it apply to a client-side implementation class or an individual
client reference. (This includes callback references.)
Putting it on an implementation class means that all references
within this class have AllowsPassByReference semantics.
For a
reference, AllowsPassByReference semantics are as follows:
a. The client code using the reference will not modify
passed
parameters in a separate thread.
b. The client code using the reference will not modify
passed
parameters in a callback.
c. The client code using the reference will not modify
parameters passed on one-way operations.
d. The client code using the reference will not modify
returned
result objects.
<1. There needs to be a description of
the time window for not modifying passed parameters, I
think. Basically, any passed parameters
must not be touched by the client for the period while
the called service method is running. For
synchronous request/response, this is simple to
define - ie from the point where the client
makes the invocation on the proxy method until control
returns. The "not on a separate
thread" and "not during a callback" really apply only to
that
time window. Once the initial invocation
has returned, the service should not be able to see the
passed parameters and so cannot be affected
by changes.
For one-way operations, the client has no
idea when the service method will complete and thus
the time window is effectively forever from
the point of the initial invocation.>
<2. I think that @AllowsPassByReference
has become a contract between client and service
since there are obligations on both. I
think that it might be preferably to have the Java interface
be marked with the @AllowsPassByReference
annotation - and I realize that this is a change.
As it is, the proposal requires both the
service and the client proxy to be marked with
@AllowsPassByReference>
2. Proxies injected into references that have AllowsPassbyReference
semantics (as defined in point 1 above) have AllowsPassByReference
semantics. Proxies injected into references that do
not have
AllowsPassbyReference semantics (as defined in point 1 above)
do not have AllowsPassByReference semantics.
<Hmm - as worded this is tautology and
does not say anything meaningful or enforceable.
I think it must be restated to say that where
a service impl is marked @AllowsPassByReference
then the service MUST obey the AllowsPassByReference
service semantics and that where a client
proxy is marked by @AllowsPassByReference
that the client MUST follow the AllowsPassByReference
client semantics - the semantics are spelled
out above for the client and in the current spec for the
service>
3. The SCA runtime MAY optimize a service call by passing parameters
by reference if and only if both the proxy making the call
and
the implementation method being called have AllowsPassByReference
semantics.
<I'd say "if both are marked
with @AllowsPassByReference and exist in the same JVM" >
4. Add a new method
boolean getAllowsPassByReference();
to the ServiceReference interface. The allowsPassByReference
value of a service reference can be queried using this method.
+1
5. Service references injected into references that have
AllowsPassbyReference semantics (as defined in point 1 above)
have an allowsPassByReference value of true.
+1
6. Proxies obtained by calling ServiceReference.getService()
have AllowsPassByReference semantics if and only if the
service reference has an allowsPassByReference value of
true.
+1
7. Proxies obtained by calling ComponentContext.getService() or
ComponentContext.getServices() have AllowsPassByReference
semantics if and only if the named reference has
AllowsPassByReference semantics.
<Hmm, how did the client every get to
indicate that this reference was @AllowsPassByReference
in this case? Where there is an @Reference
annotation but no point for injection then it isn't
obvious how that reference is known to be
@AllowsPassByReference. Are you expecting the
@Reference annotation to be annotated with
@AllowsPassByReference?>
8. Proxies obtained by calling RequestContext.getCallback() have
AllowsPassByReference semantics if and only if the service
implementation method has AllowsPassByReference semantics.
9. Proxies created by any means other than those stated in points
2, 6, 7 and 8 above do not have AllowsPassByReference semantics.
10. Service references obtained by casting proxies have an
allowsPassByReference value of true if and only if the proxy
has AllowsPassbyReference semantics.
11. Service references obtained by calling
ComponentContext.getServiceReference() or
ComponentContext.getServiceReferences() have AllowsPassByReference
semantics if and only if the named reference has
AllowsPassByReference semantics.
12. Service references obtained by calling
RequestContext.getCallbackReference() have AllowsPassByReference
semantics if and only if the service implementation method
has
AllowsPassByReference semantics.
13. Service references created by any means other than those
stated in points 5, 10, 11 and 12 above (including Java
deserialization or being passed across a remotable interface)
have an allowsPassByReference value of false.
Simon
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
