Please send your feedback to: axis-c-dev@ws.apache.org +(Subscription details are available on the Axis2 site.) Prefix +the subject with [Axis2].
Some of the main design goals of Apache Axis2/C are the usability of the +library, the ability to be plugged into different platforms, and the ability +to be embedded in other software systems to provide Web services support. +There are many features that allow Axis2/C to be pluggable into different +platforms as well as to enable the extension of the functionality of +Axis2/C.
Apache Axis2/C defines an environment struct to hold platform specific +entities such as the memory allocator, the threading mechanism, etc. The +environment is initialized at the point of starting Axis2/C and will last for +the lifetime of the Axis2/C run-time. Different sub environments can also be +created to suit particular needs, for example, each thread can create its own +environment. The Axis2 environment holds the following entities in order to +abstract the platform specific implementations.
Allocator is the wrapper for memory management mechanisms. It defines the +following primitives:
malloc - method to allocate a memory block of a given
+ size.free - method to free a memory block.Based on the platform, or the software system into which Axis2/C is +embedded, these primitives could be provided with concrete +implementations.
Error defines error reporting mechanisms for Axis2/C. All the Axis2/C
+internal functions use the axutil_error struct instance in the
+environment to report errors.
The log defines the common logging mechanisms required for the Axis2/C
+library. All internal Axis2/C code use the functions associated with the
+axutil_log struct available in the environment for logging.
The thread pool defines the thread management functions. It hides the
+complex thread pooling functions as well as the platform specific
+implementations of threads. The Axis2/C internal library uses this interface
+to manipulate threads and deal with a common thread type which is defined as
+axutil_thread.
The environment struct is the starting point for platform abstraction +supported by Axis2/C. It can be used to plug platform specific memory +management, error reporting, logging, and thread pooling mechanisms.
Axis2/C is designed in an extensible manner, so that the users can add +functionality by implementing new modules. These modules should be compiled +as Dynamic Shared Objects (DSOs). Services are also loaded dynamically at +server start up by reading the contents of the services folder and service +configuration files.
The DSO support for loading Axis2/C services and modules is based on the
+struct named axutil_class_loader. To abstract the
+axutil_class_loader from the DSO loading functionality of the
+underlying operating system, a set of platform independent macros such as
+AXIS2_PLATFORM_LOADLIB and AXIS2_PLATFORM_UNLOADLIB
+are used. These macros will be mapped to platform specific system calls in
+platform specific header files (e.g. axutil_unix.h and
+axutil_windows.h). The file
+axutil_platform_auto_sense.h will include the correct platform
+specific header file, based on the compiler directives available at compile
+time.
One of the key advantages of Axis2/C is the fact that the engine and the
+SOAP processing is independent of the transport aspects. Users can develop
+their own transports and the interface will be defined in:
+axis2_transport_sender.h and
+axis2_transport_receiver.h.
Currently, Axis2/C supports HTTP transport. Axis2/C Apache2 module (mod_axis2) is an example
+of the implementation of the axis2_transport_receiver.h
+interface. libcurl based client transport is an example of the implementation
+of the axis2_transport_sender.h interface.
Stream is a representation of a sequence of bytes. Since Axis2/C heavily
+uses streaming mechanisms to read/write XML, an implementation independent
+stream abstraction is required in order to integrate Axis2/C into other
+environments seamlessly. The core components of Axis2/C deal with this
+abstracted stream and does not worry about the implementation specific
+details. axutil_stream.h defines the stream interface.
The Axis2/C core functions such as asynchronous invocation and concurrent +request processing in simple axis2 server make use of threads. The use of +threads should be platform independent inside the Axis2/C core components.
An implementation independent interface for threads is provided in the
+axutil_thread.h header file. Platform specific implementations
+of this interface are provided for Windows and Linux.
The Axis2/C architecture depends on the XML pull model when dealing with
+XML payloads. In Java there is StAX API, but in C there is no such standard
+API. Therefore, an XML pull API, that is similar to StAX API, is defined in
+the axiom_xml_reader.h and axiom_xml_writer.h. Any
+implementation of this API can be plugged into the Axis2/C core. If an
+external XML parser needs to be plugged into Axis2/C, a wrapper that maps the
+reading/writing functions to the Axis2/C XML reader/writer API should be
+written.