Ошибка soap faultcode http faultstring internal server error

SOAP errors are handled using a specialized envelope known as a

Fault Envelope. If an error occurs
while the server processes a SOAP message, it constructs a SOAP Fault
and sends it back to the client. Here’s a typical
SOAP 1.1 Fault:

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:
xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/
XMLSchema">

<SOAP-ENV:Body>
    <SOAP-ENV:Fault>
        <faultcode>SOAP-ENV:Server</faultcode>
         <faultstring>Test Fault</faultstring>
         <faultactor>/soap/servlet/rpcrouter</faultactor>
         <detail>
            <stackTrace>[SOAPException: faultCode=SOAP-ENV:Server; msg=Test Fault]
            at StockQuantity.getQty(StockQuantity.java:21)
            at java.lang.reflect.Method.invoke(Native Method)
            at org.apache.soap.server.RPCRouter.invoke(RPCRouter.java:146)
            ...
            at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(
                ThreadPool.java:501)
            at java.lang.Thread.run(Thread.java:498)
         </stackTrace>
         </detail>
     </SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

A SOAP Fault is a special element that must appear as an immediate
child of the SOAP body element. The
<faultcode> and
<faultstring> elements are required. The
<faultactor> and
<detail> elements are optional. Table 4-1 lists the possible values for the faultcodes
and their meanings.

The body and Fault elements are namespace-qualified to the
envelope’s namespace—for example,
<SOAP-ENV:body> and
<SOAP-ENV:Fault>. The
<faultcode> element uses the local namespace
(it has no namespace prefix), and the
<faultcode> value that the element contains
is a qualified name using the envelope’s
namespace—for example,
<faultcode>SOAP-ENV:Client</faultcode>.

The SOAP Fault from the previous listing was achieved by making a
slight modification to the StockQuantity service.
In Apache SOAP, having the service throw
an exception is all that’s needed to generate a
fault; Apache takes care of the rest:

public class StockQuantity{

  public int getQty (String item) 
    throws org.apache.soap.SOAPException {

    int inStockQty = (int)(java.lang.Math.random(  ) * (double)1000);
    
    if (item.equalsIgnoreCase("Fail"))
        throw new org.apache.soap.SOAPException   
                      (org.apache.soap.Constants.FAULT_CODE_SERVER, 
                                "Test Fault");    

    return inStockQty;
   }
...
}

In Apache SOAP 2.2, this code is all that is necessary to send a
complete SOAP 1.1 Fault message back to the sender. To view the full
output of the Fault message, redirect the
CheckStock RPC call through the TunnelGui utility
by using the command:

java CheckStock -url http://localhost:5555/soap/servlet/rpcrouter -item Fail

In this command, 5555 is the port on which the
TunnelGui is listening. The RPC request and the corresponding SOAP
Fault can be viewed in the TunnelGui window, as shown in Figure 4-1.

The sending client can trap the Fault programatically and take
appropriate action. Apache
SOAP has a Fault object that can be used to access
the pieces of the Fault message, as indicated in this excerpt from
CheckStock:

    //Invoke the service
    Response resp = call.invoke (url,"urn:go-do-this");

    //Check the response
    if (resp != null) {
        if (resp.generatedFault (  )) {
                        Fault fault = resp.getFault (  );
            System.out.println ("Call failed due to a SOAP Fault: ");
            System.out.println ("  Fault Code   = " + fault.getFaultCode (  ));
            System.out.println ("  Fault String = " + fault.getFaultString (  ));

While the ability to generate a fault by throwing an exception is
handy, you may want more control over what goes into a fault message.
For example, Apache SOAP, by default, puts the current stacktrace
into the <detail> element of the SOAP fault.
That may not be what you want. We will explore how to build your own
Fault message in the context of the mustUnderstand
attribute.

            // Create a header element in a namespace
            org.w3c.dom.Element headerElement =
                doc.createElementNS(URI,"jaws:MessageHeader");
            headerElement.setAttributeNS(URI,"SOAP-ENV:mustUnderstand","1");

            // Create subnodes within the MessageHeader
            org.w3c.dom.Element ele = doc.createElement("From");
            org.w3c.dom.Text textNode = doc.createTextNode("Me");

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" 
    xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Header>
    <jaws:MessageHeader xmlns:jaws="urn:http://oreilly/jaws/samples"
        SOAP-ENV:MustUnderstand="1" >
        <From>Me</From>
        <To>You</To>
        <MessageId>9999</MessageId>
        ...
    </jaws:MessageHeader>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
...
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

<?xml version='1.0' encoding='UTF-8'?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:
xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/
XMLSchema">
    <SOAP-ENV:Body>
         <SOAP-ENV:Fault>
         <faultcode>SOAP-ENV:MustUnderstand</faultcode>
         <faultstring>Unsupported header: jaws:MessageHeader</faultstring>
         <faultactor>/examples/servlet/FaultServlet</faultactor>
         </SOAP-ENV:Fault>
     </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

public class FaultServlet extends HttpServlet
{
...

    public void doPost(HttpServletRequest request, HttpServletResponse response)
        throws IOException, ServletException
    {
    ...
           // Get the header and check it for mustunderstand
           Header header = env.getHeader(  );
           java.util.Vector headerEntries = header.getHeaderEntries(  );
                    
           screenWriter.write("nHeader==>n");
           for (java.util.Enumeration e = headerEntries.elements(  ); 
                            e.hasMoreElements(  );)
           {
               org.w3c.dom.Element el = (org.w3c.dom.Element)e.nextElement(  );
               org.apache.soap.util.xml.DOM2Writer.serializeAsXML(
                 (org.w3c.dom.Node)el, screenWriter);
                        
            // process mustUnderstand
               String mustUnderstand=
                        el.getAttributeNS(Constants.NS_URI_SOAP_ENV, 
                          "mustUnderstand");                  
               screenWriter.write("nMustUnderstand: " 
                + mustUnderstand + "n");

               String tagName = el.getTagName(  );    
               screenWriter.write("Tag Name: " + tagName + "n");

                  if(!tagName.equalsIgnoreCase("IOnlyUnderstandThis"))
                  {
                      //generate a fault.
                      screenWriter.write("Unsupported header: " + tagName + "n");
                      screenWriter.write("Generating Fault....n");
                      SOAPException se = 
                      new SOAPException(Constants.FAULT_CODE_MUST_UNDERSTAND, 
                               "Unsupported header: " + tagName);
                      Fault fault = new Fault(se);
                      fault.setFaultActorURI (request.getRequestURI (  ));
                            
                      String respEncStyle = Constants.NS_URI_SOAP_ENC;

                      org.apache.soap.rpc.Response soapResponse = 
                      new org.apache.soap.rpc.Response (
                                 null,         // targetObjectURI
                                 null,         // methodName
                                 fault,
                                 null,         // params
                                 null,         // headers
                                 respEncStyle, // encodingStyleURI
                                 null);        // SOAPContext

                      Envelope faultEnvelope = soapResponse.buildEnvelope(  );  

                      org.apache.soap.encoding.SOAPMappingRegistry smr 
                           = new org.apache.soap.encoding.SOAPMappingRegistry(  );

                      PrintWriter resW = response.getWriter(  );

                      faultEnvelope.marshall(resW, smr,   
                          soapResponse.getSOAPContext(  ));
                      response.setContentType(request.getContentType(  )); 
                      response.setStatus(response.SC_INTERNAL_SERVER_ERROR);
                      ...
                      }
                  }

<env:Envelope xmlns:env='http://www.w3.org/2001/09/soap-envelope'
         xmlns:f='http://www.w3.org/2001/09/soap-faults' >
    <env:Header>
        <f:misunderstood qname="jaws:MessageHeader"
            xmlns:jaws="urn:http://oreilly/jaws/samples" />
       </env:Header>
    <env:Body>
        <env:Fault>
                   <faultcode>env:mustUnderstand</faultcode>
                   <faultstring>
                One or more mandatory headers not understood
            </faultstring>
           </env:Fault>
    </env:Body>
</env:Envelope>

rpc:ProcedureNotPresent

rpc:BadArguments

env:DataEncodingUnknown

SOAP – это сокращение от Simple Object Access Protocol. Это протокол обмена сообщениями на основе XML для обмена информацией между компьютерами. SOAP является приложением спецификации XML.

Указывает на заметку

• SOAP – это протокол связи, предназначенный для связи через Интернет.

• SOAP может расширить HTTP для обмена сообщениями XML.

• SOAP обеспечивает транспорт данных для веб-сервисов.

• SOAP может обмениваться полными документами или вызывать удаленную процедуру.

• SOAP может использоваться для трансляции сообщения.

• SOAP не зависит от платформы и языка.

• SOAP – это способ определения, какая информация отправляется и каким образом.

• SOAP позволяет клиентским приложениям легко подключаться к удаленным службам и вызывать удаленные методы.

SOAP – это протокол связи, предназначенный для связи через Интернет.

SOAP может расширить HTTP для обмена сообщениями XML.

SOAP обеспечивает транспорт данных для веб-сервисов.

SOAP может обмениваться полными документами или вызывать удаленную процедуру.

SOAP может использоваться для трансляции сообщения.

SOAP не зависит от платформы и языка.

SOAP – это способ определения, какая информация отправляется и каким образом.

SOAP позволяет клиентским приложениям легко подключаться к удаленным службам и вызывать удаленные методы.

Хотя SOAP может использоваться в различных системах обмена сообщениями и может доставляться через различные транспортные протоколы, первоначальная цель SOAP – удаленные вызовы процедур, транспортируемые через HTTP.

Другие платформы, в том числе CORBA, DCOM и Java RMI, предоставляют функциональность, аналогичную SOAP, но сообщения SOAP написаны полностью на XML и поэтому уникально независимы от платформы и языка.

SOAP – структура сообщения

SOAP-сообщение – это обычный XML-документ, содержащий следующие элементы:

• Конверт – определяет начало и конец сообщения. Это обязательный элемент.

• Заголовок – содержит любые необязательные атрибуты сообщения, используемые при обработке сообщения, либо в промежуточной точке, либо в конечной конечной точке. Это необязательный элемент.

• Тело – содержит данные XML, содержащие отправляемое сообщение. Это обязательный элемент.

• Неисправность – необязательный элемент неисправности, который предоставляет информацию об ошибках, возникающих при обработке сообщения.

Конверт – определяет начало и конец сообщения. Это обязательный элемент.

Заголовок – содержит любые необязательные атрибуты сообщения, используемые при обработке сообщения, либо в промежуточной точке, либо в конечной конечной точке. Это необязательный элемент.

Тело – содержит данные XML, содержащие отправляемое сообщение. Это обязательный элемент.

Неисправность – необязательный элемент неисправности, который предоставляет информацию об ошибках, возникающих при обработке сообщения.

Все эти элементы объявлены в пространстве имен по умолчанию для конверта SOAP – http://www.w3.org/2001/12/soap-envelope, а пространство имен по умолчанию для кодировки SOAP и типов данных – http: //www.w3 .org / 2001/12 / мыла-кодирования

ПРИМЕЧАНИЕ. – Все эти характеристики могут быть изменены. Так что продолжайте обновлять себя новейшими спецификациями, доступными на сайте W3.

Структура сообщения SOAP

Следующий блок отображает общую структуру сообщения SOAP –

<?xml version = "1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
   SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">

   <SOAP-ENV:Header>
      ...
      ...
   </SOAP-ENV:Header>
   <SOAP-ENV:Body>
      ...
      ...
      <SOAP-ENV:Fault>
         ...
         ...
      </SOAP-ENV:Fault>
      ...
   </SOAP-ENV:Body>
</SOAP_ENV:Envelope>

МЫЛО – Конверт

Конверт SOAP указывает начало и конец сообщения, чтобы получатель знал, когда было получено все сообщение. Конверт SOAP решает проблему определения того, когда вы получили сообщение и готовы его обработать. Поэтому конверт SOAP – это, по сути, механизм упаковки.

Указывает на заметку

• Каждое сообщение SOAP имеет корневой элемент Envelope.

• Конверт является обязательной частью сообщения SOAP.

• Каждый элемент Envelope должен содержать ровно один элемент Body.

• Если конверт содержит элемент заголовка, он должен содержать не более одного элемента и должен отображаться как первый дочерний элемент конверта перед телом.

• Конверт изменяется при изменении версий SOAP.

• Конверт SOAP указывается с использованием префикса пространства имен ENV и элемента Envelope.

• Необязательная кодировка SOAP также указывается с использованием имени пространства имен и необязательного элемента encodingStyle , который также может указывать на стиль кодирования, отличный от стиля SOAP.

• SOAP-процессор, совместимый с v1.1, генерирует ошибку при получении сообщения, содержащего пространство имен конверта v1.2.

• SOAP-процессор, совместимый с v1.2, генерирует ошибку VersionMismatch, если он получает сообщение, которое не включает пространство имен конверта v1.2.

Каждое сообщение SOAP имеет корневой элемент Envelope.

Конверт является обязательной частью сообщения SOAP.

Каждый элемент Envelope должен содержать ровно один элемент Body.

Если конверт содержит элемент заголовка, он должен содержать не более одного элемента и должен отображаться как первый дочерний элемент конверта перед телом.

Конверт изменяется при изменении версий SOAP.

Конверт SOAP указывается с использованием префикса пространства имен ENV и элемента Envelope.

Необязательная кодировка SOAP также указывается с использованием имени пространства имен и необязательного элемента encodingStyle , который также может указывать на стиль кодирования, отличный от стиля SOAP.

SOAP-процессор, совместимый с v1.1, генерирует ошибку при получении сообщения, содержащего пространство имен конверта v1.2.

SOAP-процессор, совместимый с v1.2, генерирует ошибку VersionMismatch, если он получает сообщение, которое не включает пространство имен конверта v1.2.

v1.2-совместимое сообщение SOAP

Ниже приведен пример сообщения SOAP, совместимого с v1.2.

<?xml version = "1.0"?>
<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
   SOAP-ENV:encodingStyle = " http://www.w3.org/2001/12/soap-encoding">
   ...
   Message information goes here
   ...
</SOAP-ENV:Envelope>

SOAP с HTTP POST

В следующем примере показано использование сообщения SOAP в операции HTTP POST, которая отправляет сообщение на сервер. Он показывает пространства имен для определения схемы конверта и для определения схемы правил кодирования. Ссылка OrderEntry в заголовке HTTP – это имя программы, которая будет вызываться на веб-сайте tutorialspoint.com.

POST /OrderEntry HTTP/1.1
Host: www.tutorialspoint.com
Content-Type: application/soap; charset = "utf-8"
Content-Length: nnnn

<?xml version = "1.0"?>
<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
   SOAP-ENV:encodingStyle = " http://www.w3.org/2001/12/soap-encoding">
   ...
   Message information goes here
   ...
</SOAP-ENV:Envelope>

ПРИМЕЧАНИЕ. – Привязка HTTP указывает местоположение службы.

SOAP – заголовок

Необязательный элемент Header предлагает гибкую структуру для указания дополнительных требований уровня приложения. Например, элемент Header может использоваться для указания цифровой подписи для служб, защищенных паролем. Кроме того, его можно использовать для указания номера учетной записи для сервисов SOAP с оплатой за использование.

Указывает на заметку

• Это необязательная часть сообщения SOAP.

• Элементы заголовка могут встречаться несколько раз.

• Заголовки предназначены для добавления новых функций и возможностей.

• Заголовок SOAP содержит записи заголовка, определенные в пространстве имен.

• Заголовок закодирован как первый непосредственный дочерний элемент конверта SOAP.

• Когда определены несколько заголовков, все непосредственные дочерние элементы заголовка SOAP интерпретируются как блоки заголовка SOAP.

Это необязательная часть сообщения SOAP.

Элементы заголовка могут встречаться несколько раз.

Заголовки предназначены для добавления новых функций и возможностей.

Заголовок SOAP содержит записи заголовка, определенные в пространстве имен.

Заголовок закодирован как первый непосредственный дочерний элемент конверта SOAP.

Когда определены несколько заголовков, все непосредственные дочерние элементы заголовка SOAP интерпретируются как блоки заголовка SOAP.

Атрибуты заголовка SOAP

Заголовок SOAP может иметь следующие два атрибута:

Атрибут актера

Протокол SOAP определяет путь сообщения как список узлов службы SOAP. Каждый из этих промежуточных узлов может выполнить некоторую обработку и затем переслать сообщение следующему узлу в цепочке. Устанавливая атрибут Actor, клиент может указать получателя заголовка SOAP.

Атрибут MustUnderstand

Указывает, является ли элемент Header необязательным или обязательным. Если установлено значение true, получатель должен понимать и обрабатывать атрибут Header в соответствии с его определенной семантикой или возвращать ошибку.

В следующем примере показано, как использовать заголовок в сообщении SOAP.

<?xml version = "1.0"?>
<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV = " http://www.w3.org/2001/12/soap-envelope"   
   SOAP-ENV:encodingStyle = " http://www.w3.org/2001/12/soap-encoding">

   <SOAP-ENV:Header>
      <t:Transaction 
         xmlns:t = "http://www.tutorialspoint.com/transaction/" 
         SOAP-ENV:mustUnderstand = "true">5
      </t:Transaction>
   </SOAP-ENV:Header>
   ...
   ...
</SOAP-ENV:Envelope>

МЫЛО – Тело

Тело SOAP является обязательным элементом, который содержит определяемые приложением данные XML, которыми обмениваются в сообщении SOAP. Тело должно содержаться в конверте и должно следовать всем заголовкам, которые могут быть определены для сообщения.

Тело определяется как дочерний элемент оболочки, а семантика для тела определяется в связанной схеме SOAP.

Тело содержит обязательную информацию, предназначенную для конечного получателя сообщения. Например –

<?xml version = "1.0"?>
<SOAP-ENV:Envelope>
   ........
   <SOAP-ENV:Body>
      <m:GetQuotation xmlns:m = "http://www.tp.com/Quotation">
         <m:Item>Computers</m:Item>
      </m:GetQuotation>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

В приведенном выше примере запрашивается расценка компьютерных комплектов. Обратите внимание, что элементы m: GetQuotation и Item выше являются специфичными для приложения элементами. Они не являются частью стандарта SOAP.

Вот ответ на вышеуказанный запрос –

<?xml version = "1.0"?>
<SOAP-ENV:Envelope>
   ........
   <SOAP-ENV:Body>
      <m:GetQuotationResponse xmlns:m = "http://www.tp.com/Quotation">
         <m:Quotation>This is Qutation</m:Quotation>
      </m:GetQuotationResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Обычно приложение также определяет схему, содержащую семантику, связанную с элементами запроса и ответа.

Сервис Quotation может быть реализован с использованием EJB, работающего на сервере приложений; в этом случае процессор SOAP будет отвечать за отображение информации тела в качестве параметров в и из реализации EJB службы GetQuotationResponse . Процессор SOAP также может отображать информацию тела в объект .NET, объект CORBA, программу COBOL и так далее.

МЫЛО – Неисправность

Если во время обработки возникает ошибка, ответ на сообщение SOAP является элементом ошибки SOAP в теле сообщения, и ошибка возвращается отправителю сообщения SOAP.

Механизм сбоя SOAP возвращает конкретную информацию об ошибке, включая предопределенный код, описание и адрес процессора SOAP, который сгенерировал сбой.

Указывает на заметку

• Сообщение SOAP может содержать только один блок отказа.

• Ошибка является необязательной частью сообщения SOAP.

• Для привязки HTTP успешный ответ связан с диапазоном кодов состояния от 200 до 299.

• Ошибка SOAP связана с диапазоном кодов состояния от 500 до 599.

Сообщение SOAP может содержать только один блок отказа.

Ошибка является необязательной частью сообщения SOAP.

Для привязки HTTP успешный ответ связан с диапазоном кодов состояния от 200 до 299.

Ошибка SOAP связана с диапазоном кодов состояния от 500 до 599.

Подэлементы неисправности

Ошибка SOAP имеет следующие подэлементы –

<faultCode>

Это текстовый код, используемый для обозначения класса ошибок. В следующей таблице приведен список предопределенных кодов ошибок.

<faultString>

Это текстовое сообщение, объясняющее ошибку.

<faultActor>

Это текстовая строка, указывающая, кто вызвал ошибку. Это полезно, если сообщение SOAP проходит через несколько узлов в пути сообщения SOAP, и клиент должен знать, какой узел вызвал ошибку. Узел, который не действует как конечный пункт назначения, должен включать элемент faultActor .

<подробно>

Это элемент, используемый для передачи сообщений об ошибках приложения. Элемент detail может содержать дочерние элементы, называемые элементами detail.

Коды ошибок SOAP

Определенные ниже значения faultCode должны использоваться в элементе faultcode при описании неисправностей.

SOAP-ENV: VersionMismatch

Обнаружено недопустимое пространство имен для элемента конверта SOAP.

SOAP-ENV: MustUnderstand

Непосредственный дочерний элемент элемента Header с атрибутом mustUnderstand, установленным в «1», не был понят.

SOAP-ENV: Клиент

Сообщение было неправильно сформировано или содержало неверную информацию.

SOAP-ENV: Сервер

Возникла проблема с сервером, поэтому сообщение не удалось продолжить.

Пример ошибки SOAP

Следующий код является примером неисправности. Клиент запросил метод с именем ValidateCreditCard , но служба не поддерживает такой метод. Это представляет ошибку запроса клиента, и сервер возвращает следующий ответ SOAP –

<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:xsi = "http://www.w3.org/1999/XMLSchema-instance"
   xmlns:xsd = "http://www.w3.org/1999/XMLSchema">

   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
         <faultcode xsi:type = "xsd:string">SOAP-ENV:Client</faultcode>
         <faultstring xsi:type = "xsd:string">
            Failed to locate method (ValidateCreditCard) in class (examplesCreditCard) at
               /usr/local/ActivePerl-5.6/lib/site_perl/5.6.0/SOAP/Lite.pm line 1555.
         </faultstring>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

SOAP – Кодировка

SOAP включает в себя встроенный набор правил для кодирования типов данных. Это позволяет сообщению SOAP указывать конкретные типы данных, такие как целые числа, числа с плавающей запятой, двойные числа или массивы.

• Типы данных SOAP делятся на две широкие категории – скалярные типы и составные типы.

• Скалярные типы содержат ровно одно значение, такое как фамилия, цена или описание продукта.

• Составные типы содержат несколько значений, таких как заказ на покупку или список котировок акций.

• Типы соединений далее подразделяются на массивы и структуры.

• Стиль кодирования для сообщения SOAP устанавливается через атрибут SOAP-ENV: encodingStyle .

• Чтобы использовать кодировку SOAP 1.1, используйте значение http://schemas.xmlsoap.org/soap/encoding/

• Чтобы использовать кодировку SOAP 1.2, используйте значение http://www.w3.org/2001/12/soap-encoding

• Последняя спецификация SOAP принимает все встроенные типы, определенные XML-схемой. Тем не менее, SOAP поддерживает свое собственное соглашение для определения конструкций, не стандартизированных XML-схемой, таких как массивы и ссылки.

Типы данных SOAP делятся на две широкие категории – скалярные типы и составные типы.

Скалярные типы содержат ровно одно значение, такое как фамилия, цена или описание продукта.

Составные типы содержат несколько значений, таких как заказ на покупку или список котировок акций.

Типы соединений далее подразделяются на массивы и структуры.

Стиль кодирования для сообщения SOAP устанавливается через атрибут SOAP-ENV: encodingStyle .

Чтобы использовать кодировку SOAP 1.1, используйте значение http://schemas.xmlsoap.org/soap/encoding/

Чтобы использовать кодировку SOAP 1.2, используйте значение http://www.w3.org/2001/12/soap-encoding

Последняя спецификация SOAP принимает все встроенные типы, определенные XML-схемой. Тем не менее, SOAP поддерживает свое собственное соглашение для определения конструкций, не стандартизированных XML-схемой, таких как массивы и ссылки.

Скалярные Типы

Для скалярных типов SOAP принимает все встроенные простые типы, указанные в спецификации XML-схемы. Это включает в себя строки, числа с плавающей запятой, двойные и целые числа.

В следующей таблице перечислены основные простые типы, взятые из XML-схемы, часть 0 – учебник http://www.w3.org/TR/2000/WD-xmlschema-0-20000407/.

Например, вот ответ SOAP с двойным типом данных –

<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope"
   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" 
   xmlns:xsd = "http://www.w3.org/2001/XMLSchema">
   
   <SOAP-ENV:Body>
      <ns1:getPriceResponse 
         xmlns:ns1 = "urn:examples:priceservice"  
         SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">
         <return xsi:type = "xsd:double">54.99</return>
      </ns1:getPriceResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Типы соединений

Массивы SOAP имеют очень специфический набор правил, которые требуют, чтобы вы указали как тип элемента, так и размер массива. SOAP также поддерживает многомерные массивы, но не все реализации SOAP поддерживают многомерную функциональность.

Чтобы создать массив, вы должны указать его как массив xsi: type . Массив также должен включать атрибут arrayType . Этот атрибут необходим для указания типа данных для содержащихся элементов и измерений массива.

Например, следующий атрибут задает массив из 10 двойных значений –

arrayType = "xsd:double[10]"

В противоположность этому следующий атрибут задает двумерный массив строк:

arrayType = "xsd:string[5,5]"

Вот пример ответа SOAP с массивом двойных значений:

<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" 
   xmlns:xsd = "http://www.w3.org/2001/XMLSchema">

   <SOAP-ENV:Body>
      <ns1:getPriceListResponse 
         xmlns:ns1 = "urn:examples:pricelistservice"  
         SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">

         <return xmlns:ns2 = "http://www.w3.org/2001/09/soap-encoding"  
            xsi:type = "ns2:Array" ns2:arrayType = "xsd:double[2]">
            <item xsi:type = "xsd:double">54.99</item>
            <item xsi:type = "xsd:double">19.99</item>
         </return>
      </ns1:getPriceListResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Структуры содержат несколько значений, но каждый элемент указан с уникальным элементом доступа. Например, рассмотрим элемент в каталоге продуктов. В этом случае структура может содержать SKU продукта, название продукта, описание и цену. Вот как такая структура будет представлена ​​в сообщении SOAP:

<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope"
   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" 
   xmlns:xsd = "http://www.w3.org/2001/XMLSchema">

   <SOAP-ENV:Body>
      <ns1:getProductResponse
         xmlns:ns1 = "urn:examples:productservice" 
         SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">
		
         <return xmlns:ns2 = "urn:examples" xsi:type = "ns2:product">
            <name xsi:type = "xsd:string">Red Hat Linux</name>
            <price xsi:type = "xsd:double">54.99</price>
            <description xsi:type = "xsd:string">
               Red Hat Linux Operating System
            </description>
            <SKU xsi:type = "xsd:string">A358185</SKU>
         </return>
      </ns1:getProductResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

ПРИМЕЧАНИЕ. – Пожалуйста, позаботьтесь о правильном отступе при написании кода SOAP. Каждый элемент в структуре указывается с уникальным именем доступа. Например, вышеприведенное сообщение включает в себя четыре элемента доступа – имя, цена, описание и артикул. Каждый элемент может иметь свой собственный тип данных. Например, имя указывается как строка, а цена указывается как двойная.

МЫЛО – Транспорт

SOAP не привязан ни к какому транспортному протоколу. SOAP может транспортироваться через SMTP, FTP, IBM MQSeries или Microsoft Message Queuing (MSMQ).

Спецификация SOAP содержит подробности только по HTTP. HTTP остается самым популярным транспортным протоколом SOAP.

SOAP через HTTP

Логично, что SOAP-запросы отправляются через HTTP-запрос, а SOAP-ответы возвращаются в содержимом HTTP-ответа. Хотя запросы SOAP можно отправлять через HTTP GET, в спецификации содержатся сведения только о HTTP POST.

Кроме того, как HTTP-запросы, так и ответы требуются для установки типа контента text / xml.

Спецификация SOAP требует, чтобы клиент предоставил заголовок SOAPAction, но фактическое значение заголовка SOAPAction зависит от реализации сервера SOAP.

Например, чтобы получить доступ к службе перевода AltaVista BabelFish, размещенной в XMethods, в качестве заголовка SOAPAction необходимо указать следующее.

urn:xmethodsBabelFish#BabelFish

Даже если серверу не требуется полный заголовок SOAPAction, клиент должен указать пустую строку (“”) или нулевое значение. Например –

SOAPAction: ""
SOAPAction:

Вот пример запроса, отправленного через HTTP в службу перевода XMethods Babelfish:

POST /perl/soaplite.cgi HTTP/1.0
Host: services.xmethods.com
Content-Type: text/xml; charset = utf-8
Content-Length: 538
SOAPAction: "urn:xmethodsBabelFish#BabelFish"

<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope/" 
   xmlns:xsi = "http://www.w3.org/1999/XMLSchema-instance"
   xmlns:xsd = "http://www.w3.org/1999/XMLSchema">

   <SOAP-ENV:Body>
      <ns1:BabelFish
         xmlns:ns1 = "urn:xmethodsBabelFish"
         SOAP-ENV:encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/">
         <translationmode xsi:type = "xsd:string">en_fr</translationmode>
         <sourcedata xsi:type = "xsd:string">Hello, world!</sourcedata>
      </ns1:BabelFish>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Обратите внимание на тип содержимого и заголовок SOAPAction. Также обратите внимание, что метод BabelFish требует двух параметров String. Режим перевода en_fr переводит с английского на французский.

Вот ответ от XMethods –

HTTP/1.1 200 OK
Date: Sat, 09 Jun 2001 15:01:55 GMT
Server: Apache/1.3.14 (Unix) tomcat/1.0 PHP/4.0.1pl2
SOAPServer: SOAP::Lite/Perl/0.50
Cache-Control: s-maxage = 60, proxy-revalidate
Content-Length: 539
Content-Type: text/xml

<?xml version = "1.0" encoding = "UTF-8"?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENC = "http://schemas.xmlsoap.org/soap/encoding/"
   SOAP-ENV:encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/"
   xmlns:xsi = "http://www.w3.org/1999/XMLSchema-instance"
   xmlns:SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:xsd = "http://www.w3.org/1999/XMLSchema">
   
   <SOAP-ENV:Body>
      <namesp1:BabelFishResponse xmlns:namesp1 = "urn:xmethodsBabelFish">
         <return xsi:type = "xsd:string">Bonjour, monde!</return>
      </namesp1:BabelFishResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Ответы SOAP, доставляемые через HTTP, должны следовать тем же кодам состояния HTTP. Например, код состояния 200 OK указывает на успешный ответ. Код состояния 500 Internal Server Error указывает, что произошла ошибка сервера и что ответ SOAP содержит элемент Fault.

SOAP – Примеры

В приведенном ниже примере запрос GetQuotation отправляется на сервер SOAP через HTTP. Запрос имеет параметр QuotationName , и в ответе будет возвращено предложение.

Пространство имен для функции определяется по адресу http://www.xyz.org/quotation .

Вот SOAP-запрос –

POST /Quotation HTTP/1.0
Host: www.xyz.org
Content-Type: text/xml; charset = utf-8
Content-Length: nnn

<?xml version = "1.0"?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope"
   SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">

   <SOAP-ENV:Body xmlns:m = "http://www.xyz.org/quotations">
      <m:GetQuotation>
         <m:QuotationsName>MiscroSoft</m:QuotationsName>
      </m:GetQuotation>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Соответствующий SOAP-ответ выглядит так:

HTTP/1.0 200 OK
Content-Type: text/xml; charset = utf-8
Content-Length: nnn

<?xml version = "1.0"?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope"
   SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">

   <SOAP-ENV:Body xmlns:m = "http://www.xyz.org/quotation">
      <m:GetQuotationResponse>
         <m:Quotation>Here is the quotation</m:Quotation>
      </m:GetQuotationResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

SOAP – Стандарты

SOAP 1.1 был первоначально представлен W3C в мае 2000 года. Официальными представителями были крупные компании, такие как Microsoft, IBM и Ariba, а также небольшие компании, такие как UserLand Software и DevelopMentor.

В июле 2001 года рабочая группа по протоколу XML выпустила «рабочий проект» SOAP 1.2. В рамках W3C этот документ официально находится в стадии разработки, что означает, что документ, вероятно, будет обновляться много раз, прежде чем будет завершен.

SOAP версии 1.1 доступен в Интернете по адресу http://www.w3.org/TR/SOAP/.

Рабочий проект SOAP версии 1.2 доступен по адресу http://www.w3.org/TR/soap12/.

Обратите внимание, что W3C также содержит представление для «SOAP-сообщений с вложениями», которое отделено от основной спецификации SOAP. Эта спецификация позволяет сообщениям SOAP включать двоичные вложения, такие как изображения и звуковые файлы. Для получения полной информации см. Примечание W3C по адресу http://www.w3.org/TR/SOAP-attachments .

Answer by Marco Kim

Internal Server Error usually means the server got your request but it did not like one of the parameters. ,

1

Actually, no. That’s why I removed it. A sequence is a structure telling those reading (you, a server, etc.) the WSDL that the order of elements inside it is important.

– Sergiu Paraschiv

Sep 13 ’13 at 22:53

,

I used to think that Internal Server Error meant that server was busy and could not handle my request.

– Abhishek Asthana

Sep 13 ’13 at 22:29

,
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Lookin at your WSDL I can see CelciusToFahrenheit expects one parameter with this definition:

<xs:complexType>
 <xs:sequence>
    <xs:element name="nCelcius" type="xs:decimal"/>
 </xs:sequence>
</xs:complexType>

A complex type is an object. So try this:

$SoapCallParameters = new stdClass();
$SoapCallParameters->nCelcius = 30;
$obj = $client->CelciusToFahrenheit($SoapCallParameters);

Answer by Amora Brewer

Internal Server Error usually means the server got your request but it did not like one of the parameters. ,Have you tried SoapClient which is already built into PHP?,Lookin at your WSDL I can see CelciusToFahrenheit expects one parameter with this definition:,There is one tutorial: PHP — Soap Client calling .NET Web service

    <?php
    error_reporting(E_ALL);
    ini_set('display_errors', '1');
        $url = "http://webservices.daehosting.com/services/TemperatureConversions.wso?WSDL";

        $client = new SoapClient($url, array("trace" => 1, "exception" => 0)); 

        var_dump($client->__getFunctions());

        $SOAPCall = "CelciusToFahrenheit";
        $SoapCallParameters = "30";
        $obj = $client->CelciusToFahrenheit($SoapCallParameters);
        var_dump($obj);

        var_dump($client->getLastRequest());
    ?>

</body>

When i execute i get the below error. I have looked in the Apache error logs and I see the same error.

Fatal error: Uncaught SoapFault exception: [HTTP] Internal Server Error in C:wampwwwphpSandboxindex.php:16 Stack trace: #0 [internal function]: SoapClient->__doRequest('<?xml version="...', 'http://webservi...', '', 1, 0) #1 C:wampwwwphpSandboxindex.php(16): SoapClient->__call('CelciusToFahren...', Array) #2 C:wampwwwphpSandboxindex.php(16): SoapClient->CelciusToFahrenheit('30') #3 {main} thrown in C:wampwwwphpSandboxindex.php on line 16

I know for sure that the soapClient library is activated because the following code work

var_dump($client->__getFunctions());

output:

array (size=4)
  0 => string 'CelciusToFahrenheitResponse CelciusToFahrenheit(CelciusToFahrenheit $parameters)' (length=80)
  1 => string 'FahrenheitToCelciusResponse FahrenheitToCelcius(FahrenheitToCelcius $parameters)' (length=80)
  2 => string 'WindChillInCelciusResponse WindChillInCelcius(WindChillInCelcius $parameters)' (length=77)
  3 => string 'WindChillInFahrenheitResponse WindChillInFahrenheit(WindChillInFahrenheit $parameters)' (length=86)

Answer by Dallas Gregory

Went to an error 500 in production server while using PHP SoapClient library to connect to some third-party API. The error was really strange, just error 500 and nothing more, even if you are using try catch, you won’t be able to catch and see the error.

The Example:,The problem of the SoapClient is that his temporary files are messed up somehow, maybe the PHP version was upgraded or maybe the /tmp dir was full on production and the server was not able to create new ones but yes, this is the problem.,So, the solution is simple, just delete all files from /tmp directory on the server that are starting with “wsdl-“ and the error will disappear., Save my name, email, and website in this browser for the next time I comment.

Went to an error 500 in production server while using PHP SoapClient library to connect to some third-party API. The error was really strange, just error 500 and nothing more, even if you are using try catch, you won’t be able to catch and see the error.

The Example:

try{
    $client = new SoapClient("https://api.thirdparty.com/some/service?wsdl", ['exceptions' => true, 'trace' => true]);
} catch(SoapFault $fault) {
    trigger_error("SOAP Fault: (faultcode: " . $fault->faultcode . ", faultstring: " . $fault->faultstring . ")", E_USER_ERROR);
} catch(Exception $e) {
    trigger_error("SOAP Error: " . $e->getMessage(), E_USER_ERROR);
}

Answer by Preston Savage

I’m trying to run soap server in laravel 5.2. I create wsdl file using piotrooi/wsdl-creator and create SoapServer object then handle it.
And my SoapClient can call it but returns an Internal Server Error Without logging in error-log file.
Here is my code:,Sorry @AliFarhoudi i beginner Laravel user,@AliFarhoudi dont fine work, Internal Error,class SoapController extends Controller {

<?php namespace GiantHttpControllers;

class SoapController extends Controller {

    public function __construct() {
        parent::__construct();
        ini_set('soap.wsdl_cache_enabled', 0);
        ini_set('soap.wsdl_cache_ttl', 0);
        ini_set('default_socket_timeout', 300);
        ini_set('max_execution_time', 0);
    }

    public function server() {
        $location = url('server'); // http://payment.dev/server
        $namespace = $location;
        $class = "\Giant\Http\Controllers\HelloWorld";

        $wsdl = new WSDLWSDLCreator($class, $location);
        $wsdl->setNamespace($namespace);

        if (isset($_GET['wsdl'])) {
            $wsdl->renderWSDL();
            exit;
        }

        $wsdl->renderWSDLService();

        $wsdlUrl = url('wsdl/server.wsdl');
        $server = new SoapServer(
            url('server?wsdl'),
            array(
                'exceptions' => 1,
                'trace' => 1,
            )
        );

        $server->setClass($class);
        $server->handle();
        exit;
    }

    public function client() {
        $wsdl = url('server?wsdl');
        $client = new SoapClient($wsdl);

        try {
            $res = $client->hello('world');
            dd($res);
        } catch (Exception $ex) {
            dd($ex);
        }
    }
}


class HelloWorld {
    /**
     * @WebMethod
     * @desc Hello Web-Service
     * @param string $name
     * @return string $helloMessage
     */
    public function hello($name) {
        return "hello {$name}";
    }
}

Answer by Arlo Mason

OK, so I’m trying to get the built-in PHP SoapClient to connect to a .Net ASMX web service. The server requires basic auth which the SoapClient supports, so it seems pretty straight forward.,Further more, using ‘http://soap.amazon.com/schemas3/AmazonWebServices.wsdl’ to test my script seems to work (no auth required).,Is there something I’m missing? Because I just can’t seem to get this to work.,I am working completely on the client side, so I don’t have access to the server code itself, but by visiting the page in my browser and typing in the user/pass, it all shows up correctly.

Here is my current PHP (minus the url, user, and pass):

<?php

$ini = ini_set("soap.wsdl_cache_enabled","0");

$url = 'https://<blah blah>.asmx?WSDL';
$options = array(
    'login'     => "<user>",
    'password'  => "<pass>"
);

$client = new SoapClient($url, $options);

var_dump($client->__getFunctions());

?>

I am trying to connect to an API using PHP and its built-in SoapClient. I have checked against the url I was given through the ill-formatted documents the client gave and $client->__getFunctions() returns a list of three functions. HelloWorld($name), which responds with Hello ~name~, shows me that I am communicating with the server through the SoapClient call and the URL is correct.

However, when I try to access one of the other methods that __getFunctions() gives me, even after copy/pasting the XML from the docs and putting in my own credentials, I am still being given an Internal Server Error faultstring and 500 as faultcode from the SoapFault object.

I am sure that it is my own XML string that is causing the issue but I cannot for the life of me figure out how. Reaching out to the API provider directly hasn’t proven helpful. This is my first time dealing with Soap/Web Services so I am unsure of where to go from here.

I did wget http//xxx.xxx.xxx?wsdl and it returned me what looks like a valid XML response, the same one I get when I go directly to the url in the browser. What should I be looking into in order to solve this issue? All of the past API’s I’ve dealt with have been JSON/RESTful so I feel out of my element trying to debug PHP errors.

Edit

I have slowly deleted parts of my method call and parts of my XML string, trying to trigger a different error or something in order to find what I need to fix. What I have found is that by not passing in my XML string, I get a valid response from the $client->FunctionCall(...). It’s an «this isn’t right» message but it’s a message! In fact, passing that function ANYTHING for the xml parameter causes the 500 http faultcode/faultstring. Does this mean that my XMl is poorly formatted or does it mean that there is an issue on their end handling requests?

Second Edit

If I make my $client decleration as follows, I get the faultstring Could not connect to host

$opts = array(
    'ssl' => array('ciphers'=>'RC4-SHA')
  );
$client = new SoapClient($CREDS['orderingWSDL'], array (
"encoding"=>"ISO-8859-1",
'stream_context' => stream_context_create($opts),
  'exceptions'=>true,
));

I am getting more confused the longer I try to fix this.

This chapter is from the book 

Error Handling in SOAP

So far in our examples everything has gone according to plan. Murphy’s Law guarantees that this is not how things work out in the real world. What would happen, for example, if partner A failed to authenticate with the partner gateway application? How will this exceptional condition be communicated via SOAP? The answer lies in the semantics of the SOAP Fault element.

Consider the following possible reply message caused by the authentication failure:

HTTP/1.0 500 Internal Server Error
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
         <faultcode>SOAP-ENV:Client.AuthenticationFailure</faultcode>
         <faultstring>Failed to authenticate client</faultstring>
         <faultactor>urn:X-SkatesTown:PartnerGateway</faultactor>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Before we look at the XML, note that the HTTP response code is 500 Internal Server Error. This is a required response in the case of any SOAP-related error by the HTTP transport binding as presented in the SOAP specification. Other protocols will have their own way to report errors. The HTTP SOAP binding is discussed in detail in the section «SOAP Protocol Bindings.»

The body of the response contains a single Fault element in the SOAP envelope namespace. SOAP uses this mechanism to indicate that an error has occurred and to provide some diagnostic information. There are three child elements.

The faultcode element must be present in all cases. It provides information that can be used to identify the specific error that occurred. It is not meant for human consumption. The content of the element is a string prefixed by one of the four faultcode values specified by SOAP:

• VersionMismatch indicates that the namespace of the Envelope element is invalid.

• MustUnderstand indicates that a required header entry was not understood.

• Client indicates that likely cause of the error lies in the content or formatting of the SOAP message. In other words, the client should probably not re-send the message without making some changes to it.

• Server indicates that the message failed due to reasons other than its content or its format. This leaves the door open for the same message to perhaps succeed at a later time.

A hierarchical namespace of values can be obtained by separating fault values with the dot (.) character. In our example, Client.AuthenticationFailure is a more specific fault code than Client.

The faultstring element contains a human-readable message identifying the cause of the fault. It must always be present. Here we simply state that the client has failed to authenticate.

The faultactor element provides information about where in the message path the fault occurred. It must be present if the failure occurred somewhere other than at the final destination of the SOAP message. The content of the element is the URI of the actor where the error occurred. In our example, we identify the partner gateway application as the failure point.

What is not shown in this example is how application-specific error diagnostic information can be exchanged. SOAP provides a simple mechanism for this, as well. If the fault occurred during the processing of the message body, an optional detail element can be added after faultactor. There are no restrictions on its contents. This rule has one important exception: If the fault occurred during the processing of a header entry, a detail element cannot be returned. Instead, the header entry should be returned with detailed error information contained therein. This is the mechanism SOAP uses to determine whether a fault was the result of header versus body processing.

SOAP Message Processing

Now that we have covered headers with mustUnderstand behavior, intermediaries, and error handling, we can completely define the rules for SOAP message processing. Upon receiving a message, a SOAP application must:

1. Determine whether it understands the version of SOAP that the message
   uses by inspecting the namespace value of the SOAP Envelope element.
   If the version is unknown, it must discard the message with a VersionMismatch
   error. Otherwise, it has to move to the next step.

2. Identify all parts of the message intended for the application. Typically
   this is done considering the application’s role in the message path (intermediary
   or final recipient) and the values of the actor global attribute, but other
   information can be taken into account as well.

3. Verify that all mandatory parts of the message identified in Step 2 are
   supported by the application. These include mustUnderstand headers
   and, in the case of a final recipient, the body. If any mandatory part cannot
   be supported, the message is discarded with a MustUnderstand error
   in the case of headers and an application-specific error in the case of
   bodies. Otherwise, the application will move to Step 4.

4. Process all mandatory parts identified in Step 2 plus any optional parts
   that it knows about.

5. If the application is not the final recipient of the message, it must
   remove all headers that it has processed before passing the message forward
   along its path.

Having covered the SOAP envelope framework, intermediaries, and error handling, it is now time to move to other areas of the SOAP specification.