Depending on what you call a web service.

Before WSDL and REST, there was still HTTP, so basically everything you can do now could be done before as well.

There was a lack of uniformity (which is why WSDL and REST were created in the first place), but it provided the same level of data confidentiality and security you are talking about.

You can actually avoid using HTTP as well: you can draft your own protocol, and use a custom server and custom clients which would open a socket to this server and get the data they need (or post the data). Here, you lose all the standardization benefit of HTTP, but once again, you don’t give access to the database to the clients.

Ah, back when we had sticks and stones.

Before the Internet, we had something called “client/server” architecture and Local Area Networks. If you weren’t trying to establish a connection with a server several miles away, these networks worked perfectly fine to accomplish most anything. You could even establish drive letters and use connections to file servers like a remote hard drive, if you wanted to. If you were several miles away, you could use a Wide Area Network to do essentially the same thing, albeit at a slower speed and at greater expense.

The cheap way to talk remotely was to pass information across telephone lines using devices called modems, and if you wanted to rig up something where two computers talked to each other through computer applications, you did it the same way you do it today: by establishing a communications protocol. There’s nothing magical at all about that; both sides just have to agree on what all the bytes mean.

From the very early stages of the Internet, there were ways for machines to communicate across it. Web Services are just the latest flavor of the week.

Just to clear up some concepts first…

I believe data access through a webservice provides security – I don’t need to pass in the db server user name and password etc.

I think you are conflating the concepts of (1) Transport Layer Security (TLS) and (2) access controls in the above statement… Whether a user name and password needs to be supplied or not is unrelated to whether a web service is provided through (1) an encrypted channel and (2) authentication (e.g. an API key).

An extremely poorly written web service may still require passwords to be sent in plaintext over HTTP. A poorly written one may do that over HTTPS (secure, but once broken, e.g. through a man-in-the-middle attack, open to abuse). A better-written web service should handle database connectivity internally based on other inputs, e.g. session IDs, after authentication and entitlement controls are validated.

Back to the main point, @marcus’s comment on your question is essentially it. Security aspects are dealt with no differently from “modern” technologies, and that covers implementation questions such as:

• Whether your communications protocol (borrowing a little bit from @RobertHarvey’s answer) supports the transmission of encrypted data.
• The message payload structure that is relayed between the server and client.
  • Does the client simply tell the server to persist this user’s residential address, or to connect to a database at IP X.X.X.X with a user name and password, and then run the query INSERT INTO user_address ...?
• How the server manages its database connectivity (which really is isolated from the client, see first paragraph).

For more information:

• Web Service Security Cheat Sheet (from OWASP)
• Common Object Request Broker Architecture
• Remote Procedure Call