Please apply stage 1 of patch for TUSCANY-1341

[Simon Nash <na...@hursley.ibm.com>]

Because my patch for supporting callbacks across the Web Service binding
is quite large, I am splitting it into a series of smaller patches to
make it easier to apply.

The first of these patches adds some methods to ReferenceBindingProvider
and ServiceBinding Provider.  At present I have have placed default
implementations of the new methods in all the affected places.  These
will be replaced by fully implemented versions later.  The code to call
these new methods will be added in the next stages of this multi-part
patch.

I have rebuilt the trunk with this patch and everything seems OK.  Since
the new code isn't being called yet, there should be no effect (either
good or bad) at this stage.  I have attached the patch to TUSCANY-1341.

Here is a brief description of the new methods:

ReferenceBindingProvider.createInvoker(Operation) is a replacement for
the current method of the same name that also has a boolean isCallback
parameter.  This second parameter is no longer needed because binding
callback invokers will be created using the new method
ServiceBindingProvider.createCallbackInvoker(Operation) instead.

The supportsAsyncOneWayInvocation() method on ReferenceBindingProvider
indicates whether the provider supports non-blocking semantics for
one-way forward invocations.

The supportsAsyncOneWayInvocation() method on ServiceBindingProvider
indicates whether the provider supports non-blocking semantics for
one-way callback invocations.

The ServiceBindingProvider.createCallbackInvoker(Operation) method
creates a callback invoker for the binding.

   Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Please apply stage 1 of patch for TUSCANY-1341

[Simon Nash <na...@hursley.ibm.com>]

Comments inline.

   Simon

ant elder wrote:

> On 6/30/07, Simon Nash <na...@hursley.ibm.com> wrote:
> 
>>
>> Because my patch for supporting callbacks across the Web Service binding
>> is quite large, I am splitting it into a series of smaller patches to
>> make it easier to apply.
>>
>> The first of these patches adds some methods to ReferenceBindingProvider
>> and ServiceBinding Provider.  At present I have have placed default
>> implementations of the new methods in all the affected places.  These
>> will be replaced by fully implemented versions later.  The code to call
>> these new methods will be added in the next stages of this multi-part
>> patch.
>>
>> I have rebuilt the trunk with this patch and everything seems OK.  Since
>> the new code isn't being called yet, there should be no effect (either
>> good or bad) at this stage.  I have attached the patch to TUSCANY-1341.
>>
>> Here is a brief description of the new methods:
>>
>> ReferenceBindingProvider.createInvoker(Operation) is a replacement for
>> the current method of the same name that also has a boolean isCallback
>> parameter.  This second parameter is no longer needed because binding
>> callback invokers will be created using the new method
>> ServiceBindingProvider.createCallbackInvoker(Operation) instead.
>>
>> The supportsAsyncOneWayInvocation() method on ReferenceBindingProvider
>> indicates whether the provider supports non-blocking semantics for
>> one-way forward invocations.
>>
>> The supportsAsyncOneWayInvocation() method on ServiceBindingProvider
>> indicates whether the provider supports non-blocking semantics for
>> one-way callback invocations.
>>
>> The ServiceBindingProvider.createCallbackInvoker(Operation) method
>> creates a callback invoker for the binding.
> 
> 
> 
> Thanks, its good to be trying to keep the patches small as that does 
> make it
> much easier to understand and review them.
> 
> This is making breaking changes to the SPI that we've said we'll try real
> hard to keep stable so I'd really like it to be clear what all the changes
> are for:
> 
It depends on what you mean by breaking changes.  I rebuilt the trunk from
scratch with these changes applied and the build and tests completed OK.
Also, for the change to the createInvoker() signature, I followed the
procedure I had outlined in
   http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19410.html
by adding code as part of this patch for the core to call the new signature
and fall back to the old signature if the new signature is not available
(as would be the case for an existing extension binary).  I will do the
same for the other new SPI methods in the next round of changes when code
that calls these methods is added.  The only impact, as I explained in the
above referenced post, is that user extensions would need to be updated to
add the new signatures/methods in order to be able to compile against the
new trunk after this patch has been applied.

> - What are the new supportsAsyncOneWayInvocation methods for? If its 
> just an
> optimization so the runtime can sometimes avoid a thread switch then could
> we leave that optimization to be done later when there's a more complete
> picture on how all the async/conversational/etc stuff is working?
> 
Yes, this is "just" an optimization.  It turned out to be slightly more
than this during the debugging stage when exceptions were being swallowed
by the redundant thread and not reported back.  I could have put code in
place to work around this, but it seemed better to avoid the need for this
redundant thread to be created in the first place.  As to whether this could
be done later, see my comments below on the timing of these SPI changes.

> - Similar thing with the change of the createInvoker signature, a comment
> says "isCallback parameter is no longer used and will be removed in next
> stage of callback support", could this just be left as-is for now and the
> isCallback parameter be cleaned up later?
> 
Yes, this cleanup could be done later.  But as I exaplained in
   http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19410.html
the process of deprecation takes some time and a number of releases to
work thorough all the stages.  It seems better to me to start this
process now so that by the time we get to release 1.0 we can be on a
fully stable SPI without deprecated methods.

Please bear in mind that I did not just change these methods to new
signatures as would have been done in the past, but I posted a proposal
for an orderly deprecation and transition process which I have followed
in this patch.  We will discover (and are discovering) the need for SPI
changes between now and 1.0 and I believe we should establish a process
now for doing this in a way that minimizes disruption to Tuscany SCA
extension implementers.  If anyone would like to propose an alternative
approach for SPI deprecation, I'd be very interested to hear ideas and
discuss this.  The approach that I have outlined is the one that has
been followed by the JDK for a number of releases.

Another important point is the need for a new createCallbackInvoker
method on ServiceBindingProvider, without which it would not be possible
to implement binding callback support.  This implies the need for
changes to extension code to enable bindings to provide callback support.
Given that bindings will have to change anyway to add this method (for
which no default could be provided), it seems better to me to absorb
these other changes as part of the same update rather than impose two
rounds of disruption.

I will post the remaining patches for binding callback support today.
When people have had the chance to see the complete set of changes,
it would be good to continue this discussion and see how people think
we should be handling SPI changes between now and release 1.0.

   Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Please apply stage 1 of patch for TUSCANY-1341

[ant elder <an...@apache.org>]

On 6/30/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
> Because my patch for supporting callbacks across the Web Service binding
> is quite large, I am splitting it into a series of smaller patches to
> make it easier to apply.
>
> The first of these patches adds some methods to ReferenceBindingProvider
> and ServiceBinding Provider.  At present I have have placed default
> implementations of the new methods in all the affected places.  These
> will be replaced by fully implemented versions later.  The code to call
> these new methods will be added in the next stages of this multi-part
> patch.
>
> I have rebuilt the trunk with this patch and everything seems OK.  Since
> the new code isn't being called yet, there should be no effect (either
> good or bad) at this stage.  I have attached the patch to TUSCANY-1341.
>
> Here is a brief description of the new methods:
>
> ReferenceBindingProvider.createInvoker(Operation) is a replacement for
> the current method of the same name that also has a boolean isCallback
> parameter.  This second parameter is no longer needed because binding
> callback invokers will be created using the new method
> ServiceBindingProvider.createCallbackInvoker(Operation) instead.
>
> The supportsAsyncOneWayInvocation() method on ReferenceBindingProvider
> indicates whether the provider supports non-blocking semantics for
> one-way forward invocations.
>
> The supportsAsyncOneWayInvocation() method on ServiceBindingProvider
> indicates whether the provider supports non-blocking semantics for
> one-way callback invocations.
>
> The ServiceBindingProvider.createCallbackInvoker(Operation) method
> creates a callback invoker for the binding.


Thanks, its good to be trying to keep the patches small as that does make it
much easier to understand and review them.

This is making breaking changes to the SPI that we've said we'll try real
hard to keep stable so I'd really like it to be clear what all the changes
are for:

- What are the new supportsAsyncOneWayInvocation methods for? If its just an
optimization so the runtime can sometimes avoid a thread switch then could
we leave that optimization to be done later when there's a more complete
picture on how all the async/conversational/etc stuff is working?

- Similar thing with the change of the createInvoker signature, a comment
says "isCallback parameter is no longer used and will be removed in next
stage of callback support", could this just be left as-is for now and the
isCallback parameter be cleaned up later?

   ...ant