Web Services Wrap

Question

I am writing a dll referring to some WCF services. The DLL functions as a service gateway and all calls go through it. There may probably be concurrent calls.

I refer to the service, but now I can not decide how to write wrapper functions correctly.

Is there any example or best practice for this feature.

Answer 1

I would make a shell that matches the web service interface. It would also be nice to wrap all exposed objects. Basically create a proxy. What I find very useful for this type of thing is to create an interface that matches the API and implement it. This way you can create a dummy version of the DLL for testing without the overhead (or potential overhead) associated with calling WCF. It will also make it easier if you need to replace the WCF call with an alternative provider in the future.

As an example, suppose we have a WCF service for an external provider to process a payment. Something like that:

void ProcessPayment(float amount); 

We could easily connect this to our code. The problem is that simply changing the interface will result in us having to make changes to everything that the code refers to. 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); } 

Completely disconnect our code from the WCF service. We could easily create a class like this:

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

What we could dynamically load with a factory infrastructure or dependent injection like Spring.NET. Going to provider B will be as easy as creating a new shell:

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

Switching your code from provider A to B will be as simple as changing the configuration settings.

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

Answer 2

In response to Graymatter’s answer, I don’t see the difference between calling a service wrapper that provides the same calls and then forwards calls to a real service and just calls the service, assuming that one-to-one display of individual calls and no changes in transport binding.

The only reason you would like to create a shell in the first place is because the interface, opened in some way, does not meet your requirements. There are several reasons why you can do this, but a few general ones:

• Protocol translation - the service is not displayed through the correct transport binding for your needs.
• Service Composition - interface operations are too complex and do not represent business-level operations.
• Authentication - you may need an authentication level on top of the endpoint that you are using.

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