Separating API Layers

I am writing a data access API that abstracts a big pile of XML documents and
allows for some business logic on top of them.  Search(), GetContent(), etc.

This API should ultimately be available in 3 ways:

1. A compiled DLL assembly that an application can reference.
2. Exposed as a COM+ Enterprise Service.
3. Available on the Internet as a Web Service that we host.

The base question to the architecture is this, “Are the differences in these
layers sufficient to provide implementations for each one, or will a single implementation
take care of all needs?”  The answer so far seems to be a qualified, “Do
them all separately.”

The base API layer can have the flexibility of providing rich object structure and
referenced objects such as Streams and such.  The COM+ layer should expose the
same functionality, but not non-persistent objects like Streams.  The Web Service
should probably go down to the lowest common denominator like strings and such, and
would reference the COM+ layer in our IDC to get its functionality.

Now, should these things reside in the same assembly?  It would make development
and deployment simpler, not to mention unit testing.  What about name spaces? 
Divide the functionality along the lines of name spaces?

• XmlApi.Direct
• XmlApi.Service
• XmlApi.WebService

Should the layers be totally separated via different assemblies that simply reference
each other and do the inheritance?

I am leaning toward a hybrid model which would have the base and COM+ APIs share an
assembly and distinguish from each other via name spaces.  If I do this,
though, there is a function in the Direct name space that will throw an error if referenced
via a COM+ implementation.  The Web Service layer seems to have a clear
enough delineation in functionality to deserve its own application.  There are
issues around web site development there, such as session and security that the other
APIs will not care about.

What has your experience been on rolling things like this?