Where is your web service located at when you try to hit it on
server2? If the webservice  you are trying to hit is not on the actual
server that is serving WSS you might run  into Code Access Security
issues between the servers. Also, you might want to make sure the
webservice is defined in an exluded path by going to central admin,
WSS, define manage paths, and excluding the path to the Web Service.
Impersonation can be good but for the web service to be able to access
certain ojbect model elements you will need to ensure that the web
service has the aforementioned CAS to it. If you bump up your
web.config to give full trust. If this fixes your issue then your
having a CAS problem.

The web service is on the WSS server. I have turned off anonymous
access and set identity impersonate=true. Do I need to impersonate a
user that has full WSS rights (or the user running  the app pool)?
When you say "make sure the webservice  is defined in an exluded
path," where is the option to exclude? I only see wildcard
inclusion and explicit inclusion. I tried change it to full trust
with no luck. I am getting an error: "The web application at
http://<ip address>/sites/siteA/ could not be found. Verify that you
have typed the URL correctly. If the URL should be serving existing
content, the system administrator may need to add a new request
mapping to the intended application.

Any idea what that error is? Google didn't find much.

all non-included paths are excluded in 2007/V3, there is not need to define an excluded path.

also check your alternate urls in central admin to verify the URL is indeed defined as a valid namespace. the error below sometimes points to an IIS change without the correlating default internal URL change. also, all app pool identities must be local admins on every server in the farm.

This does not mean that SharePoint and
non SharePoint pages can be mixed within any given folder. Only the root
and designated Managed Paths (SharePoint Virtual Directories represented
by meta data in the database) can contain Site Collections. Only true
IIS Virtual Directories can contain non-SharePoint content. While I
haven't tried it, I suspect that one could use the root for
non-SharePoint content as long as no Site Collection had been created in
it.