Why MINA ?
Writing some network application is generrally seen as a burden, and a low level development. It's a area which is not frequently studied or known by developpers, either because it has ben studied in school a long time ago and everything has been forgotten, or because the complexity of this network layer is frequently hidden by higher level layers, so you never get deep into it.
Add that when it comes to asynchronous IO, an extra layer of complexity comes into play : time.
The big difference between BIO (Blocking IO) and NIO (Non-Blocking IO) is that in BIO, you send a request, and you wait until you get the response. On the server side, it means one thread wil be associated with any incoming connection, so you won't have to deal with the complexity of multiplexing the connections. In NIO, on the other hand, you have to deal with the synchronous nature of a non-blocking system, wich means that your application will be invoked when some events occur. In NIO, you don't call and wait for a result, you send a command and you are informed when the result is ready.
The need of a framework
Considering those differences, and teh fact that most of the applications are usually expecting a blocking mode when invoking the network layer, the best solution is to hide this aspect by writing a framework that mimic a blocking mode. This is what MINA does !
But MINA does more. It provides a common IO vision to an application that needs to communicate over TCP, UDP or whatever mechanism. If we consider only TCP and UDP, one is a connected protocol (TCP) when the other one is connectionless (UDP). MINA masks this difference, and make you focus on the two parts that are important for your application : the applicive code and the application protocol encoding/decoding.
MINA does not only handles TCP and UDP, it's also offering a layer on top of serial communication (RSC232), over VmpPipe or APR.
Last, not least, MINA is a network framework that has been specifically designed to work either on the client side and on teh server side. Writing a server make it critical to have a scalable system, which is tunnable to fit the server needs, in term of performance and memory usage : this is what MINA is good for, still making it easy to devlop you server.
When to use MINA ?
This is a intersting question ! MINA does not expect to be the best possible choice in any case. There are a few elements to consider when considering using MINA. Let's list them :
Ease of use When you have no special performance requirements, MINA is probably a good choice as it allows you to dvelop a server or a client easily, without having to deal with the various parameters and use cases to handle when writing the same application on top of BIO or NIO. You can probably write your server with a few tens of lines, and there are a few pitfalls in which you are likely to fall
A high number of connected users BIO is definitively faster that NIO. The difference is something like 30% in favor of BIO. This is true for up to a few thousands of connected users, but up to a point, the BIO approach just stop scaling : you won't e able to handle millions of connected users using one thread per user ! NIO can. Now, one other aspect is that the time spent in the MINA part of your code is probably non significant, compared to whatever your application will consumme. At some point, it's probably not worthful to spend many times more energy writing a faster network layer on your own for a gain which will be barely noticable.
A proven system MINA is used by tens of applications all over the world. There are some Apache projects based on MINA, and they are working pretty well. This is some kind of guarantee that ypu won't have to spend hours on some cryptic errors in your own implementation of the network layer.
Existing supportd protocols MINA comes with various implemented existing protocols : HTTP, XML, TCP, LDAP, DHCP, NTP, DNS, XMPP, SSH, FTP... At some point, MINA can be seen not only as a NIO framework, but as a network layer with some protocol implementation. One of MINA feature in the near future is to offer a collection of existing protocol you can use.