serialization layer for QuantLIbAddin objects

[Plamen Neykov]

Hi folks,

Eric and I have discussed a possible implementation of a serialization layer
for QLA objects. The first step would be to implement so called
"ValueObjects" generated out of the xml description of the constructor
functions (The assumption here is that the data set supplied to the
constructor is sufficient to describe the object). The generated
"ValueObject" will then provide functions for serialization - multiple
sierialization methods are possible. In addition some generic method for
accessing properties may be also implemented. E.g. the generated class might
look something like this:

class VSimpleSwap : public ValueObject {
public:
  long StartDate;
  long MaturityDate;
  // rest properties....

  void serialize(....) {
    //implements boost::serialize method
  }

  std::string toXML() const {
    // implement some xml based export
  }

  std::string getProperty(const std::string& name) const {
    if(name == "StartDate") return lexical_cast<std::string>(StartDate);
    else if(name == "MaturityDate")
       return lexical_cast<std::string>(MaturityDate);
        .........................
  }
 
  std::vector<std::string> getPropertyNames() const {
    std::vector<std::string> names;
    names.push_back("StartDate");
    names.push_back("MaturityDate");
    // rest properties ...
    return names;
  }
};

Based on those ValueObjects generic layers for persistence and remoting for
QLA objects can be developed. Also a generic XSLT processing layer might be
also developed to convert the simple xml stream into FpML or any other xml
dialect.


I'll be very happy about comments and suggestions.

cheers,
Plamen

[eric ehlers]

Hi All,

A couple of observations -

1) The existing ObjectHandler design attempted to anticipate
serialization, by providing the "property vector" and related
interface in the base Object class.  Effectively an object has two
states:

- "shallow" - the values in the property vector, and a generic
interface allowing these values to be interrogated with no knowledge
of the Object's implementation
- "deep" - the instantiation of the underlying QuantLib object

ValueObject supercedes and improves upon this idea by decoupling the
shallow state into a separate class which may be instantiated
independently of the QuantLib object.

2) The subject of serialization came up previously in this mailing
list (see the links below).  Nando and Luigi sketched out a design
using TermSheets to FpML-enable QuantLib  (independently of
ObjectHandler/QuantLibAddin).  The ValueObjects proposal is compatible
with the proposed design for TermSheets.

http://sourceforge.net/mailarchive/forum.php?thread_id=6507779&forum_id=4300
http://sourceforge.net/mailarchive/forum.php?thread_id=6539684&forum_id=4300
http://sourceforge.net/mailarchive/forum.php?thread_id=6540997&forum_id=4300
http://sourceforge.net/mailarchive/forum.php?thread_id=6543552&forum_id=4300
http://sourceforge.net/mailarchive/forum.php?thread_id=6700844&forum_id=4300

Regards,
Eric