Muchas gracias Aitor.
The problem is that our application is being developed in C/C++ (not Java).
At the end, any solution will be some kind of translator between A and B (it
does not matter whether it is Java, C or XSLT!), but the point is how to do
it in the very best way (I appreciate your experience with serialization).
Saludos,
Angel
-----Original Message-----
From: Aitor San Juan [mailto:asanjuan(_at_)bolsabilbao(_dot_)es]
Sent: 21 June 2005 16:04
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: RE: [xsl] Hiding XML to an application (serialization?)
Hi Angel,
Some time ago I used object serialization and came up with the fact
that having serialized a Java object then it was impossible to
read it back
again as a Java object after having simply recompiled the class
that represents
tha Java object. You might consider developping another component C to
act as a "translator" between the needs of A and B.
Regards.
-----Mensaje original-----
De: James Fuller [mailto:jim(_dot_)fuller(_at_)ruminate(_dot_)co(_dot_)uk]
Enviado el: martes, 21 de junio de 2005 15:48
Para: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Asunto: Re: [xsl] Hiding XML to an application (serialization?)
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>
--~--
--~------------------------------------------------------------------
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>
--~--
______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
puede contener informacion clasificada por su emisor como confidencial
en el marco de su Sistema de Gestion de Seguridad de la
Informacion siendo para uso exclusivo del destinatario, quedando
prohibida su divulgacion copia o distribucion a terceros sin la
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje
erroneamente, se ruega lo notifique al remitente y proceda a su borrado.
Gracias por su colaboracion.
______________________
This message including any attachments may contain confidential
information, according to our Information Security Management System,
and intended solely for a specific individual to whom they are addressed.
Any unauthorised copy, disclosure or distribution of this message
is strictly forbidden. If you have received this transmission in error,
please notify the sender immediately and delete it.
______________________
--~------------------------------------------------------------------
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>
--~--