پروتکل دسترسی به شی ساده (SOAP) - توضیحات کلی. پروتکل SOAP مفاهیم اساسی. ساختار پیام SOAP

برچسب بعدی است . (ما برچسبی را که در اینجا نشان داده نشده بود حذف کردیم - . در این مثال خاص وجود ندارد، اما اگر می‌خواهید در مورد آن بیشتر بخوانید، مشخصات SOAP را در اینجا بررسی کنید: http://www.w3.org/TR/SOAP/. برچسب بزنید در واقع شامل یک تماس SOAP است.

تگ بعدی در لیست − است . نام تگ، GetStockQuote، تابعی است که باید فراخوانی شود. با توجه به اصطلاحات SOAP، این عملیات نامیده می شود. بنابراین GetStockQuote عملیاتی است که باید انجام شود. ns1 فضای نامی است که در مورد ما به urn:xmethods-quotes اشاره می کند.

یک یادداشت جانبی در مورد فضاهای نام: فضای نام به شما امکان می دهد یک برچسب XML را واجد شرایط کنید. شما نمی توانید مثلاً دو متغیر با نام یکسان در یک رویه داشته باشید، اما اگر در دو رویه متفاوت باشند، مشکلی وجود ندارد. بنابراین، یک رویه یک فضای نام است، زیرا همه نام های موجود در آن منحصر به فرد هستند. به طور مشابه، تگ‌های XML در داخل فضاهای نام قرار می‌گیرند، بنابراین با توجه به فضای نام و نام تگ، می‌توان آن را به‌طور منحصربه‌فرد شناسایی کرد. ما یک فضای نام را به عنوان URI تعریف می کنیم تا NS1 خود را از نسخه های کپی آن متمایز کنیم. در مثال بالا، NS1 یک نام مستعار است که به urn:xmethods-quotes اشاره می کند.

همچنین به ویژگی encodingStyle توجه کنید - این ویژگی مشخص می کند که چگونه فراخوانی SOAP سریالی می شود.

داخل تگ شامل پارامترها در ساده ترین حالت ما، ما فقط یک پارامتر داریم - تگ . به این خط در کنار تگ توجه کنید:
xsi:type="xsd:string"
این تقریباً چگونه XML انواع را تعریف می کند. (توجه داشته باشید که من چقدر هوشمندانه از کلمه "تقریبا" هنگام تعمیم در مورد فناوری استفاده کردم که ممکن است پس از انتشار مقاله تغییر کند.) این دقیقا به چه معناست: نوع تعریف شده در فضای نام xsi، که متوجه شده اید در تگ تعریف شده است. – xsd:string. و این، به نوبه خود، رشته ای است که در فضای نام xsd تعریف شده است، دوباره قبلاً تعریف شده است. (مطمئنم که وکلا از این همه هیجان زده خواهند شد).

داخل تگ "IBM" فهرست شده است. این مقدار پارامتر نماد تابع GetStockQuote است.

خب بالاخره مثل آدم های آبرومند همه تگ ها را بستیم.

بنابراین ما بسته SOAP را کشف کردیم که تماس با سرور SOAP را تعریف می کند. و سرور SOAP با استفاده از تجزیه کننده‌های XML، یک دکمه قرمز و ایستگاه فضایی MIR، این تماس را رمزگشایی می‌کند و تعیین می‌کند که شما نیاز به قیمت سهام دارید. بلافاصله مظنه مورد نیاز را پیدا کرده و در این فرم به شما برمی‌گرداند:
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>


34.5


پس از باز کردن پاکت SOAP، پاره کردن روبان ها و خش خش لفاف، متوجه می شویم که قیمت یک سهم IBM 34.5 است.

اکثر سرورهای تجاری اطلاعات بسیار بیشتری را برمی‌گردانند، مانند اینکه آخرین سهم با چه ارزی و با چه قیمتی خریداری شده است. و قیمت سهم، شاید دقیق تر باشد.

به این ترتیب ما می دانیم که سرور SOAP چه انتظاری دارد و چه چیزی را برمی گرداند. بنابراین چگونه این اطلاعات را ارسال می کنید؟ از هر نوع حمل و نقلی می توان استفاده کرد. بیشترین روشنایی HTTP است. من وارد جزئیات HTTP نمی شوم، برای کسانی که نمی دانند، این چیزی است که مرورگر شما برای برقراری ارتباط با سایت هایی که بازدید می کنید استفاده می کند.

درخواست HTTP مورد نظر چیزی شبیه به این خواهد بود:
POST /StockQuote HTTP/1.1
میزبان: www.stockquoteserver.com

طول محتوا: nnnn
SOAPAction: "Some-URI"

بسته درخواست صابون در اینجا... تنها مورد دیگری که باید به آن توجه داشت هدر SOAPAction است. این هدر هدف درخواست را نشان می دهد و مورد نیاز است. هر سرور SOAP می تواند تعداد نامحدودی توابع داشته باشد و می تواند از هدر SOAPAction برای تعیین اینکه کدام تابع فراخوانی می شود استفاده کند. فایروال ها و مالتی پلکسرها نیز می توانند محتوا را بر اساس این هدر فیلتر کنند.

پاسخ SOAP از سرورهای HTTPبه این صورت خواهد بود:
HTTP/1.1 200 OK
نوع محتوا: text/xml; charset = "utf-8"
طول محتوا: nnnn

بسته پاسخ صابون در اینجا... چرا HTTP؟ اولاً، مدیران شبکه نیازی به باز کردن تعداد زیادی پورت مجزا برای تماس های SOAP ندارند... وب سرور می تواند تماس ها را در آرامش انجام دهد، زیرا پورت 80 معمولاً برای دریافت درخواست های دریافتی برای همه باز است. مزیت دیگر توسعه پذیری سرورهای وب با استفاده از CGI، ISAPI و سایر ماژول های بومی است. این توسعه پذیری به شما امکان می دهد ماژولی بنویسید که درخواست های SOAP را بدون تأثیرگذاری بر سایر محتوای وب مدیریت می کند.

همین

امیدوارم این مقاله به روشن کردن SOAP کمک کرده باشد. اگر هنوز اینجا هستید و می خواهید در مورد این موضوع بیشتر بخوانید، به سایت نویسنده مراجعه کنید: http://www.agnisoft.com/soap

تاریخچه خلقت

با ظهور کامپیوترهای شخصیهمچنین نیاز به ترکیب آنها وجود داشت. ابتدا اتصالات کابلی ساده ای وجود داشت، سپس پروتکل های شبکه ظاهر شد که رایانه های یکپارچه که بر روی یک سیستم عامل کار می کردند، با توسعه فناوری، نیازی به داشتن یک سیستم عامل در همه رایانه ها وجود نداشت و امکان ترکیب رایانه های در حال اجرا تحت سیستم عامل های مختلف وجود داشت. اینترنت سرعت حرکت در مسیر اتحاد را تغییر داده است.

اما حتی امروز، همه مشکلات یکپارچه سازی حل نشده است، متاسفانه هیچ پروتکل واحدی برای ارتباط بین برنامه ها و سرویس های اینترنتی وجود نداشت. برای حل این مشکل، شرکت هایی مانند مایکروسافت، DevelopMentor، UserLand Software، IBM و Lotus Development با هم همکاری کردند و در نتیجه فعالیت های مشترک آنها، (Simple Object Access Protocol) یک پروتکل دسترسی ساده به اشیا است که یک کنترل از راه دور را توصیف می کند. فراخوانی استاندارد بر اساس XML (زبان نشانه گذاری توسعه پذیر) - زبان نشانه گذاری توسعه پذیر). SOAP برای ساده سازی توسعه برنامه های کاربردی بین زبانی و ابزارهای یکپارچه سازی تجاری تا حد امکان طراحی شده است. آغاز کار توسط SOAP 1.0 گذاشته شد که برای کار کردن به پروتکل HTTP نیاز داشت.

پس از ظهور نسخه اولیه SOAP، که همانطور که قبلا ذکر شد، با تلاش مشترک مایکروسافت، DevelopMentor و UserLand ایجاد شد، IBM و Lotus به توسعه محصول پیوستند. در نتیجه، این مشخصات دستخوش طراحی مجدد قابل توجهی شده است و برای ادغام محیط‌های ناهمگن مناسب‌تر است. تفاوت اصلی بین نسخه بعدی SOAP 1.1 و نسخه اولیه، انتقال از XML-Data مایکروسافت به XML Schema بود. علاوه بر این، در نسخه جدید، مشخصات به پروتکل های حمل و نقل بستگی ندارد. SOAP 1.0 برای کار کردن به HTTP نیاز داشت، در حالی که SOAP 1.1 به نوع حمل و نقل اهمیتی نمی داد: می توانید استفاده کنید پست الکترونیکیا اشاره گر به صف های پیام (پیوندهای queving ماساژ). شرکت‌هایی که قبلاً SOAP 1.0 را پذیرفته‌اند، خود را به فناوری غیراستاندارد مایکروسافت وابسته‌اند. با این حال، تعدادی از محصولات امیدوارکننده این شرکت، از جمله BizTalk Server و SQL Server 7.0 نیز به XML-Data متکی هستند. با ظهور نسخه 1.1، دایره حامیان پروتکل SOAP در حال گسترش است

SOAP اولیه 1.1 به Task Force ارسال شد پشتیبانی فنیاینترنت IETF بر اساس فناوری XML-Data پیشنهاد شده توسط مایکروسافت در ژانویه 1998 بود. با این حال، در فرآیند در نظر گرفتن استانداردها در کنسرسیوم W3C ساختار اساسیبا XML Schema جایگزین شده است. از کنسرسیوم وب جهانی خواسته شده است تا SOAP 1.1 را به عنوان یک استاندارد بالقوه در نظر بگیرد.

آخرین نسخه مشخصات پروتکل دسترسی به شیء ساده (SOAP) در سرور وب که به اعضای برنامه توسعه دهنده MSDN™ خدمت می کند (http://msdn.microsoft.com/) موجود است. SOAP یک پروتکل باز و مبتنی بر استاندارد است که یک قالب مشترک مبتنی بر XML (زبان نشانه گذاری توسعه پذیر) را برای ارتباط بین هر برنامه و سرویس اینترنتی تعریف می کند. این نسخه قابلیت‌های SOAP را در ارتباطات ناهمزمان گسترش می‌دهد تا نه تنها از HTTP، بلکه از پروتکل‌های اینترنتی مانند SMTP، FTP و TCP/IP پشتیبانی کند. آخرین نسخه مشخصات SOAP پشتیبانی گسترده ای از شرکت هایی مانند ActiveState Tool Corp.، Ariba Inc.، BORN Information Services Inc.، Commerce One Inc.، Compaq Computer Corp.، DevelopMentor Inc.، Extensibility Inc.، IBM، دریافت کرده است. IONA Technologies PLC، Intel Corp.، Lotus Development Corp.، ObjectSpace Inc.، Rogue Wave Software Inc.، Scriptics Corp.، Secret Labs AB، UserLand Software و Zveno Pty. Ltd. مشخصات SOAP یک مکانیسم مشترک برای یکپارچه سازی خدمات در سراسر اینترنت و/یا اینترانت، بدون توجه به سیستم عامل، مدل شی یا زبان برنامه نویسی ارائه می دهد. بر اساس استانداردهای اینترنت XML و HTTP، پروتکل SOAP اجازه هرگونه یا جدید را می دهد برنامه های کاربردی موجود. وب‌سایت‌هایی که از SOAP پشتیبانی می‌کنند می‌توانند به سرویس‌های وب تبدیل شوند که صرفاً به صورت برنامه‌نویسی قابل دسترسی هستند و نیازی به دخالت انسانی ندارند. یک زیرساخت واحد که تعامل مستقیم بین برنامه‌های کاربردی متصل به اینترنت را فراهم می‌کند، فرصت‌های جدیدی را برای یکپارچه‌سازی سرویس‌ها و دستگاه‌ها - بدون توجه به جایی که آنها در اینترنت هستند، باز می‌کند.

خدمات وب و SOAP

وب سرویس ها و SOAP برای حل مشکلات تعامل بین پلتفرمی برنامه طراحی شده اند. این مقاله به شما کمک می کند تا در مورد این فناوری های نویدبخش جدید ایده بگیرید.

SOAP چیست؟

فن‌آوری‌های فراخوانی روش راه دور (DCOM، CORBA/IIOP و RMI) در حال حاضر در تنظیم و سازمان‌دهی تعامل بسیار پیچیده هستند. این مستلزم مشکلاتی در عملکرد و عملکرد سیستم های توزیع شده (مسائل امنیتی، حمل و نقل از طریق فایروال ها و غیره) است. مشکلات موجود با ایجاد SOAP (Simple Object Access Protocol)، یک پروتکل ساده مبتنی بر XML برای پیام رسانی در محیط های توزیع شده (WWW) با موفقیت حل شده است. برای ایجاد خدمات وب و روش های تماس از راه دور در نظر گرفته شده است. SOAP را می توان با انواع پروتکل های انتقال از جمله HTTP، SMTP و غیره استفاده کرد.

وب سرویس چیست؟

وب سرویس ها عملکرد و داده هایی هستند که برای استفاده توسط برنامه های کاربردی خارجی که از طریق پروتکل های استاندارد و فرمت های داده با سرویس ها تعامل دارند، ارائه می شوند. وب سرویس ها کاملا مستقل از زبان و پلت فرم پیاده سازی هستند. فناوری خدمات وب سنگ بنای آن است مدل برنامهمایکروسافت دات نت برای نشان دادن قدرت SOAP، من از اجرای SOAP Toolkit نسخه 2.0 مایکروسافت که اخیراً منتشر شده است استفاده کردم. لازم به ذکر است که نسخه فعلی Toolkit به طور قابل توجهی با قبلی متفاوت است (Microsoft SOAP Toolkit for استودیوی تصویری 6.0) و از SOAP Toolkit 2.0 بتا.

مکانیسم تعامل بین مشتری و سرور

1. برنامه کلاینت شی SOAPClient را نمونه سازی می کند
2. SOAPClient فایل های توضیحات روش وب سرویس (WSDL و Web Services Meta Language - WSML) را می خواند. این فایل‌ها را می‌توان روی کلاینت نیز ذخیره کرد.
3. برنامه مشتری، با استفاده از قابلیت‌های اتصال دیرهنگام متدهای شی SOAPClient، متد سرویس را فراخوانی می‌کند. SOAPClient یک بسته درخواست (SOAP Envelope) تولید می کند و آن را به سرور ارسال می کند. امکان استفاده از هر کدام وجود دارد پروتکل حمل و نقل، اما معمولا از HTTP استفاده می شود.
4. بسته یک برنامه سرور شنونده را می گیرد (می تواند یک برنامه ISAPI یا یک صفحه ASP باشد)، یک شی SOAPServer ایجاد می کند و بسته درخواست را به آن ارسال می کند.
5. SOAPServer توضیحات سرویس وب را می خواند، توضیحات و بسته درخواست را در درختان XML DOM بارگیری می کند
6. SOAPServer متدی را روی شی/برنامه ای فراخوانی می کند که سرویس را پیاده سازی می کند
7. نتایج اجرای روش یا شرح خطا توسط شی SOAPServer به یک بسته پاسخ تبدیل شده و برای مشتری ارسال می شود.
8. شی SOAPClient بسته دریافتی را تجزیه می کند و برمی گرداند برنامه مشترینتایج سرویس یا شرح خطای رخ داده است.

یک فایل WSDL یک سند XML است که روش های ارائه شده توسط وب سرویس را توصیف می کند. همچنین پارامترهای متد، انواع آنها، نام ها و محل Listener سرویس. جادوگر SOAP Toolkit به طور خودکار این سند را تولید می کند.

SOAP Envelope (Package) - یک سند XML که حاوی یک درخواست/پاسخ برای اجرای یک روش است. راحت تر است که آن را به عنوان یک پاکت پستی در نظر بگیرید که اطلاعات در آن محصور شده است. تگ Envelope باید عنصر ریشه بسته باشد. عنصر Header اختیاری است و Body باید وجود داشته باشد و فرزند مستقیم عنصر Envelope باشد. در صورت خطای اجرای روش، سرور بسته ای حاوی عنصر Fault در تگ Body ایجاد می کند که حاوی توضیحات مفصلی از خطا است. اگر از رابط‌های سطح بالا SOAPClient، SOAPServer استفاده می‌کنید، لازم نیست وارد پیچیدگی‌های قالب بسته شوید، اما در صورت تمایل، می‌توانید از رابط‌های سطح پایین استفاده کنید یا حتی بسته را «با دست» ایجاد کنید. .

مدل شیء SOAP Toolkit کار با اشیاء API سطح پایین را ممکن می سازد:

• SoapConnector - یک پروتکل حمل و نقل برای تبادل بسته های SOAP ارائه می دهد
• SoapConnectorFactory - روشی برای ایجاد کانکتور برای پروتکل حمل و نقل مشخص شده در فایل WSDL (برچسب) ارائه می دهد.
• SoapReader - پیام های SOAP را می خواند و درختان XML DOM را می سازد
• SoapSerializer - شامل روش هایی برای ایجاد پیام SOAP است
• IsoapTypeMapper، SoapTypeMapperFactory - رابط هایی که به شما امکان می دهد با انواع داده های پیچیده کار کنید

با استفاده از اشیاء API سطح بالا، شما فقط می توانید داده ها را از انواع ساده (int، srting، float ...) انتقال دهید، اما مشخصات SOAP 1.1 به شما امکان می دهد با انواع داده های پیچیده تر، مانند آرایه ها، ساختارها، لیست ها و ... کار کنید. ترکیبات آنها برای کار با چنین انواعی، باید از رابط های IsoapTypeMapper و SoapTypeMapperFactory استفاده کنید.

• آموزش

سلام به همه!
اینطور شد که در اخیرامن شروع به توسعه خدمات وب کردم. اما امروز موضوع در مورد من نیست، بلکه در مورد این است که چگونه می توانیم وب سرویس XML خود را بر اساس پروتکل SOAP 1.2 بنویسیم.

امیدوارم پس از مطالعه موضوع بتوانید:

• پیاده سازی سرور خود را از یک برنامه وب بنویسید.
• پیاده سازی مشتری خود را از یک برنامه وب بنویسید.
• شرح خدمات وب خود را بنویسید (WSDL).
• آرایه هایی از همان نوع داده را توسط مشتری به سرور ارسال می کند.

1 بیان مشکل

1.1 مرزها

1.2 چه داده هایی تغییر خواهند کرد؟

• برای ارسال پیامک به مشترک چه حداقل داده هایی باید به سرور ارسال شود؟
• حداقل مقدار داده ای که باید از سرور ارسال شود تا نیازهای مشتری را برآورده کند چقدر است؟

• شماره تلفن همراه و
• متن اس ام اس.

• تاریخ ارسال پیامک

• نوع پیام

و با این حال، من چیزی را فراموش کردم! اگر کمی بیشتر تأمل کنیم، شایان ذکر است که مشتری می تواند در هر بار یک پیام کوتاه یا تعداد معینی از آنها را به سرور ارسال کند. به عبارت دیگر، در یک بسته داده می تواند از یک تا بی نهایت پیام وجود داشته باشد.

در نتیجه، دریافتیم که برای ارسال پیامک به داده های زیر نیاز داریم:

• شماره موبایل،
• متن اس ام اس،
• زمان ارسال پیامک به مشترک،
• نوع پیام

ما به سوال اول پاسخ دادیم، حال باید به سوال دوم پاسخ داد. و شاید به خودم اجازه بدهم کمی تقلب کنم. بنابراین، از سرور فقط داده های بولی ارسال می کنیم که مقدار آنها به این معنی است:

• درست - بسته با موفقیت به سرور رسیده است، احراز هویت را پشت سر گذاشته و برای ارسال به ارائه دهنده پیامک در صف قرار گرفته است.
• نادرست - در همه موارد دیگر

این توضیح بیان مشکل را به پایان می رساند! و در نهایت، بیایید به جالب ترین بخش برسیم - متوجه خواهیم شد که این صابون چه نوع جانوری عجیب و غریب است!

2 SOAP چیست؟

و من داستان خود را با این واقعیت شروع می کنم که این پروتکل تبادل داده متعلق به زیر مجموعه ای از پروتکل های مبتنی بر پارادایم به اصطلاح RPC (Remote Procedure Call) است که پاد پاد آن REST (انتقال حالت نمایندگی، انتقال حالت نماینده) است. می‌توانید در ویکی‌پدیا اطلاعات بیشتری در این مورد بخوانید، پیوندهای مقاله‌ها در انتهای موضوع قرار دارند. از این مقالات، ما باید موارد زیر را درک کنیم: "رویکرد RPC به شما امکان می دهد از تعداد کمی از آنها استفاده کنید منابع شبکهبا تعداد زیادی روش و یک پروتکل پیچیده. با رویکرد REST، تعداد روش‌ها و پیچیدگی پروتکل به شدت محدود می‌شود، که می‌تواند منجر به تعداد زیادی از منابع فردی شود. یعنی در رابطه با ما، این بدان معنی است که در سایت در مورد رویکرد RPC همیشه یک ورودی (پیوند) به سرویس وجود خواهد داشت و برای پردازش داده‌های ورودی که همراه با داده‌ها ارسال می‌کنیم، کدام رویه را فراخوانی کنیم. در حالی که با رویکرد REST در سایت ما ورودی‌ها (پیوندها) زیادی دارد که هر کدام فقط داده‌های خاصی را می‌پذیرند و پردازش می‌کنند. اگر کسی که مطالعه می کند می داند که چگونه تفاوت این رویکردها را آسان تر توضیح دهد، پس حتماً در نظرات بنویسید!

نکته بعدی که باید در مورد SOAP بدانیم این است که این پروتکل از همان XML به عنوان یک انتقال استفاده می کند که از یک طرف بسیار خوب است، زیرا. بلافاصله، قدرت کامل پشته فن آوری های مبتنی بر زبان داده شدهنشانه گذاری، یعنی XML-Schema - زبانی برای توصیف ساختار یک سند XML (به لطف ویکی پدیا!)، که به شما امکان می دهد تا به طور خودکار داده های مشتریانی را که به سرور می رسند تأیید کنید.

و بنابراین، اکنون می دانیم که SOAP پروتکلی است که برای اجرای فراخوانی رویه از راه دور استفاده می شود و از XML به عنوان یک انتقال استفاده می کند! اگر مقاله را در ویکی‌پدیا بخوانید، از آنجا نیز می‌توانید یاد بگیرید که می‌توان از آن بر روی هر پروتکل لایه کاربردی استفاده کرد، و نه فقط با HTTP (متاسفانه، در این مبحث فقط SOAP را در مقابل HTTP در نظر خواهیم گرفت). و می دانید چه چیزی را در این همه بیشتر دوست دارم؟ اگر هیچ حدس و گمانی وجود ندارد، پس من به شما اشاره می کنم - SOAP!... به هر حال هیچ حدسی وجود ندارد؟... آیا شما قطعا مقاله ویکی پدیا را خوانده اید؟... به طور کلی، من شما را بیشتر شکنجه نمی دهم. بنابراین، من بلافاصله به پاسخ می پردازم: "SOAP (از انگلیسی. پروتکل دسترسی به اشیاء ساده - یک ساده پروتکلدسترسی به اشیاء؛ تا مشخصات 1.2)". برجسته این خط به صورت مورب است! من نمی دانم شما از همه اینها چه نتیجه ای گرفتید ، اما موارد زیر را می بینم - از آنجایی که این پروتکل به هیچ وجه نمی تواند "ساده" نامیده شود (و ظاهراً حتی w3 نیز با این موافق است) ، پس از نسخه 1.2 دیگر وجود ندارد. اصلا رمزگشایی شده! و به صابون معروف شد، فقط صابون و دوره.

خب، باشه، ببخشید، کمی به کناری لغزیدم. همانطور که قبلا نوشتم، XML به عنوان یک انتقال استفاده می شود و بسته هایی که بین مشتری و سرور اجرا می شوند، پاکت SOAP نامیده می شوند. اگر ساختار کلی پاکت نامه را در نظر بگیریم، برای شما بسیار آشنا به نظر می رسد، زیرا شبیه ساختار یک صفحه HTML است. یک بخش اصلی دارد - پاکت کن، که شامل بخش هایی است سرتیترو بدن، یا عیب. که در بدنداده ها منتقل می شود و یک بخش اجباری از پاکت است، در حالی که سرتیتراختیاری است. که در سرتیترمجوز می تواند منتقل شود یا هر داده دیگری که مستقیماً با داده های ورودی رویه های وب سرویس مرتبط نیست. حرفه ای عیبچیز خاصی برای گفتن وجود ندارد، به جز اینکه در صورت بروز هر گونه خطایی از سرور به مشتری می رسد.

اینجاست که داستان کلی من در مورد پروتکل SOAP به پایان می رسد (زمانی که کلاینت و سرور ما در نهایت نحوه اجرای آنها را با یکدیگر یاد بگیرند، به خود پاکت ها و ساختار آنها با جزئیات بیشتری نگاه خواهیم کرد) و یک مورد جدید شروع می شود - در مورد یک همراه SOAP تماس گرفت WSDL(زبان شرح خدمات وب). بله، بله، این همان چیزی است که بیشتر ما را از تلاش برای گرفتن و پیاده سازی API خود در این پروتکل می ترساند. در نتیجه، ما معمولا چرخ خود را با JSON به عنوان یک حمل و نقل دوباره اختراع می کنیم. بنابراین، WSDL چیست؟ WSDL زبانی برای توصیف خدمات وب و دسترسی به آنها بر اساس زبان XML (c) ویکی پدیا است. اگر از این تعریف کل معنای مقدس این فناوری برای شما روشن نشد، سعی می کنم آن را به زبان خودم توصیف کنم!

WSDL طوری طراحی شده است که به مشتریان ما اجازه می دهد تا به طور معمول با سرور ارتباط برقرار کنند. برای انجام این کار، اطلاعات زیر در فایل با پسوند “*.wsdl” توضیح داده شده است:

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

3 مقدمه ای بر طرحواره XML

وظیفه اصلی طرحواره توصیف ساختار داده هایی است که قرار است پردازش کنیم. تمام داده ها در طرحواره های XML به دو دسته تقسیم می شوند ساده(اسکالر) و مجتمع(ساختار) انواع. انواع ساده شامل انواع زیر است:

• خط،
• عدد،
• بولی،
• تاریخ.

پیشنهاد می کنم دور نرویم و یک طرح XML برای پیام اس ام اس خود بنویسیم! در زیر توضیحات xml پیام اس ام اس آمده است:

71239876543 پیام آزمایشی 2013-07-20T12:00:00 12
طرح نوع پیچیده ما به صورت زیر خواهد بود:

این ورودی به شرح زیر است: ما یک متغیر داریم " پیام» نوع « پیام"و یک نوع پیچیده وجود دارد به نام" پیام"، که از مجموعه ای متوالی از عناصر تشکیل شده است" تلفن» تایپ کنید رشته, « متن» تایپ کنید رشته, « تاریخ» تایپ کنید زمان قرار, « نوع» تایپ کنید اعشاری. این انواع ساده هستند و قبلاً در تعریف طرحواره تعریف شده اند. تبریک می گویم! ما به تازگی اولین طرح XML خود را نوشته ایم!

من فکر می کنم که معنای عناصر " عنصر"و" نوع پیچیده» همه چیز کم و بیش برای شما روشن شد، بنابراین ما دیگر روی آنها تمرکز نمی کنیم و بلافاصله به عنصر آهنگساز می رویم « توالی". وقتی از عنصر ترکیب کننده استفاده می کنیم " توالی» به شما اطلاع می دهیم که عناصر موجود در آن باید همیشه به ترتیب مشخص شده در طرح باشد و همچنین همه آنها اجباری هستند. اما ناامید نشو! دو عنصر آهنگساز دیگر در طرحواره های XML وجود دارد: انتخاب"و" همه". آهنگساز انتخاب" نشان می دهد که باید یکی از عناصر ذکر شده در آن وجود داشته باشد و آهنگساز " همه» – هر ترکیبی از عناصر فهرست شده.

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

71239876543 پیام آزمایشی 1 2013-07-20T12:00:00 12 71239876543 پیام آزمایشی N 2013-07-20T12:00:00 12
طرح چنین نوع پیچیده ای به صورت زیر است:

بلوک اول حاوی اعلان آشنا از نوع پیچیده است. پیام". اگر متوجه شدید، در هر نوع ساده موجود در " پیام"، ویژگی های واجد شرایط جدید اضافه شده است " کوچک اتفاق می افتد"و" حداکثر اتفاق می افتد". از آنجایی که حدس زدن از نام دشوار نیست، اولین ( کوچک اتفاق می افتد) نشان می دهد که دنباله داده شده باید حداقل یک عنصر از نوع " را داشته باشد. تلفن», « متن», « تاریخ"و" نوع"، در حالی که بعدی ( حداکثر اتفاق می افتد) ویژگی به ما اعلام می کند که حداکثر یک عنصر از این قبیل در دنباله ما وجود دارد. در نتیجه، زمانی که طرحواره های خود را برای هر داده ای می نویسیم، وسیع ترین انتخاب در مورد نحوه پیکربندی آنها به ما داده می شود!

بلوک دوم طرح واره عنصر " را اعلام می کند لیست پیام ها» نوع « MessageList". واضح است که " MessageList"یک نوع پیچیده است که شامل حداقل یک عنصر است" پیام"، اما حداکثر تعداد این عناصر محدود نیست!

4 WSDL خود را بنویسید

به طور کلی، برای اینکه همه چیز برای ما درست کار کند، باید یک فایل WSDL با نوع MIME صحیح را به مشتری منتقل کنیم. برای انجام این کار، باید وب سرور خود را بر اساس آن پیکربندی کنید، یعنی نوع MIME را برای فایل هایی با پسوند *.wsdl روی خط زیر تنظیم کنید:

برنامه/wsdl+xml
اما در عمل، من معمولا هدر HTTP را از طریق PHP ارسال می کنم. متن/xml»:

Header("Content-Type: text/xml; charset=utf-8");
و همه چیز عالی کار کرد!

من می خواهم فوراً به شما هشدار دهم ، سرویس وب ساده ما توضیحات نسبتاً چشمگیری خواهد داشت ، بنابراین نگران نباشید ، زیرا. بیشتر متن آب اجباری است و پس از نوشتن می توان آن را به طور مداوم از یک وب سرویس به سرویس دیگر کپی کرد!

از آنجایی که WSDL XML است، در همان خط اول باید مستقیماً در مورد آن بنویسید. عنصر ریشه یک فایل همیشه باید نامگذاری شود تعاریف»:

معمولاً WSDL از 4-5 بلوک اصلی تشکیل شده است. اولین بلوک تعریف وب سرویس یا به عبارت دیگر نقطه ورود است.

اینجا می گوید که ما یک سرویس داریم به نام - " SmsService". در اصل، تمام نام های موجود در فایل WSDL می تواند توسط شما به هر چیزی که می خواهید تغییر دهید، زیرا آنها مطلقاً هیچ نقشی ندارند.

پس از آن، ما این را در وب سرویس خود اعلام می کنیم " SmsServiceیک نقطه ورودی ("پورت") وجود دارد که به نام " SmsServicePort". به این نقطه ورود است که تمام درخواست های مشتریان به سرور ارسال می شود. و در عنصر مشخص می کنیم " نشانی» پیوندی به یک فایل کنترل کننده که درخواست ها را می پذیرد.

پس از اینکه یک وب سرویس را تعریف کردیم و یک نقطه ورودی برای آن مشخص کردیم، باید رویه های پشتیبانی شده را به آن متصل کنیم:

برای انجام این کار، فهرست می کند که کدام عملیات و به چه شکل y فراخوانی می شود. آن ها برای بندر SmsServicePort» یک اتصال به نام « SMSServiceBinding"، که دارای نوع تماس است" rpc” و HTTP به عنوان پروتکل انتقال (حمل و نقل) استفاده می شود. بنابراین، ما در اینجا نشان دادیم که یک تماس RPC از طریق HTTP برقرار خواهیم کرد. پس از آن، ما توضیح می دهیم که کدام رویه ها ( عمل) در وب سرویس پشتیبانی می شوند. ما فقط از یک روش پشتیبانی خواهیم کرد - " ارسال پیامک". از طریق این روش، پیام های فوق العاده ما به سرور ارسال می شود! پس از اعلام رویه، باید مشخص شود که داده ها به چه شکلی منتقل می شوند. در این مورد مشخص شده است که از پاکت های استاندارد SOAP استفاده خواهد شد.

پس از آن، باید رویه را به پیام‌ها متصل کنیم:

برای انجام این کار، ما مشخص می کنیم که اتصال ما ("binding") از نوع " SMSServicePortType"و در عنصر" portType» با همان نام نوع، اتصال رویه ها به پیام ها را مشخص کنید. بنابراین، پیام دریافتی(مشتری به سرور) نامیده می شود sendSmsRequest"، و خروجی (از سرور به مشتری)" sendSmsResponse". مانند همه نام‌ها در WSDL، نام پیام‌های ورودی و خروجی دلخواه است.

حال باید خود پیام ها را شرح دهیم، یعنی. ورودی و خروجی:

برای این کار، عناصر " را اضافه می کنیم پیام» با اسامی « sendSmsRequest"و" sendSmsResponse" به ترتیب. در آنها، ما نشان می دهیم که یک پاکت باید به ورودی بیاید که ساختار آن با نوع داده مطابقت دارد. درخواست". پس از آن، یک پاکت حاوی نوع داده از سرور بازگردانده می شود - " واکنش».

اکنون باید کمی انجام دهیم - شرحی از این انواع را به فایل WSDL خود اضافه کنیم! و به نظر شما WSDL داده های ورودی و خروجی را چگونه توصیف می کند؟ فکر کنم خیلی وقته همه چیزو فهمیدی و با خودت گفتی با کمک طرحواره های XML! و شما کاملا درست خواهید بود!

می توانید به ما تبریک بگویید! اولین WSDL ما نوشته شده است! و ما یک قدم به رسیدن به هدفمان نزدیکتر شده ایم.
در مرحله بعد، ما به آنچه PHP برای توسعه برنامه های کاربردی توزیع شده خود در اختیار ما قرار می دهد، خواهیم پرداخت.

5 اولین سرور SOAP ما

بعد از اینکه همه چیز نصب و پیکربندی شد، باید فایل " را ایجاد کنیم smsservice.php» با محتوای زیر:

setClass ("SoapSmsGateWay"); //سرور را راه اندازی کنید $server->handle();
آنچه در بالای خط تابع "ini_set" قرار دارد، امیدوارم نیازی به توضیح نداشته باشد. زیرا تعریف می کند که کدام هدرهای HTTP را از سرور به مشتری ارسال کنیم و محیط را پیکربندی می کند. در خط "ini_set"، ما کش کردن فایل WSDL را غیرفعال می کنیم تا تغییرات ما در آن بلافاصله بر روی مشتری اعمال شود.

حالا میرسیم به سرور! همانطور که می بینید، کل سرور SOAP تنها سه خط طول دارد! در خط اول، یک نمونه جدید از شی SoapServer ایجاد می کنیم و آدرس توضیحات سرویس وب WSDL خود را به سازنده آن ارسال می کنیم. اکنون می دانیم که در ریشه میزبان در فایلی با نام مشخص قرار خواهد گرفت. smsservice.wsdl.php". در خط دوم، به سرور SOAP می گوییم که کدام کلاس را بکشد تا پاکت دریافت شده از مشتری را پردازش کند و پاکت را با پاسخ برگرداند. همانطور که ممکن است حدس بزنید، در این کلاس است که تنها روش ما توضیح داده خواهد شد. ارسال پیامک. در خط سوم سرور را راه اندازی می کنیم! همه چیز، سرور ما آماده است! که با آن به همه ما تبریک می گویم!

حالا باید یک فایل WSDL ایجاد کنیم. برای انجام این کار، می توانید به سادگی محتویات آن را از قسمت قبلی کپی کنید، یا آزادانه عمل کنید و کمی آن را "الگو" کنید:

"; ?> /" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:http="http:// schemas.xmlsoap.org/wsdl/http/" name="SmsWsdl" xmlns="http://schemas.xmlsoap.org/wsdl/"> /">

/smsservice.php" />
در این مرحله، سرور حاصل باید کاملاً مناسب ما باشد، زیرا. می‌توانیم پاکت‌هایی را که به سمت آن می‌آیند ثبت کنیم و سپس با آرامش داده‌های دریافتی را تجزیه و تحلیل کنیم. برای اینکه بتوانیم هر چیزی را روی سرور دریافت کنیم، به یک کلاینت نیاز داریم. پس بیایید با آنها کار کنیم!

6 مشتری SOAP در راه است

messageList = new MessageList(); $req->messageList->message = new Message(); $req->messageList->message->phone = "79871234567"; $req->messageList->message->text = "تست پیام 1"; $req->messageList->message->date = "2013-07-21T15:00:00.26"; $req->messageList->message->type = 15; $client = new SoapClient("http://($_SERVER["HTTP_HOST"])/smsservice.wsdl.php، array("soap_version" => SOAP_1_2)); var_dump($client->sendSms($req));
بیایید اشیاء خود را توصیف کنیم. هنگامی که WSDL را نوشتیم، سه موجودیت در آن برای پاکت ورودی به سرور توضیح داده شد: درخواست, MessageListو پیام. بر این اساس، طبقات درخواست, MessageListو پیامبازتابی از این موجودات در اسکریپت PHP ما هستند.

بعد از اینکه اشیاء را تعریف کردیم، باید یک شی بسازیم ( $req) که به سرور ارسال می شود. سپس دو خط محبوب ترین برای ما می آیند! مشتری SOAP ما! باور کنید یا نه، اما این کافی است تا سرور ما شروع به ارسال پیام از مشتری کند و همچنین سرور ما با موفقیت آنها را دریافت و پردازش کند! در اولین مورد، یک نمونه از کلاس SoapClient ایجاد می کنیم و آدرس محل فایل WSDL را به سازنده آن ارسال می کنیم و به صراحت در پارامترها نشان می دهیم که با استفاده از پروتکل SOAP نسخه 1.2 کار خواهیم کرد. در خط بعدی متد را فراخوانی می کنیم ارسال پیامکهدف - شی مشتری $و بلافاصله نتیجه را در مرورگر نمایش دهید.
بیایید آن را اجرا کنیم و ببینیم در نهایت چه چیزی به دست آوردیم!

من شی زیر را از سرور دریافت کردم:

Object(stdClass) public "status" => boolean true
و این فوق العاده است، زیرا. اکنون ما با اطمینان می دانیم که سرور ما کار می کند و نه تنها کار می کند، بلکه می تواند مقادیری را به مشتری برگرداند!

حالا بیایید به گزارشی که با احتیاط در سمت سرور نگه می داریم نگاه کنیم! در قسمت اول آن، داده های خام وارد شده به سرور را مشاهده می کنیم:

79871234567 پیام آزمایشی 1 2013-07-21T15:00:00.26 15
این پاکت است. حالا شما می دانید که چگونه به نظر می رسد! اما بعید است که ما علاقه مند باشیم که دائماً آن را تحسین کنیم، بنابراین بیایید شیء را از فایل log جداسازی کنیم و ببینیم آیا همه چیز با ما خوب است یا خیر:

Object(stdClass) public "messageList" => object(stdClass) public "message" => object(stdClass) public "phone" => string "79871234567" (length=11) public "text" => string "Test message 1" " (length=37) public "date" => string "2013-07-21T15:00:00.26" (length=22) public "type" => string "15" (length=2)
همانطور که می بینید، شی به درستی deserialized شده است، که من می خواهم با آن به همه ما تبریک بگویم! بعد، چیز جالب تری در انتظار ما است! یعنی ما توسط مشتری نه یک پیامک، بلکه یک بسته کامل (به عبارت دقیق تر، سه کامل) به سرور ارسال می کنیم!

7 ارسال اشیاء پیچیده

// ایجاد یک شی برای ارسال به سرور $req = new Request(); $req->messageList = new MessageList(); $msg1 = new Message(); $msg1->phone = "79871234567"; $msg1->text = "پیام آزمایشی 1"; $msg1->date = "2013-07-21T15:00:00.26"; $msg1->type = 15; $msg2 = new Message(); $msg2->phone = "79871234567"; $msg2->text = "پیام آزمایشی 2"; $msg2->date = "2014-08-22T16:01:10"; $msg2->type = 16; $msg3 = new Message(); $msg3->phone = "79871234567"; $msg3->text = "پیام آزمایشی 3"; $msg3->date = "2014-08-22T16:01:10"; $msg3->type = 17; $req->messageList->message = $msg1; $req->messageList->message = $msg2; $req->messageList->message = $msg3;
گزارش های ما نشان می دهد که بسته زیر از مشتری آمده است:

79871234567 پیام آزمایشی 1 2013-07-21T15:00:00.26 15 79871234567 پیام تست 2 2014-08-22T16:01:10 16 79871234567 پیام تست 3 2014-08-22T16:01:10 17
چه مزخرفی، شما می گویید؟ و شما به یک معنا درست خواهید بود، زیرا. همانطور که فهمیدیم کدام شی از کلاینت خارج شده است، دقیقاً به همان شکل به شکل پاکت به سرور ما آمد. درست است، پیام های اس ام اس در XML آن طور که ما نیاز داشتیم سریال سازی نمی شدند - آنها باید در عناصر پیچیده می شدند. پیام، نه در ساختار. حال بیایید ببینیم که چنین شیئی به چه شکلی به روش می آید ارسال پیامک:

Object(stdClass) public "messageList" => object(stdClass) public "message" => object(stdClass) public "Struct" => array (size=3) 0 => object(stdClass) public "phone" => string "79871234567" (length=11) public "text" => string "Test message 1" (length=37) public "date" => string "2013-07-21T15:00:00.26" (length=22) public " type" => string "15" (length=2) 1 => object(stdClass) public "phone" => string "79871234567" (length=11) public "text" => string "Test message 2" (length= 37) public "date" => string "2014-08-22T16:01:10" (length=19) public "type" => string "16" (length=2) 2 => object(stdClass) public "phone " => string "79871234567" (length=11) public "text" => string "Test message 3" (length=37) public "date" => string "2014-08-22T16:01:10" (length= 19) عمومی "type" => رشته "17" (طول = 2)
این دانش چه چیزی به ما می دهد؟ فقط این که مسیری که انتخاب کرده ایم درست نیست و پاسخی برای این سوال دریافت نکرده ایم - "چگونه می توانیم ساختار داده صحیح را روی سرور دریافت کنیم؟". اما من پیشنهاد می کنم ناامید نشویم و سعی کنیم آرایه خود را به نوع خود برسانیم یک شی:

$req->messageList->message = (object)$req->messageList->message;
در این صورت، پاکت دیگری دریافت خواهیم کرد:

79871234567 پیام آزمایشی 1 2013-07-21T15:00:00.26 15 79871234567 پیام تست 2 2014-08-22T16:01:10 16 79871234567 پیام تست 3 2014-08-22T16:01:10 17
وارد روش شد ارسال پیامکشی دارای ساختار زیر است:

Object(stdClass) public "messageList" => object(stdClass) public "message" => object(stdClass) public "BOGUS" => array (size=3) 0 => object(stdClass) public "phone" => string "79871234567" (length=11) public "text" => string "Test message 1" (length=37) public "date" => string "2013-07-21T15:00:00.26" (length=22) public " type" => string "15" (length=2) 1 => object(stdClass) public "phone" => string "79871234567" (length=11) public "text" => string "Test message 2" (length= 37) public "date" => string "2014-08-22T16:01:10" (length=19) public "type" => string "16" (length=2) 2 => object(stdClass) public "phone " => string "79871234567" (length=11) public "text" => string "Test message 3" (length=37) public "date" => string "2014-08-22T16:01:10" (length= 19) عمومی "type" => رشته "17" (طول = 2)
در مورد من، پس "از تغییر در مکان های اصطلاحات، مجموع تغییر نمی کند" (ج). چی جعلی، چی ساختارهنوز به هدفمون نرسیدیم! و برای رسیدن به آن باید مطمئن شویم که به جای این نام های نامفهوم، بومی ماست پیام. اما نویسنده هنوز نمی داند چگونه می توان به این امر دست یافت. بنابراین، تنها کاری که می توانیم انجام دهیم این است که از شر ظرف اضافی خلاص شویم. به عبارت دیگر، ما اکنون مطمئن خواهیم شد که به جای پیامتبدیل شد جعلی! برای انجام این کار، شی را به صورت زیر تغییر دهید:

// ایجاد یک شی برای ارسال به سرور $req = new Request(); $msg1 = new Message(); $msg1->phone = "79871234567"; $msg1->text = "پیام آزمایشی 1"; $msg1->date = "2013-07-21T15:00:00.26"; $msg1->type = 15; $msg2 = new Message(); $msg2->phone = "79871234567"; $msg2->text = "پیام آزمایشی 2"; $msg2->date = "2014-08-22T16:01:10"; $msg2->type = 16; $msg3 = new Message(); $msg3->phone = "79871234567"; $msg3->text = "پیام آزمایشی 3"; $msg3->date = "2014-08-22T16:01:10"; $msg3->type = 17; $req->messageList = $msg1; $req->messageList = $msg2; $req->messageList = $msg3; $req->messageList = (object)$req->messageList;
اگر خوش شانس باشیم و نام صحیح از طرح بیرون بیاید چه؟ برای انجام این کار، بیایید به پاکت ارسال شده نگاه کنیم:

79871234567 پیام آزمایشی 1 2013-07-21T15:00:00.26 15 79871234567 پیام تست 2 2014-08-22T16:01:10 16 79871234567 پیام تست 3 2014-08-22T16:01:10 17
بله، معجزه اتفاق نیفتاد! جعلی- ما برنده نخواهیم شد! وارد شد ارسال پیامکشی در این مورد به شکل زیر خواهد بود:

Object(stdClass) public "messageList" => object(stdClass) public "BOGUS" => array (size=3) 0 => object(stdClass) public "phone" => string "79871234567" (length=11) public " text" => رشته "پیام آزمایشی 1" (طول = 37) عمومی "تاریخ" => رشته "2013-07-21T15:00:00.26" (طول=22) عمومی "نوع" => رشته "15" (طول =2) 1 => object(stdClass) public "phone" => string "79871234567" (length=11) public "text" => string "Test message 2" (length=37) public "date" => string " 2014-08-22T16:01:10" (طول = 19) عمومی "type" => رشته "16" (طول=2) 2 => شی (stdClass) عمومی "phone" => رشته "79871234567" (طول= 11) public "text" => string "Test message 3" (length=37) public "date" => string "2014-08-22T16:01:10" (length=19) public "type" => string " 17 اینچ (طول = 2)
همانطور که می گویند - "تقریبا"! در این یادداشت (کمی غم انگیز)، پیشنهاد می کنم بی سر و صدا جمع کنیم و برای خودمان نتیجه گیری کنیم.

8 نتیجه گیری

• می توانید فایل WSDL لازم را برای وب سرویس خود بنویسید.
• شما می توانید مشتری خود را بدون هیچ مشکلی بنویسید که می تواند با استفاده از پروتکل SOAP با سرور ارتباط برقرار کند.
• شما می توانید خود را بنویسید سرور خودبرقراری ارتباط با دنیای خارج از طریق SOAP؛
• شما می توانید آرایه هایی از همان نوع اشیاء را از مشتری خود به سرور ارسال کنید (با برخی محدودیت ها).

• کلاس بومی SoapClient نمی داند که چگونه ساختارهای داده ای از همان نوع را در XML به درستی سریال سازی کند.
• هنگام سریال سازی آرایه به XML که تولید می کند عنصر اضافیبا نام ساختار;
• هنگام سریال سازی یک شی در XML، یک عنصر اضافی به نام ایجاد می کند جعلی;
• جعلیشر کمتر از ساختاربا توجه به این واقعیت که پاکت نامه فشرده تر است (هیچ فضای نام اضافی در هدر XML پاکت اضافه نمی شود).
• متأسفانه، کلاس SoapServer به طور خودکار داده های پاکت را با طرح XML ما تأیید نمی کند (شاید سرورهای دیگر نیز این کار را انجام ندهند).

عنوان موضوع واقعاً یک سؤال است، زیرا من خودم نمی دانم چیست و برای اولین بار سعی می کنم در چارچوب این مقاله با آن کار کنم. تنها چیزی که می‌توانم تضمین کنم این است که کد زیر کار می‌کند، با این حال، عبارات من فقط فرضیات و حدس‌هایی درباره نحوه درک من از همه اینها خواهند بود. پس بزن بریم...

معرفی

1. صابون. قبل از فراخوانی یک روش راه دور، باید این تماس را در یک فایل XML با فرمت SOAP توصیف کنید. SOAP تنها یکی از بسیاری از آنها است نشانه گذاری XML، که در وب سرویس ها استفاده می شود. هر چیزی که بخواهیم از طریق HTTP به جایی بفرستیم ابتدا تبدیل به آن می شود توضیحات XMLسپس SOAP در یک بسته HTTP قرار می گیرد و از طریق TCP/IP به رایانه دیگری در شبکه ارسال می شود.
2. WSDL. یک وب سرویس وجود دارد، یعنی. برنامه ای که روش های آن را می توان از راه دور فراخوانی کرد. اما استاندارد ایجاب می کند که توضیحاتی به این برنامه ضمیمه شود که می گوید "بله، اشتباه نکردید - این واقعاً یک وب سرویس است و می توانید روش های فلان و فلان را از آن فراخوانی کنید." این توضیحات توسط یک فایل XML دیگر که فرمت متفاوتی دارد، یعنی WSDL نشان داده می شود. آن ها WSDL فقط یک فایل XML است که یک وب سرویس را توصیف می کند و نه چیز دیگری.

رویکرد عمومی

1. رابط وب سرویس ما را شرح دهید
2. این رابط را پیاده سازی کنید
3. وب سرویس ما را راه اندازی کنید
4. یک کلاینت بنویسید و از راه دور با روش وب سرویس مورد نظر تماس بگیرید

سرور

مشتری

نتیجه

صابونیک پروتکل مبتنی بر متن است که از XML برای تبادل پیام های ساختاریافته در یک محیط محاسباتی توزیع شده استفاده می کند. SOAP در ابتدا برای پیاده سازی در نظر گرفته شده بود تماس از راه دوررویه‌ها (RPC)، و نام آن مخفف بود: پروتکل دسترسی به اشیا ساده - یک پروتکل ساده برای دسترسی به اشیا. اکنون این پروتکل برای تبادل پیام های دلخواه در قالب XML و نه فقط برای فراخوانی رویه ها استفاده می شود. مشخصات رسمی آخرین نسخه 1.2 پروتکل به هیچ وجه نام SOAP را رمزگشایی نمی کند. SOAP توسعه پروتکل XML-RPC است. SOAP را می توان با هر پروتکل لایه کاربردی استفاده کرد: SMTP، FTP، HTTP و غیره، اما تعامل آن با هر یک از این پروتکل ها ویژگی های خاص خود را دارد که باید جداگانه تعریف شود. اغلب، SOAP از طریق HTTP استفاده می شود. SOAP یکی از استانداردهایی است که فناوری وب سرویس ها بر آن استوار است. ارتباط بین وب سرویس ها و مشتریان آنها از طریق پیام هایی با فرمت XML انجام می شود. SOAP (پروتکل دسترسی به اشیاء ساده) یک پروتکل پیام رسانی برای انتخاب خدمات وب است. می توان گفت که فرمت SOAP برای فناوری RPC (تماس از راه دور) ایده آل است، زیرا پیام SOAP حاوی پارامترهایی است که توسط مشتری ارسال می شود یا مقدار بازگشتی ارسال شده توسط سرویس.

مزایای استفاده از فرمت SOAP:

· انواع داده های انعطاف پذیرتر.

پشتیبانی از هدرها و پسوندها:

ایرادات:

· استفاده از SOAP برای انتقال پیام ها باعث افزایش حجم آنها و کاهش سرعت پردازش می شود. در سیستم هایی که سرعت مهم است، ارسال اسناد XML به طور مستقیم از طریق HTTP رایج تر است، جایی که پارامترهای درخواست به عنوان پارامترهای HTTP معمولی ارسال می شوند.

· اگرچه SOAP یک استاندارد است، برنامه های مختلف اغلب پیام هایی را در قالبی ناسازگار تولید می کنند. به عنوان مثال، یک درخواست ایجاد شده توسط یک کلاینت AXIS توسط سرور WebLogic قابل درک نخواهد بود.

مفاهیم اولیه پروتکل: طرفی که پیام SOAP را ارسال می کند فرستنده SOAP نامیده می شود و کسی که دریافت می کند گیرنده SOAP نامیده می شود. مسیری که یک پیام SOAP از فرستنده اصلی تا گیرنده نهایی طی می کند مسیر پیام نامیده می شود. مسیر پیام حاوی فرستنده اصلی، گیرنده نهایی و 0 یا بیشتر واسطه SOAP است. نهادهایی که پیام ها را طبق قوانین تعریف شده توسط پروتکل های SOAP پردازش می کنند، گره های SOAP نامیده می شوند. واحد ابتدایی اطلاعاتی که در تبادل بین گره های SOAP شرکت می کند، پیام SOAP نامیده می شود. سند XMLبا لفاف SOAP روی عنصر ریشه.