Improving the spring-ws client

[jpeterson]

I have been tracking spring-ws for a while and I am beginning to use it pretty extensively. One thing that keeps coming up is that the web-service client support (imho) could use some improvement. I wanted to float the idea of trying to refactor the client package to be less complicated, more capable, and easier to use. I've got an idea for how to do that and, with Arjen's permission, I would like to submit it as a contribution.

As an intellectual exercise for myself I have already done a good portion of the refactoring work. But before I submit it or do any more work I wanted to get a feeling for what other people thought. Is this something that would be valuable?

[Arjen Poutsma]

Well, if you have a good idea, I'm certainly open to it. But since we're really to close to 1.0, I cannot change too much.

[jpeterson]

Do you have a preference on how I submit it? Should I create a branch and commit it into subversion or would you prefer I upload a zip file somewhere? Its going to be 10-20 files including unit tests.

[Arjen Poutsma]

The best thing to do is to create a JIRA issue, and attach the code to it.

Could you also give a brief explanation as to what the improvements are?

[jpeterson]

Ok. I'll do that.

There are two main improvements. The first is an approach to solving SWS-148. The rest are what I would consider structural improvements. I'll see if I can explain the strucutral approach.

There are two base interfaces, WebServiceClient and WebServiceClientFactory. As one might imagine, the factory creates the clients. The WebServiceClient interface has two methods for sending WebServiceMessages. Extending these two interfaces are two more interfaces: MarshallingWebServiceClient and MarshallingWebServiceClientFactory. Same pattern, but adding marshalling-related methods.

There are four implementation classes which realize all of the interfaces described above: BaseWebServiceClient, BaseWebServiceClientFactory, OxmMarshallingWebServiceClient, and OxmMarshallingWebServiceClientFactory. The BaseWebServiceClient supports the use of multiple WebServiceInterceptors. The WebServiceInterceptor interface supports two methods which allow full access to the message before it is sent and after it is received.

Clear as mud?

[jpeterson]

I should add, my expectation was that people using these classes would inject one of the factory implementations into their code. They would then be able to create as many clients as their runtime operations needed. This was one of the other main improvements. I was trying to account for the scenario where the application does not know what endpoint it will be talking before runtime.

[jpeterson]

http://opensource.atlassian.com/proj...browse/SWS-163

[Arjen Poutsma]

Thanks for the code. It looks interesting!

Unfortunately, we are too far in the 1.0 release cycle to add this new feature now. We will probable add it in the post 1.0 timeframe, either in a minor update (1.0.x), or - more likely - 1.1.

Remember, if you want to see this functionality in SWS as soon as possible, vote for the issue!

[mmccaskill]

Do these proposed changes include support for multiple marshallers? The problem I'm running into is I need to have multiple marshallers/adapters on the server (which it does) but I cannot replicate that on the client. Until then I have to shove 30! objects into the same package.

[Arjen Poutsma]

Yes, this will probably include the possibility of multiple marshallers.

[mmccaskill]

I'm a situation where I can either
a) keep using one (un)marshaller on the server and client (using Spring-WS for both)
b) switch to SAX/StAX but not sure how that will play out on the client
c) wait for the client to support multiple (un)marshallers

I'd like to go for c. I'd like to help with this feature but I'd need some direction as to how you would like the architecture. Let me know your thoughts.

[Arjen Poutsma]

Theoretically, you can use multiple marshallers yourself right now, by inject the marshallers your own class, and using them directly in the callback. Take a look at the source code of WebServiceTemplate, and see that the marshal* methods are nothing more than convenience methods for the generic sendAndReceive() method.

[mmccaskill]

So I see

public void doWithMessage(WebServiceMessage request) throws IOException, TransformerException {
                MarshallingUtils.marshal(getMarshaller(), requestPayload, request);
                if (requestCallback != null) {
                    requestCallback.doWithMessage(request);
                }
            }

@line 258 in WebServiceTemplate. So really I have to do is something to the affect of:

private List<Marshaller> marshallers;
private List<Unmarshaller> unmarshallers;
...
public void doWithMessage(WebServiceMessage request) throws IOException, TransformerException {
                for (Marshaller marshaller : marshallers) {
                    MarshallingUtils.marshal(marshaller, requestPayload, request);
                    if (requestCallback != null) {
                        requestCallback.doWithMessage(request);
                    }
                }

And the same for the unmarshallers. Is this right?

[Arjen Poutsma]

Yup, something like that. I'm not sure if you want to iterate over all the marshallers in order, that seems a bit weird.

[mmccaskill]

How else would I do it? Use reflection to determine the package name and use the appropriate (un)marshallers? I mean I'll end up having at least two (un)marshallers in every operation.