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

[Mike Edwards <mike_edwards@uk.ibm.com>]

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.>

<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