Let's try to reconsider this all.

From what I understand, the basic concept is that application components are turned into services, which may be reused by other applications if needed, or may be separated out onto other servers, etc. Also of course there are third-party services that can be used.

Components is already about reuse. Services is a further and higher level step, where you turn a component into a self-standing application (a service) to be accessed from some client application. To get the picture: To use components in your project, you have to get the dll and add a reference to your project. All code, including those components, gets built into a single application, your application. To use services - say implemented as web services - you just get a web reference and access the wrapping proxy classes. In this case there's anything you are building apart from your specific logic. The service you access is a distinct and separate application.

With services you components become external self-standing applications. Here you can swap a node with another, provided they expose the same interface, and here not only you can cross the boundary of machines, but also that of organizations...

So, components is about modularization, and services is about making those modules self standing applications.

I don't think the business services should directly contact the database, since that'd be cutting out the data layer. However, I still think they should be the ones to know about the data they hold, and be aware of the structure of it. They should not know about which type of data storage is being used, or how to connect to it, but still shouldn't they be the ones to specify the structure of that data?

I think "business services" is a bit misleading here. As already stated by [vivek], the point is a service needs a facade to expose to the external world. This facade must provide an "usable" interface to the client, and maybe handle related things, like authentication, validation, (requests) state management, and similar interface stuff. Then, behind the facade there's a self standing application, where you apply all the needed engineering practices, including layering and tiering when needed...

Also, I've read about service routers, so that the services aren't dependent on the location of other services. How would such a router be built? Would it be a service that was the intermediary of all services, and knew about the location of all these services?

I think a "locator" rather than a "router". You just ask it for the current address of some service. It answers the address, and you can connect to the target service...

It appears that different people have different views on when SOA should be used. I think that it'd be good for separate components of an application, so that they can be deployed wherever necessary, and can be reused by other applications.

Others seem to think that services themselves are applications, and so SOA is the communication between several applications, and that the services have their own layers, similar to a regular application.

Are both of these correct?

You cannot deploy components anywhere (apart from the datastores), as they are logical bulding blocks of a single application. That's where services come into play. Anyway, provided we keep in mind components are building blocks for a service, not at the same "level", then i guess we can say the two positions above are both part of the overall picture.

I'm one for using business objects, instead of datasets. So how would something like this be handled? Unless business objects are just used internally within a service, but transformed into a DTO for the outgoing message. It'd accept a DTO as a request, also, and I guess transfer it into the appropriate business object(s).

This is irrelevant to services. Even if you are for business objects, services just exchange "data", so making objects to/from data in just up to your logic. Services exchange messages. Semantics is not in the message, it's in the applications logic.

Quoting Mr Lhotka: "In my business objects books and framework I talk about moving actual business objects across the wire using remoting. Of course the reality here is that only the data moves – but the code must exist on both ends."

So, are you saying that services should not be dependent upon any other services? However, could services still make up the components of a single application? I mean they wouldn't be a tier of the application, but they would provide features that the application required?

SOA as an abstract architectural concept might be applied at any level imho, including the single application. Be worn anyway that there are many ways to implement a service in concrete, from "i've written it so that i might make a real service of it at any time", to separate web services. I'd say components are degree zero for services. So design your high-level components architecture, then when comes time to allocation and design, just don't overengineer... 

-LV