Preserved Topic: Why an XML layer??

Hokay so for my work we are starting to look at new content management solutions. We are planning on moving from a straight apache web server to a full application server.

One of the things we've seen a lot is that many of the content solutions use some sort of XML/XSL layer between the database calls and the presentation.

The question we keep having is what are the benefits of having the xml/xsl layer? We're not questioning the ability to generate XML, that is fairly self evident however why do we want an additional transformation between the db calls, the cache and the presentation?

I was reading this article on Ace's Hardwares setup and if I understand it correctly they make one call to the db the first time a page is loaded and the story data is stored in cache memory, then that data is combined with some sort of templating and used to serve the page. Subsequent calls are then served from the cache memory instead of calling from the db.

The only thing I can think of is that large volume serving many different pages would prefer to store the data in an XML file instead of keeping it resident in memory.

Anyone got an opinion on this?





.:[ Never resist a perfect moment ]:.

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

Lemme rephrase.

I understand the advantages to having XML formatted data availible. No question there. The issue being the advantages of having it as a layer in the content creation and serving process.

ie

I have this

request from db -> store data in memory cache (only needs to make one request to the db this way)-> apply presentation logic to data -> serve to client (either HTML or XML switched in the presentation logic)

90% of my web requests are fine with that kind of structure. Yet many of these app servers have something like this:

request from db -> store data in memory cache -> create xml document -> parse XML doc -> apply presentation logic to parsed XML -> serve to client

I can't guarantee that the storing of data in memory is after the database request or after the XML parsing I'm still looking at these from a relatively high level.

Now since these are reffering to app servers Storing the data in memory (RAM) is fine why use the extra cycles to store as XML and parse that as opposed to just using the data already in memory. Since I already have a presentation layer, if I want to serve XML I can just apply a new set of presentation logic to the data already in memory.




.:[ Never resist a perfect moment ]:.

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

Interesting question and I suppose sometimes people add things like this for the sake of it.

However, if you did something like:

query db -> results parsed as XML document (cached) -> XSL/XSLT serves up different version (PDF, HTML, SVG, etc.) depending on user agent and/or output request.

So you reduce strain on your database and increase speed and flexibility whilst allowing for as many versions to be produced from the one set of data as your tools allow.

As far as I'm aware this is one of the reasons for Apache's XML modules:
http://xml.apache.org

Which allow you to export data as SVG (Batik), PDF, TXT, etc. (FOP) or you can create your own modules if you so require.

Or I might be stating the obvious or missing the point

___________________
Emps

FAQs: Emperor

hmm no for a standard say php or perl based solution that's a good way to do it. But app servers allow you to create stateful applications. Which means as opposed to script based apps which run each time a request is made, this application is persistant. In other words I can have a variable (or say a story 'object') that maintains it's value between different requests.

Check this out it explains it pretty well.

So in other words where in your example I can store the data in the form of an xml document, in this example I can just store the story data in memory (RAM) between various requests.

The more I look at this the more I'm convinced that the XML is used to save memory by creating a file I can parse with less overhead.



.:[ Never resist a perfect moment ]:.

There is one more thing that hasn't been mentioned yet.
That aspect is the caching of pages. Using the multilayered structure with middlestorage in XML gives you the opportunity to cache either in the database, in raw XML or in parsed XML for different media. I'd say that this kind of solution first and foremost offers flexibility for the developer to create a solution that fits the needs of the customer.

The pure database route is very good for some things, XML/XSLT is very good at other things, offering both is a way of getting the best of both ways.

Also don't forget that demand for complete XML support is rising very fast in corporations and governments nowadays.

For example, governments in most countries are now looking at ways of seamless integration between different departments and similar, this is where standards like XML/SOAP come into play, if you don't provide that support in your product as a vendor, you are out of the procurement-loop...

/Dan

{cell 260}
-{ a vibration is a movement that doesn't know which way to go }-

By forcing your pages to be generated from XML rather than directly through the database, you allow the database to be completely changed without affecting the public side. In fact, the whole backend could be scrapped or outsourced to another company. Where you would really see the most benefits is if the XML DTD is the best definition of the data you are working with. You may not know what all you will want to do with the data in the future, but if you have it well organized in XML, you will be able to change the front and back ends at will.

As for efficiency, i don't see any way that using XML can help at all. Parsing text will never approach a well-written DB performance-wise. Losing the XML layer will undoubtedly benefit performance. The downside is that your database, application, and output generator are then inextricably linked. Certainly a well-designed API could separate those sections so that they would be independently developed, but determining what your DATA needs are is far easier. The data is, in fact, the easiest thing to define; even the marketing people know what data the application is supposed to handle. Therefore you can jump in, define the XML DTD then happily build modules that attach to it.



-jiblet