On Tue, 9 Aug 2011, Iain Adams wrote:
I am building an application that requires both a Server/Client socket
connection to multiple clients AND also exposing multiple webservices.
If I was to deploy my application on a Java container (JBoss/Tomcat
etc) is there a way I can get it to a) start the webservices and b)
start the server (so that it can listen on a specific port for
For the web services, things are pretty simple. You can create a web
service using JAX-WS, annotating an interface and a class with
@WebService, then mapping the class as a servlet (even though it isn't
really a servlet). Geronmio has a good example:
The container will then take care of binding the HTTP port, supplying
handler threads, and so on.
The raw server socket is marginally trickier.
For a start, the J2EE specification specifically provides that most code
in the container (including servlets and EJBs) might not be allowed to
open a server socket or create a thread (that's supposed to the
container's job!). The only code that is officially allowed to open a
server socket is code which is part of a resource adapter; resource
adapters also get access to thread pools. So, if you want to be
squeaky-clean J2EE compliant, you will need to write a resource adapter;
i have never done it, but my impression is that it is not a fun experience.
However, i think it's usually the case that opening server sockets and
creating threads is actually allowed in all parts of the container
(JBoss has never stopped me doing it, for example). So, your path of
least resistance might be to commit the venial sin of deviation from the
spec, and just set up your server in application code.
I would suggest staging your deviation in a servlet. You can write a
servlet which will never actually handle a request, but whose init
method binds a socket and starts a listener thread. You can then mark
that servlet to be started on startup, by adding a load-on-startup
element inside the servlet element in the web.xml.
Meaning JCA for the socket listening and threading.