axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From damitha kumarage <dami...@opensource.lk>
Subject Re: Improving / re-factoring Axis C++
Date Thu, 22 Jul 2004 13:01:38 GMT
On Wed, 2004-07-21 at 16:08, Susantha Kumara wrote:
> 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 ?).

This means lot of changes. Late merging will be a problem. If the
changes are so big continuous merging is also a difficult task.

Why not we work on a branch and may be that branch is aimed for Axis C++
2.0. We will continue with current branch until Axis C++ 1. series is 
very stable.

> 
>  
> 
> 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 ).

> How do we do this?
>  
> 
> 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.
> 
I think we first concentrate on txpp and later we can later write type
conversion wrappers for other paresrs.

Current one is not by anyway complete. It is just a prototype kind of
thing to test certain things

Anyway shall we start a seperate discussion thread on txpp once we start
working on it. I guess we will be working on it very soon.


> 
>  
> 
> 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.
> 
>  
> 
> Deserializer
> 
> ------------
> 
> 1. Minimize code
> 
> 2. Separate type conversion layer (use that of spp)
> 
+1

> 3. Use of string literal tables and namespaces registering mechanism
> 
+1
>  
> 
> 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*>
> etc.
> 
>             - Use map<int, void*> for map<char, xxx*>, map<int, yyy*>
> etc.
> 
> 3. Remove map<int, list<xx*>> kind of containers.
> 
>  
> 
> SoapFaults
> 
> ----------
> 
>  
> 
> SOAPHeaders
> 
> -----------
> 
> We may need to consider following for SOAP Header handling,
> 
> 1. Having a base class (Similar to ComplexType) for custom SOAP Header
> structs.
> 
> 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,
> 
cool
> 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.

> 
>  
> 
> Thanks,
> 
>  
> 
> Susantha.
> 
thanks
damitha
>  
> 
> 


Mime
View raw message