Architecture Guide


Contents

Introduction

This guide describes the architecture of Axis C++ implementation.


Architecture Overview

Axis C++ is all about deploying C++ web services and processing SOAP messages. Axis C++ architecture closely follows Axis Java in Handler and message paths.

Handlers and the Message Path in Axis

Axis C++ implementation follows how handlers and message paths work in Axis Java implementation. When the central Axis processing logic runs, a series of Handlers are each invoked in order. The order of invocation is determined by two factors - deployment configuration and whether the engine is a client or a server. The object which is passed to each Handler invocation is a MessageData


A MessageData is a structure which contains several important parts:
  • Deserializer
  • Serializer
  • A bag of properties


  • We will be discussing more on each of this later on this Architecture Guide.

    Message Path on the Server


    The server side message path is shown in the following diagram. The small cylinders represent Handlers and the larger, enclosing cylinders represent Chains (ordered collections of Handlers which will be described shortly).


    figure 1.0

    Above diagram shows you how the Axis C++ Engine architecture works to invoke functions of AxisC++ Server Engine.

    A message arrives (in some protocol-specific manner) at a Transport Listener. In this case, let's assume the Listener is an apache module. It's the Listener's job to package the protocol-specific data into a soapstream object (specified in Packet.h), and pass it to Axis C++ Engine to be processed. The soapstream is also loaded with various properties by the Listener - in this example the property "trtype" would be set to the transport type and the value of the SOAPAction HTTP header is inserted in to a header list. The Axis C++ Server Engine's first job is to check what the transport is. Then the MessageData object is created and populated (with Serializer, Deserializer etc). Also the Serializer and Deserializer is initialized. Then the configured handlers and the target web service handler are loaded. All transport, global and service specific handlers are loaded in to Chains. A Chain is also a Handler consisting of a sequence of Handlers which are invoked in turn -- more on Chains later. Transport request handlers are invoked.
    Then the loaded handler chains are invoked in the order as shown in the diagram, passing the MessageData object into the invoke().
    Note:
    Service Specific Layer
    Actual Web service provider is wrapper Class. Handler Chains invoke a list of Handlers in a while loop and HandlerChains.cpp invoke handler one by one.

    Message Flow

    Handlers and Chains

    Handlers are invoked in sequence to process messages. At some point in the sequence a Handler may send a request and receive a response or else process a request and produce a response. Such a Handler is known as the pivot point of the sequence. As described above, Handlers are either transport-specific, service-specific, or global. The Handlers of each of these three different kinds are combined together into Chains. So the overall sequence of Handlers comprises three Chains: transport, global, and service. The following diagram shows two sequences of handlers: the client-side sequence on the left and the server-side sequence on the right.

    figure 3.0

    A web service does not necessarily send a response message to each request message, although many do. However, response Handlers are still useful in the message path even when there isn't a response message, e.g. to stop timers, clean up resources, etc. A Chain is a composite Handler, i.e. it aggregates a collection of Handlers as well as implementing the Handler interface

    A Chain also has similarities to the Chain of Responsibility design pattern in which a request flows along a sequence of Handlers until it is processed. Although an Axis Chain may process a request in stages over a succession of Handlers, it has the same advantages as Chain of Responsibility: flexibility and the ease with which new function can be added. Back to message processing -- a message is processed by passing through the appropriate Chains. A message Data is used to pass the message and associated environment through the sequence of Handlers. The model is that Axis Chains are constructed offline by having Handlers added to them one at a time. Then they are turned online and message data start to flow through the Chains. Handlers and Chains can be defined to have 'request', 'session', or 'application' scope.

    1.Axis Engine

    AxisEngine contains the core logic of the message flow. AxisEngine's "Process" method contains the message flow logic. Following sequence diagrams show the message flow logic. Following Diagram shows how the transport listener passes the SOAP message to the AxisEngine. AxisEngine is a singleton object for a process.

    2.HandlerPool

    AxisEngine instantiates a HandlerPool object in its constructor. HandlerPool does the following 3 tasks,


    1. Loads and keeps Transport and Global handlers.
    2. Loads service specific handlers when needed and unloads when needed.
    3. Loads target web service handler when needed and unloads when needed.

    To provide above functionality the HandlerPool makes use of other two classes HandlerChain and HandlerLoader. HandlerLoader loads holds and unloads the dynamic link library (or shared object) that contain either a handler or a web service. HandlerChain is used to keep a list of handlers to be invoked in order. HandlerChain itself is a handler.

    In order for the HandlerLoader to dynamically load a class, every DLL (or Shared object) must have following export functions.

    int GetClassInstance(DCLInterface **inst);

    int DestroyInstance(DCLInterface *inst);

    AxisEngine has no idea of any web service methods in the deployed web service class that is dynamically loaded from a DLL. Therefore in order to communicate with loaded class we have to have a known interface. This interface is known as BasicHandlerand is known to AxisEngine. This interface is implemented by every webservice and a handler.

    3.Message Model

    The XML syntax of a SOAP message is fairly simple. A SOAP message consists of an envelope containing:
    · an optional header containing zero or more header entries (sometimes ambiguously referred to as headers),
    · a body containing zero or more body entries, and
    · zero or more additional, non-standard elements.

    The only body entry defined by SOAP is a SOAP fault which is used for reporting errors. Some of the XML elements of a SOAP message define namespaces, each in terms of a URI and a local name, and encoding styles, a standard one of which is defined by SOAP. Header entries may be tagged with the following optional SOAP attributes: · actor which specifies the intended recipient of the header entry in terms of a URI, and · mustUnderstand which specifies whether or not the intended recipient of the header entry is required to process the header entry. So the SOAP message model looks like this:

    4.Soap Deserializer

    Currently the Soap Deserializer is implemented using SAX2 parser. Soap Deserializer exposes and API such that the API is independent of the implementation.

    5.Soap Serializer

    Soap Serializer's task is to generate the SOAP stream to be sent. There are a set of functions (API that is the opposite functionality with Soap Deserializer). Once the Serializer is given all the information that is required to generate a SOAP using the API, the getStream(..) function can be used to generate the SOAP message.

    6.WSDD Module

    WSDD module is a set of classes that parses the deployment descriptor file(server.wsdd) which, is a XML file and makes the information available to the AxisEngine. The WSDD module represents the structure of a WSDD file.

    WSDL2Ws Tool

    WSDL2Ws Tool is generated Client Side stubs and server side skeletons and wrappers.It's architecture is described in WSDL2Ws.html

    Diagram Book

    This Diagram Book includes Following Diagrames which are drawn to describe Axis Cpp Engine and it's process.

    1) Use case diagram(s)

    2) Sequence diagrams

    3) Class diagrams(s)

    4) Deployment diagram(s)

    Open Issues