Angel Gavin wrote:
Hi,
I have an application that consists of two components, say A and B.
Component A is a kind of monitoring and control system. It reads application
configuration files (in XML; customer requirement), keeps these files
updated (e.g., updating values on user request) and call component B with
(relevant) configuration parameters. The point is that we want to keep
component A as much independent as possible from the XML "vocabulary" used
in configuration files. In doing so, changes in file definition (e.g., new
parameters) will not (ideally) affect component A. Component A is going to
be developed by a third party, and the idea behind this is that we do not
want to request a change in A in case we discover we have to add, say, a new
configuration parameter.
parameterisation is always a good approach irregardless of data format
or how it is manipulated.
Lessons learnt in the past show that changing A is (irremediably) more
frequent than expected. I think we can manage configuration files quite well
by defining a set of XSLT scripts to do the dirty work (we would assume this
activity), and then component A would only have to know which is the script
to be executed, its input and input/output XML files. Perhaps
this solution is quite twisted, but it is supposed to work, isn't it? Any
hint will be much appreciated.
u do not have to use xslt if u just want to marshall simple
configuration data into an application, depending upon the programming
environment there are many tools to 'slurp' up an xml file and
objectify/arrayfy into internal data representation.
u could use XSLT to generate the final xml configuration files quite
easily though
Concerning the second part of the problem (calling B with relevant
configuration data), the good news are that we develop this component (and
its interfaces) but I am afraid that:
- B cannot read data from files
dont think of XML as a file format....it can live in a database, inside
most programming environments....by orientating your architecture around
the concept of files you maybe limiting yourself for no reason.
- My colleagues in charge of the "B thing" do not want to receive data in
XML. For sure there is a good reason for that (dunno!), but at the end the
problem is the same. I feel a bit stupid playing around with this, but the
point is that we want A to be independent of XML file structure, passing
data to B in a "non-XML fashion" (the XSLT trick above will not work).
like i said there are plenty of ways of marshalling data back and forth
from xml to whatever
I've been reading something about serialization. I do not know if this will
be of help or not (far from being an expert on this; I have never used this
stuff in my life). Any ideas?
serialisation is just the marshalling of data from one format to
another, lets use an example with Objects in the OO sense....lets say your
program creates a bunch of objects which u want to persist after the
program stops executing saving some sort of state information...one
method of doing this is to serialise the object to some out of memory
format (lets say binary or perhaps xml).
I would start (as with any application) designing the configuration data
into the simplest possible xml format, then take whatever platform
specific tool to slurp up xml and turn it into a string|array|object
(castor is a good java example...xml beans etc).
good luck, Jim Fuller
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--