Posted by
Xiaowen Wang on
May 25, 2002; 9:43am
URL: http://quantlib.414.s1.nabble.com/plan-for-soap-extension-tp10090.html
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