Separating Serviced Components from Data Access Components

In Christian Nagel’s book "Enterprise Services with the .NET Framework", he talks about separating serviced components from components that perform data access. This way the serviced components are really just wrappers that call other components that perform the real work of interacting with the database. The data access components don't contain any Enterprise Services related attributes.

He uses the following simple example to illustrate this point:

Serviced Component A --> Data Access Component B --> Database.

I am wondering if anybody has experience with complex scenarios like this:

Serviced Component A --> Data Access Component B --> Data Access Component C --> Data Access Component D --> Database

In this case, Data Access Component B calls Data Access Component C, which in turn calls Data Access Component D, all three of which perform data access. Only Component A is a serviced component.

I ran some tests that show this scenario does work; if an exception is thrown all data access operations are rolled back.

Does anybody have experience with this kind of design

Are there are additional resources that explain how and why the transaction context can flow across multiple components that are not serviced components

What are the flaws in this approach

Thanks.

Ray.