Explain the execution flow when Axis2 receives an inbound SOAP request using Axiom?

The flow starts at the transport layer and ends with a service-specific message receiver, with Axiom's deferred building threaded through nearly every step in between.

sequenceDiagram
  participant Client
  participant TR as Transport Receiver
  participant Builder as StAXSOAPModelBuilder
  participant MC as MessageContext
  participant Ph as Phases (Transport/Security/Dispatch)
  participant DB as Databinding (e.g. ADB)
  participant MR as Message Receiver / Service

  Client->>TR: Raw bytes over HTTP/JMS/etc.
  TR->>Builder: Create XMLStreamReader, wrap in builder
  Builder-->>MC: SOAPEnvelope (incomplete), attached to MessageContext
  MC->>Ph: Pass through configured phases in order
  Ph->>Ph: Inspect relevant headers (partial build as needed)
  Ph->>MC: Determine target service/operation (dispatch)
  MC->>DB: Hand body to databinding for deserialization
  DB->>DB: Fully build body subtree, map to Java objects
  DB->>MR: Invoke target operation with deserialized params
  MR-->>Client: Response OMElement built and serialized back out

Two details matter for a deeper understanding here: first, the envelope handed into the phase chain is not fully built - each phase only forces as much materialization as its own logic actually requires, so a phase that only reads the WS-Addressing header never touches the body at all. Second, the response path mirrors this laziness: if the service uses an OMSourcedElement-backed databinding output, the Java-object-to-XML conversion for the response body is itself deferred until the outbound message is actually serialized to the transport.

This is why profiling an Axis2 service under load often shows very different bottlenecks depending on payload shape - a service that reads only headers behaves very differently, performance-wise, from one whose message receiver immediately deserializes the entire body on every request.