WS binding and callback changes

[ant elder <an...@gmail.com>]

Simon, I've lots track a little of all the changes you've been doing
to the Axis2 based WS binding, could you give a summary of whats being
done? I'm interested in what updates may need to be also done in the
other binding impls like the JAXWS one and if any of these callback
changes need to also be done in any of the other non-WS bindings?

   ...ant

Re: WS binding and callback changes

[Simon Laws <si...@googlemail.com>]

On Fri, Jun 18, 2010 at 9:21 AM, ant elder <an...@gmail.com> wrote:
> Thank you both for the quick replies.
>
> I'd really like to try to make the JAX-WS RI based binding be spec
> compliant as well as the Axis2 based one. Could you guys at least call
> out when you make specific changes the the Axis2 based binding so i
> notice and can update the tuscany-binding-ws-runtime-jaxws-ri (or even
> better would be if you can make the necessary changes in both binidng
> impls, but i'll understand if you don't like the extra work).
>
>   ...ant
>

I'd still like to make the two implementations a little more closely
related but my last attempt ran into the weeds. I did notice during
testing this week that the two implementations treat WSDL namespaces
slightly differently but haven't got to the bottom of it.

I propose to get rid of itest/ws-jaxws and I see you've added
launcher-base to itest/ws which sounds right and will do the same
thing as ws-jaxws but hopefully in a way that is easily shared between
jaxws and axis2 implementations.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: WS binding and callback changes

[ant elder <an...@gmail.com>]

Thank you both for the quick replies.

I'd really like to try to make the JAX-WS RI based binding be spec
compliant as well as the Axis2 based one. Could you guys at least call
out when you make specific changes the the Axis2 based binding so i
notice and can update the tuscany-binding-ws-runtime-jaxws-ri (or even
better would be if you can make the necessary changes in both binidng
impls, but i'll understand if you don't like the extra work).

   ...ant

Re: WS binding and callback changes

[Mike Edwards <mi...@gmail.com>]

ant elder wrote:
> Simon, I've lots track a little of all the changes you've been doing
> to the Axis2 based WS binding, could you give a summary of whats being
> done? I'm interested in what updates may need to be also done in the
> other binding impls like the JAXWS one and if any of these callback
> changes need to also be done in any of the other non-WS bindings?
> 
>    ...ant
> 
Ant,

I am sure that Simon will also reply to your questions, but here is an initial summary.

We've been working on getting the binding.ws implementation to meet the OASIS spec requirements - 
I've built the binding.ws test suite in the last week or so, and it is not surprising to find that 
Tuscany is not compliant and fails various testcases.

The first main thing that was wrong related to the handling of the binding in the case that the 
client of a bidirecional service offered over binding.ws was a non-SCA client (Java SE JAXWS) - as a 
result there were a set of changes necessary to the handing of EPRs and related EPs for the callback 
from the service to the client.  The previous code worked almost by chance for clients and services 
entirely within the SCA Domain, but fell apart for non-SCA clients.

The second thing that needed doing was to correct the handling of the callback EPR passed over the 
web service invocation by the Web service client.  This is in a WSA header.  Basically, the code 
picked up the EPR and then put it in a place where the callback reference could not find it.  These 
changes largely involved the Tuscany Axis service provider code.

At this point, we now had an Axis binding.ws that works for a non-SCA client to a bidirectional service.

At present, there are still a set of failing testcases and I am working on those.  These deal with 
another set of SOAP headers that are defined in the OASIS web service binding spec but which the 
current code does not handle at all.  I hope that by the end of today, all these will be properly 
handled.

Is this relevant to other bindings?  The fixes to the handling of Tuscany EPRs and EPs will help all 
bindings deal with callbacks better.  The fixes to the Axis code are really confined to binding.ws 
but could form a template for what to do with other binding.ws implementations.  I suggest waiting 
for a couple of days before trying to transfer anything - just so that we can fully test our solution.


Yours,  Mike.