Problem Statement
With the programming model that was just presented, the client ends up programming directly against the service provider (SimpleCalculator, in this case), instead of against a generic abstraction of the service. A better approach is for the SimpleCalculator web service to be polymorphic with a service abstraction—that is, an interface. Programming against an interface rather than a particular service implementation enables the client to switch between different providers, with minimal or no changes. This way, the client becomes indifferent to changes in the service provider. For example, imagine the client wants to switch from SimpleCalculator to a different calculator web service, called ScientificCalculator, that supports the same interface as SimpleCalculator but is perhaps more accurate, faster, or cheaper. Ideally, either the client or the service providers would agree to define an abstract calculator interface, the ICalculator interface:
[WebInterface]//Imaginary attribute. Does not exist in .NET.
public interface ICalculator
{
int Add(int argument1,int argument2);
int Subtract(int argument1,int argument2);
int Divide(int argument1,int argument2);
int Multiply(int argument1,int argument2);
}If such a web interface were available, the client could code against the interface definition, not a particular implementation, as shown in Example A-3.
Example A-3. Web services client-side interface-based programming model
ICalculator calculator = new ScientificCalculator(); ...