Posted by
Penschke, Walter on
Feb 18, 2005; 6:35am
URL: http://quantlib.414.s1.nabble.com/ObjectHandler-and-QuantLibAddin-II-tp10742.html
Hi Eric,
here my thougts on your last posting:
- I am still not clear about interface.hpp/interface.cpp:
I can see that it is a procedural wrapper for ObjectHandler and understand
that it is required
for environments like Excel. What is a bit striking to me is that it is
tightly bound to ObjectWidget
which is one specific sub-class of Object. Am I right that for any other
subclass of Object - and if
I understood your idea correctly, there will be lots - again such a
procedural wrapper is required?
If so, could it be an alternative to incorporate the actual class we are
dealing with "somehow" in
the signature of interface? Having had a look at the current code of
interface, I was thinking if one
could for example add the name of the class and then use a factory to create
an instance of the
class in the (now general) MAKE method of interface. Wrt to the UPDATE
method I am not sure
if we need to know about the concrete derived class at all. Could it work to
use straight forward
polymorphism here? May be I missed something, but if that would work we
would be fine with
one single interface class. Haven't yet found time to actually try it.
- Here is what I have done so far with SOAP and what design issues I
encountered:
I am using gSoap (
http://gsoap2.sourceforge.net) and it seems to be ok. It
seems to be pretty fast
and works on both platforms which are relevant to me (Windows and Linux).
STL types are not
fully supported. It does work with lists but not with maps for example (at
least the version I am using,
which is only 2-3 month old.) The available documentation is pretty good and
big.
Up to now I did get working a small sample pricing server and a small Excel
based market data retrieval server.
I wrote an own little ExcelEngine for accessing Spreadsheets, which hides
all the nasty COM stuff away.
I am not too much into gSoap and therefore was using a procedural interface
approach (similar to your idea).
I.e. the communication between client and server is based on a set of
functions. Haven't yet checked if an
object based approach is supported and works.
My approach so far was to leave the client as dumb as possible. Within Excel
for example I don't need to
have QuantLib available. For my little sample stuff this is ok as I only did
have to provide a small VB-routine
which accesses the server via a thin client library.
At this stage I was thinking how to sensibly extend the service prototypes.
It seems to me that the principal
problem is the same as you are addressing with ObjectHandler/QuantLibAddin:
There is the need to wrap up
QuantLib functionality as a whole, via a set of functions.
Problem is that the number of thes functions can become pretty big. As I am
reluctant to wrap up all QL functionality
I was first thinking about reducing the granularity on the client side. The
question is: To what extend? One idea I have
in mind is to provide one big "master-method", which is fed with a variable
list of arguments. I this case I would need
a corresponding Dispatcher on the client side. Also, the load on the server
would be pretty high as it not only performs
pricing but also needs to create the objects from scratch for each request.
At this stage I came across your ObjectHandler/QuantLibAddin packages. The
idea of a local object store is nice as
it would reduce the load on the server. I also don't see a big problem with
having QL available on the client side as well.
Clearly you are going the other way of keeping the granularity on the client
side in sync with QL, which is natural when
QL also resides on the client.
The remaining problem of wrapping up the complete QL functionality is
however remaining.
For the SOAP-calls your idea with (XML-)serialisation seems to be the right
way. In contrast to Java this is, however,
not a neglectable task within C++ because in C++ no proper reflection
mechanism is available (Class.forName(...)).
Perhaps one could supply a big serialiser/deserialiser class. But this idea
also seems to be a bit clunky.
Alternatively there might be other SOAP implementations available, which
support automatic stub/skeleton-generation
from a "normal" C++ class. Perhaps one could create the required
communication code automatically???
Sorry that I have more questions than answers. I am also pretty much at the
beginning.
Please, let me know what you think about it.
wpe