Not the first time...
From an email I got recently, lightly edited. Responses to follow.
Problem:
The data layer of application architecture must be flexible enough to adapt to
virtually any new data-driven functional requirement demanded by today’s
client..right...well to support such adaptability in client deployments, the
data model must allow almost arbitrary categorizations and groupings of data
within the system without hindering development speed, system response time,
ease of use and system simplicity.
Proposed Architecture: I am really started to
take a liking to Java/XSLT that is driven by XML...well here is my
thinking:
- Client requests can
easily be transformed into client-independent XML
structures
- EAI tools or APIs could
handle both receiving and transmitting events via
XML
- SQL result sets can possibly
be naturally modeled as XML
fragments
- The XML tree fragments
returned from the API and database queries may be used to generate dynamic
queries.
- Client side response
should first be represented as XML to capture the data structure. Of course this
XML could be converted to whatever format required by the
client
Benefits:
- Both data and events are naturally modeled in a similar structure:
XML
- A single tool, XSLT, is able
to transform and generate both data and
events
- Using a standard XML format
for both incoming client requests and outgoing response allow clean client
independence.
Weaknesses:
- No interactive debugging tools. However this could be mitigated by extensive
debug logging by the application
server.
- XSLT is a recursive
functional language and requires you to adapt a new methodology other than
object oriented.
- Abstraction
hurdles would not be enforced by the interpreter but possibly with superb coding
discipline.