Listening ports are used in servers. If you have an apache web server for example, it does not know in advance when it will be used. Listening means that it just waits (like a recepcionist in a hotel :) and it is ready to send an answer whenever a client program (a browser for example) requests it. The connection becomes open when a client connects to that port and a conversation begins.
If no program is listening on a port, and a client tries to connect, then the operating system will reject it.
Why Rewrite What you can Get Off the Shelf?
Why not use RedDwarf Server (formerly Project DarkStar)?
RedDwarf Server is an open source middleware solution for developing the server-side of massively multiplayer online games. It is the official community fork of Project Darkstar, an open source project supported and managed by Sun Microsystems. - from RedDwarf's Wikipedia article
RedDwarf's domain seems down today (2013-06-12), but there's still a wiki, and they are migrating to a GitHub repo.
RedDward presents its philosophy and goals as:
- Make server-side game code reliable, scalable, persistent, and fault-tolerant in a manner that is transparent to the game developer.
- Present a simple single-threaded event-driven programming model to the developer. The developer should never have his or her code fail due to interactions between code handling different events.
(from the RedDwarf Tutorial)
Not that this doesn't mean that server-code is single-threaded, but that it is abstracted from the game developer's perspective. The RedDwarf Tutorial provides a lot more information on what RedDwarf can do and clarifies many of its design decisions.
One point of concern for you, though, was that the multi-node capability wasn't fully implemented last time I check (ca. 2011).
From Scratch
That shouldn't stop you from attempting to do most of these things from scratch, if you value the learning experience. However, this is a major effort and will be rather time-consuming, and as, you noted in your question, some of these issues are rather low-level in the tech stack to deal with and will greatly increase the complexity of the code you'll have to maintain.
But anyways, regarding your 3 options, your first one seems the best to me, if you were to go for a home-made implementation. Option 2 (using HTTP servlets) seems only adapted for some games, though I guess it could be a relatively decent alternative to implement something yourself while still delegating to the a middleware, and you could benefit from many web server additions for handling the load (cache modules, etc...). Option 3 (using JMS + JEE) indeed seems overengineered, but it's hard to know for sure without knowing what you have in mind.
And if you're here to try to learn, then obviously Option 1 will cover a lot of ground. But it's going to be a rather uphill battle.
Best Answer
As you say, typically it is very difficult or impossible to establish a socket connection originating at a central server and attempting to connect to mobile devices. Instead, what you can do is originate the connection at the mobile device, connect to the central server, and leave the socket open waiting for a command from the central server. Of course the first thing your Android code would do on connection is identify itself to the central server, so the central server knows who it is talking to.
Fortunately, Google has already done this for you in Google Cloud Messaging for Android: