बाकी बनाम साबुन। भाग 2. प्लेटफॉर्म संचार को व्यवस्थित करना कितना आसान और अधिक कुशल है?

लेख का पहला भाग लिखने के बाद, मेरी भूख बढ़ गई और मैं अध्ययन जारी रखना चाहता था, इस बार व्यावहारिक भाग पर ध्यान केंद्रित करना। हमारे सभी उपद्रव अनुप्रयोगों और प्लेटफार्मों के बीच बातचीत की आवश्यकता के कारण भड़क गए हैं, यही वजह है कि यह लेख मुख्य रूप से इसके लिए समर्पित होगा।

सामग्री की तालिका:

बाकी बनाम साबुन। भाग 1. अंतर महसूस करें।
बाकी बनाम साबुन। भाग 2. प्लेटफॉर्म संचार को व्यवस्थित करना कितना आसान और अधिक कुशल है?

यह सब क्यों?

हमें अनुप्रयोगों, विशेष रूप से विभिन्न प्लेटफार्मों पर लिखे गए लोगों के बीच बातचीत की आवश्यकता क्यों है? बेवकूफ सवाल, निश्चित रूप से। प्रोग्रामिंग की दुनिया में, कई पूरी तरह से स्वतंत्र हैं, और कुछ जगहों पर भी युद्धरत, प्लेटफॉर्म मौजूद हैं और समानांतर में विकसित होते हैं। इसके अलावा, सॉफ़्टवेयर की एक बड़ी मात्रा पहले से ही लिखी गई है और सफलतापूर्वक काम करती है, इसलिए कोई भी इसे प्रत्येक नए प्लेटफ़ॉर्म के लिए फिर से नहीं लिखेगा। उदाहरण के लिए एक बैंक लें। सभी इन-हाउस बैंक प्रोग्रामर ने हमेशा जेएवीए में लिखा है, इसलिए बैंक में एक सेवा है जो 5 वर्षों से ठीक काम कर रही है, हाल ही में एंड्रॉइड पर सुंदर मोबाइल एप्लिकेशन दिखाई दिए हैं जो ओएस के लगभग सभी संस्करणों पर काम करते हैं, और एक ऐपलेट के साथ एक वेबसाइट भी है, जो शिक्षक खार्कोव विश्वविद्यालयों में अभी भी उन्नत वेब प्रौद्योगिकियों (jk) के उदाहरण के रूप में दिखाए जाते हैं। और अब विंडोज के लिए एक डेस्कटॉप बैंकिंग एप्लिकेशन विकसित करने का कार्य है। बैंक ने आउटसोर्सिंग कंपनी से WPF आवेदन का आदेश दिया। संचार प्लेटफार्मों को कैसे व्यवस्थित करें?

थोड़ा इतिहास

आइए हम उदाहरण से हटें और इतिहास की ओर मुड़ें। मेरे कई सहयोगियों की तुलना में शायद ऐसा करना मेरे लिए कठिन है, क्योंकि मैं .Net के दिनों में प्रोग्रामर के संप्रदाय में शामिल हो गया, जब साइटों को लिखने के लिए HTTP प्रोटोकॉल को जानना आवश्यक नहीं है, और आप कभी भी WinAPI को सुने बिना पूरी तरह कार्यात्मक डेस्कटॉप एप्लिकेशन भी लिख सकते हैं। । लेकिन मैं इस तरह का भ्रमण करने की कोशिश करूंगा। हम विशेष रूप से डायनासोर के समय पर विचार नहीं करेंगे (हम मानते हैं कि 1998 में XML के आगमन के साथ डायनासोर विलुप्त हो गए थे) ताकि मुख्य विषय से दूर न जाएं। मान लीजिए हमारे पास दो अनुप्रयोगों के बीच एक स्थापित कनेक्शन है, जिसके माध्यम से एक बाइट भेज सकता है और दूसरा उन्हें प्राप्त करेगा। आगे क्या है? अनुप्रयोगों को इस बात से सहमत होना चाहिए कि, उदाहरण के लिए, "1" का अर्थ है "सभी ग्राहकों की सूची भेजें", "2 | 36782" - "ग्राहक के लिए लेनदेन की एक सूची भेजें 36782"। शायद मेसोज़ोइक युग के दिन कुछ ऐसा ही हुआ था। यह हर एप्लिकेशन इंटरैक्शन के लिए एक नई बाइक का आविष्कार करने के लिए डेवलपर्स की आवश्यकता है। इंटरनेट (90 के दशक के मध्य) के विकास के साथ, एप्लिकेशन सूचनाओं का आदान-प्रदान करने में सक्षम थे, इसे सहमति वाले URL पर सहमति के रूप में प्रदान करते हैं (बाद में इसे "REST" कहा जाएगा)। एक्सएमएल-आरपीसी के आगमन से पहले क्या प्रोटोकॉल थे और कैसे आवेदन किया गया था - मैं नहीं लिखूंगा, क्योंकि मैं बहुत कम जानता हूं, शायद किसी को टिप्पणियों में उदासीन भावना होगी।

आरपीसी

RPC एक "दूरस्थ प्रक्रिया कॉल" है, एक बहुत पुरानी अवधारणा है, जो प्राचीन, मध्यम और आधुनिक प्रोटोकॉल को जोड़ती है जो आपको किसी अन्य एप्लिकेशन में एक विधि को कॉल करने की अनुमति देती है। एक्सएमएल-आरपीसी एक प्रोटोकॉल है जो 1998 में एक्सएमएल के आगमन के तुरंत बाद दिखाई दिया। यह मूल रूप से Microsoft द्वारा समर्थित था, लेकिन जल्द ही Microsoft पूरी तरह से SOAP में बदल गया और इसलिए .Net फ्रेमवर्क में हमें इस प्रोटोकॉल का समर्थन करने के लिए कक्षाएं नहीं मिलेंगी। इसके बावजूद, एक्सएमएल-आरपीसी अभी भी विभिन्न भाषाओं (विशेष रूप से पीएचपी) में रहता है, जाहिर है, इसने अपनी सादगी के लिए डेवलपर्स का प्यार अर्जित किया है। एक दिलचस्प एहसास जब आप अंत में समझते हैं कि मैंने एक लंबे समय के लिए फिर से शुरू में क्या लिखा था। यह XML-RPC और मेरे स्टिल स्टूडेंट रिज्यूम के बारे में है। :)

सोप

1998 में Microsoft के प्रयासों से SOAP भी दिखाई दी। इसे सॉफ्टवेयर की दुनिया में एक क्रांति के रूप में घोषित किया गया था। यह कहना नहीं है कि सब कुछ माइक्रोसॉफ्ट की योजना के अनुसार चला गया, प्रोटोकॉल की जटिलता और भारीपन के कारण भारी मात्रा में आलोचना हुई। उसी समय, ऐसे लोग थे जो SOAP को वास्तविक सफलता मानते थे। 2003 में W3C ने अपनी सिफारिश के रूप में SOAP 1.2 को मंजूरी दे दी, जब तक कि प्रोटोकॉल ने दर्जनों नए और नए विनिर्देशों का विकास और उत्पादन जारी रखा, जो अब अंतिम है। SOAP परिवार निकला प्रभावशाली, यहां देखें उनकी पारिवारिक तस्वीर:

(फोटो में - WS- एड्रेसिंग, WS-Enumeration, WS-Eventing, WS-Transfer, WS-Trust, WS-फेडरेशन, वेब सिंगल साइन-ऑन ... और आपको यह याद नहीं है कि दाईं ओर दूसरा है।

दस वर्षों से अधिक के दौरान, SOAP पर बहस थम नहीं रही है, इसकी कम गति के लिए यह अभी भी भीड़ की जमकर आलोचना कर रही है। हालांकि, प्रोटोकॉल इसके विपरीत, मर नहीं गया, हालांकि, दुनिया ने इसे या तो कब्जा नहीं किया। प्रोटोकॉल की आलोचना काफी हद तक सही है : HTTP सुविधाओं का उपयोग नहीं किया जाता है, संदेश की लंबाई REST से अधिक लंबी होती है , इन सभी में WS-फेडरेशन और WS-AtomicTransaction का अक्सर कोई उपयोग नहीं होता है।

लेकिन मैं कुछ और पर ध्यान केंद्रित करना चाहता हूं - आप कितनी जल्दी SOAP प्रोटोकॉल परिवार का उपयोग करके वितरित एप्लिकेशन विकसित कर सकते हैं! क्या यह क्रांति Microsoft ने हमसे वादा नहीं किया है? मेरी राय में, वह वह है। मैं कोड में अन्य विशेषताओं को कहां व्यवस्थित कर सकता हूं, सेवा पर प्रकाशित करें बटन पर क्लिक करें, क्लाइंट पर जनरेट प्रॉक्सी बटन पर क्लिक करें और कोड को कॉल करें जैसे कि यह एक ही परियोजना में है? इसलिए, सबसे आगे का सवाल है कि ऐसी कहानी किन भाषाओं और प्रोग्रामिंग वातावरण में संभव है। मैं इस डेटा को एक तालिका में कम करने का प्रयास करूंगा:

लेकिन REST के बारे में क्या, वास्तव में इसकी आवश्यकता नहीं है?

पते से लेकर SOAP तक सभी चापलूसी शब्दों के बावजूद, मैं किसी भी तरह से यह कहने वाला नहीं हूं कि REST दृष्टिकोण की आवश्यकता नहीं है। REST शब्द 2000 में प्रकट हुआ, अर्थात सोप के पहले संस्करण की तुलना में सिर्फ दो साल बाद। दृष्टिकोण बहुत पहले ही प्रकट हो गया था, 2000 में यह बस एहसास हुआ, प्रलेखित किया गया था, और नाम एक लंबे समय से बदल गया "मैं आपको ऐसी और ऐसी जानकारी देता हूं" एक असंगत "रीस्ट" के लिए। नाम की उत्पत्ति और REST के सिद्धांतों पर लेख के पहले भाग में विस्तार से चर्चा की गई थी। यहां मैं ध्यान दूंगा कि REST का उपयोग कहां और क्यों किया जाता है :

1. जावास्क्रिप्ट से उपयोग की जाने वाली सेवाओं में। यहां कहने के लिए कुछ भी नहीं है, जावास्क्रिप्ट के साथ जावास्क्रिप्ट अच्छी तरह से काम करती है, इसलिए यह वही है जो आपको प्रदान करने की आवश्यकता है।
2. ऐसी सेवाओं में जो उन भाषाओं से उपयोग की जाएंगी जिनमें क्लाइंट प्रॉक्सिस उत्पन्न करने का कोई तरीका नहीं है। उदाहरण के लिए, यह Objective-C है । आपको मैन्युअल रूप से SOAP लिफाफे को पार्स करने की आवश्यकता नहीं है, यह आवश्यक नहीं है।
3. जब बहुत अधिक प्रदर्शन की आवश्यकताएं होती हैं । ये आमतौर पर ट्विटर एपीआई या गूगल एपीआई जैसे बहुत अधिक उपयोग किए जाने वाले एपीआई हैं।

और SOAP का उपयोग कब करें:

1. जब प्लेटफ़ॉर्म के बीच इंटरैक्शन होता है जिसके लिए SOAP का उपयोग करके विकास में तेजी लाने के लिए उपकरण मौजूद हैं । उदाहरण के लिए, JAVA में SOAP सेवा लिखना सही है, जिसका उपयोग .Net और फ्लेक्स से किया जाएगा।
2. जब सभी एसओएपी धोखा से लाभ संभव है। मेरे पास विश्वसनीय जानकारी नहीं है कि कोई ऐसा करने में कामयाब रहा। मैं एक स्पष्ट उदाहरण के साथ नहीं आ सकता।

इस प्रकार, यह सब इस तथ्य पर उतर आया कि आपको SOAP का उपयोग करने की आवश्यकता है जहां यह समर्थित है, अन्यथा REST का उपयोग करें । यह वेब सेवा ग्राहकों को विकसित करने और उनमें परिवर्तन करने और कोड को विस्तार से दर्ज करने और वहां नए क्षेत्र जोड़ने के बजाय, "अपडेट सेवा संदर्भ" बटन पर क्लिक करने के समय को काफी कम कर देगा।

.Net में REST और SOAP सेवाओं की विकास गति समान है। WCF में, सामान्य तौर पर, आप विन्यास के साथ सरल और समय लेने वाली धोखाधड़ी से SOAP सेवा को रूस्टफुल और इसके विपरीत में बदल सकते हैं, इसलिए, विकास की गति को तेज करने की बात करते हुए, मेरा मतलब है कि ग्राहक भाग, जिसे सर्वर भाग के साथ एक साथ विकसित किया जा सकता है, और बहुत बाद में और पूरी तरह से। दूसरी कंपनी। SOAP का उपयोग करने के लाभ बढ़ जाते हैं यदि सेवा स्वीकार करती है और बड़े और जटिल डेटा संरचनाओं को वापस करती है ।

क्या SOAP दिन गिने जाते हैं?

REST और SOAP दोनों अब सफलतापूर्वक उपयोग किए जाते हैं, लेकिन ऐसा हो सकता है कि SOAP वास्तव में गायब हो जाए, जैसा कि इसके आलोचक लिखते हैं। यह, मेरी राय में, संभव है अगर RESTful सेवाओं के लिए WSDL या इसी तरह के एक प्रोटोकॉल का उपयोग किया जाना शुरू हो जाए, जो क्लाइंट प्रॉक्सी की पीढ़ी को अनुमति देगा। ऐसे ढोंगी थे, प्रोटोकॉल को WADL कहा जाता था, लेकिन फिलहाल इस तरह का कुछ भी मौजूद नहीं है। बेशक, इस तरह के परिदृश्य के लिए आईटी दुनिया में कम से कम एक मुख्य खिलाड़ी की इच्छा और सभ्य प्रयासों की आवश्यकता होगी, लेकिन मैं इस तरह के विकल्प को खारिज नहीं करूंगा। और फिर हमारे पास दो दुनियाओं में से सबसे अच्छा होगा - नेटवर्क आर्किटेक्चर से सरलता और लाभ और क्लाइंट प्रॉक्सी का उपयोग करके एप्लिकेशन इंटरैक्शन को स्वचालन।

उदाहरण

क्या हर कोई लेख की शुरुआत से उदाहरण के बारे में भूल गया है? उसे जीवन से लिया जाता है। आपको याद दिला दूं कि एक WPF एप्लिकेशन विकसित किया गया है जिसे JAVA में लिखी गई मौजूदा सेवा से डेटा प्राप्त करना चाहिए। वह हमें किस प्रारूप में डेटा दे सकता है ताकि सब कुछ इस लेख के अनुसार सुंदर लगे? सही, SOAP में। और वह जसन देता है। मुझे आशा है कि किसी ने भी यह नहीं सोचा है "REST के अर्थ में यह किस तरह का है?" बेशक ! REST साधारण XML, json, या किसी अन्य अनुरोधित प्रारूप में डेटा लौटा सकता है, यहां तक ​​कि प्रारूप में भी "जैसा कि वास्या ने पूछा था", जब तक कि आप इस प्रारूप को अनुशंसित W3C मानकों में से एक बनाने में सक्षम नहीं हैं या कम से कम सेवा के डेवलपर्स से सहमत हैं, ताकि वे जान सकें कि क्या करना है इसके द्वारा:

Content-Type: application/as-Vasya-asked; charset=utf-8

हम व्यापार से विचलित हैं। खैर, सेवा डेटा को जसन में लौटाती है, और इससे हमें क्या खतरा है? लेकिन यहाँ एक बात है: हम ग्राहक के लिए एक प्रॉक्सी नहीं बना सकते हैं, हमें मैन्युअल रूप से अनुरोध और पार्स उत्तर भेजने होंगे। आपको इसके ऊपर HttpWebRequest या ऐड-ऑन का उपयोग करना होगा। और SOAP होगा - ग्राहक का पैसा बच जाएगा।

निष्कर्ष

मुझे आशा है कि मैं भाषा और मंच की परवाह किए बिना, अनुप्रयोगों के आदान-प्रदान की एक समग्र समग्र तस्वीर को रेखांकित करने में सक्षम था। मैं जोड़ना चाहता था कि वर्णित तीन दृष्टिकोण (REST, XML-RPC, SOAP) सभी संभव विकल्प नहीं हैं। उदाहरण के लिए, सामाजिक नेटवर्क के लिए खिलौने (फ्लेक्स में लिखे गए) अक्सर सॉकेट्स के माध्यम से सी # में लिखे गए सर्वर साइड पर एक सीधा संबंध स्थापित करते हैं। इसके कारण, प्रत्येक नए आवेदन के लिए मोपेड का आविष्कार करने की आवश्यकता के साथ गति में एक लाभ प्राप्त होता है। कहीं यह पहले से ही था ...
यह संभव है कि मैं कुछ महत्वपूर्ण चूक गया, खासकर अगर यह चिंता नहीं करता है। नेट, मुझे इसके बारे में जानकर खुशी होगी।

PS कल के लिए अपने कर्म को बढ़ाने के लिए int03e , SSSurkv और 1nd1go के लिए धन्यवाद। ताकि मैं इस लेख को प्रकाशित कर सकूं ।