آشنایی با پروتکل دسترسی آسان به اشیاء (Simple Object Access Protocol - SOAP)

SOAP توان استفاده از یک پروتکل لایه کاربرد اینترنت را بعنوان یک پروتکل انتقال، ایجاد می‌کند. انتقاداتی مطرح شده‌است مبنی براین که این کار یک جور سوء استفاده از چنین پروتکل‌هایی می‌باشد، چون این هدفی نبوده‌است که برایش در نظر گرفته شده باشد و بنابراین نمی‌تواند به خوبی از عهده این نقش برآید. اما طرفداران SOAP تناسب را در استفاده موفق از پروتکلها در سطوح مختلف برای tunneling سایر پروتکلها، گوشزد کرده‌اند.

SMTP و HTTP هردو پروتکلهای مجاز لایه کاربرد هستند که بعنوان انتقال برای SOAP استفاده شده‌اند اما از آنجا که HTTP بخوبی با زیر ساختهای امروزی اینترنت کار می‌کند، بیشتر مورد پذیرش قرار گرفته‌است، بویژه اینکه SOAP بخوبی با دیوارهای آتش کار می‌کند. SOAP می‌تواند بر روی HTTPS نیز استفاده شود (چونکه آن هم دارای پروتکل مشابه HTTP در لایه کاربرد است ولی در زیر آن از پروتکل انتقال انکریپت شده استفاده می‌کند.). این متد مورد نظر WS-I برای ایجاد امنیت در سرویس‌های وب است. این یک پیشرفت بزرگ در برابر سایر پروتکلهای منتشری چون GIOP/IIOP یا DCOM است که بطور طبیعی توسط firewallها فیلتر می‌شوند.
XML بعنوان فرمت استاندارد پیغامها انتخاب شده‌است چون بطور گسترده‌ای توسط موسسات بزرگ و موارد کد باز مورد استفاده قرار می‌گیرد. بعلاوه، تعداد زیادی از ابزارهایی که بطور رایگان در دسترس هستند، بطور مشهود سبب راحتی تبدیل به یک کاربری‌های مبتنی بر SOAP می‌شود.

ترکیب نحوی عمدتا طولانی XML می‌تواند هم حسن باشد و هم نقص. فرمت آن برای انسانها قابل خواندن است اما می‌تواند پیچیده باشد و زمان پردازش آن آهسته باشد. به عنوان مثالCORBA ، GIOP ، ICE و DCOM از فرمتهای پیغام باینری کوتاهتر استفاده می‌کنند. از طرفی، وسایل سخت افزاری در دسترس هستند تا پردازش پیغامهای XML را تسهیل کنند.

• استفاده از SOAP روی HTTP در مقایسه با تکنولوژیهای اجرایی قبلی، سبب تسهیل ارتباط در پس پراکسی‌ها و فایروال‌ها می‌شود.
• SOAP به حدی فراگیر است که استفاده از پروتکلهای انتقال مختلف را مقدور می‌سازد. Strackهای استاندارد از HTTP بعنوان یک پروتکل انتقال استفاده می‌کنند اما از سایر پروتکلها نیز می‌توان استفاده نمود (TCP, SNMP).

• به علت فرمت طولانی XML، SOAP می‌تواند بطور قابل ملاحظه‌ای نسبت به تکنولوژیهای میان افزار رقیب مانند CORBA کندتر باشد. این مساله هنگامی که پیغامهای کوتاه تبادل می‌شوند، چندان قابل توجه نیست. از سوی دیگر، SOAP دارای مکانیسم بهینه سازی انتقال پیغام می‌باشد.
• بسیاری از کاربری‌های SOAP مقدار داده‌هایی را که باید فرستاده شود، محدود می‌کنند.
• اکثر استفاده‌ها از HTTP به عنوان یک پروتکل انتقال، با چشم پوشی از این مساله که چگونه این عمل در HTTP مدل بندی می‌شود، انجام می‌گیرد. این چشم پوشی به عمد انجام می‌گیرد (با قیاس به اینکه چگونه پروتکلهای مختلف در IP stack بر روی همدیگر می‌نشینند) اما این قیاس ناقص است (چون پروتکلهای application استفاده شده بعنوان پروتکلهای انتقال، در واقع پروتکلهای انتقال نیستند). به همین دلیل راهی وجود ندارد که بدانیم آیا متد استفاده شد برای عمل مورد نظر مناسب است یا خیر. این مساله، تحلیل درست عملیات را در سطح application-protocol با مشکل مواجه می‌سازد که در بهترین وجهش به سبب نتایج غیر بهینه‌است (اگر اتصالات مبتنی بر POST برای یک application استفاده شده‌است که در HTTP ممکن است بطور خنثی تر بعنوان عملیات GET مدل بندی شده باشد) و می‌تواند دارای باگ باشد (اگر بعنوان مثال اتصالات مبتنی بر GET برای عملیاتی استفاده شده باشد که دارای idempotency مورد نیاز GET نباشد.)