Please send your feedback to: c-dev@axis.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.