axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <susan...@opensource.lk>
Subject Axis C++ todo list
Date Thu, 12 Feb 2004 05:47:04 GMT
Hi All,

I have prepared a TODO list for Axis C++. The content in this list is
based on my knowladge/ideas of Axis and recent discussions held with Axis
C++ team. Please feel free to suggest/criticize them.

I wish we start discussion threads on each of the items so that all
developers understand the task to ensure that all proceed the the correct
direction.

Then each contributor can choose a particular area to develop.

I know few of these work have already been done and some are in progress.
Please let others know what of these have been done already and what are
in progress.

Also we have to take a decision on the set of items we consider for next
release of Axis C++ (release 1.1 is planned to the first week of March
2004).

This TODO list is available at wiki page

http://nagoya.apache.org/wiki/apachewiki.cgi?AxisCpp_TODO

Thanks,

Susantha.

                                Axis C++ TODO List
============================================================================

1).Transport
============
Axis transport layer should be improved to support following features.

1. Both http chunked and http unchunked data transfer
2. Support for plug-in other kind of trasport layers (SMTP etc).
3. Making the transport layer a separate DLL at client side. Then this DLL
is loaded by Axis Client library.
4. Using libWWw for axis transport layer.
5. Implementaion of XIO transport layer for axis.
6. Supporting two types of transport APIs.(decided at compile time)

	- The two APIs are,

	a. Transport layer allocates receive buffers and passed to Axis. buffers
to send are allocated by Axis
	   and passed to trasport layer to be sent. There can be multiple buffers
passed to / from Axis for a
	   single request. This API is suitable for non-blocking transport
layers. Example for this kind of
	   transport is XIO.

	b. To receive data Axis provides a buffer to the trasport layer and the
transport layer fills and returns
	   it back to Axis. To send data Axis passes a buffer to the transport
layer. There is only one buffer in
	   each way (per thread). The two buffers are allocated by Axis and may
be re-used within a single request.
	   Essentially Axis blocks when the transport layer processes. But as
this API (model) best fits the XMLPull
	   parsing model, this should be the default API.

	- Providing ineterfaces for C and C++ transport layers.

	For each of above APIs Axis should provide interfaces and/or C function
pointer table definition (like "module"
	in apache modules)

7. Implementaion of Axis ISAPI extension to use Axis with Microsoft IIS.

2).Source Restructuring
=======================

1. Include files should be restructured in the CVS folder hiarachy to keep
include files that goes with binary
   distribution seperately. Then CVS folder /c/include will contain only
the include files that goes with binary
   distribution and all other include files are moved to the respective
/c/src folder. Following structure is to
   be adopted for /c/include folder.

   /c
    |--client
    |     |--libwww
    |     |--axis
    |     |--xio
    |--server
    |     |--apache1_3
    |     |--apache2_0
    |     |--iis


3). Build environments
======================

1. Distribution build files. Rather than building each project and
manually copying the files to prepare the
   distribution we need to have build files (Makefiles, Visual C++ build
files, other) to automate this process.
2. Eclipse CDT projects and/or build files
3. Borland C projects and/or build files
4. Unittests /unittest/cppunit

4).Client Engine
================

1. Implementation of client Side handler processing.
2. Making Axis client a common DLL so that any (all) client application(s)
use the same Axis client DLL. Then the
   generated stubs are not compiled with all Axis code. But minimum code
that can load the client Axis DLL.

5).Server Engine
================
1. Making Axis server a common DLL so that any server side module can use
the same Axis DLL (apache module, ISAPI,
   JNI, XIO or SimpleAxisServer etc).

6).Serialization / Deserialization
==================================
1. Axis source at CVS head does not support parsers other than Expat. We
need to write wrappers for using xerces/libxml/txpp
2. Implementation of the basic XMLPull parser for Axis.
3. Axis have to come up with an architecture to support extensible types
and #any types.

7).WSDD
=======
1. Axis source code at CVS uses only Expat parser to parse WSDD file.We
have to define Interfaces and wrappers for supporting
   other parsers (xerces/libxml/txpp).
2. Implementation of serialize methods to every WSDD class for writing
WSDD file from the memory representation (this
   feature is required for dynamic deployment/undeployment).
3. Explore the situattion when multiple clients or servers work with same
wsdd. Either we have to workout a way to have
   a single WSDD for each server/client application or have separate
sections in the same WSDD for each server/client.
4. Studying other facilities of wsdd schema and changing/modifying it to
fit Axis C++.
   At the moment Axis C++ uses the same WSDD schema designed for Axis
Java. But IMO we have the freedom to customize it
   to fit Axis C++ requirements. Ex: typeMapping and beanMapping sections.

8).Error Handling
=================
1. At the moment Axis uses only 2 global error codes (AXIS_SUCCESS and
AXIS_FAIL) and hence when an error occured not
   enough information is returned back to where the error is handled. SO
we have to define a global flat list of errors
   and propagate enough information about the error.
2. In Axis not all the code base handle every possible error situations.
Also there are places where the same error is
   checked more than onece. We have to avoid these trivial error checkings.

9). C/C++ API for XML RPC (CAx-RPC)
===================================
1. Axis C++ team has to come up with a draft document for "C/C++ API for
XML RPC". Also all interested parties should
   be invited to participate.

10).Standard Handlers
=======================
Axis should implement set of standard handlers for following purposes.
	a. Ws-Security
	b. Ws-Transaction
	c. Ws-Routing

11).New featurs to Add
=========================
1. SOAP with attachements.

12). Architecture/Code reviews
==============================
Software architects/developers should be invited to review the
architecture and the code of Axis and get thier feedback.

13). Tutorial preparation
=========================
Axis has to prepare 2 sets of comprehensive tutorials on using Axis server
and client library. Step by step guide on both
Windows and Linux platforms.

14). Performance tuning
=======================
1. Minimizing the usage of STL.
2. Remove the trivial code. Ex: Param class and ArrayBean class
3. Avoid trivial error checking.

15). Support for internationalization
=====================================
1. Providing 2 different Axis libraries for utf-8 and utf-16
applications/services. we have to have a compiler
   directive to decide what the output encoding is.

16). WSDL2WS code generation
============================
1. Code generation to handle fault messages
2. C/C++ names of Complex types should be fully qualified to avoid name
collisions.
   Ex: http___www_opensource_lk_MyType instead of Mytype
3. Code generation for Extensible types and #any type support.

17). Session support
====================
Even if the Axis code base written to handle sessions, non of the
transport modules use that feature (both client and server).

18). Security
=============
1. Support transport-level security (SSL etc).
2. Support SOAP-level security according to existing security SOAP-level
standards.

19). Code improvements
======================
1. Praparing a coding standard guidelines document for Axis C++.
2. Applying those coding standards to the existing code base.





Mime
View raw message