Re: [sca-j] JAVA-6: Proposed direction

[Simon Nash <oasis@cjnash.com>]

Mike,
Responses inline.

   Simon

Mike Edwards wrote:
> 
> 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:  mike_edwards@uk.ibm.com
> 
> 
> From: 	Simon Nash <oasis@cjnash.com>
> To: 	OASIS Java <sca-j@lists.oasis-open.org>
> 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.>*
> 
I think the time window needs be "forever" in all cases.  This
is because the provider implementation might have retained a
reference to the parameters or results of the method, even after
the method has returned.  With this in mind, the rules could be
simplified to say:
   a. The client code using the reference will not modify any
      parameters passed on the call at any time after the call
      has been made.
   b. The client code using the reference will not modify a
      returned result object at any time after the call has
      returned.


> *<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>*
> 
I don't agree that it is a contract.  Just because the service
uses AllowsPassByReference semantics, there is no obligation
on the client to do likewise.  This is a runtime optimization
that can be applied if both the service implementation and the
client implementation observe certain coding conventions.
> 
>  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>*
> 
My version of this is not a tautology.  It is saying that the
AllowsPassByReference semantics declared for the reference will
be applied to proxies created by the SCA runtime for injection
into that reference.  This needs to be stated explicitly.

I'm not convinced about your version of this.  This is putting a
conformance target on something that a client or service
implementation MUST do.  I would rather say what the SCA runtime
MUST do.

> 
>  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" >*
 >
I'm OK with this change.  Minor nit: the proxy object isn't always
"marked" with this annotation.  This can be the case for points
6, 7 and 8 below.

> 
>  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?>*
> 
How can there be a @Reference annotation with no point for
injection?  For a Java implementation, the only way to create
a reference in the component type is by using @Reference (or
via the default algorithm in the Java C&I spec).  In the latter
case, these is no @AllowsPassByReference annotation so the
returned proxy would not have AllowsPassByReference semantics.
I think this API can only be called for references that are
part of the introspected component type; do you agree?

   Simon
> 
>  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/
> 
> 
> 
> 
> 
>