Technologies to use:
* -Tomcat 6
* -Java 6
* -NetBeans 1.6
* -MySQL 5
* -Use connection pooling via JNDI
For the development of this module, the following are the requirements.
* Score uploading is done via https (SSL) connection
* Server shall have a digital certificate and signature signed with the companies like Verisign
* The J2ME score upload client has already been done. What you need do to is to "receive" the score and other data from the J2ME client via https
* nickname value is encoded with a special algorithm. Thus, server needs to be able to decode this value. The class that encodes this shall be provided
* nickname value is stored in JAD file in the J2ME client.
* Checksum is the value created from file size of the jar (game) file. The checksum value will be uploaded with the score. Your module needs to verify that the uploaded checksum is the same as the current checksum in the database table. Each user generated a checksum when they download the J2ME client. Checksum class shall be provided
* The score value can be integer or alphabets (encoded)
* System must be able to ban nickname+phonenumber pair from uploading. This is important because, assuming someone's phone is stolen and the phone already has a game with the nickname stored inside the JAD file. If someone used the phone and decrypted the nickname value and use this nickname to upload the score, the original owner of the phone will be charged!
* When the score is uploaded (request), the server will read the paramaters and confirm if the nickname or gameid exists. If No, the server response with fail code. If yes, then the checksum value is compared against the checksum value and phonenumber+nickname pair banned list stored in the server database. If the value is the same, then the score is processed (stored)
* The server-side shall acknowledge each score upload request with a successful response
* There must be a queuing system that ensures that the server is able to accept ALL concurrent score upload requests. There should be something like a ScoreReader that QUICKLY inserts score data into the score table and response back to client, and ScoreFetcher that reads the score data one by one. This is to accomodate as many as 3,000 concurrent requests in 1 sec
TERMS & CONDITIONS
-There shall be no initial deposit. We shall only pay (not escrow) 30% of the fees upon completion of first UAT. We shall pay the balance 70% after successful subsequent UAT and all bugs are fixed
-All work/deliverables are subjected to changes. Changes that are mutually agreed as major, shall be charged with rate that is mutually agreed
-Changes are defined to be changes that is within the scope/requirements/feature, but needed to be done differently. For example, a database table to store users information that has not been normalized, needs to be normalized.
-Full payment will only be paid after we have successfully tested your code/work and we are 100% satisfied and agreed that you have meet our requirements
-Full payment will only be paid after we receive all your deliverables
-Successful deliverables means your deliverables that has 100% meet our requirements to our satisfaction.
-Very, very positive feedback will only be given to providers that 100% meet our requirements to our satisfaction
-Service provider (which is you) must provide milestones for your service. Each milestone achieved and fully completed (with successful UAT with bugs fixed) shall be reciprocated with progress payment. Progress payment for each milestone will only be performed after the deliverables for that milestone is performed. Typical deliverables are (but not limited to) source codes and files (like .aspx, .php, .html, .java), image files (.jpeg, .gif, .png), source image files (.psd, .png), multimedia files (.mid, .avi, .mpg) and other documents (.doc, .txt)
-Winner must provide the info below for record keeping
National ID Num:
-Please do Javadoc provisioning for each class, package, methods
-Please put comments on lines that is significant, for example a line or section that does a specific process
-Information for the system that you think will not be constantly changed, like server URL or IP, place them in property file -Information that you foresee will change especially when you change it you cannot restart the server, then place them in database. For example, classname or username/password -MUST NOT do hard coding
STANDARD DELIVERABLES (but not limited to):
-NetBeans project files (.zip)
-Database structure in (.sql)
-Other source files includes proprietary software files like Photoshop files, xml files, properties files, config files, image files, etc
-Report, if required
-Screen captures, if required
-Readme file that contains instructions that we need to know, like URL, example of URL to test, configuration tutorial, etc