How Mediator Determines Which Builder and Formatter Classes to Use (and How You Can Override Them)

Run-time Step	Description
Mediator receives the request from the client	It is important that the client's PUT or POST requests contain the HTTP header Content-Type because the Content-Type header determines the message builder Mediator uses to parse the input stream. (GET or DELETE request do not require a Content-Type header.)
Mediator sends the request to the service provider	Mediator uses a message formatter to serialize the request, and then sends the serialized request to the native service provider. Mediator determines the message formatter to use as follows: If you explicitly specify a message formatter (by setting the MESSAGE_TYPE context variable in a webMethods IS service and invoking this service in the virtual service’s Invoke webMethods IS Service action), then Mediator uses that formatter. The Content-Type header that Mediator sends to the native provider is the one that is associated with the MESSAGE_TYPE context variable. Else, Mediator will use the message formatter associated with the Content-Type sent by the client (and sends the Content-Type to the native provider). Else, if no Content-Type was sent by the client, then: For PUT requests, the default formatter used (and the Content-Type header that Mediator sends to the native provider) is application/xml. For POST requests, the default formatter used (and the Content-Type header that Mediator sends to the native provider) is SOAP (and the request will fail). For GET or DELETE requests (which do not require a Content-Type header), the default formatter used (and the Content-Type header that Mediator sends to the native provider) is application/x-www-form-urlencoded.
Mediator receives a response from the service provider	When the provider returns a response to Mediator, a message builder parses the response stream into an Axiom message to be stored in the message context. Mediator determines which message builder to use as follows: 1. Mediator will select the message builder associated with the request's Accept transport header, if one was specified. 2. Else, you can set the BUILDER_TYPE context variable in a webMethods IS service, and invoke this service in the virtual service’s Invoke webMethods IS Service action. Mediator will check that the builder type is a valid Content-Type for the list of builders in axis2.xml. This variable takes priority over the current setting specified in the Accept transport header. That is, Mediator will only use the Accept header to determine the builder type needed to parse a native provider response if no IS service was written to set the BUILDER_TYPE context variable. 3. Else, Mediator will use the builder associated with the Content-Type specified in the request (assuming that the Content-Type is one of the types that is mapped in axis2.xml). 4. Else, if no Content-Type was specified in the request (for example, a PUT or POST request with no Content-Type, or any GET or DELETE request), or if the Content-Type is not one of the types that is mapped in axis2.xml, then Mediator will default to application/xml.
Mediator sends a response to the client	Mediator serializes the response and sends it to the client. By default, Mediator uses the formatter that was used to serialize the request sent to the provider. (If the formatter was application/x-www-form-urlencoded (for a GET or DELETE request), then Mediator will instead use application/xml so it can send the response.) You can override the Content-Type that is sent to the client by setting the MESSAGE_TYPE context variable in a webMethods IS service, and invoking this service in the virtual service’s Invoke webMethods IS Service action.