How my data layer abstraction got messed up

So I made some mistakes in the design. The design is broken into 6 parts: Pages, Order Information, Message Objects, a Data Layer, and two conceptual sub layers of SQL and XML. Pages only really interact with the Message Objects which are fed to the DataLayer that spits up a responding Message.

All good so far, but how I encapsulated data in the message was bad. I originally envisioned the message as a light wrapper around an xml document. Most of the code is written this way and it often just rips the xml out of the message. But then I switch my session state mode to 'Server" instead of 'InProc'. So the difficultly was that I was saving search results in a non-serializable XmlDocument. When I looked at the code a DataTable was being transformed into an XmlDocument to make it a Message. Not horrible, but transforming it back and forth for serialization would be bad. So I basically just tacked the DataTable to the Message and one part grabs a DataTable out of the Message instead of getting an XmlDocument. This reduced data transformations and since DataTable are serializable it fixed this problem.

Course now the abstraction is fucked. So the questions are 'What exactly is inside an Mesage?' and 'How do Pages interact with Message? Do they know how the data is stored inside?' Now the best way to do this revolves around how you rebuild the back end. Of course, it doesn't need to have the back end working. And the whole Data Layer will most likely be replaced. Perhaps I should not worry about it until I rebuild the Data Layer to support a more modern back end.

I could make Message a self-contained object so that the Pages don't need to know whether a DataTable or XmlDocument is inside it, but the work to value ratio is pretty low on that. Why build some crap like that when you have DataTable and XmlDocument that do all sorts of crap for you.