We Keep Coding

Is it possible to write a non-HTTP servlet for Tomcat container?

I would like to handle non-HTTP traffic, but (now it seems) I have to run it at Cloud Foundry ecosystem.
Is there any way to write (and push) a servlet which can handle raw TCP connections or is this against the whole servlet container design (as I can see now)?

As of right now TCP is not supported in Cloud Foundry. However, TCP is coming this year. Check out http://www.slideshare.net/Pivotal/cloud-foundry-summit-2014-cloud-foundry-roadmap for the roadmap!

Tomcat listens to an HTTP port, and converts the requests sent to it on Java objects that passes to a servlet method.
You cannot make Tomcat listen to anything different than HTTP or HTTPS. So, if you have a class that handles raw TCP connections it will take no advantage of being in Tomcat.

Servlets handle requests (not necessarily HTTP requests per the spec, but always requests). You could write code that would listen on a raw TCP socket, but that would have nothing to do with whether it's running in Tomcat.

To add some more information about your original question of if it is possible to write a non-HTTP servlet for a Tomcat container, the answer is yes, this is very much possible. TomCat is preconfigured with built-in support for the HTTP protocol; however, it is not too farfetched of an idea that you can extend the servlet concept and adapt this to support other protocols on top of TCP/IP.
If you look at your servlet class, you will see that this class extends HttpServlet, and that HttpServlet extends the GenericServlet class. It would be up to you to create your own unique protocol class that extends GenericServlet. For example, you could create a FTPServlet or a SMTPServlet class. However, it will be up to you to investigate if the servlet paradigm is the best architecture to implement other protocols with. Wish you luck.

How can I create an async java desktop client?

I must create a desktop java client that comunicate to a servlet in order to receive some notificationes.
The servlet is an async servlet but my doubt is with the client.
How is the best way to "listen" a response from the server. I looked to the httpcomponents-asyncclient from apache, but I´m not trully convinced about that library. Maybe an infinite loop?

You might want to check out netty, it's what we use for our IntelliJ IDEA real time collaboration plugin to communicate with our remote server. It's very simple to get started with and abstracts all the hard parts, including creating secure connections. This is the netty user guide, it should get you started.

HttpComponents from Apache is very common
(be careful not to use the old one). Check a simple example.
Do you need to be constantly waiting for responses? If so, this is not the correct direction! The client should not have to call any method to get notifications... it should just be listening to some socket that the server writes to... Or just processing some queue. Perhaps you need to consider learning a bit of real time technologies and methods.

Can I implement a socket server on Tomcat using GenericServlet?

I would like to implement a socket server that will be connected to by multiple clients. In order to make the implementation as simple as possible and not have to code management of threads and connections etc I'd like to use Tomcat. We already use tomcat as part of our solution.
I am sure that Tomcat can be used for non http servlets and socket connections - with GenericServlet. I'd like this to be confirmed and any tips that can be given about implementations.
UPDATE - using tomcat seems the wrong tactic - little is gained from the rest of tomcat infrastructure. Anyone got other implementation suggestions? For example Apache MINA has been recommended - any others?

If you want to create support for a non-HTTP server inside tomcat you will need to implement a new protocol handler (see the docs for PoolTcpEndpoint). But at that point you're mostly going to be gaining the Catalina startup and shutdown functionality and not a whole lot else.
If you do want to base your app on a servlet container, I'd suggest jetty for size, ease of use, ability to start programatically and ability to fit completely inside the debugger.

Best Java supported server/client protocol?

I'm in the process of writing a client/server application which should work message based. I would like re-use as much as possible instead of writing another implementation and curious what others are using.
Features the library should offer:
client and server side functionality
should work message based
support multi-threading
should work behind load balancer / firewalls
I did several tests with HTTPCore, but the bottom line is that one has to implement both client and server, only the transport layer would be covered. RMI is not an option either due to the network related requirements.
Any ideas are highly appreciated.
Details
My idea is to implement a client/server wrapper which handles the client communication (including user/password validation) and writes incoming requests to a JMS queue:
#1 User --> Wrapper (Check for user/password) --> JMS --> "Server"
#2 User polls Wrapper which polls JMS
Separate processes will handle the requests and can reply via wrapper to the clients. I'd like to use JMS because:
it handles persistence quite well
load balancing - it's easy to handle peaks by adding additional servers as consumer
JMSTimeToLive comes in handy too
Unfortunately I don't see a way to use JMS on it's own, because clients should only have access to their messages and the setup of different users on JMS side doesn't sound feasible either.

Well, HTTP is probably the best supported in terms of client and server code implementing it - but it may well be completely inappropriate based on your requirements. We'll need to actually see some requirements (or at least a vague idea of what the application is like) before we can really advise you properly.

RMI works nicely for us. There are limitations, such as not being able to call back to the client unless you can connect directly to that computer (does not work if client is behind a firewall). You can also easily wrap your communication in SSL or tunnel it over HTTP which can be wrapped in SSL.
If you do end up using this remember to always set the serial version of a class that is distributed to the client. You can set it to 1L when you create it, or if the client already has the class use serialver.exe to discover the existing class's serial. Otherwise as soon as you change or add a public method or variable compatibility with existing clients will break.
static final long serialVersionUID = 1L
EDIT: Each RMI request that comes into the server gets its own thread. You don't have to handle this yourself.
EDIT: I think some details were added later in the question. You can tunnel RMI over HTTP, then you could use a load balancer with it.
I've recently started playing with Hessian and it shows a lot of promise. It natively uses HTTP which makes it simpler than RMI over HTTP and it's a binary protocol which means it's faster than all the XML-based protocols. It's very easy to get Hessian going. I recently did this by embedding Jetty in our app, configuring the Hessian Servlet and making it implement our API interface. The great thing about Hessian is it's simplicity... nothing like JMS or RMI over HTTP. There are also libraries for Hessian in other languages.

I'd say the best-supported, if not best-implemented, client/server communications package for Java is Sun's RMI (Remote Method Invocation). It's included with the standard Java class library, and gets the job done, even if it's not the fastest option out there. And, of course, it's supported by Sun. I implemented a turn-based gaming framework with it several years ago, and it was quite stable.

It is difficult to make a suggestion based on the information given but possibly the use of TemporaryQueues e.g. dynamically created PTP destinations on a per client basis might fit the problem?
Here is a reasonable overview.

Did you tried RMI or CORBA? With both of them you can distribute your logic and create Sessions

Use Spring....Then pick and choose the protocol.

We're standardizing on Adobe's AMF as we're using Adobe Flex/AIR in the client-tier and Java6/Tomcat6/BlazeDS/Spring-Framework2.5/iBATIS2.3.4/ActiveMQ-JMS5.2 in our middle-tier stack (Oracle 10g back-end).
Because we're standardizing on Flex client-side development, AMF and BlazeDS (now better coupled to Spring thanks to Adobe and SpringSource cooperating on the integration), are the most efficient and convenient means we can employ to interact with the server-side.
We also heavily build on JMS messaging in the data center - BlazeDS enables us to bridge our Flex clients as JMS topic subscribers. That is extremely powerful and effective.
Our Flex .swf and Java .class code is bundled into the same .jar file for deployment. That way the correct version of the client code will be deployed to interact with the corresponding middle-tier java code that will process client service calls (or messaging operations). That has always been a bane of client-server computing - making sure the correct versions of the respective tiers are hooked up to each other. We've effectively solved that age-old problem with our particular approach to packaging and deployment.
All of our client-server interactions work over HTTP/HTTPS ports 80 and 443. Even the server-side messaging push we do with BlazeDS bridged to our ActiveMQ JMS message broker.

Java EE and application servers - What can i do?

I decided that it is time for me to dig into the whole Java EE stuff. I am using EE some techniques whithin Java SE like JPA or JMS, but i still messing around with Java SE and i believe Java EE and an application server will solve some of my problems i have.
BUT: I have still some questions after reading some articles on the web.
1st: Am i limited to request-response applications? I have an application which serves XML documents via HTTP. All delivered objects are added to a queue which will be dispatched in a different thread. Some validation is made for this objectes, including the opening of sockets to a remote machine (I heard EJ-Beans are not allowed to do this, is this true?). So, is is possible to do this within an application server?
2nd: I know there are Message driven beans, is it possible to send JMS messages to a MDB from outside of the application server? I have a service which sends JMS messages, but runs, as a legacy system, not inside the same application server.
3rd: How can the System Adminstrator or User configure my application? I know that some things like database connections are configured within the application server and my application can lookup them via JNDI or get them via DI. But what about application specific configuration?
Yeah, these are quite noobish questions, but maybe someone has the time to explain me how all this stuff is working. :)
regards,
Posix
PS:
4th: It seems EJBs are not allowed to do anything with files, so Java EE seems to be no option for a Service which receives Files, pushes them around to different systems and want them to write to a Socket (see question 1)?

I can say that Java EE can be used without any doubts in your case. Let me drill a little bit more into your specific questions:
You can open socket connection from your EJB. There is nothing that prevents you from doing that. However this kind of operation is not advised for Java EE applications. In my opinion the better option is to implement Java EE Connector (JCA) that would manage pool of socket connections to your proprietary system. This is the model way to implement such a integration as per specification.
Yes! It is perfectly possible to receive messages send from external application/system (outside the AS). This is main idea of integration using messaging :) In many cases your application being Java EE application receives messages via MDB from JMS channel, but JMS is only an API and can be implemented by any messaging system e.g. IBM MQ. In this architecture the external system puts an MQ message onto the queue and your Java EE application that listens to the very queue receives the message via JMS API!
Generally speaking Application Server gives the Administrator great tools to manage Java EE resources i.e. data sources, JMS connection factories, JMS destinations, JTA transaction manager, etc. If you require the ability to change your specific Java EE application the best options seems to be JMX. Just implement a few MBeans, export those to the JMX server embedded within your Application Server and you are done. This task is really trivial in, say, JBoss, but most of the modern Application Servers offer extensive JMX capabilities these days.
For the first glance, EJB doesn't seem to be the best for dealing with files. But remember that implementation of your EJBs is still written in pure Java, so nothing prevents you from reading/streaming files and so on. I have experience with large Java EE applications that are handling large files as input files and can assure you that Java EE is is a good technology choice :)

Here are the restrictions on EJB 1.1 spec.
Here's my take on your questions:
I believe an EJB can open a socket on a remote machine, but I would say that opening sockets is too low level an operation. I'd think about exposing whatever that socket is doing for you as another EJB.
An MDB is just a listener that's registered with a particular topic or queue. It doesn't say anything about sending. If your client knows how to get a message to the queue it's possible. They just have to know the queue URL and be able to create a connection.
The admin sets up connection pools, JNDI names, etc. - everything. They do it using the admin console for the app server.

It's a violation of the EE spec to do anything with files (to ensure that an EE app is portable and distributable). However since it's all just plain Java code, yopu can choose to do anything that you want. As long as you know how your target environment looks (eg the system is for internal use) I wouldn't hesitate modifying files just because the spec says so.

In an application server like Tomcat (others too, probably, but I've never worked with them) you can not only execute things upon receiving a request, but also do things (including starting long running threads) on server startup. Basically you can do anything that you can with "normal" Java. In fact, you could put a normal Java app in application server if you just include a piece of code which calls the appropriate main() on server startup.

I would suggest applying each technology to the appropriate points where you are currently feeling pain. Regarding your specific points,
In an EE context, you would add the messages to a JMS queue, that has MDBs which would do the actual processing. Regarding the management of the HTTP request/response lifecycle, you would manage this the same way you do now, or use an existing library to do if for you. By moving to an EE app server, you would allow the app server to manage the threading, transactions, etc. instead of having to manage it manually.
As duffymo stated, MDBs are responsible for receiving messages, they do not care where the message originated from.
The system administrator can configure the app server as duffymo stated. Additionally, you can expose JMX beans to other systems or to the end user to allow them to configure services if you so desire.