Limitations of exposing Java web services using javax.xml.ws.Endpoint?

Question

I am trying to expose some Java web services so that I can interoperate from C# (see this SO question). The proof of concept code below works great with WCF!

My question is about the use of the javax.xml.ws.Endpoint class to publish my service:

1. What do I forfeit by going this route instead of a full-blown application server?
2. Is this an appropriate solution for long-running service with a low volume of calls?

The following produces WSDL, is cleanly callable from .Net, and performs well. Why wouldn't I use it?

@javax.jws.WebService
public class TestSvc { 
    @javax.jws.WebMethod()
    public String sayHello() {
        return "Hello!";
    }
}

import javax.xml.ws.Endpoint;
public class Main  {
    public static void main(String[] args) throws Exception {
        Endpoint.publish("http://localhost:8181/Test", new TestSvc());
    }
}

Answer 1

Often the scalability arguments (thread pools etc) are quite forceful, but you've already discounted those.

Next, reliability. Some App Servers have nice clustering capabilities, very easy to add new instances, hence enabling fault tolerance while enabling a consolidated administrative view.

Ease of administration generally is quite handy as your number of services grows.

Security infrastructures and declarative security models can be quite important.

For me, the whole JEE programming model is worth having when your business logic becomes non-trivial. Now we could get into the whole EJB v Spring v ... debate. But the general point I want to make is that as your business logic gets more serious you need facilities such as thread management, persistence, connection pooling, messaging, caching and scheduling; stuff you find in App Servers. Some of that comes naturally in EJB3+JPA, or Spring, some as a natural add-on in the App Servers. If you have prospects of doing serious enterprise-scale Java development it may be better to buy into a little more complextity now in order to get onto an extensible basis for the future.

Answer 2

Besides losing the benefits of an application server in general, you may lose the ability to manage and administer and test the service if you were to use an application server.

In the inter-op side, you would not be able to extract a WSDL without the java call. If your new service executed something when it was published, you may have to design around that. If you plan to use WCF or something similar to consume the WSDL, there are some quirks in the VS side that you have to work around when generating the service clients (the quirks don't happen every generation, but they do happen from time to time.)

A long-running service (I assume in other words you mean a service expected to run indefinitely) would just have to be managed as a process. Depending on your design and requirements, you would have to think about starting and stopping the process, pausing it, etc.