We Keep Coding

Tomcat vs Vert.x

For the past few days I have been reading Vert.x documents. I know that Vert.x is polyglot, single threaded, non-blocking IO, modular architecture, high scalability.
Is there any other major differences between tomcat and Vert.x?
Also when we should use tomcat and when to use Vert.x?

Tomcat is a servlet container, so it offers you a platform that helps you to develop and deploy HTTP based applications like web sites or web services.
Vert.x instead helps you to develop and deploy any kind of asynchronous applications. It's true that modern versions of Tomcat support asynchronous servlets, but Vert.x comes with a far larger amount of user friendly asynchronous APIs plus other goodness:
Complete Filesystem asynchronous API
TCP (server and client)
UDP (server and client)
HTTP(S) (server and client)
Shared data service (share objects between polyglot modules)
HA and Clustering
Cluster-wide messaging (event loop)
Event bus bridge (the extension of the event loop to browsers via SockJS)
A growing ecosystem of Vert.x modules
Possibility to embed Vert.x in legacy code
Leveraging the existing rich and solid ecosystem of Java libraries (Vert.x runs on the JVM, unlike Node.js)
Personally I think learning Vert.x is very useful. At work I reused the same knowledge with great success to realise three very different products: a zero-copy ultrafast Redis proxy, a JPA-backed REST API, and a reactive single-page web application.
Have a look at the example code, it's pretty straight forward and the boilerplate is close to zero.
One more thing: where did you read Vert.x is single threaded? It's not true! Vert.x has a very neat concurrency model that makes sure all the cores are equally used (again, unlike Node.js).
Enjoy!

Vert.x HTTP server allows to you listen to many ports in the same time. Also, its concurrency model is much better than any thread pool based approach if you want to combine your HTTP server with http client or anything else. Its performance is much better as well.

Duplex streaming in Java EE

I'm looking for a full duplex streaming solution with Java EE.
The situation: client applications (JavaFX) read data from a peripheral device. This data needs to be transferred in near real-time to a server for processing and also get the response back asynchronously, all while it keeps sending new data for processing.
Communication with the server needs to have an overhead as low as possible. Data coming in is basically some sensor data and after processing it is turned in what can be described as a set of commands.
What I've looked into:
A TCP/IP server (this is a non-Java EE approach).This would be the obvious solution. Two connections opened in parallel from each client app: one for upstream data and one for downstream data.
Remote & stateless EJBs. This would mean that there's no streaming involved and that I pack sensor data in smaller windows (1-2 seconds worth of sensor data) which I then send to the server for processing and get the processing result as a response. For this approach, while it is scalable, I am not sure how fast it will be considering I have to make a request each 1-2 seconds. I still need to test this but I have my doubts.
RMI. Is this any different than EJBs, technically?
Two servlets (up/down) with long polling. I've not done this before, so it's something to be tested.
For now I would like to test the performance for my approach #2. The first solution will work for sure, but I'm not too fond of having a separate server (next to Tomcat, where I already have something running).
However, meanwhile, it would be worth knowing if there are any other Java specific (EE or not) technologies that could easily solve this. If anyone has an idea, then please share it.

This looks like a good place for using JMS. Instead of stateless EJBs, you will probably be using Message-Driven Beans.
This gives you an approach similar to your first solution, using two message queues instead of TCP/IP connections. JMS makes your communications fully asynchronous and is low-overhead in the sense that your clients can send messages as fast as they can regardless of how fast your server can consume them. You also get delivery guarantees and other JMS goodness.
Tomcat does not come with JMS, however. You might try TomEE or integrate your existing Tomcat with a JMS implementation like ActiveMQ.

There are numerous options you could try. Appropriate solutions depend on the nature of your application, communication protocol, data transfer type, control you have over the client and server and firewall restrictions on client server routes.
There's not much info on this in your question, but given what you have provided, you may like to look at netty as it is quite general purpose and flexible and seems to fit your requirements. Netty also includes a duplex websocket implementation. Note that a netty based solution may be more complex to implement and require more background study than some other solutions (such as jms).
Yet another possible solution in GraniteDS, which advertises a JavaFX client integration and multiple server integrations for full duplex client/server communication, though I have not used it. GraniteDS uses comet (your two asynchronous servlets with long polling model) with the Active Message Format for data which you may be familiar with from Flex/Flash.

Have you looked at websockets as a solution? They are known to keep persistent connections and hence the asynchronous response will be quick.

Java Non-Blocking HTTP Server

I have written an application using embedded Jetty that makes network calls to other services.
I presume that the serving threads are idle whilst waiting for the network calls to complete.
Is there any way to have a worker thread that switches between requests to perform work that can be done at the current time and then when the network calls return also handle that? A request would be returned when all work has been completed for it.
I know this is a common paradigm, and I have used it for non-blocking TCP networking, but I'm unsure as to how to achieve this on a Java HTTP server whilst also waiting on external results.
Any links or explanations are appreciated.
Thanks
Update:
I'm using Membase and ElasticSearch (the only network calls). Membase returns "Future" objects and ElasticSearch returns "ListenableActionFuture". I'd like to be able to continue processing on a thread in response to these objects being returned.

You may take a look at Deft, which is single threaded, asynchronous, event driven web server.

Netty is a java library that allows you to do asynchronous networking.
http://www.jboss.org/netty
Netty supports http, but it is a fairly low level library.
A higher level library is finangle by twitter,
http://twitter.github.com/finagle/
Finangle is built on top of netty, but supports connection pooling, load balancing, and has a lot of other features. Finangle supports http.

If you want to do work at the same time as IO, I suggest you add a thread pool to perform the work. It is possible to re-use the existing threads but its a lot of extra work for possibly too little benefit.

How to provide a cross platform, asynchronous service interface

What is the best way to provide an asynchronous service interface to multi-platform (primarily java and .net) clients? The backend service is implemented in java.
We are looking at asynchronous web service and message queues, but apparently cross platform asynchronous web service* is not supported yet in java (as far as I know) and for message queues, I was not sure which codec/protocol would be best.
*:Cross platform asynchronous web services can be described in WSDL 2.0, but not in WSDL 1.1 (As far as I understand). Now, JAX-WS 2.x does support asynchronous web service, but not WSDL 2.x. So I'm assuming that JAX-WS asynchronous web service's clients have to be JAX-WS clients, and that we can not use.
Thanks in advance!
EDIT: The difficulty here is that the service is asynchronous, and we prefer a callback based interface for efficiency (so we don't want to use 2 calls on a synchronous WS interface, etc.)

If its messaging, than use a Messagequeue system. like ZeroMQ. they are all cross platform.
otherwise we do it with .net WCF, and use JaxWS from java to test, that the interface is compatible.

Don't know, what's best, but SOAP is a good choice for a Java backend. The messages are xml based (e.g. not restricted to Java platforms) and it is widely used so you get a lot of support, tools and libraries on the net.
Another idea that might fit your needs: XMPP.
It is definitly asynchronous, client sending a service request (wrapped in a xmpp message) is the callback and doesn't wait for an immediate answer. I've used in a scenario where I send 'service request' from a xmpp client to a server and received the answers, immediately or a bit later, depending on the complexity of the calculation. This was a human-machine interaction but machine-machine should be even easier.

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.