Send your feedback to: axis-c-dev@ws.apache.org (Prefix the subject with [Axis2]). To subscribe to developer or user mailing lists see here
One of the main design goals of Axis2/C is the re-usability of the library and the ability to plug into different platforms. 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.
Axis2/C defines an environment to hold platform specific entities such as the allocating mechanism, the logging mechanism, etc. This environment is initialized at the point of starting Axis2/C and will last for the lifetime of Axis2/C library. Different sub environments can also be created to suit a particular scenario (eg: the thread specific environment). The Axis2 environment holds the following entities in order to abstract the platform.
Allocator is the wrapper for memory management mechanisms. It defines the following primitives:
malloc - method to allocate a memory block of given
size.realloc - method to change the size of the memory
block.free - method to free a memory block.Axis2 Error defines error reporting mechanisms for Axis2 library. All of
the Axis2 internal functions use the axis2_error in the
environment to report errors.
Axis2 Log defines the common logging mechanisms required for the Axis2
library. All of the internal Axis2/C code uses the functions defined in the
axis2_log available in the environment.
Axis2 Thread Pool defines the thread management functions. It hides the
complex thread pooling functions as well as the platform specific
implementations of threads. Axis2 internal library uses this interface to
manipulate threads and they deal with a common thread type which is defined
as axis2_thread.
Axis2 environment is the starting point for platform abstraction of Axis2/C. It can be used to plug platform specific memory management, error reporting, logging and thread pooling mechanisms to Axis2 core functions.
Axis2 is a modular program where the user can add functionality by selecting a set of modules. The modules can either be compiled at the source tree of Axis2 or separately. These modules should be compiled as Dynamic Shared Objects (DSOs) that exist separately. Services are also loaded dynamically by reading the contents of the services folder. This dynamic loading is mandatory in order to provide hot deployment/update as well as to facilitate runtime selection of transports.
The DSO support for loading individual Axis2 components is based on the
component named class_loader, which must be statically compiled
with Axis2 core components (in the util package). To abstract
the 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 a
platform specific header file (e.g. axis2_unix.h). The file
axis2_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 is the fact that the engine and the other
SOAP processing is independent from the transport aspect. Users can develop
their own transports and the interface is defined in:
axis2_transport_sender.h and
axis2_transport_receiver.h.
Currently Axis2/C supports HTTP transport. The transport receiver is a Simple HTTP server provided by Axis2 or the Axis2 Apache2 (mod_axis2) module. The transport sender uses sockets to connect and send the SOAP Message.
Inside the HTTP transport, the receivers and clients are abstracted so
that the user can easily plug in their own senders and receivers (eg: A
libcurl based client can be implemented instead of the simple
http client available in the axis2 distribution).
Stream is a representation of a sequence of bytes. Since Axis2 heavily uses streaming mechanisms to read/write xml, an implementation independent stream abstraction is required in order to integrate Axis2 in other environments seamlessly. The core components of Axis2 deal with this abstracted stream and does not worry about the implementation specific details. The creating point of the stream (eg: the transport receiver) knows what type of stream should be created (eg: socket, file, etc) and creates the appropriate stream. Thereafter, rest of the components are independent from the implementation details of the stream.
The stream also serves as a main point in internationalization support. It can convert the the internal byte representation to different types of encodings as specified by the user. This can be achieved by plugging an encoding engine to the stream.
Axis2 core functions, such as hot deployment/update, asynchronous invocation, concurrent request processing in simple axis2 server, etc., heavily depend on threads. At the same time these threads should be platform independent inside the Axis2 core components. Another important requirement in threading model is the ability to pool the threads. This thread pooling mechanism should be Axis2 independent and Axis2 core components should be able to deal with the thread pooling mechanisms via a uniform interface.
So the above two aspects lead to two main requirements in the threading model:
These two requirements are implemented in current Axis2 using a platform
independent thread type axis2_thread and an implementation
independent thread pool axis2_thread_pool.
Axis2 architecture depends on the XML pull model. But in C there is no
such API (such as StAX API). Therefore, an XML pull API, which is specific to
Axis2 is defined in as axis2_xml_reader and
axis2_xml_writer. Any implementation of this API can be plugged
into the Axis2 core as long as they follow the API strictly. If an external
XML parser needs to be plugged into Axis2, a wrapper that maps the
reading/writing functions to the Axis2 XML reader/writer API should be
written.