Architecture
The architecture of the application is based on so-called EJBs, which run in a Java EE environment.
Most calls from the client are realized using the RPC-technology provided by JEE.
In some cases (e.g. for synchronizing the game with all players) the backend uses JMS-Topics to which the client is connected via observer pattern. This guarantees that all clients are in the same state.
The Game-Message is an object message and contains all information that could be sent to all clients. Only clients that are in the game are receiving the game-messages, because we implemented an message-selector which looks for the current player in an string property of the message.
The lobby is also updated via a JMS-Topic, but the difference here is, that every client only gets a empty message from server which means "anything in the lobby has changed". After that every client on the lobby-page is requesting the current specators and players in the lobby to display them. This method was chosen, because all players in a game don't need information about the lobby.
All communication which should be kept private, for example the login data of a client or the current cards of a player are requested and responsed via CORBA. This is like we have done it in the lecture and the chat project.
To get a sync message for a game, the clients can send a message to a so-called "GameQueue". This game-queue is handled by a messsage driven bean and checks for every message if the sender is in a game. If the sender is in a game, there will be generated a synchronization message with all details about the game. This message is then sent via the topic to all listening clients, just like there was a change in the game. The client needs that queue, because if a player closes the playground-window he will be forced to log in again. After that he will get back into the game. If nothing changes, he will not get notified with all the game-objects and the GUI can't display the game. So on a new login the client asks the server via queue "hey, can you give me the current game i'm in?" and the server replies on the already implemented way.
Before implementing the game logic we tried to find all actions a user could do and all rules that a player have to check for this move. As a result of this we created an activity diagram, in which you could see the general game flow and a second in which you can see a move of a player.
For the game-management we created a bean which only operates with the help of the GameValidationBean. The GameValidationBean checks if the current move is valid and the GameManagementBean does all what is nessecary to play the game. We got many of the information how the game-management should work out of the previously generated activity diagrams.
The AI is fully integrated into the GameManagementBean, because the server should not run a new instance of the serviceclient itself. So we integrated a full move of the AI into the "next player"-method. If the AI is the next player it will do some things. Things the AI can do are: Check the current value of the cards on the hand and check the value of the cards in the hand with the LIFO-Stack-card and then decide what card to draw. Then the AI can check if it is possible to lay a phase on the table or to add cards to open piles on the table. At the end the AI discards the card which is the less useful and highest in value for the current deck.
The JPA 2.0 implementation EclipseLink provided by glassfish is used to persist data. Each group member installed a local MySQL database which was linked to the Java EE Code by JPA.
The following models were implemented as persistent entities and configured by annotations:
