axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Susantha Kumara" <>
Subject Improving / re-factoring Axis C++
Date Wed, 21 Jul 2004 10:08:56 GMT
Hi all,
After the recent discussions with Aleksander Slominski we realized that
we had made following mistakes when we were designing Axis C++ (Actually
iterative designs). 
1. Supporting C on top of C++
2. Not using Exceptions for error handling. This made error handling
incomplete and complicated.
3. Excessive use of STL. 
So following are the improving/refactoring considerations of Axis C++. I
suggest we create a branch and continue this refactoring/improvements
etc so that the CVS HEAD is not affected. In the future when this branch
is very stable we may consider it to be merged with the HEAD (probably
for Axis C++ 2.0 ?).
C Support
It is realized that current way of supporting C stubs and services has
made the Axis C++ code too complicated. So we should refactor Axis C++
so that the engine is independent of C support specific code.
So we expect to do following regarding the C support. Assumption is that
a developer always has a C++ compiler 
(no need of a linker)
1. Inside Axis C++ only new/delete is used (no malloc and free). Its
usually not a problem to "delete" any memory allocated using malloc.
    But the other way round may lead to memory leaks. But what about
realloc when array deserialization ?. 
2. Complex types are created as structs but is always wrapped by a C++
class. Ex:-
            typedef struct {
                        int x;
                        int y;
        } Point; 
            Class PointWrapper : public ComplexType // ComplexType is an
interface with serialization/deserialization functions
            /* This PointWrapper will implement the
serialization/deserialization/other functions of ComplexType interface
3. Server side wrapper is C++ and the skeletons will be in C;
4. Client side stub is always C++ and a separate .cpp file is generated
that has wrapping functions with C linkage. 
5. Support for base types and extended types in WSDL (At the moment
every extended type copies the attributes of base type ).
Error handling
The performance gain we get by avoiding Exceptions is not worth the
effort we spend for non-Exception based design. So We can
decide to use Exception throughout the Axis C++ code. This will enable
us to handle the error situations more easily. But
we should take care to throw exceptions ONLY on an error situation (No
catch and continue).
1. Improve the existing exception model
2. Introduce new exception classes where necessary
3. Introduce exceptions to all places in the Axis Code and handle every
possible error.
4. Catch all exceptions by any C wrappers and return a meaningful error
code to C client applications.
XML Parser API
The existing parser API is not that good. We need to come up with an
improved API for,
1. Optimized for SPP. Probably Typed Pull parser API.
2. Better white space handling,
3. Sequential querying based.
4. That supports DOM building.
5. May introduce the namespaces registering (see spp implementation)
Then implement it by Expat/xerces and spp. The type conversion layer
should be between deserializer and 
parser(Need to discuss and design this). 
SOAP Pull parser (SPP) Implementation
The current txpp implementation should be added the namespace support
and the type conversion layer. This type conversion layer may
not be tightly coupled with rest of spp in order to use with xerces and
expat. Introduce namespace registering mechanism.
Transport Layers
The existing transport API should be changed for following,
1. Avoid the use of the callback function. Let the transport handle
buffers in its way.
2. The serializer should not concatenate the strings. Instead should
send to the transport directly.
3. All buffers passed to transport in above 2 may not be null
terminated. The size of the buffer/character should be passed.
4. Better timeout handling.
1. Minimize code
2. Separate type conversion layer (use that of spp)
3. Use of string literal tables and namespaces registering mechanism
Serializer and related area
1. Drop creation of buffer and string coping to it. Instead send the
bytes directly to transport along with string length.
2. Use string literal tables throughout the Serialize DOM tree
(SOAPEnvelop, SOAPBody, SOAPHeader etc)
WSDL2Ws tool
1. If we drop/change the way we support C stubs and skeletons we can
reduce the code duplication that we have at the moment.
2. Need to adopt latest Axis jars.
3. Need to support multiple <portType> s in wsdls.
4. Need to add/improve code generation for changing Soap Fault handling
and Exception handling mechanisms.
4. May need to add code generation for type registering.
STL Usage
We are not going to eliminate STL but minimize. We do not expose STL to
either stubs or skeletons. 
1. Use char* instead of std::string where performance is affected
(string concatenation etc).
2. Can reduce the number of template instances used by using template
instances with void* type. Ex:
            - Use list<void*> for list<Param*>, list<SoapSerializer*>
            - Use map<int, void*> for map<char, xxx*>, map<int, yyy*>
3. Remove map<int, list<xx*>> kind of containers.
We may need to consider following for SOAP Header handling,
1. Having a base class (Similar to ComplexType) for custom SOAP Header
2. WSDL2Ws tool generated code based approach.  
Introduce String literal tables
Bring all string literals in Axis C++ code to one (or few) file(s). This
introduction of string literal tables will,
1. Reduce the size of the executable
2. Provide an effective compilation mechanism for both utf8 and utf16.
3. Effective copy
Research Areas
1. Asynchronous messaging with Apache server.
2. Check whether there is a more efficient function similar to ap_rputs
that takes the string length as a parameter.

View raw message