پروتکل دسترسی آسان به اشیاء

از ویکی‌پدیا، دانشنامهٔ آزاد.

در متن این مقاله از هیچ منبع و ماخذی نام برده نشده‌است. شما می‌توانید با افزودن منابع بر طبق اصول اثبات‌پذیری و شیوه‌نامهٔ ارجاع به منابع، به ویکی‌پدیا کمک کنید. مطالب بی‌منبع احتمالاً در آینده حذف خواهند‌ شد.

با استفاده از پروتکل دسترسی آسان به اشیاء یا سُوپ (Simple Object Access Protocol - SOAP) می‌توان به ارسال و تبادل پیامهایی از جنس اکس‌ام‌ال بر روی شبکه‌های رایانه‌ای مبادرت کرد.

[ویرایش] کاربرد

این پروتکل برای تبادل پیغامهای مبتنی بر اکس‌ام‌ال در میان شبکه‌های کامپیوتری است که معمولا از HTTP/HTTPS استفاده می‌کند. سُوپ لایه زیر بنای پشته خدمات وب را تشکیل می‌دهد که یک چارچوب پیغام دهی ایجاد می‌کند که لایه‌های مجرد بیشتری می‌توانند بر روی آن ایجاد شوند.

طرحهای پیغام دهی مختلفی در سُوپ موجودند که معمول ترین آنها طرح remote procedure call می‌باشد و بدین گونه‌است که یک گره شبکه (مشتری) یک پیغام درخواست را به گره دیگر (سرور) می‌فرستد و سرور به سرعت یک پیغام پاسخ را به مشتری می‌فرستد. SOAP جانشین XML-RPC می‌باشد که خنثی بودن درمورد انتقال و تبادل را از آن و پوشش/سرفصل/بدنه را از جای دیگر (معمولا WDDX) به عاریه گرفته‌است.

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

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

اکس‌ام‌ال بعنوان فرمت استاندارد پیغامها انتخاب شده‌است چونکه بطور گسترده‌ای توسط موسسات بزرگ و موارد کد باز مورد استفاده قرار می‌گیرد. بعلاوه، تعداد زیادی از ابزارهایی که بطور رایگان در دسترس هستند، بطور مشهود سبب راحتی تبدیل به یک کاربری‌های مبتنی بر سُوپ می‌شود.

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

[ویرایش] نقاط قوت

• استفاده از سُوپ روی HTTP در مقایسه با تکنولوژیهای اجرایی قبلی، سبب تسهیل ارتباط در پس پراکسی‌ها و فایروال‌ها می‌شود.

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

[ویرایش] نقاط ضعف

• به علت فرمت طولانی اکس‌ام‌ال، سُوپ می‌تواند بطور قابل ملاحظه‌ای نسبت به تکنولوژیهای میان افزار رقیب مانند CORBA کندتر باشد. این مساله هنگامی که پیغامهای کوتاه تبادل می‌شوند، چندان قابل توجه نیست. از سوی دیگر، سُوپ دارای مکانیسم بهینه سازی انتقال پیغام می‌باشد.

• بسیاری از کاربری‌های سُوپ مقدار داده‌هایی را که باید فرستاده شود، محدود می‌کنند.

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