Implementation of the client of the Mobile Payment System of j2m's
The logical architecture of the entire agent is composed of several functional modules that cover network communication, user interface, security, and other functions, the client functions of the Mobile Payment System are realized through inter-module communication.
The logical structure 2 is shown. ~ F indicates the following:
A: user requests transaction/transaction operation results
B: transaction request information entered by the user/transaction result returned by the server
C: XML-encrypted request information/results returned after XML signature authentication
D: XML-Signed encrypted request information/parsed XML returned results
E: assembled XML data packets/XML data packets received by the network communication module with XML Signature and encrypted request information
F: XML data packets sent to the server/XML data packets received from the server
The black double arrow indicates the data of the RMS database specific to the j2-based architecture. The database access module is responsible for calling the functional interfaces of the RMS database of j2m's, using personalized settings for the user interface module, private keys and public key pairs for XML encryption and signature, the network communication module uses the HTTP access address and settings to access data, while other modules access the required data through the database module.
In the implementation of the client system, some third-party API libraries are used: kXML and Bouncy Castle API. Here, kXML is a tool for XML assembly/parsing, while Bouncy Castle API is a specialized tool for XML encryption/decryption and signature/verification for j2s applications.
The main modules of the client are as follows:
1) database access module
The database access module is required by all other modules. This is because it accesses the program configurations and user settings required by the entire j2_client to the j2_database. A simple Record-based database Management System (RMS) is defined in j2-midp. In RMS, Record Store is equivalent to a Table in a general database System ), it is a file that records a series of records.
The data warehouse access module operates on RMS and provides two interfaces for the external module to access data:
Interface for saving data to RMS by name: public void setDataToRecordStore (String name, String data)
Interface for retrieving data from RMS by name: public String getDataFromRecordStore (String name)
2) User Interface Module
The user interface module enables human-computer interaction, receives user input, and outputs the operation results in a friendly manner. In addition to using advanced user interface controls such as Display, Screen, Label, Command, Alert, Form, and TextField provided by j2s, you also need to use Canvas, Image, and other low-level user interface APIs provided by j2s, to achieve animation and other special effects.
3) XML encryption/decryption module
The two modules decrypt the shared key encrypted with the RSA algorithm public key from the server, and then use the shared key to encrypt the confidential information using the Triple DES algorithm.
By using the Bouncy Castle API password pack, we can easily encrypt and decrypt the confidential information in the transaction request to be transmitted in XML format. The org. bouncycastle. the crypto package has the vast majority of classes required for encryption/Decryption. In addition, the org. bouncycastle. the util package provides useful tools such as Base64 encoding conversion and Hex Encoding conversion. In the Bouncy Castle API, public keys, private keys, and shared keys are all objects. before trying to use them, you must reconstruct these keys through their main parameters. RSA Public Keys have two main parameters: Modulus and Exponent. In addition to these two parameters, RSA private keys also have several parameters, including privExp, dp, dq, p, q, and qInv, the Triple DES shared key only has a single key parameter. When these key parameters or encrypted information are passed, because many elements encrypted in XML use Base64 encoding, Base64 is also required. We have defined an Encryptor class to handle all encryption/Decryption problems. The interface is defined as follows:
TripleDES encryption interface: public byte [] encryptTripleDES (byte [] data) throws CryptoException
RSA decryption interface: public synchronized byte [] decryptRSA (byte [] data) throws CryptoException
4) XML Signature/verification module
In the XML signature process, the Digest of the original data is generated first, and then the digest is signed. The SHA1 algorithm is generally used to generate summaries. The Bouncy Castle API package also provides SHA1Digest classes for generating signature summaries, as well as RSAEngine and PSSSigner classes for digital signatures. We define the Signature class to encapsulate all the code for processing signatures. The interface is defined as follows:
Generate Abstract: private byte [] getDigest (String mesg) throws Exception
Use RSA private key signature: public byte [] RSASign (byte [] toSign) throws Exception
5) XML assembly/parsing module
To simplify the problem, XML assembly can be implemented using simple String concatenation. For XML parsing, kXML is used for processing. It is an XML syntax analysis program that only occupies a small bucket, and is very suitable for j2_based applications.
KXML has a unique DOM operation method and a syntax analysis method called Pull. DOM is a simple method for interacting with XML. Generally, this XML is a complete XML tree and is parsed into a node Structure Stored in the memory, you can retrieve information about all nodes by traversing this tree. It is very easy to use, but because the entire tree exists in the memory, it causes the storage burden. Unlike DOM, Pull syntax analysis allows programmers to "Pull" the next event from the syntax analysis program. Pull syntax analysis makes it easier to change the processing status, because you can send analyzer to different functions to maintain their own state variables. In addition, Pull is especially suitable for situations where the memory usage needs to be kept as little as possible in the j2s environment. Therefore, we use the Pull method for XML parsing. The interface is defined as follows:
Get the corresponding value based on the XML node name: private String getXMLNodeValue (String nodeName)
6) Network Communication Module
In the MIDP 1.0 API of j2m's, the network communication protocol supports UDP, HTTP, Socket, and so on. Although theoretically, the Socket or UDP protocol can be used to communicate with the outside world, some manufacturers' MIDP devices may not support these protocols. Using these protocols for communication may cause program transplantation problems. HTTP is the most important communication protocol on the internet today. Therefore, mobile terminal devices of all manufacturers Support HTTP. Therefore, we use the HTTP protocol for communication. The following code sends and receives data: public String sendAndReceiveByHttp (String url, String strToSend) throws Exception
{
HttpConnection hc = (HttpConnection) Connector. open (url, Connector. READ_WRITE );
Hc. setRequestMethod (HttpConnection. POST );
Hc. setRequestProperty ("Connection", "Keep-Alive ");
DataOutputStream dos = hc. openDataOutputStream ();
Dos. writeUTF (strToSend); // send data to the destination URL
Dos. flush ();
Dos. close ();
DataInputStream dis = hc. openInputStream ();
String strReceived = dis. readUTF (); // receives the response data of the target URL.
Dis. close ();
Return strReceived;
}