tags:

views:

138

answers:

2

Hi everyone,

Is it possible to split a web service in to multiple classes and still provide a single path to the web service?

I know this isn't possible because of the duplicate url-pattern values. It sort of illustrates where we're wanting to go :)

<endpoint name="OneBigService"
          implementation="SmallImpl1"
          url-pattern="/OneBigService"/>

<endpoint name="OneBigService"
          implementation="SmallImpl2"
          url-pattern="/OneBigService"/>

Basically, how do avoid having one monolithic @WebService class?

Thanks!

Rob

+1  A: 

You could delegate functionality to a composed class from your web service class:

@WebService
public class OneBigService {
    ISmall delegate = new SmallImpl1(); // or new SmallImpl2();

    @WebMethod
    public Result webMethodStuff() {
        // do something with delegate
    }
}
Fabian Steeg
+1  A: 

Is it possible to split a web service in to multiple classes and still provide a single path to the web service?

No. A URI is a connection point to one web service (defined by the Port/Endpoint).

Basically, how do avoid having one monolithic @WebService class?

Well, in my opinion the real question is more when should I use several Port/Endpoint? And I would be tempted to answer: regroup/split things logically.

For example, while it make sense for a Calculator service to expose add, subtract, multiply and divide operations, I would use another service to expose a getQuote operation.

Now, you can always split the logic into several classes and delegate to them from your @WebService.

Pascal Thivent
The reason is that more endpoints mean more pain on the client side when specifying services. The two web services I'm familiar with are Rally and VMware, both with a massive amount of APIs yet still one webservice URL. This is great for me as a client developer because I don't have to wonder what URL this API is at (still a +1 vote though because now I know for sure I can't break it up :)
Rob S.