Design and Architecture of Jxta-Based Game Software in Java.

. This paper discusses the interest of explicit software processes of design and architecture for (1) architectural view understanding and communication, (2) design reuse and principles of Jxta-based game software development. The considered architecture includes hierarchical and logical views which are modeled in the Java-based Maiar API and achieved by Jxta message exchanges . The topology of the world map of the game software can be viewed as undirected graph in which vertices (nodes) represent the rooms and the edges represent the playable movements between nodes.


INTRODUCTION
In order to share resources, peers in Maiar interact directly with each through the exchange of messages. Peers directly access and exchange the share resources they utilize in without a centralized service. A framework called shoal 1 based on the technology, JXTA [8] used in the design of the peer-to-peer game software has the notion that for cross subnet communication like the internet there needs to exist a virtual list of hosts which will be used to route all messages to other peers over the internet. Peer-to-Peer (P2P) software is simply a software system with a completely decentralized self-organization and resource usage. P2P mechanisms can be used to access any kind of distributed resources and may offer any new internet-based applications mostly in the area of gaming [14]. In order to achieve that we introduce a peer called Server which is logically another peer with the same shared resource as the other peers, Maiar Player-Peer. This model offers adequate formal basis to deal with the reliable design of distributed software. It has become important that for internet-based applications, issues of scalability, performance, security, flexibility and quality of service 1 Shoal is a java based scalable dynamic clustering framework that provides infrastructure to build fault tolerance, reliability and availability. The framework can be plugged into any product needing clustering and related distributed systems capabilities without tightly binding to a specific communications infrastructure. https://shoal.dev.java.net/. needs to be taken care of. These requirements are some good benefits which P2P offers in the main architecture of P2P software. The Server is a Web Server precisely Tomcat [16] and this will enable the application to continue working once Tomcat is up and running. Graph [1] played an important role in defining the notion of the world map.
The rest of paper is organized as follows: In Section 2, the overall overview of Maiar architectural views with detail explanation of its 5 components. An introductory material and the design principles of each of the major 5 components are provided. Section 3 describes the game component model. In Section 4, I will look at the design principles of the messaging component model. In Section 5, the principles of design of the game component model are described. Again, Section 6 describes the principles of the logging component. Section 7 is the look at the security component model in details. Section 8 will be the architecture of Maiar that will be accessed on how it provides some major software quality attributes. In Section 9, I look at the deployment view of Maiar game software. Finally, I conclude this paper.

The main contributions achieved in this paper are as follows:
 The architectural design of peer-to-peer game software in Java.

ARCHITECTURAL VIEWS OF MAIAR
In this section, we will start with the representation of world and discussion of the major components of the Maiar API with concise reasons of choice of technology. The API is comprised of a number of components, specialized for a specific purpose. Layers and domain objects are applied to the design of Angels and Demons game called Maiar to introduce a clear identification and modular separation of all baseline architecture elements in both their Login Authenticator responsibilities and core usage relationships. As such vertical and horizontal decomposition of the game's functionality is realized using Apache Maven [10]. Figure 1 depicts the hierarchical view of Maiar Architecture and Figure 2 depicts the logical layer of the Maiar Architecture.

World Representation
In this section, I will have a look at the algorithm for the XMLtoObject parser and the structure of the XML [3], [15] document.

XML Structure of World.
The xml structure of the world is defined with a DTD schema. The elements used in the representation of the World are as follows:

Parsing the XML to the world graph.
In order of the world to be used during runtime it needed to be converted into an Object. The chosen object type for the parsing was a graph of rooms for the room representation and a map of commands for the global commands. For parsing the XML, the use of the Jdom library has proven to be the best choice because of the tree form of the XML file it offers, and the access methods to the XML file. First the XML is read using a SAX builder, which parses the XML to a tree. Then each room is parsed on its own using the getChildren command which returns a list of the chosen element type.

GAME COMPONENT MODEL
The game model requires that there is an XML data of the world map along its inventor y stored on a peer-to-peer model system. The player class is the main instantiation of the game execution.

Design Principles
Since the game revolves around commands and states of the world, its engine required a way to handle each command and send a response to it which must become visible to the player. For this functionality a number of classes are used to represent the game entities which are extracted from the XML data. These classes are a 1-1 mapping of the XML elements with specialized effects, and additional remote effects which are a way of indirect communication with the message service. The main class of the game engine, the player includes all other classes mentioned and handles interactions between them, and is responsible for communicating with other components of the game. It's connected to other components using a request-response protocol, where any component which needs to communicate with the game engine, must send its input and wait for a response output, and handle the output. The player interface is the only means of changing the state of the player and the only way of verifying if a command is valid. It is a full representation of the game world as seen in a client, since the player class holds the player's details, the room in which he or she is, the entire game is mapped as a graph, the player state (inventory, active and finished quests, health points, and list of players with who m he or she is fighting), as well as a map to the global commands and their actions, as they are extracted from the XML data.

M ESSAGING COM PONENT M ODEL
One of the most important aspects of communication between clients is the broadcasting and reception of messages. Through messaging, the clients, update their local world states, and represent the states of other clients.

Design Principles
The publish-subscribe architecture pattern describes an abstract mechanism for loosely coupled, many-to-many communications between publishers of messages and subscribers who wish to receive messages [6]. The messaging component can accept any number of listeners and when a message is being received all of the listeners are being notified of this change and they can act upon the state change. The advantage of using this model is that we can add different components which can manipulate messages at any time just by having the m subscribe to the message publisher. Also this separates the message component fro m the client component which enables the possibility of replacing the implementation of the message component with a different one without changing the subscribers. For the actual broadcast of messages there were several choices of technology includ ing JGroups [7] and Jxta. All the messages are an extension of the AbstractMessage class, where a sender and a message string are defined, as well as a date and the message type. The AbstractMessage class is an abstract imp lementation of IGMessage interface as defined below:

public interface IGMessage extends Serializable { public String getSender(); public void setSender(String sender); public String getMessage(); public void setMessage(String message); public void setDate(Date date); public Date getDate(); public String getType(); }
Each type of message extends this class by adding any additional information it may require. Specifically, Location messages add the room id of the player's location as well as the player's fraction. Chat messages add a scope and the receiving roo m id and/or player; cache update messages add a recipient who should update his or her cache. Chat messages are extended by fight messages which are a special type of chat messages and use a specific message string for communication, and damage messages are a special type of fight messages which introduce a damage amount integer. To achieve this, several types of messages are used, each one sent when the appropriate effect is triggered, and are processed accordingly. There is also a distributed and a local cache used for sharing the user states that need to be shared. Sending Messages. Messages are sent through the JXTAConnection class using the send method. Messages are formed according to the commands the player enters, and are broadcast on the group. When a message has a limited scope, that message is discarded on reception if the receiving client is not a me mber of that scope. Receiving Messages. When a message is received, if its scope includes the receiving client, it is added to the appropriate history in the local cache and the message listeners are notified of an update of the local cache. Each receiving client then processes the message and responds to it either by representing it or sending a message of its own depending on the nature of the message. The types of messages are separated into state changing messages and player communication messages. State changing messages are Location messages, New User messages and Cache Update messages. player uses the whisper command. The global chat messages are represented in all clients, while  the room messages are represented only by players who are in the same room as the sender, and  personal messages are represented by the player set as a recipient, if that player is in the same  room as the sender. All these types of messages are saved as a history in the local cache of each  player. This cache contains a chat history, a new user history, a cache update history, and a  location

GAME ENGINE
The game engine is the heart of the Maiar game software and is developed mainly on interfaces for easy extensibility of many actions and effects. It revolves around actions and effects that show in the 2D graphical user interface with skinning support. Based on a certain query of state of the room and an action inputted by the player/user will in turn then trigger an effect for the player like rendering a different room in the sequence of procedure described in the XML data. Let's look at the design principles of the engine component model.

Design Principles
The engine component (model) co mmunicates with other components using a requestresponse architecture through its interface. That interface is the player class interface which offers methods for retrieving trivial data from the player class, and two methods which can result in ga me state changes. These methods are the tryAction method, and the ExternalEffect method, both of which return a list of effects to be handled and represented to the GUI. The main difference between them is that the tryAction method takes as input a String co mmand which is the player input command after it's been parsed by the command parser, while the ExternalEffect method takes as input a RemoteEffect, which is a type of effect which involves multiplayer interaction and is invoked by an incoming effect. In Figure 3, the life cycle of the remote interaction between GUI of peers is in Figure 3 and so is the internal life cycle of operational activities of local states described in Figure 4.
This architecture ensures that the engine component can work independently of either a multi player component or a GUI component, and can be used in a different type of game, which could have a different GUI and no multi player mode with just slight modifications. This also allows asynchronous communication with other players since the messaging engine works asynchronously from the GUI in Figure 5.

LOGGING COMPONENT MODEL
Maiar Logging provides a facility for maintaining the development of the game in the development stage and for custo mers at production stage. Basically, the logging facility provides these core functionalities: Developer Diagnosis: The most obvious functional merit of logging is to help developers under development stages to be able to debug the application. Because a modular approach was used in designing the game, it is essen-tial that each module is able to log its activities to help us to identify other proble ms that occur at runtime and other low-level libraries were used in the imple mentation, logs help locate problems in the application. End-Users and System Administrator Diagnosis: It is important that messages sent by a peer are transmitted successfully to the group, which is the core building block of the design. End-users can use logging activities in the application to convey the errors in the application to the System Administrators for system diagnosis. In practice, common end-user needed logs include system failure, me mory issues and errors in the configuration files. With the Maiar Logging, these logs are generated and can be configured to send email to the Maiar development team.

Design Principles
There are a lot of logging frameworks out there, which each has different core functionality. The idea of designing Maiar Logging over the other frameworks inclusively SlF4J [13], Log4j [9] and JDK logging requires a common interface to abstract the imple mentations of the frameworks from the imple mentation. The Logging compound component shows the three basic factory components each of which provides an access to a particular logging frameworks. The use of the abstract factory design pattern separates the details of the imple mentation of a set of objects from their general usage. The basic details of the factories are:

SECURITY COM PONENT M ODEL
At the architectural level, security boils down to understanding the precise security requirements for an application, and devising mechanis ms to support them [6]. The most common security-related requirements [2] are: The architecture only supports authentication but the other three security-related requirements can be provided. New users to the system first create an account by registering their details and choosing user name and password. This information is stored in the database. Whenever users wish to play the game, they would supply user name and password and is checked against the one in the database, MySQL [11]. If the information provided matches with the information in the database, access is immediately granted. This ensures that no unauthorized user ever gets access to the system.

SOFTWARE QUALITY ATTRIBUTES
This section provides an overview of the software quality attributes that the application attains much to do with the choice of the technology. Quality attribute requirements are part of an application's nonfunctional requirements, which capture the many facets of how the functional requirements of an application are achieved [6]. The application captured the following major quality attributes (S-M-E-P) that the software Need:

DEPLOYM ENT
The executable program will be installed on the peer system after has successfully registered with the Maiar Server Web Application. For the client peer to work, it requires some dependencies which are just Java Executable jar files as shown in Figure 6. A Peer requires the Java Runtime Environment (JRE) installed on the system to be able to play the game, Maiar. There is an optional installation process for Peers that does not have the JRE installed on their systems and this is bundled with the Game installer deployed and hosted on the Application Server. Peer Dependencies: For a peer to successfully run the Maiar Game, these are the required artifacts on their system:

• Logging.jar: This artifact is the logging component of the application. It is required to provide the basic logging functionality at the peer side. • Model.jar: This artifact contains the domain model of the game • Client.jar: This artifact contains the Graphical User Interface, which is the Swing Application with interactive response and user experience. • Messaging.jar: This artifact is the most essential component of the peer dependency because Maiar
server classes are placed.

Figure 6 Deployment View
CONCLUSION. This work has thoroughly detailed the design and architecture of Maiar game software mainly in terms of the game engine design principles, game modeling of actions/effects, messaging design of the message exchange component model, security model of the game application, logging component for application messages (warning, debug, information, etc) software attributes needed in the requirement process and deployment view of the game software in general.