My client application will have a set of varying business functions. These functions will be fullfiled via various 3rd party services (i.e. web services, http post/get, remote data access or socket to socket feeds)...in other words, the protocol for getting to those services to fulfill a business request may be different.  

What i intend to do is to define the functions in an interface so that the client code can be implemented against this interface independent of the business or data tiers which will actually execute the action; let's call this interface IClientServices .

Now the dilema i am facing is in by business/data tier which will be reaching out to the services to perform the tasks, how to i get IClientServices to work against the various services. One idea was to build a wrapper for each service.  The concrete implementation (call it ConcreteClientServices) of  IClientServices can then use composition and delegation to interact with the various services (the wrappers would be members ConcreteClientServices).  The issue here though is that if we move from one 3rd part service,  we obviously would have to create a new wrapper for this new service...that's fine.  However, what is troubling is having to modify ConcreteClientServices each time we change to a new service provider, since i am using delegation within the concrete implementation. With this method, i still have a dependency on 3rd party services sort of...it's not a clean separation. What is the best way to solve this problem? 

Also, how do you handle a situation where a single set of related business functions require interaction with two or more different 3rd party services?  Would it be best to build one adapter that uses IClientServices, and through composition and delegation, does the dirty work of figuring out which methods should be mapped to the different services (rather than creating separate adapter for each service as described in my above paragraph).  Is the pattern here
considered Adapter or Provider? 

thanks,
Mike