किसी वेब सेवा का उपयोग कब नहीं किया जाना चाहिए?

Question

एक वेब सेवा का उपयोग अक्सर एक उत्कृष्ट वास्तुकला दृष्टिकोण है। और, .NET में डब्ल्यूसीएफ के आगमन के साथ, यह और भी बेहतर हो रहा है।

लेकिन, मेरे अनुभव में, कुछ लोगों को लगता है कि वेब सेवाओं को हमेशा डेटा एक्सेस लेयर में डेटाबेस के लिए कॉल के लिए उपयोग किया जाना चाहिए। मुझे नहीं लगता कि वेब सेवाएं सार्वभौमिक समाधान हैं।

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

कोई वेब सेवा के साथ और बिना वेब वेब के दो संस्करण बनाकर इसका परीक्षण कर सकता है, और तनाव परीक्षण कर सकता है, लेकिन मैंने इसे नहीं किया है।

क्या आपके पास छोटे पैमाने पर वेब ऐप के लिए वेब सेवाओं का उपयोग करने पर कोई राय है? कोई अन्य मौका जब वेब सेवाएं एक अच्छी वास्तुशिल्प पसंद नहीं हैं?

Answer 1

वेब सेवाओं डेटा पहुंच के लिए एक बिल्कुल भयानक पसंद है। यह लगभग शून्य लाभ के लिए ओवरहेड और जटिलता का एक टन है।

यदि आपका ऐप एक मशीन पर चलने वाला है, तो इसे डेटा एक्सेस कॉल में प्रक्रिया करने की क्षमता क्यों नकारें? मैं सीधे आपके यूआई कोड से डेटाबेस तक पहुंचने के बारे में बात नहीं कर रहा हूं, मैं आपके भंडारों को दूर करने के बारे में बात कर रहा हूं लेकिन अभी भी आपकी चल रही वेबसाइट में उनकी असेंबली शामिल है।

ऐसे मामले हैं जहां मैं वेब सेवाओं की सिफारिश करता हूं (और मुझे लगता है कि आप एसओएपी का मतलब मानते हैं) लेकिन यह ज्यादातर अंतःक्रियाशीलता के लिए है।

सेवाओं की ग्रैन्युलरिटी भी यहां प्रश्न में है। एसओए भावना में एक सेवा एक ऑपरेशन या एक व्यापार प्रक्रिया encapsulate जाएगा। डेटा एक्सेस विधियां केवल उस प्रक्रिया का हिस्सा हैं।

दूसरे शब्दों में: वेब सेवाओं के लिए

- someService.SaveOrder(order); // <-- bad 
    // some other code for shipping, charging, emailing, etc 

    - someService.FulfillOrder(order); //<-- better 
    //the service encapsulates the entire process 

वेब सेवाओं गैर जिम्मेदाराना प्रोग्रामिंग है।

Answer 2

यदि आप अपने इंट्रानेट के लिए एक छोटा (50 से कम उपयोगकर्ता) वेब एप्लिकेशन कोडिंग कर रहे हैं, तो एक वेब सेवा ओवरकिल लगती है। विशेष रूप से यदि इसका प्राथमिक कार्य (कई सेवाओं तक पहुंच का एक बिंदु प्रदान करना) का उपयोग नहीं किया जाएगा।

Answer 3

एक छोटे पैमाने पर वेब ऐप के लिए (आपको सवाल पूछना है, "क्या यह हमेशा छोटे पैमाने पर रहेगा?" हालांकि) वेब सेवाओं का उपयोग करके, अलग-अलग व्यावसायिक परतें, डेटा परतें, और इसी तरह से आगे बढ़ सकते हैं ।

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

हालांकि ... सवाल पूछना याद रखें "क्या यह हमेशा छोटे पैमाने पर रहेगा?" :-)

Answer 4

मैं मानता हूं कि एक छोटे पैमाने पर वेब ऐप में एक वेब सेवा का उपयोग जटिलता की एक परत जोड़ता है जो उचित नहीं लगता है। मेरे अधिकांश समाधान, इंटरनेट और इंट्रानेट, 10-50 उपयोगकर्ता, वेब सेवाओं को नियोजित नहीं करते हैं। मुझे खुशी है कि दूसरों को भी ऐसा लगता है ... मैंने सोचा कि मैं अकेला था।

Answer 5

सिर्फ इसलिए कि उपकरण स्टब्स का एक गुच्छा उत्पन्न करता है इसका मतलब यह नहीं है कि यह एक अच्छा उपयोग है। डब्ल्यूएस- * उन परिदृश्यों में उत्कृष्टता है जहां आप बाहरी पार्टियों के लिए सेवाएं का पर्दाफाश करते हैं। इसका मतलब यह है कि डेटा ऑपरेशन के विपरीत प्रत्येक ऑपरेशन व्यवसाय प्रक्रिया की ग्रैन्युलरिटी पर होना चाहिए।

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

यह सब स्वचालित रूप से जेनरेट होने के लिए असंभव के बगल में है। सी # स्टब जेनरेटर केवल आपकी कक्षा का भौतिक इंटरफ़ेस जानता है, लेकिन इसमें शामिल अर्थशास्त्र के बारे में कोई जानकारी नहीं है। अधिक विस्तृत चर्चा के लिए this paper देखें।

यदि आप कोई वेबसाइट बना रहे हैं, तो एक वेबसाइट बनाएं। यदि आप अपने आवेदन के अंदर एसिंक्रोनस मैसेजिंग चाहते हैं, तो MSMQ का उपयोग करें। यदि आप आंतरिक ग्राहकों को डेटा का खुलासा करना चाहते हैं, तो POX का उपयोग करें। यदि आपको कुशल बाइनरी संदेश प्रारूप की आवश्यकता है, तो Google के Protocol Buffers देखें या यदि आपको RPC चेक Hessian for C# या DCOM की आवश्यकता है।

वेब सेवाएं एक मोटे अनाज वाले एकीकरण समाधान हैं। वे कठोर हैं, वे विकल्पों की तुलना में धीमे हैं, वे अच्छी तरह से करने के लिए बहुत अधिक प्रयास करते हैं (और जब अच्छी तरह से नहीं किया जाता है तो व्यर्थ के बगल में होते हैं)।

संक्षेप में: "वेब सेवा का उपयोग कब किया जाना चाहिए?" - कभी भी आप के बिना प्राप्त कर सकते हैं यह

Answer 6

निक हैरिसन, शेर्लोट में एक शानदार डेवलपर, इन परिदृश्यों का सुझाव दिया है, जहां एक वेब सेवा का उपयोग करता है भावना:

• एक वेब खेत पर, जहां की मेजबानी कई वेब सर्वर देखते हैं वेबसाइट (ओं), सभी वेब सेवा पर इंगित करते हैं जो किसी अन्य वेब सर्वर पर चल रहे हैं। यह एकाधिक सर्वरों पर लोड को वितरित करने की अनुमति देता है।
• ग्राहक/सर्वर, जहां विंडोज़ ऐप्स बनाते हैं, वे एक वेब सेवा कॉल कर सकते हैं।
• क्रॉस मंच
• एक फ़ायरवॉल

Answer 7

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

हालांकि ऐसा नहीं निम्न परिदृश्यों में उपयोग वेब सेवाओं:

• आप परिवहन और अपने डेटा के Xml क्रमबद्धता के रूप में Http का उपयोग करना चाहिए और आप डेटा के विभिन्न बिट्स के बहुत सारे, तुल्यकालिक की जरूरत है और अक्सर। चाहे आरईएसटी या एसओएपी या डब्ल्यूएस- * आपको प्रदर्शन के मुद्दों का सामना करना पड़ेगा। आप जितनी अधिक कॉल करेंगे उतनी धीमी गति से आपके सिस्टम होंगे।यदि आप डेटा के मध्यम आकार के हिस्सों को कम बार-बार चाहते हैं, तो असीमित रूप से और आप सीधे TcpIp (उदा। Wcf netTcp बाइंडिंग) का उपयोग कर सकते हैं, तो आप बेहतर होंगे।
• जब आप क्वेरी और अन्य डेटा स्रोतों के साथ अपने वेब सेवा से डेटा में शामिल होने की जरूरत है, बल्कि एक डेटा गोदाम जो enterprize भर से ठीक से समेकित और युक्तिसंगत बनाया डेटा के साथ किया जा सकता है के लिए प्रेरित

यह मेरा अनुभव है , आशा करता हूँ की ये काम करेगा।