Re: [Quantlib-dev] QuantLib/SOAP: a SOAP interface to QuantLib

[Toyin A. <toy...@ho...>]

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/