> I think it's an excellent question around which to
> examine some architectural issues.
>
> Among the many questions to be answered are:
In a different order than posted...
> * Is the function well understood?
XML is easy, its just text with a bit of mark up, learning Wordstar at school
was harder. Where XML differs to 'other' formats is it is one standard that
a lot of people seem to be adopting/adopted, especially in the industry I
work in (Government, banks etc.). Previously every system had a raft of
propriety interfaces and propriety formats, now they are all starting to use
XML
> The first question, of course, is whether or not a piece of functionality
> is appropriate to embed in the server.
I see two peices of funtionality
- Getting XML in and out of the DB
- Using XML within the DB (SP's, triggers etc.)
I would argue that the first one could and should be done by the client app
or via UDF's as others have suggested. The second is the area that
'embedding' could be the way forward
> * Is the function sufficiently general?
XML is nothing if not general.
> Does it cross applications,
> segments of the industry, and differing application topologies?
Yes, and increasing
> * Is the function well understood?
Yes and no. I think XML is quite easily understood, as well as some of its
associated technologys, but how, and in what way, to use it, is not,
especially in a DB situation
> Is extensibility expected?
> Required?
Yes and Yes.
> * Is there a clear performance benefit to moving the function
> into the server?
Depends on what you are using it for, but in a lot of cases, the answer is
yes.
> Is network traffic decreased in round trips and bytes
> transfered?
As above.
> Can the cost of server resources required to support the
> function sufficiently offset in gains in communication efficiency?
Hardware is cheap, unfortunatly "buying a another server" is too often
cheaper and quicker than spending more than a few days improving the
performance of code.
> * Is there a clear security benefit for moving the function into the
> server? Conversely, is there a security liability in doing so?
Depends on what you are doing, how it is done and how you get the function to
the server.
> * What additional information/context must be maintained in the server
> to support the function?
Very little, IMO
> * Does centralizing the function into the server significantly reduce
> application complexity?
Again, depends on how its done, and what you do with it. If done right, the
function can be optional and/or ignored by those than don't want it, or need
it. If done wrong, it could be come a burden for everyone.