CODEWITHSUNDEEP
c#servicestack
Stephen Patten
Stephen Patten

Reputation: 6363

How to change the operation names of a ServiceStack soap12 proxy?

Given the following service definition:

public class RuleEngineServices : Service
{
    public object Any(ExecuteRule request)
    {
        var response = new ExecuteRuleResponse();


        return response;

    }
}

How might I influence the proxy name that is generated by adding a 'web service reference' in visual studio? If I named the web reference 'RuleEngineWS' then the following signature is created:

using (var client = new RuleEngineWS.SyncReply())
{
    ExecuteRule request =  new ExecuteRule(); //request DTO
    ExecuteRuleResponse response = client.ExecuteRule(request);
}

Both the request DTO and the method have the same name which consumers of said service find confusing. Is there a way to clearly demarcate the method from the dtos?

Thank you, Stephen

Upvotes: 0

Views: 66

Answers (1)

mythz
mythz

Reputation: 143284

There is no way to modify how the code is generated in by Visual Studio's "Add Service Reference" other copying and hand-modifying the generated WSDL and getting users to generate a Service Reference off your modified WSDL. But you need to be careful you don't alter the wire-format of the SOAP messages that's sent.

But SOAP is an extremely fragile, bloated and rigid protocol that has many attributes that make it a poor choice for Service Interop, notwithstanding it will unlikely be available in future versions of ServiceStack which supports .NET Core.

Your focus should instead be on getting your Service consumers to use a superior development workflow as seen in Add ServiceStack Reference which is cleaner, faster, more resilient, has more features and offers the ideal typed client API and greater HTTP fidelity which behind the scenes is just sending clean DTO's in the optimal Format of your ServiceClient without additional the overhead and runtime issues of embedding the message in a SOAP envelope.

There should be very few reasons for using SOAP today which offers no inherent advantage over HTTP for consuming Services, the only valid reason I can think of needing to use it today is that your consumers are using an enterprise tool that only allows connections to SOAP endpoints.

If for some reason your consumers are mandated to use use SOAP they can use the Soap12ServiceClient which still uses a generic WCF client for the underlying SOAP message exchange but benefits from having a better and more consistent API. Failing that you can create a thin facade on the client which hides the generated API's behind the ideal API's names you'd prefer, e.g:

var client = new RuleEngineClient(new RuleEngineWS.SyncReply());
var response = client.Send(new ExecuteRule { ... });

and behind-the-scenes calls the appropriate SyncReply.ExecuteRule() method.

Upvotes: 3

Related Questions