مقدمه‌اى بر اصول SOAP

قسمت اول

نويسنده: Tarak Modi

JavaWorld

مترجم: شهناز پيروزفر

چكيده

SOAP يك برنامه كاربردي جديد توانمند نظير XML است كه مي‌تواند در دنياي برنامه نويسي توزيع شده به كار رود. اين مقاله كه قسمت اول از يكسري مقاله چهار قسمتي است، به معرفي اصول SOAP مي‌پردازد.

***

بسياري از توسعه دهندگان با اين مشكل مواجه هستند: كلاينت CORBA به تهيه سرويسهاي كلاينت (Distributed Component Object Model) DCOM نياز دارد و برعكس. راه كار متداول براي رفع مشكل اين است كه از پل ارتباطي COM/CORBA استفاده نماييم. با وجود اين، پاسخ مذكور از چند نظر با شکست مواجه مي‌شود. فرض كنيد شما يك بخش نرم‌افزار جديد در بين بخشهاي پيچيده قبلي (زير ساختار CORBA ORB و COM) اضافه نموده‌ايد. تفسير كامل از پروتكل CORBA (Internet Inter-ORB) IIOP به ORPC (Object Remote Procedure Call)، DCOM پيچيده به نظر مي‌رسد. ايجاد هر گونه تغيير در اين پروتكل به معناي ايجاد تغيير در اين پل ارتباطي است. اما SOAP مي‌تواند اين مشكل را حل كند.

(Simple Object Access Protocol) SOAP پروتكلي باسيم مشابه IIOP براي CORBA، يا ORPC براي DCOM و يا JRMP (Java Remote Method Protocol) براي RMI (Java Remote Method Invocation) مي‌باشد. شايد از خود بپرسيد با وجود اين همه پروتكل چرا به پروتكل ديگري نياز داريم. در واقع SOAP تا اندازه‌اي با ساير پروتكلهاي با سيم متفاوت است.

اجازه دهيد اين تفاوت را بررسي نماييم:

- در حاليكه IIOP، ORPC و JRMP پروتكلهاي باينري هستند، SOAP پروتكل مبتني بر متن است كه از XML استفاده مي‌كند. استفاده از XML براي encoding داده‌ها به SOAP توانايي‌هاي ويژه‌اي مي‌بخشد. براي نمونه، debug برنامه‌هاي كاربردي مبتني بر SOAP آسانتر است، زيرا خواندن XML راحتتر از خواندن يك رشته باينري است و از آنجاييكه همه اطلاعات موجود در SOAP به صورت متن است، SOAP فايروال پسند‌تر از IIOP، ORPC يا JRMP مي‌باشد.

- از آنجاييكه SOAP مبتني بر XML، HTTP و (Simple Mail Transfer Protocol) SMTP مي‌باشد، همه فروشندگان طالب آن هستند. براي نمونه، مايکروسافت خود را به SOAP مقيد نموده، همانند بسياري ديگر از فروشندگان که خود را به CORBA ORB مقيد نموده‌اند مثل Iona. IBM كه نقش عمده‌اي در مشخصه SOAP دارد، يك تول كيت عالي SOAP براي برنامه نويسان جاوا تهيه نموده است. IBM اين تول كيت را به پروژه XML بنياد نرم‌افزار آپاچي (Apache Software Foundation) اهدا کرده که Apache-SOAP را توليد کرده است. اين نسخه تحت گواهينامه Apache به رايگان در دسترس علاقمندان قرار دارد. به مشكل فوق باز مي‌گرديم، اگر DCOM و ORB از SOAP استفاده نمايند، مشكل مذكور به ميزان قابل ملاحظه‌اي كمتر مي‌شود.

SOAP تكنولوژي است كه به طور عميق در آينده محاسبات توزيع شده، جاي گرفته است. SOAP به همراه ساير تكنولوژي‌ها نظير Universal Discovery Description and Integration) UDDI و WSDL (Web Services Description Language)، نحوه برقراري ارتباط برنامه‌هاي تجاري را بر روي وب با سرويس‌هاي وب تغيير مي‌دهد.

درون SOAP

همانگونه كه در فوق اشاره شد، SOAP از XML به عنوان فرمت كدگذاري داده‌ها استفاده مي‌كند. فقط SOAP از XML استفاده نمي‌كند. XML-RPC و ebXML نيز XML را به كار مي‌گيرند.

رابط جاوا زير را در نظر بگيريد:

public interface Hello
{
public String sayHelloTo(String name);
}

ليست 1

كلاينتي كه متد SayHelloTo() را با يك نام فرا مي‌خواند، و انتظار دارد پيام "Hello" را از سرور دريافت نمايد. اينك تصور كنيد كه RMI، CORBA و DCOM وجود ندارند و فراخواني متد و ارسال آن به ماشين راه دور به شما بستگي دارد. حتما مي‌گوييد "از XML استفاده كنيم"، با شما موافقم. اجازه دهيد يك فرمت درخواست به سرور ارسال نماييم. فرض كنيد قصد داريم فراخواني SayHelloTo("John") را شبيه سازي كنيم، من پيشنهاد زير را دارم:

<?xml version="1.0"?>
<Hello>
    <sayHelloTo>
        <name>John</name>
    </sayHelloTo>
</Hello>

ليست 2

من نام رابط را به عنوان گره ريشه در نظر گرفتم. همچنين گره‌هاي اسامي متد و پارامتر را لحاظ نمودم. اينك بايد اين درخواست را به سرور بدهيم. به جاي ساخت پروتكل TCP/IP، از HTTP كمك مي‌گيريم. لذا گام بعدي بسته بندي درخواست به صورت درخواست HTTP Post و ارسال آن به سرور است.

در بخش بعدي مقاله درباره اين درخواست به تفصيل صحبت خواهم كرد. سرور، درخواست را دريافت، XML را كشف رمز و پاسخ را مجدد به صورت XML به كلاينت ارسال مي‌كند. فرض كنيد پاسخ به صورت زير باشد:

<?xml version="1.0"?>
<Hello>
    <sayHelloToResponse>
        <message>Hello John, How are you?</message>
    </sayHelloToResponse>
</Hello>

ليست 3

هنوز گره ريشه با نام رابط hello آمده است. اما به جاي نام متد، نام گره، SayhelloTo، نام متد به انضمام رشته Response مشاهده مي‌شود. كلاينت مي‌داند كه چه متدي را فرا خوانده است و براي يافتن پاسخ آن متد، به سادگي عنصري را كه به همراه نام متد و رشته Response است، جستجو مي‌كند.

من فقط ريشه‌هاي SOAP را معرفي نمودم. ليست 4 نحوه كد نويسي درخواست در SOAP را نشان مي‌دهد:

<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>
     </SOAP-ENV:Header>
    <SOAP-ENV:Body>
         <ns1:sayHelloTo
             xmlns:ns1="Hello"SOAP-ENV:encodingStyle="
              http://schemas.xmlsoap.org/soap/encoding/">
             <name xsi:type="xsd:string">John</name>
         </ns1:sayHelloTo>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

ليست 4

اين كد كمي پيچيده تر به نظر مي‌رسد، اينطور نيست؟ در واقع كد مذكور مشابه كد قبلي است و بهبودهايي در آن صورت گرفته است. اول اينكه، به نحوه سازماندهي دقيق سند SOAP در Envelope (گره ريشه)، بخش header و body توجه نماييد. بخش header براي محصور سازي داده‌هايي كه به متد خاصي متصل نيستند‌، به كار مي‌رود. اما در عوض دانش زمينه‌اي نظير ID ارتباط و اطلاعات امنيتي را فراهم مي‌آورد. بخش body حاوي اطلاعات ويژه متد است. در ليست 2‌، XML فقط بخش body داشت.

دوم اينكه‌، به استفاده از فضاي نام گسترده XML توجه نماييد. SOAP-ENV به فضاي نام http://schemas.xmlsoap.org/soap/envelope/، xsi به http://www.w3.org/1999/xmlschema-instance و xsd به http://www.w3.org/1999/xmlschema نگاشت مي‌شود. اينها فضاهاي نام استانداردي هستند كه همه اسناد SOAP دارند.

در نهايت، در ليست 4، نام رابط (مثلا Hello) به عنوان يك نام گره در مقايسه با آنچه در ليست 2 بود، طول عمر كمتري دارد، در عوض به فضاي نام ns1 رجوع مي‌كند. اطلاعات نوع نيز به همراه مقدار پارامتر به سرور ارسال مي‌گردد. به مقدار صفت encodingStyle در envelope توجه نماييد. اين مقدار به http://schemas.xmlsoap.org/soap/encoding/ ست مي‌شود. اين مقدار سرور را از سبك كد گذاري آگاه مي‌سازد، مثلا" سريال سازي–متد‌، سرور براي انجام موفقيت آميز كشف سريال متد به اين اطلاعات نياز دارد.

پاسخ به درخواست SOAP قبلي به صورت زير است:

<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:sayHelloToResponse xmlns:ns1="Hello"
          SOAP-NV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:string">Hello John, How are you doing?</return>
          </ns1:sayHelloToResponse>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

ليست 5

ليست 5 مشابه پيام درخواست ليست 4 است. در كد فوق پارامترهاي متد حاوي مقدار بازگشتي نيستند، -- در اين مثال پيام "hello" --.

فرمت سند انعطاف پذيراست. براي نمونه، سبك كد گذاري ثابت نيست، اما درعوض كلاينت آن را مشخص مي‌كند.

به علاوه جدا سازي اطلاعات زمينه فراخواني بدين معناست كه متد خودش با آن اطلاعات در ارتباط نيست. اكثر سرورهاي برنامه كاربردي در بازار امروزي از اين فلسفه تبعيت مي‌كنند. پيشتر اشاره نمودم كه دانش زمينه مي‌تواند شامل اطلاعات ارتباط و امنيتي باشد. در اينجا مثالي از SOAP header با برخي اطلاعات ارتباطي آمده است:

<SOAP-ENV:Header>
     <t:Transaction xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">
          5
     </t:Transaction>
</SOAP-ENV:Header>

ليست 6

فضاي نام t به برخي از URI‌هاي ويژه برنامه كاربردي نگاشت مي‌شود. 5، ID ارتباطي است. به استفاده از صفت mustUnderstand در SOAP envelope توجه نماييد. اين صفت به 1 ست شده است و بدين معناست كه سرور بايد درخواست ارتباط را درك و تاييد نمايد يا پردازش پيام را انجام ندهد.

هنگاميكه درخواست‌هاي SOAP با مشكل مواجه مي‌شوند

تنها به اين دليل كه از SOAP استفاده مي‌كنيد، همواره درخواست‌هايتان با موفقيت پاسخ داده نمي‌شوند. براي نمونه، شايد سرور درخواستتان را تاييد نكند، زيرا نمي‌تواند به يك منبع بحراني مثلا" پايگاه داده‌ها دسترسي پيدا كند.

اجازه دهيد به مثال "Hello" باز گرديم و محدوديتي را به آن بيفزاييم: گفتن سلام در روز سه شنبه مجاز نيست. لذا در روز سه شنبه حتي اگر درخواست ارسالي به سرور معتبر باشد، سرور پاسخ خطا به كلاينت باز مي‌گرداند. اين پاسخ به صورت زير است:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
   <SOAP-ENV:Fault>
       <faultcode>SOAP-ENV:Server</faultcode>
       <faultstring>Server Error</faultstring>
       <detail>
           <e:myfaultdetails xmlns:e="Hello">
           <message>
            Sorry, my silly constraint says that I cannot say hello on Tuesday.
           </message>
           <errorcode>
                   1001
           </errorcode>
           </e:myfaultdetails>
           </detail>
       </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

ليست 7

اجازه دهيد بر روي عنصر Fault كه در فضاي به نام http://schemas.xmlsoap.org/soap/envelope تعريف شده است، متمركز شويم. همواره همه سرورهاي SOAP بايد هر گونه شرط خطا را در آن عنصر باز گردانند و آن هميشه child مستقيم عنصر Body است. عنصر Fault بدون استثنا بايد عناصر faultcode و faultstring را دارا باشد. Faultcode، كدي است كه مي‌تواند مشكلات را شناسايي نمايد، نرم‌افزار Client-Side از Faultcode براي پردازش الگورتيميك استفاده مي‌كند. مشخصه SOAP، مجموعه كوچكي از كدهاي خطا را كه مي‌توانيد استفاده نماييد، تعريف مي‌كند، از سوي ديگر faultstring براي انسان تهيه شده است.

كد موجود در ليست 7، عنصر detail را نشان مي‌دهد. از آنجاييكه خطا در هنگام پردازش بخش body پيام SOAP روي مي‌دهد، عنصر detail بايد ارائه گردد. در ليست 7، برنامه كاربردي آن عنصر را براي توضيح مفصل‌تر ماهيت خطا، مورد استفاده قرار داد. كد خطاي ويژه برنامه كاربردي نيز همينطور ارائه مي‌شود: يك عنصر نيمه اختياري به نام Faultfactor كه من در پيام خطا نشان نداده‌ام. من آن را نيمه اختياري مي‌نامم، زيرا هنگامي لحاظ مي‌شود كه پيام خطا توسط سروري كه در نقطه پردازش پاياني درخواست قرار نداشت، ارسال گردد. SOAP وضعيتي را كه در آن عنصر Faultcode لحاظ نمي‌شود، مشخص نمي‌كند.

در ليست 7 برنامه كاربردي پردازش كننده متد سبب اين خطا شده است. اينك اجازه دهيد نوع ديگري از خطا را بررسي كنيم، خطايي كه در نتيجه عدم توانايي سرور براي پردازش اطلاعات header حاصل مي‌شود. به عنوان نمونه، فرض كنيد همه پيام‌هاي hello بايد در زمينه transaction توليد شوند. اين درخواست به صورت زير خواهد بود:

<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>
        <t:Transaction xmlns:t="some-URI"SOAP-ENV:mustUnderstand="1">
              5
         </t:Transaction>
     </SOAP-ENV:Header>
    <SOAP-ENV:Body>
         <ns1:sayHelloTo ns:ns1="Hello"

           SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
          <name xsi:type="xsd:string">Tarak</name>
         </ns1:sayHelloTo>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

ليست 8

بخش header پيام فوق عنصر transaction دارد، اين عنصر تعداد ارتباطي را كه متد بايد بخشي از آ ن باشد، مشخص مي‌كند. من از must استفاده نمودم، زيرا عنصر transaction صفت mustUnderstand را به كار مي‌برد. همانگونه كه پيشتر اشاره نمودم، سرور SOAP بايد آن را تاييد يا پردازش درخواست را رد نمايد. اجازه دهيد فرض كنيم كه سرور نمي‌تواند آن را تاييد و لذا درخواست را رد مي‌كند. در اينصورت پاسخ به صورت زير خواهد بود:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Body>
       <SOAP-ENV:Fault>
           <faultcode>SOAP-ENV:MustUnderstand</faultcode>
           <faultstring>SOAP Must Understand Error</faultstring>
       </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

ليست 9

كد فوق مشابه پيام خطاي ليست 7 است. اما توجه نماييد كه عنصر detail حضور ندارد. مشخصه SOAP مي‌گويد اين عنصر در صورتيكه خطا در هنگام پردازش header روي دهد، بايد ظاهر شود. در واقع حضور يا عدم حضور عنصر detail به شما مي‌گويد كه خطا در هنگام پردازش header روي داده يا body.

HTTP و SOAP

در اولين مثال، درخواست XML را از طريق HTTP به سرور ارسال نمودم. اجازه دهيد به آن مراجعه نماييم. چگونه مي‌توانم يك درخواست SOAP را بر روي HTTP به سرور ارسال نمايم؟ SOAP به طور طبيعي از مدل پيام درخواست/پاسخ HTTP تبعيت مي‌كند. اين مدل پارامترهاي درخواست SOAP را در پارامترهاي درخواست HTTP و پاسخ SOAP در پاسخ HTTP فراهم مي‌آورد.

در اين سري‌ها من فقط SOAP را در زمينه استفاده آن با HTTP مورد بحث قرار خواهم داد. اجازه دهيد به مثال hello باز گرديم. اگر ما درخواست SOAP را از طريق HTTP به سرور ارسال نماييم، كد آن به صورت زير خواهد بود:

POST http://www.SmartHello.com/HelloApplication HTTP/1.0
Content-Type: text/xml; charset="utf-8"
Content-Length: 587
SOAPAction: "http://www.SmartHello.com/HelloApplication#sayHelloTo"
<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>
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
      <ns1:sayHelloTo xmlns:ns1="Hello"
           SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
       <name xsi:type="xsd:string">Tarak</name>
       </ns1:sayHelloTo>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

ليست 10

ليست 10 همان درخواست SOAP موجود در ليست 4 را به همراه برخي كدهاي ويژه HTTP نشان مي‌دهد. خط اول مشخص مي‌كند كه اين يك درخواست POST است كه مطابق با قوانين هر HTTP 1.1 مي‌باشد. http://www.smarthello.com/helloapplication مقصد POST است. خط بعدي بيانگر نوع محتواست. محتوا بايد هنگام لحاظ شدن bodyهاي موجوديت SOAP در پيامهاي HTTP، text/xml باشد. طول محتوا، طول درخواست POST را مشخص مي‌كند.

خط چهارم ويژه SOAP اجباري است. فيلد header درخواست SOAPAction HTTP، هدف درخواست SOAP HTTP را تعيين مي‌كند. URI اين هدف را شناسايي مي‌كند. SOAP هيچگونه محدوديتي بر فرمت URI قرار نمي‌دهد.

فايروال از فيلد SOAPAction استفاده مي‌كند و با بازبيني مقدار فيلد درباره عبور يا عدم درخواست، تصميم مي‌گيرد.

به محض اينكه سرور درخواست را پردازش نمود، پاسخ را به كلاينتي كه شبيه ليست 11 است ( با فرض اينكه خطايي رخ نداده است)، باز مي‌گرداند.

HTTP/1.0 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: 615
<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:sayHelloToResponse xmlns:ns1="Hello"
            SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
         <return xsi:type="xsd:string">Hello John, How are you doing?</return>
         </ns1:sayHelloToResponse>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

ليست 11

اين پاسخ مشابه پاسخ SOAP در ليست 5 به همراه برخي كدهاي ويژه HTTP است. از آنجاييكه خطايي رخ نداده است، خط اول كد 200 را توليد مي‌كند كه در HTTP بدين معناست كه "مشكلي وجود ندارد" اگر هنگام پردازش پيام SOAP، خطايي روي دهد. كد بازگشتي 500 را توليد مي‌كند كه در HTTP به مفهوم "خطاي داخلي سرور است". لذا خط اول به صورت زير خواهد بود:

HTTP 500 Internal Server Error

چهارچوب گستره HTTP

بسياري از برنامه‌هاي كاربردي به سرويسهايي فراتر از آنچه HTTP سنتي فراهم مي‌آورند، نياز دارند. در نتيجه چنين برنامه‌هايي‌، پروتكل HTTP سنتي را بسط مي‌دهند. با وجود اين، چنين گستره‌هايي مختص برنامه كاربردي هستند. چهار چوب گستره HTTP سعي دارد اين مشكل را با توصيف مكانيسم جامع گستره براي HTTP رفع نمايد. چهارچوب مذكور متد M-POST را مي‌افزايد كه M به معناي اجبار است. درخواست HTTP درصورتي كه حداقل يك اعلان گستره اجباري داشته باشد، درخواست اجباري را فرا مي‌خواند.

اعلان گستره اجباري را مي‌توان با كمك فيلدهاي header، Man يا C-Man لحاظ نمود. نام متد درخواست اجبار بايد با پيشوند M- همراه باشد. لذا متد اجباري POST ، M-POST ناميده مي‌شود.

در SOAP 1.0 بايد كلاينت با درخواست HTTP POST غير فعال مي‌شد و درخواست M-POST را در صورتيكه سرور خطاي HTTP 5/0 را باز مي‌گرداند، ارسال مي‌نمود.

SOAP 1.1 چنين محدوديتي را براي كلاينت قرار نمي‌دهد. درخواست زير به صورت M-POST ارائه مي‌گردد:

M-POST http://www.SmartHello.com/HelloApplication HTTP/1.1
Content-Type: text/xml; charset="utf-8"
Content-Length: 587
Man: "http://schemas.xmlsoap.org/soap/envelope/"; ns=01
01-SOAPAction: "http://www.SmartHello.com/HelloApplication#sayHelloTo"
<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>
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
      <ns1:sayHelloTo xmlns:ns1="Hello"
          SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
      <name xsi:type="xsd:string">Tarak</name>
      </ns1:sayHelloTo>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

ليست 12

ليست 12 با ليست 10 تفاوتي ندارد. Header شامل چند بخش متفاوت است. براي نمونه، به جاي درخواست POST، درخواست M-POST را داريم. همانگونه كه در فوق بيان شد، هر درخواست HTTP اجباري نظير M-POST حداقل به يك اعلان گستره اجباري نياز دارد. در اين ليست چنين حالتي وجود دارد: فيلد Man يك اعلان گسترده اجباري end-to-end را توصيف نموده پسوند 01 را به فضاي نام http://schemas.xmlsoap.org/soap/envelope مي‌نگارد. به نحوه اتصال اين پيشوند به فيلد SOAPAction توجه نماييد.

به محض اينكه سرور درخواست را پردازش كند، پاسخ را به كلاينت باز مي‌گرداند و كد آن به صورت زير خواهد بود (با فرض اينكه خطايي رخ نداده است)

HTTP/1.0 200 OK
Ext:
Content-Type: text/xml; charset="utf-8"
Content-Length: 615
<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:sayHelloToResponse
            xmlns:ns1="Hello"
            SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
        <return xsi:type="xsd:string">Hello John, How are you doing?</return>
          </ns1:sayHelloToResponse>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

ليست 13

پاسخ در ليست 13 همانند --- درخواست POST ليست 11 است، به جز فيلد Ext.

در استفاده از SOAP از طريق HTTP، مشاهده مي‌نماييد كه پيام واقعي SOAP همواره مانند پيام باقي مي‌ماند، بدون پروتكل و مي‌توان اينگونه نتيجه گرفت كه HTTP تنها پروتكلي نيست كه SOAP با آن كار مي‌كند. براي نمونه،SOAP مي‌تواند به سادگي با SMTP يا هر پروتكل سفارشي كار كنند. و فقط بايد كلاينت و سرور پروتكل را درك نمايند.

SOAP هر چيزي را تعريف نمي‌كند

تا كنون جوانب مختلفي را كه SOAP تعريف مي‌كند، مورد بررسي قرار داديم، اما بخشهايي وجود دارند كه SOAP آنها را تعريف نمي‌كند. نويسندگان مشخصه SOAP به طور صريح جوانب سازنده مدل آبجكت و هر آنچه قبلا ساخته شده است را از اين مشخصه مستثني نمودند. دليل اين امر را بايد در اهداف SOAP جستجو كرد. هدف اصلي طراحي SOAP به جز بسط پذيري، ساده سازي نيز مي‌باشد. نويسندگان SOAP براي ساده نگهداشتن SOAP تصميم گرفتند فقط جوانبي را كه براي ساخت پروتكل بحراني هستند، تعريف نمايند. براي نمونه SOAP هيچ چيزي را درباره garbage collection توزيع شده، ارتباطات HTTP دو طرفه، پردازش Object-by-reference، pipeline يا no-object activation تعريف نمي‌كند. SOAP بايد ساده باشد پروتكلي كه توسعه دهنده بتواند طي چند روز با كمك هر زبان برنامه نويسي بر روي هر سيستم عاملي پياده سازي نمايد. وقتي با اين ديدگاه SOAP را مورد بررسي قرار مي‌دهيد، درمي‌يابيد كه مي‌تواند به سادگي با هر تكنولوژي موجود و براي ساخت سيستم‌هاي توزيع شده منطبق شود.

منابع

- The SOAP 1.1 specification at W3C:
http://www.w3.org/TR/SOAP/

- For more information about XML-RPC go to:
http://www.xmlrpc.com/

- For more information about ebXML go to:
http://www.ebxml.org/

- Learn more about the HTTP extension framework at:
http://www.normos.org/ietf/rfc/rfc2774.txt

- Sign up for the JavaWorld This Week free weekly email newsletter and keep up with what's new at JavaWorld:
http://www.idg.net/jw-subscribe