I've started looking at improving binding.ws and I wanted to kick off
this thread so I can record thoughts and get everyone's opinions as I
go. So please feel free to pitch in.
The motivation for the exercise is..
OASIS support (although It doesn't look like there are too many
things we don't already do)
integrate policy more consistently (more of a problem)
allow policy implementations to contribute configuration logic as
well as interceptors
introduce binding wire
this is not particular to binding.ws but got to start somewhere
clean up structure of binding implementation
remove all the cruft that's built up
the are lots of fixes and work arounds some of which can now be removed
port to Axis1.5
I have a couple of immediate thoughts based on the playing I've been
doing here [1]. This is based on looking at the service side
integration in the first instance.
A/ configuration lookup
currently we use our configurator which is littered with code to
work around previous axis/maven problems
I've looked to replace this with a basic configuration creation from
file. It would be good to have a really obvious way that the basic
axis configuration
is created. We made need to go back to the old method if we want
conditional Rampart loading but we'll see how it goes.
B/ There are several questions in code comments about sharing
configuration context. I'm not sure whether this was ever resolved
C/ From an aesthetic (and possible flexibility) point of view I want
to separate the static engine configuration code from the runtime hook
code. Currently the service provider provides an invokeTarget method
alonside all the config code. The stuff in invokeTarget is pretty much
generic but the engine configuration is very specific to the way that
we configure Axis. I want to move the engine configuration code in the
the binding providers and have the service providers play the role
that you would expect a JAX-WS generic provider play
D/ Policy configuration. This is a big issue IMHO as policy is not
consistently integrated in the binding. I've drawn a couple of
diagrams to help me think about the problem [2] as this has wider
implications than just the ws binding. The generic service and
implementation policies are already catered for. I think we need a
binding provider to cater for binding specific interceptors. We can
remove the existing experimental BindingPolicyProvider base class and
replace it we a new binding provider methods on the policy factory.
The one that looks a little more difficult is what to do about binding
specific static configuration. Maybe this just stays as hard coded
logic in the binding provider. Needs more thought.
E/ Need to enable the binding wire to allow us to do binding specific
policy processing in a pluggable way.
>From a code point of view I'm aiming to do basic changes and get the
Axis 1.5.1 conversion done so that we can switch it on. We can then
continue the re-factoring in line.
More soon.....
Regards
Simon
[1]
http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/binding-ws-axis2-15-runtime/
[2] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/WS+Binding
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
