Posted by
eric ehlers on
Jun 12, 2007; 5:05pm
URL: http://quantlib.414.s1.nabble.com/QuantLib-SOAP-a-SOAP-interface-to-QuantLib-tp9494p9497.html
Hello,
A few thoughts in response to the key points in Toyin's message.
Two approaches have been proposed for implementing serialization in QuantLib:
1) Fpml: Under this approach QuantLib Would be supplemented with a
library QuantLibFpML which would support the serialization to/from
FpML of those QuantLib classes which map to FpML representations. No
serialization support would be added directly to QuantLib. Details of
this idea can be found in the mailing list archives.
2) ValueObjects: This is a feature of ObjectHandler, supported by
QuantLibAddin/QuantLibXL, in which each object in the OH repository is
supplemented by a VO which captures the inputs to the object's
constructor. The VO can be serialized and later reused to
reconstitute the object to its original state. VOs are stateless, the
disadvantage of this is that the VO doesn't reflect changes to the
state of the corresponding object after construction, the advantage is
that it's simpler to implement serialization around VOs than a lower
level approach such as FpML. Following a design and initial prototype
provided by Plamen Neykov I'm in the process of implementing VO
serialization in the development environment for inclusion in the next
release.
Stateful/Stateless grid - Toyin I agree with you that a stateless grid
simplifies things considerably and in my experience this approach can
be implemented quickly with dramatic results.
I wouldn't entirely dismiss the idea of a stateful grid. Objects
could be persisted on the server and their state shared by multiple
clients. I concede that implementation would be considerably more
expensive.
VOs offer us a middle ground. Suppose you want to price a portfolio
of instruments. With a truly stateless grid, you have one big fat
function which accepts all of the inputs needed to price a single
swap, from setting the rates through to bootstrapping the yield curve
and pricing the instrument. This exercise must be repeated from
scratch for each instrument in the portfolio.
With VOs you could serialize the entire state of the client
environment and send this to the grid as a batch of objects.
Deserializing these would cause them to be stored in the OH
repository. It would only be necessary to set up the market
environment once and this could be reused to price all instruments.
The state of the grid would be discarded when the results are returned
to the client. A similar approach could be used for sensitivity or
monte carlo analyses.
I shouldn't have used the term "QuantLib Server" as that's an
exaggeration. I envision a process which runs on each node of the
grid, supporting the QLA/OH interface, the process receives a batch of
serialized VOs, loads them into the OH repository, prices the
instruments and returns a result. The process would be single
threaded and would lose its state after each call. If a batch of n PV
calculations is split across multiple nodes then each node would
initialize its own copy of the market data objects.
Regards,
Eric
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev