axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Susantha Kumara" <susan...@opensource.lk>
Subject RE: Improving / re-factoring Axis C++
Date Fri, 23 Jul 2004 12:54:33 GMT
> -----Original Message-----
> From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> Sent: Friday, July 23, 2004 1:20 PM
> To: Apache AXIS C User List; 'Apache AXIS C Developers List'
> Cc: 'Apache AXIS C User List'
> Subject: Re: Improving / re-factoring Axis C++
> 
> To me this sounds like lots of engineering/reengineering work.
> I would like to suggest a divide and conqure approach, where one
module is
> addressed at a time.

Yes this is lots of re-engineering work. Its true that we can do this by
module by module. But It would take lot of developers time for testing.
Also this approach would make the developers dependent of each other
(one may be waiting till the other finishes one module etc). So onece we
figure out what changes we are going to do we can go ahead and do it.
After we feel that we have finished with refactoring etc we can
integrate and test it.

What I would suggest is that we do these re-factoring in few weeks (say
3-4 weeks) and then start integration and testing etc to make it stable.
 
> 
> As I have mentioned earlier, I too have some comments on
> serializer/deserializer and transport
> coupling, which I came to notice during the implementation of LibWWW
> transport.
> 
> I also think that it will be a good idea to consider mails in the past
on
> the same subject over
> mailing list related to design. I had couple of them sent (e.g. on the

I have considered most of the feedbacks I got in the mailing list.
Please feel free to point out any miss outs. Also I would like if you
add to the following list any other re-factoring suggestions (with
detailed explanations) in any code segment (file, API, modules etc).

> stub level copy
> constructing that I had to do because of the state related problems in
the
> engine; may be not
> engine problems but still worth considering). Personally I believe
state
> management is important.
> (This feeling gets stronger, as I am looking into thread safety issues
of
> LibWWW these days.)

Will focus on keep Alive and chunking too.

> 
> Another suggestion would be to sync these new items with WS-I and
other
> similar kinds of
> compliances. Now we know the problems, we would be in a better
position to
> more easily achieve
> compliance in the future improvements.

If you could prepare is list on non-compliant areas that would be a
great job.
 
> 
> I am not sure how much this would apply to an open source project, but
I
> would like to reverse
> engineer the source and build the current desing model, to more
> objectively asses the current
> desing, before jumping into refactoring.

This too is very good because it would also help the recent developers
to easily understand and figure out any problem / areas to improve etc.

Thanks,

Susantha.

> 
> Samisa...
> 
> --- Susantha Kumara <susantha@opensource.lk> 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 ?).
> >
> > 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.
> >
> > Deserializer
> > ------------
> > 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*>
> > 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,
> > 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.
> >
> >
> 
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - 50x more storage than other providers!
> http://promotions.yahoo.com/new_mail


Mime
View raw message