Posted by
Toyin Akin on
Jun 12, 2007; 6:45pm
URL: http://quantlib.414.s1.nabble.com/QuantLib-SOAP-a-SOAP-interface-to-QuantLib-tp9494p9498.html
Hi Eric,
Thanks for the response!!
Your ValueObject approach is exactly what we have done. However, for both
the stateless and statefull approaches, the API for the developer is exactly
the same. Thus you program against only one set of interfaces and later on
decide on whether you want to use the stateless server (for client/server
work) or the more traditional stateful library (probably for local (fat)
application development). You just link to the right library. Currently we
have over 600 valueObjects coded. Each valueObject corressponds to a
function within our low-level library that creates an object in memory. The
rest of our 1500 query functions are split across 120 singleton classes.
For the statefull library, we have packaged up both the valueObjects and the
calculation classes within the same library (java, c++ and .NET).
For the stateless library, we have packaged the valueObjects within a single
library and the calculation classes within another. With this split, the
valueObjects can be provided to the client to develop against. The
valueObjects library will have no depenencies on the server/calculation
libraries and as such can be deployed to client linux/macs/window boxes to
be developed against (java/.NET at the moment).
Our ValueObjects are not simply dumb data objects.
They can notify the user when one of the data inputs have changed (ie, a
tick within one of the points within the yieldcurve) via an event. You can
also modify the contents of any of the input parameters directly without
recreating the entire valueObject.
When used in client/server mode, each valueObject (in which the majority
will have links to other dependant valueObjects (ie - YieldCurve
valueObjects will hold references to Index valueObjects, Calendar
valueObjects etc... )) know how to prepare and seralize the XML stream
needed to be passed to the c++ layer.
When used in fat application mode, valueObjects do not construct XML
packets. The data is passed directly to the c++ library (with a little help
via SWIG for java and .NET).
The valueObjects can also be saved to file as either binary or XML.
In a nutshell, our new API layer now returns ValueObjects rather than string
keys that are pointers to memory locations. The valueObjcets are the new
reference data types, but this time, you can directly query the valueObjects
for it's state (parameter inputs).
The user would build their financial objects via a combination of
valueObjects. Once this is done, the objects are then saved to the required
stream (c++, java or .NET depending on the language in use and once this
stream hits the server, the objects are packaged up into XML packages and
then passed to the c++ library for pricing. The c++ library would simply
create the needed c++ objects and then price. Thus the objects would remain
in memory during the pricing request. The library must also be
multi-threaded in order to cater for other users pricing at the same time.
Once the pricing is done, the memory is wiped for the current user and the
result returned.
For the .NET libraries, we have embedded (server library and fat application
library) 17 categories of windows performance counters, thus you can monitor
the performance of the the library (via the performance monitor) in order to
help you make decisions on how to better partition/plan your server
architecture under regular/heavy load.
This framework is currently being testing and we have produced over 1500
test cases for each of the c++, java and .NET (C#) libraries (our current
release only has test cases for the low level .NET library). The source code
for the test cases will be released as part of the developer libraries.
For this release, the .NET layer will have .NET Remoting and .NET web
services.
We are currently looking at java web services and java remoting as well as
Microsoft's new WCF framework.
We did look at using gSOAP for our c++ layer, but the gSOAP framework could
not hande the number of functions we were exposing. Anyway, web services
should not really expose chatty interfaces!!
Our ultimate goal is to produce a working environment using some of the
excellent public domain GRID frameworks such as the java GLOBUS and .NET
Alchemi.NET frameworks.
Another thing we are looking at is the serialsation of our valueObjects to a
database via NHibernate/Hibernate.
However doing all this from c++ is bloody hard. Java and .NET have great
support (especially free) for web services, remoting, GRID computing and
object database serialisation.
The remoting part is of special interest to us because we would also like to
create some nice user interfaces using Adobe Flex/Flash. Adobe Flex
(Actionscript 3.0) can comminicate with .NET via remoting and thus this will
allow us to write some user interface demos that can run on Windows/Linux
and Macs.
There is WPF also but there's a lot to nerd up on and I'm not sure how great
the support for linux with be via WPF/E
Best Regards,
Toyin Akin,
www.QuantTools.com
>From: "eric ehlers" <
[hidden email]>
>To: "Toyin Akin" <
[hidden email]>
>CC:
[hidden email]
>Subject: Re: [Quantlib-dev] QuantLib/SOAP: a SOAP interface to QuantLib
>Date: Tue, 12 Jun 2007 18:05:26 +0200
>
>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_________________________________________________________________
Play your part in making history - Email Britain!
http://www.emailbritain.co.uk/-------------------------------------------------------------------------
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