views:

93

answers:

2

Currently, each web service for our application has a user parameter that is added for every method. For example:

@WebService
public interface FooWebService {
   @WebMethod
   public Foo getFoo(@WebParam(name="alwaysHere",header=true,partName="alwaysHere") String user, @WebParam(name="fooId") Long fooId);

 @WebMethod
   public Result deletetFoo(@WebParam(name="alwaysHere",header=true,partName="alwaysHere") String user, @WebParam(name="fooId") Long fooId);

   // ...
}

There could be twenty methods in a service, each with the first parameter as user. And there could be twenty web services.

We don't actually use the 'user' argument in the implementations - in fact, I don't know why it's there - but I wasn't involved in the design, and the person that put it there had a reason (I hope).

Anyway, I'm trying to straighten out this Big Ball of Mud.

I have already come a long way by wrapping the web services by a Spring proxy, which allows me to do some before-and-after processing in an interceptor (before there were at least 20 lines of copy-pasted boiler plate per method).

I'm wondering if there's some kind of "message header" I can apply to the method or package and that can be accessed by some type of handler or something outside of each web service method.

Thanks in advance for the advice, LES

A: 

Who or what is expecting the user message to be bound to SOAP headers? Are your web services secured? Is that some kind of authentication header? It might have been the original intention. Actually, someone should have the answer to these questions. Find who. And if you find out that you won't ever need it, stop passing it. But if you need it, I think it's better to add it (even if you don't use it for now) unless if modifying the WSDL is not an issue (especially on the client side).

PS: I don't know how to avoid adding a parameter with @WebParam(header=true) to Java methods in order to generate a WSDL with operations having a <soap:header> in their input. AFAIK, this is how JAX-WS works when starting from Java.

Pascal Thivent
I think it is supposed to be used for authentication in the future, but currently, no one does anything with it. It annoys me that this seemingly can't be done DRYly. :(
LES2
WS-Security with the UsernameToken profile might be the DRY way to do this but, well, you're not using it (and actually, I don't know how it can be used with a Java first approach).
Pascal Thivent
A: 

If there is no reason why you need to have that variable as a parameter, you can have each one of your services extend a super class. In that super class have spring inject the MessageContext, ServletContext, ServletRequest, HttpHeaders or whichever is appropriate (probably MessageContext for JAXWS) using either the @Context annotation or @Resource annotation.

Then supply some methods in that super class to pull the user information from the request.

jconlin
The point is to have a `<soap:header>` for that operation in the generated WSDL. Inheritance doesn't help here.
Pascal Thivent