SOAP, c++ and an embedded interpreter

Since I don't have a blog, I periodically litter this forum with some unwise words. . .prepare for some grandiose, unsupported statements.

 

 

Problem: soap calls in c++

 

 

My initial strategy was to use one of the commonly available native toolkits--easysoap, gsoap or axis++:

 

 

Pros: *thinking, stretching, thinking* Uhh, since they're natively compiled code, they should be fast, right? Overall, it's difficult to state what I like about them.

 

 

Cons: in my experience, their downsides aren't substantially different from those attributed to Corba. Succinctly, they require too heavyweight a methodology (particularly for someone writing test software). Specifically, wsdl --> generated c/c++ --> compile to object files --> link requires too much environmental scaffolding. Furthermore, individual toolkits have some unhealthy foibles. Gsoap's well-intentioned and godawful namespace-mangling guarantees you'll resort to obscene cpp-macrology as a prophylaxis against carpal tunnel. Axis++? Well, I consider anything that doesn't compile out of the box unusable (NB: while it's possible it *will* compile now, I don't remember seeing anything that made me think it'd be significantly better than gsoap).

 

Overall, beyond honing my skill in writing Makefiles, I was unhappy with the available choices.

 

 

I then had another idea--embed an interpreter with access to SOAP libraries into my c++ code, build classes to access the interpreter, and propagate the interpreter's exceptions into c++ exceptions.

 

 

Pros: I use the same toolkit for scripting and compiled programs. Most importantly, it's far more flexible than compiling everything:

 

 

 
      INTERPRETER interpreter; 
      interpreter(SCRIPTFILE("setup")); 
      doItIsDifficultToExtendTheInterpreterWithTemplatedTests(interpreter); 
      interpreter(SCRIPTFILE("teardown")); 
 

 

 

Modifications to the setup and teardown scripts can be done wantonly without a recompile. This is particularly useful in a development cycle where a particular method might be unstable and you might want to bandaid some error-handling around it. NB: while conceptually similar to popen(file_to_execute), code is evaluated in your current process space which gives you dramatically better error-handling capability while removing the need for inter-process communication. Finally, with functors and templates, I was surprised at how easily you can create small custom objects that provide you the beginnings of a SOAP-ish domain-specific language (exception handling is omitted for clarity):

 

 

 
    argmap args; 
    SYSTEM systemObj(address,uid,passwd); 
    q("SystemInfo","get_version",args);  // args is empty at this point 
  
    args["service_action"]  = "'SERVICE_ACTION_START'"; 
    InterpreterResult* rp; 
    q("Services","get_list",args,&rp); 
 

 

 

Cons: many people find embedding difficult and inelegant (AKA it fails their "code smell" test). Likewise, it requires an intimate understanding of the "HOWTO" for embedding a particular interpreter (being fair, I'd argue learning a compile SOAP toolkit takes only slightly less time). Finally, in my experience, while this model is almost painless for declarative setups and teardowns, it's unclear how well it works when you need to exchange massive amounts of data with the interpreter.