Questions on ObjectHandler and QuantLibAddin

[Penschke, Walter]

Hi,

with high interest I followed the announcement of ObjectHandler and
QuantLibAddin.

Got a couple of questions:

- I am not sure what Widget/ObjectWidget is supposed to do. Is it an example
for the usage of ObjectHandler?
Is it related anyhow to graphical representation (widget = window + object)?

- I don't quite understand the files interface.hpp/interface.cpp. Are they
supposed to define a general interface?
If so, why do they depend on ObjectWidget?

- Other than the current development build in CVS, I could not yet find a
released version of QuantLibAddin. Am I right?

- I am currently thinking about a (clever) way of remotely accessing QL
functionality (via SOAP). In the documentation/mailing lists
of ObjectHandler I read that this is also something you want to address in
the future and that you want to establish an XML-based
serialisation in order to achieve this (FpML). The problem I see is that for
remote access, a client-side proxy-logic is required for each QL class.
I assume that you want to achieve this client logic by various sub-classes
of Objects. Is that correct? If so, this would result in completely
"shadowing" QL classes with derivations of class Object. Am I right? If so,
isn't that a pretty cumbersome way? I actually don't know
any better way myself :(



wpe

[eric ehlers]

Hi Walter

Many thanks for your message..

> - I am not sure what Widget/ObjectWidget is supposed to do. Is it an example
> for the usage of ObjectHandler?

Yes, it's intended as a standalone (independent of QuantLibAddin)
example for the usage of ObjectHandler.

> Is it related anyhow to graphical representation (widget = window + object)?

Not at all, and Widget was a poor choice of name for the example
class, I'll change this to Foo.

> - I don't quite understand the files interface.hpp/interface.cpp. Are they
> supposed to define a general interface?

Yes.  In fact a client could use ObjectHandler in a completely
object-oriented way, in which case there would be no need for an
interface layer.  But the Widget example mirrors QuantLibAddin's use
of ObjectHandler, i.e. linking an object-oriented environment
(QuantLib) to a procedural one (Excel), so the interface layer is
required in order to wrap class constructors/methods into functions.

> If so, why do they depend on ObjectWidget?

Well, in interface.cpp, objects of class ObjectWidget are constructed,
so there must be a dependency on ObjectWidget?

However looking at the code now I notice that the statement

    #include <objectwidget.hpp>

could be transferred from interface.hpp to interface.cpp and I will
make this change.

I'm not sure I've understood your question, please get back to me if not.

> - Other than the current development build in CVS, I could not yet find a
> released version of QuantLibAddin. Am I right?

Yes, that's right.  The first release will be in the next couple of weeks.

> - I am currently thinking about a (clever) way of remotely accessing QL
> functionality (via SOAP). In the documentation/mailing lists
> of ObjectHandler I read that this is also something you want to address in
> the future and that you want to establish an XML-based
> serialisation in order to achieve this (FpML). The problem I see is that for
> remote access, a client-side proxy-logic is required for each QL class.
> I assume that you want to achieve this client logic by various sub-classes
> of Objects. Is that correct? If so, this would result in completely
> "shadowing" QL classes with derivations of class Object. Am I right? If so,
> isn't that a pretty cumbersome way? I actually don't know
> any better way myself :(

It's very much my intention to anticipate distributed computing in the
design of ObjectHandler/QuantLibAddin.

I've been assuming that it will be necessary to install QL both on the
client and on each node of the grid.  Consider the case where you want
to price a QL object which is very resource intensive, or to price a
long list of simple objects.  The idea is that you construct the
object(s) on the client, transmit them to the grid to be priced, and
receive the results back to the client for display.  So QL is
installed on both client and grid but the hard work is done remotely.

Yes, the design dictates that for every QL object to be stored in
ObjectHandler, the relevant QL class must be wrapped in a class
descended from Object.

I considered a lot of different possibilities before settling on this
approach, and once you get into the details the chosen approach seems
the most elegant.  However it's entirely possible that I missed
something and if a superior design is possible then we'll use it.
You'd be most welcome to look at it in more detail and come back with
more specific comments, that would be much appreciated.  I'd also be
very interested to hear in more detail about your ideas for
incorporating SOAP.

Regards
Eric