MockeMe

For client-server applications (with xml interchange) where the client is based on J2ME, it is interesting to be able to start the development without having to wait for the business layer services to be implemented.

Waiting for the implementation of business objects usually involves delays in the availability of services on which to test the client.

 

MockMe has been devised as a tool for this kind of situation, i.e. XML-based interchange between client-server applications. It allows the client to be tested without having to wait for the service layer to become available or, perhaps more importantly in complex applications, without having to wait for data to become available for processing.

 

Part of the development process in client-server applications with XML-based communication involves establishing the interchange formats (between front—end and back-end). With MockMe, once they have been defined and the tool configured, both parts can begin to work in parallel.

As Mock Me is a war, it only needs to be placed in the deploy directory of the selected server (/webapps en Tomcat). Fig. 1 shows a Tomcat deploy directory after the MockMe deploy.

 

Fig. 1 Deploy directory after the MockMe.war deploy.

 

Within the MockMe directory, you will see the following:

 

Fig. 2 MockMe structure.

 

 The XML directory is the place where the xml files that you want the server to return are stored. These files are edited according to your needs and stored here for the tool to return them later according to the operation code it receives.

 

Fig. 3. xml files stored in the /XML directory.

 

The files .properties, config and operations are the most important for configuring the tool. In operations, the association between operation codes and xml files takes place.

 

Fig. 4. Association between operations and files in Operations.properties

 

The general configuration parameters of the tool are found in config.properties.

 

Fig. 5. Configuration parameters in config.properties

 

Operator parameter

 

The operator parameter specifies the name of the operation parameter that will be passed in the petition url. In agreement with the figure, a petition for this configuration would be of the form:

 

http://localhost:8080/MockMe/mock?codoper=31

 

If you want to use the "oper" operator instead of the codoper, go to config.properties and replace the first line with

 

operator = oper

 

Random parameter

 

The second parameter refers to the way you want the results to be returned, if there is more than one xml file for one operation code (see code 31 in Fig. 4). If, as in the figure, you have:

 

random = yes

 

it means that the server must select the xml files at random. In the case of code 31, there are two different files, which means that it could return either of them. If instead you have:

 

Random = no

 

it would only return the first from left to right for a given operation. (xml31-1 in the case of Fig. 4).

 

Log parameter

 

The third parameter refers to the possibility of the tool logging the petitions received. This log will be recorded in the log files (localhost.DATE.log) that are in the (/logs en Tomcat) log directory.

 

It can be cancelled with log = no. But if there are problems with the configuration files, the errors will be informed anyway by means of this mechanism.

 

Finally, the petitions to the tool can be made either from a browser or from the JME WTK emulator. Note that to petition from a mobile phone, the host where MockMe is placed must be published.

Whether using a browser or the JME WTK emulator, the petition for a given operation code will return the xml you have defined.

Fig. 6 shows the result of a petition with operation code = 1 (which, according to the operations.properties in Fig. 4 corresponds to the xml1-1 file).

 

Fig. 6. xml result of a log-in operation returned by MockMe.

 

Thus, with MockMe, the behavior of the application developed in the mobile as a result of a given response of the server can be seen either from the emulator or from the mobile device itself, without having to wait for the implementation of the services that will later be returned from the server.

 

Considerations

This tool has been devised for developing j2me clients, because as this API lacks serialization and introspection, the interchange of pure objects is usually less frequent than the interchange of XML objects. Nevertheless, it is worth pointing out that if the programmer wishes, he may create his own serialization mechanism. Whatever the case, this tool can also be applied to multi-layer j2ee architecture, as long as the interchange between layers is XML-based.  

Contact: 

If you have any suggestions, please write to me at: 

mario.lamenza@gmail.com