How to solve the problem with various data formats(XML,JSON,SOAP) for data exchange?

Question

We are supporting data exchange in JSON, XML and SOAP for our customers. The bird view of the data flow would be like this

• Partner 1 sends request for some data with XML data
• Partner 2 sends request with JSON
• Partner 3 sends request with SOAP

To have a general approach for all partners. We have created a file for each partner where we are defining the partner's parameters and our corresponding parameters.

After getting the data required we process the data and generate a response. This response has to be sent to partners in their respective formats again. For that, we have templates where we just fill the response data into the template and sent that to the partner.

How do you normally solve this problem?

What am I working on? I am creating a generic parser which transforms partners request into our required format with the help of the file we have with parameters.

Answer 1

You use a very valid approach, but your question is quite broad: there are plenty of ways to handle it. The right answer will depend heavily on your existing architecture.

My first guess would be to:

• use a strategy pattern for format dependent parsing;
• use a strategy again for generating the answer (if the template approach would no longer be sufficient)
• if needed, put a format selector in your parser output request in order to keep track of output format to be used for sending back the answer.

If an ad-hoc parser is not sufficient, you could use out of the box parsers, and handle the different parsing events in a way to build an homogeneous format independent request object (i.e. The requests could be implemented using the command pattern, which when carried out will execute the request and produce the answer).

P.S: I understand that your system carries out some kind of transactional processing, and that the parsing is more about getting the parameters/arguments of the transaction than elaborate parsing of complex requests. This is why I didn't suggest the interpreter pattern.