लाइब्रेरी के बजाय सेवाओं (REST / SOAP) का उपयोग क्यों करें?

22

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

api soa services

— नैट रीड
स्रोत

6

हे नैट, स्टीवे के Google प्लेटफ़ॉर्म रेंट को पढ़ें , यह प्लेटफ़ॉर्म (सेवाओं) बनाम उत्पाद (पुस्तकालय) प्रश्न पर महान अंतर्दृष्टि प्रदान करता है ...

— yannis

11

दोनों के बीच अंतर सूक्ष्म हो सकता है। उदाहरण के लिए .NET की दुनिया में, आपके पास एक ऐसा एप्लिकेशन हो सकता है जो एक अंतिम उपयोगकर्ता के लिए अखंड जैसा महसूस होगा और जो एक ही मशीन पर काम करेगा, लेकिन अंदर, WCF सेवाओं के एक समूह में अलग हो जाएगा। आपके पास ऐसे आर्किटेक्चर भी हो सकते हैं जहां लाइब्रेरीज़ दृढ़ता से जुड़ी हुई नहीं हैं (एडिंस / प्लगइन्स) और एक दूसरे से बात करते समय एक प्रोटोकॉल का पालन कर रहे हैं।

यदि हम उन मध्यस्थ मामलों के बारे में बात करने से बचते हैं, और केवल दृढ़ता से जुड़े एपीआई पुस्तकालय बनाम एक अलग आरईएस सेवा से निपटते हैं, तो आप निम्नलिखित बिंदुओं पर विचार करना चाह सकते हैं:

लाइब्रेरी API को उसी मशीन पर कहा जाता है। सेवाओं को कहीं भी होस्ट किया जा सकता है और कहीं से भी कॉल किया जा सकता है। यदि आप प्रदर्शन / स्केलेबिलिटी / सुरक्षा कारणों से कई मशीनों पर एप्लिकेशन को होस्ट कर रहे हैं, तो संभावना है कि आपको सेवाओं का उपयोग करना होगा।
स्थिति समान है जब यह कई मशीनों पर तैनात एक अनुप्रयोग द्वारा एक सेवा का उपयोग करने के लिए जाता है। उदाहरण के लिए यदि आप कुछ वित्तीय संगणना करने वाले बैंक के लिए आवेदन कर रहे हैं, तो एक तरीका यह है कि हर डेस्कटॉप पर पूरे बड़े एप्लिकेशन को तैनात किया जाए, और हर ग्राहक को बड़े आकार के अपडेट करने के लिए मजबूर किया जाए; एक और तरीका यह होगा कि सर्वर पर कम्प्यूटेशन पार्ट को होस्ट किया जाए, और डेस्कटॉप के लिए केवल यूआई और उन सर्वर पर कॉल का एक गुच्छा के साथ एक हल्के ऐप को तैनात किया जाए।
यदि आप एक REST सेवा की मेजबानी कर रहे हैं, तो कोई भी इसका उपयोग कर सकता है: एक मैक उपयोगकर्ता, लिनक्स का उपयोग करने वाला व्यक्ति, आदि। यदि आपने विजुअल स्टूडियो के साथ C # लाइब्रेरी बनाई है और आप इसे DLL के रूप में वितरित करते हैं, तो उपयोगकर्ताओं (ग्राहकों के बारे में) को भूल जाएं। ;) जिनके पास विंडोज नहीं है।

— आर्सेनी मूरज़ेंको
स्रोत

9

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

— माइक ओ'कॉनर
स्रोत

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

— Lews थेरिन

8

पुस्तकालय लाभ:

प्रति ओवरहेड लोअर कॉल (केवल कूद या इनलाइन ) = प्रदर्शन को बढ़ा सकता है
सबसे सरल बात जो संभवतः काम कर सकती है
सभी उपभोक्ताओं पर केंद्रीयकृत सेवा के कम होने और प्रभावित होने का कोई खतरा नहीं है

सेवा लाभ:

सभी को तुरंत और पारदर्शी रूप से अपग्रेड किया जाता है (जब तक कि एपीआई की पेशकश नहीं की जाती)
उपभोक्ता कोड को अपघटित नहीं कर सकते हैं
सर्विस हार्डवेयर को अलग से स्केल कर सकते हैं
प्रौद्योगिकी अज्ञेय। एक साझा पुस्तकालय के साथ, उपभोक्ताओं को एक संगत प्रौद्योगिकी का उपयोग करना चाहिए।
ज्यादा सुरक्षित। यूआई टियर उस सेवा को कॉल कर सकता है जो डीबी तक सीधे पहुंचने के बजाय एक फ़ायरवॉल के पीछे बैठता है।

— कोरी हाउस
स्रोत

"मूल कोड" वास्तव में यहां कोई मतलब नहीं है: ए) एक सेवा "मूल कोड" का भी उपयोग कर सकती है, और बी) सिर्फ-समय संकलन अक्सर मूल कोड के समान प्रदर्शन प्रदान करता है।

— सिल्के

मुद्दा लेना। जब मैं कहता हूं कि मैं "मूल कोड" कहता हूं तो यह है कि एक पुस्तकालय एक "प्रक्रिया में" कॉल है। वहाँ कोई सेवा परत उपरि नहीं है (जैसे HTTP यदि वेब API कॉल कर रहा है)

— Cory House

हां, कॉल ओवरहेड वास्तव में कम होना चाहिए। मैंने आपके उत्तर को संपादित करने की स्वतंत्रता ली, "लोअर कॉल ओवरहेड" के साथ "मूल कोड" के उल्लेख को बदलने के लिए। यदि आप असहमत हैं तो :-) फिर से संपादित करें।

— सिल्के

मुझे जो जोड़ना पसंद है वह है लेन-देन का उपयोग । यह आमतौर पर सेवा सीमाओं में लेन-देन का काम करने के लिए बहुत कठिन है, क्योंकि यह एक साझा पुस्तकालय में है।

— c_mart

2

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

— Jiggy
स्रोत

1

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

— पॉल टी डेविस
स्रोत

0

कई अच्छे उत्तर हैं, लेकिन मैं दिए गए उत्तरों में और चीजें जोड़ना चाहूंगा:

एपीआई लाइब्रेरी विधि बहुत उपयोगी है जब आप चीजों को जितना संभव हो उतना कम ओवरहेड के साथ बातचीत करना चाहते हैं। परिणाम यह है कि एपीआई और इसके उपयोग वाले अनुप्रयोगों के बीच एक उच्च युग्मन है। कभी-कभी, यह आवेदन के लिए ठीक है और यहां तक कि आवश्यक भी है, हालांकि यदि आपके पास बहुत वितरित प्रणाली है या आपको लगता है कि अंतरनिर्धारण एक बहुत बड़ा मुद्दा है, तो आपको बाद में एक कदम ऊपर जाने और संचार के अन्य तरीकों का उपयोग करने की आवश्यकता हो सकती है। विशेष रूप से, यदि आप एक वितरित प्रणाली चाहते हैं, तो SOAP SOA में अगले चरण की तरह है, लेकिन आप अभी भी इकाइयों के बीच निर्भरता से बचे रहेंगे, क्योंकि उन्हें एक-दूसरे की प्रक्रियाओं को जानना होगा। REST इसे एक एकीकृत स्तर पर अन्य सेवाओं पर सामग्री के बारे में कुछ सीखने की अनुमति देकर मशीन को एक नए स्तर पर ले जाता है।

आपके मामले में, यदि आपका आवेदन वितरित नहीं किया गया है, तो मुझे आपके आवेदन को SOA में बदलने का कोई कारण नहीं दिखता है।

— Aagaard
स्रोत