A few comments in line... On Fri, Jan 29, 2010 at 5:56 PM, Simon Laws <[email protected]> wrote: > 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. >
Two things that would be nice to clean up with the existing WS binding structure are: - change the wsdlgen module to be more of a standalone utility with no or minimum dependencies on the WS binding. There's already been some work on that and IIRC it doesn't now drag in the entire Axis2 runtime but it could be cleaned up more so that you can gen a wsdl port type without needing any WS binding. - separate the scdl xml/model from the Axis2 runtime modules so you can use scdl including WS (and policy) without dragging in all the Axis2 runtime (does anyone really care about this? we try to keep all the model modules separate from the runtime ones but its not done properly yet and after 4 years _no one_ has ever asked or complained about it so maybe we shouldn't bother trying) > 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 A lot of those modifications were to do with getting Axis2 to support the SCA service names which can include slashes which didn't used to be supported in Axis2 but i think might be now. The main things to check are the service name we want can be registered and the correct endpoint is made available and the wsdl gets the correct endpoint. > > 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 I don't think it was. Axis2 has a ConfigurationContext that configures the Axis2 runtime including all the configuration for each service endpoint. Right now we create a new ConfigurationContext for every WS service. That sounds inefficient though i've no idea how much overhead it really is. > > 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 >
