First let me explain about Axis "styles" and differentiate them from WSDL "styles".
The WSDL "style" refers to the way the WSDL describes the content of a SOAP message body. There are two options:
- Document: indicates that the WSDL explicitly describes the content of the SOAP message body -- in all cases the body is described by a schema element definition. The message description contains at most one message part, and that message part must reference an element definition in a schema defined or imported into the types section.
- RPC: indicates that the WSDL implicitly describes the content of the SOAP message body by specifying an operation name and a set of parameter types. The message description contains one message part for each parameter, and each message part must reference a type definition. At runtime, the SOAP engine dynamically constructs the message based on the following convention: The root element of the SOAP body has a local name that is equal to the operation name and is in the namespace specified in the namespace attribute from the <soap:body> definition. The root element contains a child accessor element for each message part defined. Each accessor element gets its local name from the name attribute of the message part. All parameter accessor elements are in no namespace.
The Axis "style" refers to the programming model that Axis exposes for a given service. The Axis "style" represents a combination of the WSDL "style" plus the message processing system--or "provider"--used to handle messages.
Axis supports two types of providers:
- RPC: The RPC provider automatically converts the XML in a SOAP message into Java objects and invokes a specific method associated with the incoming message type. (There's also an EJB provider that can invoke an EJB rather than a POJO.)
- MSG: The MSG provider converts the XML in a SOAP message into DOM and invokes a generic method to process the request
- RPC: Uses the RPC provider and generates an RPC style WSDL
- Wrapped: Uses the RPC provider and generates a Document style WSDL that conforms to the "wrapped" convention. From a programming perspective, it feels exactly like RPC style. At runtime, Axis automatically "wraps" input parameters in a containing element.
- Document: Uses the RPC provider and generates a Document style WSDL, but it does not conform to the "wrapped" convention. From a programming perspective, input and output parameters must be wrapped in a bean.
- Message: Uses the Message provider and generates a Document style WSDL.
Message style is basically do-it-yourself message processing. Axis will perform all SOAP header processing, but it's up to the developer to write the code to process the SOAP body contents. Message style support four method signatures:
public Element  method(Element  bodies);This style is appropriate if the application wants to work natively in XML. It's also an effective means to support a completely dynamic system -- it can process any type of input or output message. If you use the RPC provider, Axis needs to know what type of messages to expect and how to map them to Java objects. When using the Message provider, Axis just maps them to DOM, and it's up to the application to then figure out how to process them.
public SOAPBodyElement  method (SOAPBodyElement  bodies);
public Document method(Document body);
public void method(SOAPEnvelope req, SOAPEnvelope resp);
A word of caution, though: if you use the "Message" style and you ask Axis to generate a WSDL, the WSDL will have basically no information in it. Axis doesn't know anything about the content of the messages; therefore, it generates element definitions with type="xsd:anyType". Unless your goal is to build a completely dynamic processor, it's typically a bad idea to use "xsd:anyType" or "xsd:any"in a WSDL. For better interoperability, it really helps to explicitly define the expected contents of all input and output messages. (That's why WSDL Document style is preferred to RPC style.)
So if you use the message style, make sure you also hand-craft your WSDL and add a schema definition of your input and output messages.