HTTP/SOAP को "मोटी"

Question

क्यों माना जाता है मैंने कुछ राय सुना है कि SOAP/HTTP वेब सेवा कॉल स्टैक "मोटी" या "हेवीवेट" है, लेकिन मैं वास्तव में क्यों इंगित नहीं कर सकता। एसओएपी लिफाफे और संदेश के क्रमिकरण/deserialization के कारण यह मोटी माना जाएगा? क्या यह वास्तव में एक भारी वजन ऑपरेशन है?

या क्या यह एक निश्चित कनेक्शन पर कच्चे/बाइनरी डेटा हस्तांतरण की तुलना में "मोटी" माना जाता है?

या यह कोई अन्य कारण है? क्या कोई इस पर रोशनी डाल सकता है?

Answer 1

SOAP को HTTP के अलावा अन्य ट्रांसपोर्ट का उपयोग करने के लिए पर्याप्त सार बनाने के लिए डिज़ाइन किया गया है। इसका मतलब है कि, अन्य चीजों के साथ, यह HTTP के कुछ पहलुओं का लाभ उठाता है (ज्यादातर यूआरएल और विधियों का रीस्टफुल उपयोग, उदाहरण के लिए PUT /customers/1234 या GET /customers/1234)।

SOAP उसी कारण से मौजूदा टीसीपी/आईपी तंत्र को भी छोड़ देता है - परिवहन-स्वतंत्र होने के लिए। दोबारा, इसका मतलब है कि यह अनुक्रम प्रबंधन, प्रवाह नियंत्रण, सेवा खोज (उदाहरण के लिए accept() एक प्रसिद्ध बंदरगाह पर एक कनेक्शन में आईएनजी का मतलब है) सेवा का लाभ नहीं ले सकता है, आदि

SOAP उपयोग एक्सएमएल के सभी सीरियलाइजेशन के लिए - जबकि इसका मतलब है कि डेटा केवल एक एक्सएमएल पार्सर के साथ "सार्वभौमिक रूप से पठनीय" है, यह इतनी बॉयलरप्लेट पेश करता है कि आपको कुशलता से कार्य करने के लिए वास्तव में एक एसओएपी पार्सर की आवश्यकता होती है। और उस समय, आप (एक सॉफ्टवेयर उपभोक्ता के रूप में) ने एक्सएमएल का लाभ खो दिया है; अगर आपको किसी भी तरह से इसे संभालने के लिए libSOAP की आवश्यकता होती है तो तार पर तार की तरह दिखता है।

एसओएपी को इंटरफेस का वर्णन करने के लिए डब्ल्यूएसडीएल की आवश्यकता है। डब्ल्यूएसडीएल स्वयं एक समस्या नहीं है, लेकिन यह वास्तव में जितना अधिक "गतिशील" है, उतना ही विज्ञापित किया जाता है। कई मामलों में, एक एकल डब्लूएसडीएल बनाया जाता है, और निर्माता/उपभोक्ता कोड उस से स्वतः उत्पन्न होता है, और यह कभी भी नहीं बदलता है। कुल मिलाकर, इसके लिए वास्तव में मूल समस्या को हल किए बिना बहुत सारे टूलींग की आवश्यकता होती है (विभिन्न सर्वरों के बीच संवाद कैसे करें) किसी भी बेहतर तरीके से। और चूंकि अधिकांश एसओएपी सेवाएं HTTP पर चलती हैं, इसलिए मूल समस्या पहले से ही अधिक से शुरू करने के लिए हल हो गई थी।

Answer 2

सबसे पहले, यह आपकी सेवाओं को कैसे लागू किया जाता है इस पर निर्भर करता है (यानी आप अपने विधि हस्ताक्षर कैसे किए जाते हैं, इस बारे में सावधान रहकर पेलोड को कम करने के लिए बहुत कुछ कर सकते हैं)।

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

सामान के संग्रह को वापस करने के तरीकों से धारावाहिक विधि रिटर्न के निम्नलिखित उदाहरणों पर विचार करें। कक्षाओं/रैपरों के लिए बस सही [क्रमबद्धता] नाम चुनना और सदस्यों को क्रमबद्ध डेटा (जैसे सूचियां/संग्रह/सरणी) लौट रहे हैं तो क्रमबद्ध साबुन अनुरोध/प्रतिक्रिया की क्रिया में एक बड़ा अंतर डाल सकते हैं।

संक्षिप्त/लघु नाम:

<?xml version="1.0" encoding="utf-8"?> 
<ArrayOfShortIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/"> 
    <ShortIDName> 
    <id>0</id> 
    <name>foo 0</name> 
    </ShortIDName> 
    <ShortIDName> 
    <id>1</id> 
    <name>foo 1</name> 
    </ShortIDName> 
    <ShortIDName> 
    <id>2</id> 
    <name>foo 2</name> 
    </ShortIDName> 
    ... 
</ArrayOfShortIDName> 

लांग नाम:

<?xml version="1.0" encoding="utf-8"?> 
<ArrayOfThisClassHasALongClassNameIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/"> 
    <ThisClassHasALongClassNameIDName> 
    <MyLongMemberNameObjectID>0</MyLongMemberNameObjectID> 
    <MyLongMemberNameObjectName>foo 0</MyLongMemberNameObjectName> 
    </ThisClassHasALongClassNameIDName> 
    <ThisClassHasALongClassNameIDName> 
    <MyLongMemberNameObjectID>1</MyLongMemberNameObjectID> 
    <MyLongMemberNameObjectName>foo 1</MyLongMemberNameObjectName> 
    </ThisClassHasALongClassNameIDName> 
    <ThisClassHasALongClassNameIDName> 
    <MyLongMemberNameObjectID>2</MyLongMemberNameObjectID> 
    <MyLongMemberNameObjectName>foo 2</MyLongMemberNameObjectName> 
    </ThisClassHasALongClassNameIDName> 
    ... 
</ArrayOfThisClassHasALongClassNameIDName> 

Answer 3

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

फिर उस के लिए WSDL और ठेठ "उद्यम" पुस्तकालय कार्यान्वयन की जटिलता बढ़ ...

Answer 4

मैं इसे अपेक्षाकृत बड़े पैकेजिंग और संदेश खोल के साथ शामिल भूमि के ऊपर की वजह से "मोटी" (serializing और deserializing माना)।

Add नामक वेब विधि के साथ एक वेब सेवा पर विचार करें जो दो 32-बिट पूर्णांक लेता है। कॉलर दो पूर्णांक को संकुल करता है और उत्तर में एक पूर्णांक प्राप्त करता है। जहां वास्तव में केवल 9 6 बिट सूचनाएं प्रसारित की जा रही हैं, एसओएपी पैकेट के अतिरिक्त प्रत्येक दिशा में लगभग 3,000 या अधिक अतिरिक्त बिट्स जोड़ देंगे। एक 30x वृद्धि।

इसमें जोड़ा गया यूटीएफ -8 (या जो कुछ भी) एक्सएमएल में संदेश को क्रमबद्ध करने और deserializing के साथ अपेक्षाकृत धीमी प्रदर्शन है। माना जाता है कि इन दिनों यह बहुत तेज है, लेकिन यह निश्चित रूप से तुच्छ नहीं है।

Answer 5

एसओएपी का सिग्नल-टू-शोर अनुपात बहुत कम है। एक साधारण बातचीत के लिए कोई डेटा मूल्य के साथ बहुत अधिक संरचनात्मक ओवरहेड है; और वहां बहुत अधिक स्पष्ट कॉन्फ़िगरेशन आवश्यक है (जेएसओएन की तरह निहित कॉन्फ़िगरेशन की तुलना में)।

यह इस तरह से शुरू नहीं हुआ, लेकिन मानकों की समिति में शामिल होने पर एक अच्छा विचार होने के लिए यह एक पोस्टर-बच्चे बन गया।

Answer 6

1 - एक्सएमएल स्कीमा, जो डब्लूएसडीएल स्पेक का एक प्रमुख हिस्सा हैं, वास्तव में, वास्तव में बड़े और जटिल हैं। व्यावहारिक रूप से, आप टूल्स जो प्रोग्रामिंग भाषा संरचनाओं के लिए मानचित्र एक्सएमएल स्कीमा जैसी चीजें करते हैं, केवल एक्सएमएल स्कीमा सुविधाओं के सहायक भाग को समाप्त करते हैं।

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

Answer 7

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

require 'xmlrpc/client' 

server = XMLRPC::Client.new2("http://example.com/api") 
result = server.call("add", 1, 2) 

XML-RPC के अलावा, वहाँ इस तरह के सादे XML या HTTP पर JSON के रूप में अन्य तकनीकों है कि यह भी बहुत अधिक सरल और हल्के हो सकता है, कर रहे हैं (अक्सर, REST रूप में जाना जाता है, हालांकि यह है कि संकेत मिलता है कुछ अन्य डिजाइन विचार)। HTTP पर XML या JSON जैसे कुछ का लाभ यह है कि जावास्क्रिप्ट से उपयोग करना आसान है या यहां तक ​​कि फ़ॉर्म सबमिट करने के साथ केवल एक गूंगा वेब पेज है। इसे curl जैसे टूल के साथ कमांड लाइन से आसानी से स्क्रिप्ट किया जा सकता है। यह किसी भी भाषा के साथ काम करता है क्योंकि HTTP पुस्तकालय, एक्सएमएल पुस्तकालय, और जेएसओएन पुस्तकालय लगभग हर जगह उपलब्ध हैं, और यहां तक ​​कि यदि कोई JSON पार्सर उपलब्ध नहीं है, तो यह स्वयं लिखना बहुत आसान है।

संपादित करें: मैं स्पष्ट करना चाहिए कि मैं कैसे धारणात्मक हैवीवेट सोप है की चर्चा करते हुए कर रहा हूँ, के रूप में भारी वजन के लिए विरोध यह डेटा के कच्चे राशि के मामले में है।मुझे लगता है कि डेटा की कच्ची मात्रा कम महत्वपूर्ण है (हालांकि यदि आपको बहुत से छोटे अनुरोधों को संभालने की आवश्यकता है तो यह तेज़ी से बढ़ता है), जबकि यह अवधारणात्मक रूप से हेवीवेट कितना महत्वपूर्ण है, क्योंकि इसका मतलब है कि वहां बहुत अधिक जगहें हैं जहां कुछ गलत हो सकता है, जहां एक असंगतता हो सकती है, आदि

Answer 8

मैं पहले पोस्टर से सहमत हूं, लेकिन इसमें शामिल करना चाहता हूं। मोटी और पतली परिभाषा सापेक्ष है। जेएसओएन या आरईएसटी जैसे उभरते एसओएपी जैसे परिवहन के साथ "हैलो वर्ल्ड" उदाहरणों के लिए सतह पर भारी दिखता है। अब जैसा कि आप पहले से ही जानते हैं कि एसओएपी भारी और डब्ल्यूएस 2.0 सामान्य रूप से उद्यम/मजबूत विशेषताएं क्या बनाता है। जेएसओएन उसी तरह से सुरक्षित नहीं है जिस तरह डब्ल्यूएस 2.0 हो सकता है। मैंने एसओएपी को मोटी के रूप में नहीं सुना है, लेकिन कई गैर-एक्सएमएल पागल इन विनिर्देशों को भारी या मोटी के रूप में देखते हैं। स्पष्ट होने के लिए मैं दोनों के लिए या उसके खिलाफ बात नहीं कर रहा हूं क्योंकि दोनों के पास उनकी जगह है। एक्सएमएल अधिक वर्बोज़ और मानव पठनीय और इस प्रकार "मोटा"। आखिरी टुकड़ा यह है कि कुछ लोग HTTP को एक स्थायी कनेक्शन प्रोटोकॉल को भारी पृष्ठ पर सेवा देने के बजाए AJAX जैसे नए वेब रुझानों को भारी मानते हैं। कनेक्शन ओवरहेड बड़ा है क्योंकि वास्तव में कोई लाभ नहीं है।

संक्षेप में, कोई असली कारण कोई अन्य SOAP/HTTP मोटी कॉल करना चाहता है, यह सब रिश्तेदार है। कम मानकों को सही और सभी परिदृश्यों के लिए हैं। अगर मुझे लगता है कि कुछ स्मार्ट वेब डेवलपर सोचते हैं कि वह एक्सएम टेक्नोलॉजीज और कैसे सुपर JSON है, इस बारे में बात करके ओह इतना स्मार्ट हो रहा है। प्रत्येक में एक जगह है।