For almost any game, you really don't want to use the architecture you described. The reason for this is that the server is just forwarding what the players do without anything to prevent cheaters, and you also have a high probability of data races. As an easy example, suppose you write an FPS like this. A compromised client could auto-shoot at any enemies in sight, and making the clients smart enough to protect against this (and more importantly, agree on who's cheating and who's not) would be quite difficult to do. For data races, consider the case where two players shoot at each other at the same time. Due to network ping differences and packet loss/reordering, the messages will not reach the server at the same time and will not reach to the clients until even later. In this case, it's very easy to have clients that both think their player hit the other guy. Now you have a conflict where two clients think they scored a point, where really only one did. Sure, you could come up with some elaborate way to sync the clients so that these cases are taken care of, but (a) this kind of synchronization is extremely difficult to get right, and (b) it's likely that any solution is very costly in terms of time. Yes, it's possible to build a synchronized, distributed, peer-to-peer architecture that will work, but in terms of runtime performance and development time (and ease), you will do much, much better by making the server authoritative. This means that the server is running some "world simulation," and may or may not even be running as a standard jME SimpleApplication. Whenever somebody running the client does something, instead of the client "doing it" the client sends a message to the server saying "Player X wants to do Y," the server checks if it's a valid thing to do, updates its internal state, and then notifies Player X's client (and anyone else who is in range to see/should know/etc.) that Player X just did Y. This makes it far easier to prevent cheating and ensure that all clients stay in sync (or that out of sync clients don't mess up everybody else).
You certainly can run a server as a headless (authoritative) jME application, like you mentioned, but it's not strictly necessary. The server for my project uses a totally different internal architecture and just embeds SpiderMonkey (the jME network stuff) for communicating with the client (which is a very typical jME application that gets all its data about the world state from the server). That being said, unless you can identify a very good reason why your server shouldn't be a jME application, you probably want to write your server as a headless application. jME's architecture gives you a lot of power and gives you a lot of functionality that you easily find you need/want later down the road.