Drawbacks of a Sudo Strategy Pattern Drawbacks

I'm working on a project where I need to call many different services and wanted to abstract out as much of the common logic as I can. The kicker is that I also want to return custom objects instead of something such as json. As I designed a way of doing this, I arrived at a paradigm that reminds me of a Strategy Pattern, but I don't quite think it fits. I'm wondering if there are any design flaws or dangers in how I've done this.

Basically I've created an abstract class (ServiceCall) that holds the common logic for calling a service (have an internet client and get a json response from the desired service). This is all done with the public method call(Map<String, String> params, Map<String, String> headers). The abstract class also defines two abstrach methods: createCustomDTO(Map<String, String> params, Map<String, String> headers) and parseResponseToObject(String json). I'll explain the purpose of these in just a second.

Each call to a different service will be created with a class that extends ServiceCall and creates an implementation of the abstract methods. createCustomDTO will create a custom object that contains all the information needed to call the service (url, and headers). parseResponseToObject will take a json response and turn it into the java object I want to use later in my code.

Here is a simple implementation of what I did

ServiceCall

public abstract class ServiceCall {

    protected abstract Object parseResponseToObject(String json);

    protected abstract CustomServiceDTO createDTO(Map<String, String> keys,
        Map<String, String> headers);

    public Object call(Map<String, String> params, Map<String, String> headers) {

        // create and configure a CustomServiceDTO to call services with
        CustomServiceDTO dto = createDTO(params, headers);

        try {
            // make the service request
            String json = getServiceResponse(dto);
        catch (Exception e) {
            return CustomServiceError(e);
        }

        // parse the response into the desired java object
        Object response = parseResponseToObject(json);
        return response;
    }

    private String getServiceResponse(CustomServiceDTO dto) {
        // use common logic to call the service using the information provided
        // by the dto

        String dummyResponse = "{\"prop\":\"value\"}";
        return dummyResponse;
    }
}

SampleImplementation

    public class AddressCall extends ServiceCall {

    @Override
    protected Object parseResponseToObject(String json) {
        return new Address(json);
    }

    @Override
    protected CustomServiceDTO createDTO(Map<String, String> keys, 
        Map<String, String> headers) {
        CustomServiceDTO dto = new CustomServiceDTO();
        dto.setUrl("http://ift.tt/1W9ZVoY" + keys.get(0) + "=" + keys.get(1));
        dto.setHeaders(headers);
        return dto;
    }
}

The main drawback I see to this is that never directly calling createCustomDTO and parseResponseToObject is a little strange.

The main advantage for me is the ease of use and having my responses returned as java objects.

What I really want to know is are there any other concerns or drawbacks to this paradigm? It's very nice in the code, but I admit it seems a bit different from how java is normally used.