Menu

#73 Reduce compile dependencies for services (SOAP header)

open
nobody
None
5
2011-10-28
2011-10-28
po79
No

If you have multiple services that should be chained (according section 7.2.8 in gSOAPs documentation) it would be nice, to compile them independently. As far as I discovered the SOAP header processing makes it a bit difficult since you have to specify the header in one place and generate the common code for all services at last. In the documentation it is metioned multiple times with the env.h file.

Two different things have influence on the dependencies:
1. the SOAP_ENV__Header structure and
2. the namespace mapping table.

The first one is no problem, if you do not need acces to any header fields in the service implementation. In case of using the wsaapi it is a bit tricky since the wsaapi.h includes the SOAP_ENV__Header via the soapH.h inclusing. Two different solutions exist for this special case: 1. avoid including wsaapi.h in your service and declare the wsaapi function yourself in your code or 2. move the soapH.h include from the wsaapi.h file to the wsaapi.c file. In the latter case you have to include stdsoap2.h in the wsaapi.h file instead. As far as I discovered, some forward declations are necessary such as struct wsa__FaultSubcodeValues.

A general solution to acces the SOAP_ENV__Header (independed of the member position) is to generate setter and getter functions for all SOAP_ENV__Header members. Then a service can use the provided function and does not rely on the SOAP_ENV__Header structure itself.

The namespace mapping table is much more complicated. It is necessary to have the namespaces of all SOAP_ENV__Header members in all service namespace tables. This is because the generated code (-j) overwrites the namespace mapping table in the dispatch() function. Also without that overwrite, it is necessary to merge the service namespace table with the header namespace table. This is not easy. Another problem is, that the code generation with the proposed call "soapcpp2 -penv env.h" does not generate a .nsmap file.

Conclusion:
- Generate for all member in SOAP_ENV__Header setter and getter functions
- Generate for all (known) member of a service a forward declaration of that setter and getter function in their code generation.
- Generate a .nsmap file for "soapcpp2 -penv env.h" that can be used in the global chaining/dispatching function for parsing the soap header.
- Add a function to merge namespace mapping tables (so that the header namespacetable can be merged with the service specific namespace tables). Using one global namespace mapping table has the disadvantage of embedding all known namespaces to outgoing messages (this may be another enhancement: only serialize used namespaces in outgoing messages).

Discussion


Log in to post a comment.