Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Axis architecture guide Axis Architecture Guide -- -- -- -- Axis Architecture Guide Version Feedback axis-dev ws apache org Introduction This guide records some of the rationale of the architecture and design of Axis Architectural Overview Axis consists o

Axis Architecture Guide -- -- -- -- Axis Architecture Guide Version Feedback axis-dev ws apache org Introduction This guide records some of the rationale of the architecture and design of Axis Architectural Overview Axis consists of several subsystems working together as we shall see later In this section we'll give you an overview of how the core of Axis works Handlers and the Message Path in Axis Put simply Axis is all about processing Messages When the central Axis processing logic runs a series of Handlers are each invoked in order The particular order 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 MessageContext A MessageContext is a structure which contains several important parts a request message a response message and a bag of properties More on this in a bit There are two basic ways in which Axis is invoked As a server a Transport Listener will create a MessageContext and invoke the Axis processing framework As a client application code usually aided by the client programming model of Axis will generate a MessageContext and invoke the Axis processing framework In either case the Axis framework's job is simply to pass the resulting MessageContext through the configured set of Handlers each of which has an opportunity to do whatever it is designed to do with the MessageContext Message Path on the Server Page Copyright ? - The Apache Software Foundation All rights reserved 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 A message arrives in some protocol-specific manner at a Transport Listener In this case let's assume the Listener is a HTTP servlet It's the Listener's job to package the protocol-specific data into a Message object org apache axis Message and put the Message into a MessageContext The MessageContext is also loaded with various properties by the Listener - in this example the property http SOAPAction would be set to the value of the SOAPAction HTTP header The Transport Listener also sets the transportName String on the MessageContext in this case to http Once the MessageContext is ready to go the Listener hands it to the AxisEngine The AxisEngine's first job is to look up the transport by name The transport is an object which contains a request Chain a response Chain or perhaps both A Chain is a Handler consisting of a sequence of Handlers which are invoked in turn -- more on Chains later If a transport request Chain exists it will be invoked passing the MessageContext into the invoke method This will result in calling all the Handlers specified in the request Chain configuration After the transport request Handler the engine locates a global request Chain if configured and then invokes any Handlers specified therein At some point during the processing up