Login  Register

Re: QuantLib/SOAP: a SOAP interface to QuantLib

Posted by Toyin Akin on Jun 01, 2007; 5:26pm
URL: http://quantlib.414.s1.nabble.com/QuantLib-SOAP-a-SOAP-interface-to-QuantLib-tp9494p9496.html


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