Which design pattern best suits this need?

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). Some are action type services (i.e. create account or update
some info about a given user), and others are read only, retrieval of
data.

What i intend to do is to define the functions in an interface so
that the client code can be implemented against this interface; let's
call it IClientServices

Now the dilema i am facing is 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. 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

Re: Which design pattern best suits this need?

hmmm...not a very active group? or is there a better another group
that better suits architecting topics?