views:

299

answers:

2
public class Pojo {
   private String value;

   public static void printValue() {
      System.out.println("value=" + value);
   }
}

I would want to return this from a web service as follows:

@WebService
public class MyService {
   @WebMethod
   public Pojo getPojo() {
      return new Pojo();
   }
}

Can't seem to find the definitive answer on whether I can, should, can't, or shouldn't.

+1  A: 

No. Think about it:

  1. Web services are meant to be platform-independent
  2. What is sent across the wire is simply XML (or some other format) data

So how would you be able to send across the wire a static method? How would non-Java clients be able to interpret your web service's response?

matt b
That's what I figured. I really don't care if the static method is sent across the wire. It could be a utility method only need in my application, for example.The question I have is whether this will cause an error. I understand that the static method won't be available in the WSDL.At this point, it seems that it would be a bad idea to use static methods. A utility class would be a better place.I just didn't want to create a utility class when the method would more logically fit on the class itself.
LES2
How are you going to send a regular method for that matter? Only data are sent over the wire.
Vladimir Dyuzhev
I suppose I meant "accessible by the client", not "sent over the wire".Basically, when the client receives the result of the web service call, it might be useful to have some convenience methods for working with it. How is this typically done (what's the best practice)?
LES2
You cannot define you convenience methods in a portable way. Thus, the re-use of code is only possible if you have, let's say, Java on both sides. Then you can (and people often do) pack the utility classes into a separate JAR and deploy on both client and server.
Vladimir Dyuzhev
+2  A: 

Only data are sent over the wire. Static or non-static methods are not sent.

If on the receiving side you bind the data to the same class -- fine, you have your methods back, but SOAP has nothing to do with it, it's your own trickery. Clients written in other languages (C#, python, ...) won't have your method, of course.

P.S. The class of any object you're sending back always has methods. Your Pojo is implicitely subclassed from Object, and thus have toString(), hashCode(), and so on. JAX-WS doesn't care.

Vladimir Dyuzhev