Xfire implementation of WebService client test focus

A few days ago the work of contact with a lot of system WebService call, here want to talk about WebService based on spring+xfire implementation of the client stepped on some pits, need to test the point of concern.

Configuration items for Xfire

It is relatively easy to implement WS client clients in spring, just to write an interface class that is consistent with the WebService interface. There are several parameters to follow in the configuration of XML:

• Http.timeout: Response time-out, that is, the server received a WS request, but did not return for a long time when processing the request, timed out
• Http.connection.timeout: Connection timeout, which is the time-out for establishing a connection to the server

Filtering and encoding of the message body sent by the Xfire

When Xfire is called, the WS call fails if the request parameter contains a special ASCII character (0x00 ~ 0x1F) of the ASCII code. The processing method is to filter the request parameters and remove the control characters.

Another consideration based on sending the message body is i18n, which attempts to include: half-width, full-width, double-byte characters, three-byte characters, and so on.

Xfire Call service-side failure handling

1. Retry after Xfire call exception

The failure of some key business webservice calls can have more serious consequences, but the Xfire itself has no retry mechanism. Now, if the Xfire call fails, the catch does an exception and the message body is inserted into a retry task table, which is retried later by the dispatch task.

2. Xfire call exception, print the log desensitization

If the Xfire call fails, the Exception log is typically printed after the catch exception is caught. If you are involved in a core business, from a data security standpoint, you need to focus on whether sensitive information (such as credit card numbers) will be included in the exception stack, and the abnormal log printing needs to filter out sensitive information.