QuantLib/SOAP: a SOAP interface to QuantLib

[Anwar Ludin]

Hi all,

I would like to develop a SOAP "front-end" to QuantLib. I don t think
anyone has started this yet. Would there be any interest in this?

The idea would be to expose QuantLib as a standalone service/server
that could be leveraged through SOAP calls by other systems.

Cheers,
Anwar.

-------------------------------------------------------------------------
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

[eric ehlers]

Hi Anwar,

> I would like to develop a SOAP "front-end" to QuantLib. I don t think
> anyone has started this yet. Would there be any interest in this?

Yes!  I'm just now looking at this exact same idea.

> The idea would be to expose QuantLib as a standalone service/server
> that could be leveraged through SOAP calls by other systems.

How would you see the link from SOAP to QuantLib, i.e. how would you
propose to deserialize an XML stream into an instance of a QuantLib
object?

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

[Toyin Akin]

Hi Anwar,

You have to be careful about how you do this because there are some elements
within quantLib that are based on static structures/objects and thus under a
client/server framework, this would break down (ie, Currency class, Calendar
classes with the inclusion/exclusion of user defined holidays etc... ).

Also, you have to somehow be able to serialize Quantlib objects to a XML
stream. As you know, the QuantLib object model is vast, and unless you want
to expose only a small part of the framework as a web service, this will
take some time. You could, I guess, start off from the QuantLibXL framework
instead.

Our current v2.0.6 (CapeTools Quantools) libraries are very similar to
quantLib's wrapper frameworks (java and .NET) in that SWIG is used to
generate the wrappings. The problem with these wrappers is that the
underlying financial data is STILL stored within the c++ layer and thus the
.NET/java objects cannot be serialized.

Within our v2.0.6 library, when you create an object, you are returned a
string key which is a pointer to memory (very similar to QuantLibXL).

Well this is crapp for client/server, web services, remoting or GRID
computing environments.

The core library needs to be stateless.

What if you want to view the details of one of the parameters passed to the
created object?
What if you want to change one of the parameters passed to an object?

Any type of distributed system requires the objects to be serializable
(unless you are using .NET Remoting where you aer passing around a proxy).

Having access to a string key pointer doesn't really help.

In fact QuantLib's C#/Java/Phython etc... wrappers suffer from the same
problem in that once you create an object, you cannot easily set/get the
properties/parameters passed to the constructor unless this functionality
was exposed at the c++ level. The data is also tied to the underlying c++
library and thus you cannot serialize the objects.

If you try to use Visual Studio's inteliisense or new debugging features,
you would be at loss as to where the objects that were passed to the
constructors are stored. You cannot view them directly from .NET/java, you
would have to debug at the c++ level.

Systems such as FinancialCAD and MBRM do not have this problem because they
do not use objects at all (at the client level). Basically to build a
yiledcurve, you pass in very complex structures to a single function and out
pops out data. The library remains stateless. Not really elegant but it
works.

Within our new v2.0.7 library, we have devised a new c++ core (with the
exact API of our original v2.0.6 stateful core library) in which the new
core library is stateless. Stateless and also multi-threaded. In a nutshell,
all functions which creates objects internally within the library can
serialize their state to XML.

We did think about FpML, but from experience, (I worked with guys who were
part of the FpML commitee and worked for swapswire too) the architecture is
over the top for what we needed.

We have implemented a FpML library (c++, .NET and java), but we have other
plans for it.

On top of this new c++ stateless core library, we also have two new
libraries for each of the platforms (.NET, c++ and java).

An Object library and a Query Library.

>From a java EJB point of view, you can look at the object library as a
collection of Enitity Beans and the Query library as a collection of
Stateless Session Beans.

The first library (Objects Library) contains class definitions of all the
objects that can be created
(currently 800+). For users from an Excel (QuantLibXL) point of view, these
classes are basically wrappers around the functions that create objects
internally and return string-keys.

This library has no dependency on the underlying c++ core library and really
is a way that users can construct financial objects using more traditional
OOP methods (rather than dealing with string keys that are pointers to
objects in memory).

Each class contains a constructor, properties that can be set/get by the
users and the class can serialize itself to a stream (even c++ via boost).
If the user constructs an object and then changes a parameter via a set
method afterwards , the set() method will kick off a changed event (c++,
.NET and java). Thus you can write handlers to catch these events.

The Objects Library is also a perfect candidate to distribute to client
machines when the architecture is used within a client/server framework
(more on this below).

The second library (Query library) is the calculation library. These contain
singleton classes that have
functions that simply execute financial functions. This library depends on
the object library described above and the new stateless c++ core library.

The Query library takes objects rather than string keys as parameters, the
objects are then converted to XML and passed to the stateless core c++ layer
for execution. The Query library does not create objects directly. Only
executes functions against objects passed to it.

As a result of this, we have two more libraries built on top on the new .NET
infrastruture.

A .NET remoting library. Thus you can build a client/server solution using
any combination of TCP/HTTP and SOAP/BINARY. We recommend though, that you
use a message queue with this also.

A .NET Web Services library.

For both of the new .NET libraries, all 2100+ functions are exposed for
client/server, web services usage.

Again, the key point in enabling all this is in making the underlying core
c++ library stateless and to ensure that any objects passed around within a
remoting or web services solution are serializable.

We are in the last phases of testing. Should be released in a few weeks.

The new infrastructure can also be used within a more traditional rich
client application setting where the user prefers to play with objects that
can be serialized. Also, using Visual Studio's intellisense/debugging
feature against an object is not the same as against a string-key that
points to memory (or Swig's wrapper objects).

Next steps after this release are,

1) Serialize the objects to a relational database (java, .NET via
Hibernate/NHibernate).

2) Web services for java

3) A new .NET Windows Communications Framework layer for .NET 3.0
(microsoft's new remoting/web services layer).

4) A new .NET Windows Presentation Framework layer for .NET 3.0 (microsoft's
new form based UI architecture).

Bascially, we want to create some windows custom controls that will ease UI
development.

Best Regards,
CapeTools QuantTools,
www.QuantTools.com
Toyin Akin.

_________________________________________________________________
The next generation of Hotmail is here! http://www.newhotmail.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

[eric ehlers]

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

[Toyin Akin]

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