Web Service wrapper

Question

I am writing a dll that is referencing to some WCF service. The dll is functioning as a Gateway of the service and all calls are going through it. Probably there can be concurrent calls .

I have referenced the service but now I cannot decide how to write the wrapper functions correctly.

Is there some example or best practice for this functionality.

Answer 1

I would make wrapper that matches the web service interface. It would also be a good idea to wrap up all of the objects exposed. Basically create a proxy. What I find really useful for this type of thing is to create an interface that matches the API and implement that. That way, you can create a dummy version of the DLL for testing without the overhead (or potential costs) associated with the WCF call. It would also make it much simpler if you need to replace the WCF call with an alternate provider in the future.

As an example, lets assume that we have an WCF service to an external provider for processing a payment. Something like this:

void ProcessPayment(float amount);

We could easily hook this into our code. The problem is that a simple change to the interface would result in us having to make changes everywhere the code is referenced. The same would be necessary if we changed providers to someone else, even if the interface was almost identical. Adding something like a simple interface:

interface IPaymentProvider
{
    void ProcessPayment(float amount);
}

Would completely decouple our code from the WCF service. We could easily build a class like this:

class PaymentProviderAWrapper : IPaymentProvider
{
    void ProcessPayment()
    {
        // Call the WCF service
    }
}

That we could load dynamically with a factory or dependency injection framework like Spring.NET. Changing to a provider B would be as simple as creating a new wrapper:

class PaymentProviderBWrapper : IPaymentProvider
{
    void ProcessPayment()
    {
        // Call provider B's Native DLL
    }
}

Switching your code from provider A to B would be as simple as changing a configuration setting.

Even if we compiled the library directly into our code, all we would need to do is change the construction logic to use the new library. The rest of our application would not change at all. Just a simple recompile.

Answer 2

In response to Graymatter's answer I don't see what the difference is between calling a service wrapper which exposes the same calls and then forwards the calls to the real service, and just calling the service, assuming a one-to-one mapping on individual calls and no change in transport binding.

The only reason you would want to create a wrapper in the first place is that the interface exposed in some way does not meet your requirement on it's own. There are several reasons you may want to do this but a few common ones:

1. Protocol translation - the service is not exposed across the correct transport binding for your needs
2. Service Composition - the interface operations are too granular and don't represent business-level operations.
3. Authentication - perhaps you require an authentication layer on top of the endpoint you are consuming.

So how to wrap the service endpoint depends on why you want to wrap the service...