Unfortunately, I'm not aware of any (good) online resources or books on this topic. And I don't know Java. However, seeing that there are no answers yet, I'll share a few tips from personal experience.
First off, you need a fast and reliable RPC, or at least message queue, mechanism. This is what shall be used for both client-server and server-server communication. I don't know if there are any ready-made solutions for Java. With .NET we'd always made our own custom one, as this mechanism is really important. Most commonly a lightweight binary message protocol over TCP is used, but other options may be better depending on the type of game. A turn-based strategy might be better with XML or SOAP, and a fast-paced shooter may warrant UDP.
The absolute minimum for messaging system is the ability to reliably invoke remote actions, while guaranteeing their order. A really helpful addition is support for request-answer pattern, where a remote action may return some kind of result to its initiator. This is not required, but can make your life much easier.
Once you have your messaging, think about partitioning your server. Most probably, a single server machine will not be enough to host the game for all players. You need to carefully consider what tasks can be independent of each other, and thus can be delegated to different servers. Authentication and login is the most obvious candidate for this partitioning. Among others are statistic and rating calculations, database communication (a server to act a specialized DB cache). The problem with MMO games, as opposed to web apps, is that they tend to be highly stateful, with lots of data needed for each player. And most operations require access to all, or almost all, of this data.
Even if you use a single server, you pretty much have to take advantage of multiple processors. Any MMO server is a highly concurrent program (our current server has about 30 concurrent threads). To have any hope of solving synchronization problems, you have to isolate different threads. Like different servers, they'll have their own data, and will communicate using some kind of message-passing interface. Possibly even the same RPC that you network uses, if it's fast enough.
Then you have your database. MMO players usually do a lot of things and generate a lot of chages to the game world, that have to be saved in the database. All the servers I worked with did not save these immediately - instead, changes were accumulated in memory and then saved in bulk every 5 minutes or so. This allows the game to progress more smoothly, at the cost of possible delay when writing takes place. This delay is the main reason to have a separate machine for database communication.
Usually MMO games use relational databases as their data backend, but I believe that NoSQL databases might be better. Usually, you have a bunch of data in your DB for each character, load it all when said character logs in, and very rarely, if ever, do any complex queries. This mode of operation seems to be the forte of NoSQL. That said, I've yet to use a NoSQL DB with an actual MMO server, so I might be wrong here.
Another database-related thing I want to warn you about is this. Many developers, especially early in production cycle, are tempted to store "game-design" data in a DB. I'm talking about things like items' and NPCs' parameters, abilities, and other stuff like that. Don't do that. These things are actually static data that does not change unless there's a server update; and this data is always needed by the server. Normally, you won't be doing any queries against it except a SELECT * ... at server startup. Thus, you don't actually need a database, and having these things in a DB has a lot of drawbacks. For one, you can't put a database under source control.
These are three main components for a MMO server architecture: network communication, logic partitioning and database access. All logic using these three is probably very game-dependent. I might have some more advice if you ask more specific questions and tell us more about the game.
