plan for soap extension

[Xiaowen Wang]

Hi everyone:
I've been thinking about the SOAP extension of
Quantlib. The following is my thoughts that I'd like
to discuss with you:

1) The target of QuantLib-SOAP is to provide
portafolio evaluation functionalities accessible via
standardized wire protocol(http,smtp etc). And to more
specific, it's a collection of stateless functions
remotely invocable(RPC instead of messenging style).

As put in some articles, there's so far no consensus
as to what the web service buzz really is. But one
thing seems to be sure is that it's not yet another
distributed object architecture like CORBA or RMI. As
a service provider, the simplest service that
QuantLib-SOAP extension can offer is a collection of
stateless functions, just like the stateless session
beans in the enterprise java bean(EJB) architecture.
And because QuantLib is mostly about portofolio
evaluation, stateless functions is OK for the initial
offering. As the extension becomes more mature,
stateful conversational functions (like stateful
session bean in EJB) can be added.

A note about the RPC .vs. messenging is necessary
here. I think RPC is sufficient for quantlib project
because I don't think there's a usage scenario that
involves more than 2 parties. It's a simple
communication of the request-response within bounded
time style. Asynchronous Messenging is the standard
communication style used in distributed computing
analysis because almost all those problems involve a
bunch of participants. And the most important, the
decision of RPC or Messenging is orthogonal to the
other parts of quantlib-soap extension.

2) QuantLib-SOAP requires a complete C++ binding for
FpML specification.

Just like in CORBA we need to translate IDL into stub
classes for subclassing, in SOAP extension we need to
translate WSDL into stub classes for subclassing. The
service interface description(WSDL) is simply a
function signature description(if we adopt RPC style),
the messy part is the XML encoding of those complex
data structures in the parameters and return values.
FpML specifies the XML encoding of these data
structures, and thus we need a FpML elements <-> C++
objects binding scheme.

This binding scheme will be realized in two code
layers:
a) FpML elements to weak typing C++ binding. This
layer should be generated using automatic code
generator, because the sheer volume of components in
FpML spec is large. And because FpML is specified
using DTD, which is weak typing(everything is bound to
string), the C++ objects generated from this layer are
weak typing.

b) A thin layer of C++ wrapper objects for the weak
typing C++ objects generated in a). This layer is
nothing but type checking and conversion. As a
reference note, the XML Java binding (JAXB) is
currently also in this stage. Strong type checking is
achieved through an extra type binding xml file.

One sidenote is that QuantLib-SOAP extension is be
different from the script language extensions like
Quantlib-Python etc. This is because SOAP uses wire
protocol to connect instructions in the distributed
address spaces, whereas SWIG connects instructions
within a single address space. The former requires
complete serialization/deserialization of complex data
structure whereas the latter can work around this by
resorting to the opaque object reference.

3) The extension needs some helper classes to
interface with the selected wire protocols to
participate in the RPC.

As in CORBA and IDL, the implementation stubs can be
automatically generated from WSDL. In implementing
these stubs, some helper classes are needed to take
care of the plumbing job.

In short, it's my opinion that the plan for
QuantLib-SOAP extension will be three steps:
1) Implement the automatic code generation for FpML
<-> C++ binding.
2) Select the collection of stateless portfolio
evaluation functions.
3) Implement the functions selected in 2). There're
many open source tools out there to help out in this
stage.

Stage 1 is essentially a lexical analysis and parsing
process. I think a lex file from DTD grammer is the
starting point.

Looking forward to your comments.

Cheers
Xiaowen

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

[Ferdinando M. Ametrano-2]

Hi Xiaowen

>I've been thinking about the SOAP extension of
>Quantlib. The following is my thoughts that I'd like
>to discuss with you:
Please consider to write a QuEP to be published on the web site and
announced on the quantlib-users list for general discussion. The material
you posted here could be a good draft.
I know there are at least a couple of quantlib-users subscribers involved
with FpML that could be interested in your project

>1) The target of QuantLib-SOAP is to provide
>portafolio evaluation functionalities accessible via
>standardized wire protocol(http,smtp etc).
While I do not feel qualified on the technical (protocol, stateless session
beans, etc.) side
I wonder if you have a list of functionalities you plan to provide. I would
say that even a limited set of functionalities would be ok to start working
on a proof of concept

>2) QuantLib-SOAP requires a complete C++ binding for
>FpML specification.
FpML specification support is in my opinion one of the most important
QuantLib goal.

>This binding scheme will be realized in two code
>layers:
>a) FpML elements to weak typing C++ binding. This
>layer should be generated using automatic code
>generator, because the sheer volume of components in
>FpML spec is large. And because FpML is specified
>using DTD, which is weak typing (everything is bound to
>string), the C++ objects generated from this layer are
>weak typing.
>
>b) A thin layer of C++ wrapper objects for the weak
>typing C++ objects generated in a). This layer is
>nothing but type checking and conversion. As a
>reference note, the XML Java binding (JAXB) is
>currently also in this stage. Strong type checking is
>achieved through an extra type binding xml file.

Mmmm ... I'm not sure I got this description. Sorry for being so naive, but
could you provide an example?
BTW FpML is moving to Schema instead of DTD

>3) The extension needs some helper classes to
>interface with the selected wire protocols to
>participate in the RPC.
Once again I would appreciate a concrete example

If/when you need a QuantLib-SOAP module, just let me know and I'll create it

ciao -- Nando