علت خطا . حاوی یک ویژگی xml: lang اختیاری است که زبان پیام را نشان می دهد (به فصل D مراجعه کنید) و تعداد دلخواه عناصر تو در تو که خطا را توصیف می کند.

عناصر اختیاری

? - URI گره SOAP میانی که با خطا مواجه شده است.

? - نقش گره SOAP که متوجه خطا شد.

? - شرح خطای مشاهده شده در هنگام پردازش بدنه پیام، اما نه عنوان.

لیست 3.2 پیام خطایی را نشان می دهد که هنگام تلاش برای اجرای رویه رخ داده است. خطا این است که نام آرگومان های رویه به اشتباه در پیام SOAP نوشته شده است و رویه نمی تواند آنها را درک کند.

لیست 3.2. پیغام خطا

xmlns:env="http://www.w3.org/2002/06/soap-envelope" xmlns:rpc='http://www.w3.org/2002/06/soap-rpc'>

env: فرستنده

rpc:BadArgumentsc/env:Value>

Ptocessing ETror

xmlns:e="http://www.example.org/faults"> نه من مطابقت ندارد 999

انواع خطا

لیست کدهای خطا دائما در حال تغییر و گسترش است. نسخه 1.1 چهار نوع خطا را تعریف می کند.

VersionMismatch - فضای نام شناسایی نشده است. شاید قدیمی باشد یا نامش اشتباه نوشته شده باشد.

MustUnderstand - یک بلوک هدر که با ویژگی mustUnderstand با مقدار 1 مشخص شده است، مطابق با نحو آن که در طرح سند تعریف شده است، مطابقت ندارد.

سرویس گیرنده - سند XML حاوی پیام نادرست است و به همین دلیل سرور نمی تواند آن را پردازش کند. مشتری باید پیام را تغییر دهد.

سرور - سرور به دلایل داخلی خود نمی تواند یک پیام ضبط شده را به درستی پردازش کند.

نسخه 1.2 پنج نوع خطا را تعریف می کند.

VersionMismatch - فضای نام شناسایی نشده است. ممکن است قدیمی باشد، یا نام آن اشتباه نوشته شده باشد، یا پیام با نام عنصر XML مواجه شده است که در آن فضای نام تعریف نشده است. سرور عنصر را در هدر پاسخ می نویسد شمارش عناصر تو در تو نام فضای نام را درست همانطور که توسط سرور درک می شود. پاسخ سرور در فهرست 3.3 نشان داده شده است.

MustUnderstand - یک بلوک هدر که با مشخصه mustunderstand علامت گذاری شده است مطابق با نحو آن همانطور که در طرح سند تعریف شده است مطابقت ندارد. سرور عناصر را در هدر پاسخ می نویسد ، که ویژگی qname حاوی نام بلوک نامعتبر است. لیست 3.4 حاوی نمونه ای از پاسخی است که سرور در صورت غلط املایی سرصفحه در لیست 3.1 می دهد.

DataEncodingUnknown - داده های نامفهومی در پیام یافت شد، شاید آنها در یک رمزگذاری ناشناخته نوشته شده باشند.

فرستنده - سند XML حاوی پیام نادرست است و به همین دلیل سرور نمی تواند آن را پردازش کند. مشتری باید پیام را تغییر دهد.

گیرنده - سرور به دلایل داخلی خود نمی تواند یک پیام ضبط شده را به درستی پردازش کند، به عنوان مثال تجزیه کننده XML مورد نیاز وجود ندارد.

سرور می تواند برخی از انواع خطاهای خود را به این نوع خطاها اضافه کند. معمولا

آنها به جزئیات انواع استاندارد و پیام های مربوط به آنها در عناصر ظاهر می شوند همانطور که در فهرست 3.2 در بالا نشان داده شده است.

? لیست 3.3. پاسخ سرور با یک پیام خطا از نوع VersionMismatch

xmlns:env="http://www.w3.org/2002/06/soap-envelope">

xmlns:upg="http://www.w3.org/2002/06/soap-upgrade">

xmlns:nsl="http://www.w3.org/2002/06/soap-envelope"/>

xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/"/>

env:VersionMismatch

عدم تطابق نسخه ها

Listong3.4. پاسخ سرور با پیام خطایی مانند MustUnderstand

xmlns:t='http://some.com/transaction' />

env: MustUnderstand

یک یا چند سرصفحه اجباری درک نشده است

ادبیات:

Khabibullin I. Sh. توسعه خدمات وب با استفاده از جاوا. - سن پترزبورگ: BHV-Petersburg, 2003. - 400 p.: ill.

صابونیک پروتکل مبتنی بر متن که از 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 از عنصر ریشه است.

کلاه 23 جولای 2013 در 01:09 ب.ظ

نوشتن یک برنامه سرویس گیرنده-سرور SOAP در PHP

• PHP

• آموزش

سلام به همه!
این اتفاق افتاد که اخیراً درگیر توسعه خدمات وب شده ام. اما امروز موضوع در مورد من نیست، بلکه در مورد این است که چگونه می توانیم وب سرویس 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
طرح چنین نوع پیچیده ای به صورت زیر است:

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

بلوک دوم طرح واره عنصر " را اعلام می کند لیست پیام ها» نوع « 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 = پیام جدید(); $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 = پیام جدید(); $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 ما تأیید نمی کند (شاید سرورهای دیگر نیز این کار را انجام ندهند).

10 پاسخ

WSDL یک سند XML است که یک سرویس وب را توصیف می کند. در واقع به معنای زبان تعریف وب سرویس است.

SOAP یک پروتکل مبتنی بر XML است که اجازه می دهد اطلاعات از طریق یک پروتکل خاص (مانند HTTP یا SMTP) بین برنامه ها رد و بدل شود. مخفف عبارت Simple Object Access Protocol است و از XML برای فرمت پیام خود برای انتقال اطلاعات استفاده می کند.

REST یک سبک معماری است سیستم های شبکهو از انتقال یک کشور نماینده حمایت می کند. این خود یک استاندارد نیست، اما از استانداردهایی مانند HTTP، URL، XML و غیره استفاده می کند.

هر بار که کسی از SOAP/WSDL نام می برد، به اشیاء و کلاس های تعریف شده در xml فکر می کنم...

"شما از SOAP مانند هر کلاس PHP استفاده می کنید. با این حال، در این مورد، کلاس در محلی وجود ندارد. سیستم فایلبرنامه های کاربردی، اما در یک میزبان راه دور قابل دسترسی از طریق http."... "اگر ما به استفاده از یک سرویس SOAP به عنوان کلاس PHP دیگر فکر می کنیم، سند WSDL لیستی از همه است. روش های موجودو خصوصیات کلاس

و هر زمان که کسی در مورد REST صحبت می کند، به دستورات HTTP (روش های درخواست) مانند POST، GET و DELETE فکر می کنم.

مثال: به زبان سادهاگر یک وب سرویس ماشین حساب دارید.

WSDL: WSDL در مورد توابعی صحبت می کند که می توانید آنها را پیاده سازی کنید یا در معرض دید یک کلاینت قرار دهید. به عنوان مثال: جمع، حذف، تفریق و غیره.

SOAP: در جایی که با استفاده از SOAP در واقع اقداماتی مانند doDelete()، doSubtract()، doAdd() انجام می دهید. بنابراین SOAP و WSDL سیب و پرتقال هستند. ما نباید آنها را با هم مقایسه کنیم. هر دوی آنها عملکرد خاص خود را دارند.

چرا از SOAP و WSDL استفاده می کنیم: برای تبادل داده های مستقل از پلت فرم.

ویرایش: در زندگی عادی روزمره:

WSDL:وقتی به رستوران می رویم، آیتم های منو را می بینیم، این WSDL است.

کلاس های پروکسی:اکنون، پس از مشاهده آیتم های منو، تصمیم خود را می گیریم (در حال پردازش دیدگاه خود از سفارش): بنابراین، اساساً کلاس های Proxy را بر اساس سند WSDL می سازیم.

صابون:سپس هنگامی که ما واقعاً غذا را بر اساس منو سفارش می دهیم: به طور ضمنی از کلاس های پراکسی برای فراخوانی روش های خدماتی استفاده می کنیم که با استفاده از SOAP انجام می شود. :)

SOAP → SOAP (Simple Object Access Prototype) یک لایه پروتکل کاربردی است که برای ارتباط ماشین به ماشین طراحی شده است. پروتکل قوانین استاندارد را تعریف می کند. همه طرف هایی که از پروتکل خاصی استفاده می کنند باید قوانین پروتکل را رعایت کنند. مانند TCP، در لایه انتقال باز می شود. پروتکل SOAP در سطح برنامه (هر برنامه‌ای که از SOAP - Axis2، .Net پشتیبانی می‌کند) درک می‌شود.

پیام WSDL → SOAP شامل SoapEnevelope-> SoapHeader و SoapBody است. فرمت پیام را مشخص نمی کند؟ چه همه حمل و نقل ها (HTTP، JMS) پشتیبانی می شوند؟ بدون این اطلاعات برای هر مشتری که می خواهد از یک وب سرویس خاص برای ایجاد یک پیام SOAP استفاده کند، دشوار است. حتی اگر این کار را انجام دهند، مطمئن نخواهند بود که همیشه کار کند. WSDL نجات دهنده است. WSDL (زبان توصیف خدمات وب) عملیات، قالب‌های پیام و داده‌های انتقال پیام SOAP را تعریف می‌کند.

REST → REST (انتقال وضعیت نمایندگی) بر اساس حمل و نقل است. بر خلاف SOAP که بر روی اقدامات متمرکز است، REST بیشتر در مورد منابع است. REST منابع را با استفاده از URL (مثال -http://(serverAddress)/employees/employeeNumber/12345) پیدا می کند و بستگی به پروتکل حمل و نقل(با HTTP-GET، POST، PUT، DELETE، ...) برای اقدامات برای اجرای منابع. سرویس REST منبع را بر اساس URL تعیین می کند و عمل را بر اساس فعل عمل انتقال انجام می دهد. این بیشتر یک سبک معماری و قرارداد است.

SOAP مخفف عبارت Simple (sic) Object Access Protocol است. در نظر گرفته شده بود که با ارسال XML از طریق HTTP، تماس های رویه از راه دور با اشیاء راه دور برقرار شود.

WSDL یک زبان توصیف خدمات وب است. درخواستی که با نقطه پایانی ".wsdl" خاتمه می یابد، منجر به نمایش پیام XML می شود که درخواست و پاسخی را که استفاده کننده انتظار دارد را توصیف می کند. این قرارداد بین خدمات و مشتری را شرح می دهد.

REST از HTTP برای ارسال پیام به سرویس ها استفاده می کند.

SOAP یک مشخصات است، REST یک سبک است.

قرار نیست "فقط" چیز پیچیده ای را درک کنید.

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

WSDL توسط برنامه خوانده می شود و بنابراین می توان از آن برای تولید تمام یا بخشی از کد مشتری مورد نیاز برای فراخوانی وب سرویس استفاده کرد. به این معنی است که خدمات وب مبتنی بر SOAP را "خود توصیفی" بنامیم.

REST اصلا مربوط به WSDL نیست.

ویکی‌پدیا می‌گوید: «زبان توصیف خدمات وب یک زبان مبتنی بر XML است که مدلی برای توصیف خدمات وب ارائه می‌دهد». به عبارت دیگر، WSDL به یک وب سرویس اشاره دارد، همانطور که javadoc به جاوا اشاره می کند.

با این حال، چیز بسیار خوب در مورد WSDL این است نرم افزارمی تواند مشتری و سرور را با استفاده از WSDL ایجاد کند.