Webservices से पहले डेस्कटॉप एप्लिकेशन ने दूरस्थ सर्वर के साथ कैसे संवाद किया?

11

मेरे पास डेस्कटॉप एप्लिकेशन के साथ बहुत अधिक विस्तार नहीं है, लेकिन अगर मुझे एक क्लाइंट सर्वर डेस्कटॉप ऐप बनाना है, तो डेटा एक्सेस एक वेब सेवा के माध्यम से किया जाएगा। मेरा मानना है कि webservice के माध्यम से डेटा एक्सेस सुरक्षा प्रदान करता है - मुझे db सर्वर उपयोगकर्ता नाम और पासवर्ड आदि में पास होने की आवश्यकता नहीं है।

Webservices से पहले, डेटाबेस एप्लिकेशन ने यह कैसे किया? क्या सभी महत्वपूर्ण डीबी जानकारी डेस्कटॉप ऐप की स्थापना में पारित हो गई थी? यदि ऐसा है तो प्रोग्रामर सुरक्षा पहलू का प्रबंधन कैसे करते हैं? या प्रोग्रामर ने webservices के समान कुछ का उपयोग किया?

programming-practices security

— हॉवेल्स हाग्रिड
स्रोत

5

दूरस्थ प्रक्रिया कॉल के लिए मज़ेदार चीज़ें थीं, जैसे DCOM (वितरित COM), CORBA, Java RMI ... मुझे उनमें से कोई भी पूरी तरह से समझ में नहीं आया, जबकि HTTP के माध्यम से कुछ डेटा तुरंत मांगने का अर्थ था। मुझे लगता है कि वेब ब्राउज़र का उपयोग करने से हर रोज़ वेबसर्विस को आसान बनाने के लिए :-)

— marcus

3

@marcus: संभवतः क्योंकि HTTP में अनुरोध-प्रतिसाद बनाया गया है, जबकि "कुछ सॉकेट पर कुछ प्रोटोकॉल" का परिणाम सभी में उस पहिये को थोड़ा अलग आकार देने में है।

— स्टीव जेसप

11

इसके आधार पर जिसे आप वेब सेवा कहते हैं।

WSDL और REST से पहले, अभी भी HTTP था, इसलिए मूल रूप से अब आप जो कुछ भी कर सकते हैं वह सब पहले भी किया जा सकता है।

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

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

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

17

आह, पीछे जब हम लाठी और पत्थर थे।

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

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

इंटरनेट के बहुत शुरुआती चरणों से, मशीनों के उस पार संचार करने के तरीके थे। वेब सेवाएँ सप्ताह का केवल नवीनतम स्वाद हैं।

— रॉबर्ट हार्वे
स्रोत

5

"वहाँ उस के बारे में बिल्कुल कुछ भी नहीं जादुई है, दोनों पक्षों बस क्या सब मतलब बाइट्स पर सहमत होना होगा।" और endianness :)

— hjk

2

@ हज्क, यह आसान है: लिटिल-एंडियन स्व-स्पष्ट रूप से अन्य सभी विकल्पों से बेहतर है :-)

— मार्क

3

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

— स्टीव जेसप

2

@SteveJessop: आप गलत हैं, " यह ट्यूबों की एक श्रृंखला है "।

— Deduplicator

3

बस कुछ अवधारणाओं को स्पष्ट करने के लिए पहले ...

मेरा मानना है कि webservice के माध्यम से डेटा एक्सेस सुरक्षा प्रदान करता है - मुझे db सर्वर उपयोगकर्ता नाम और पासवर्ड आदि में पास होने की आवश्यकता नहीं है।

मुझे लगता है कि आप उपरोक्त कथन में (1) ट्रांसपोर्ट लेयर सिक्योरिटी (TLS) और (2) एक्सेस कंट्रोल के कॉन्सेप्ट को कन्फ़र्म कर रहे हैं ... वेब सेवा है या नहीं, इसके लिए यूजर नेम और पासवर्ड की जरूरत है या नहीं (1) एक एन्क्रिप्टेड चैनल और (2) प्रमाणीकरण (जैसे एपीआई कुंजी) के माध्यम से प्रदान किया गया।

एक बेहद खराब लिखित वेब सेवा को अभी भी HTTP पर प्लेनटेक्स्ट में भेजे जाने वाले पासवर्ड की आवश्यकता हो सकती है। एक खराब लिखा हुआ व्यक्ति HTTPS (सुरक्षित, लेकिन एक बार टूटने के बाद, जैसे कि एक आदमी के बीच का हमला, दुरुपयोग के लिए खुला) के माध्यम से कर सकता है। एक बेहतर लिखित वेब सेवा को अन्य कनेक्टिविटी के आधार पर डेटाबेस कनेक्टिविटी को संभालना चाहिए, जैसे कि प्रमाणीकरण और हकदारी नियंत्रण मान्य होने के बाद सत्र आईडी,।

मुख्य बिंदु पर वापस, आपके प्रश्न पर @ marcus की टिप्पणी अनिवार्य रूप से है। सुरक्षा पहलुओं को "आधुनिक" प्रौद्योगिकियों से अलग तरीके से नहीं निपटा जाता है, और यह कार्यान्वयन के सवालों को कवर करता है जैसे:

चाहे आपका संचार प्रोटोकॉल (@ रॉबर्टहार्वे के उत्तर से थोड़ा सा उधार) एन्क्रिप्टेड डेटा के संचरण का समर्थन करता है।
संदेश पेलोड संरचना है कि सर्वर और ग्राहक के बीच रिले की जाती है।
- क्या क्लाइंट केवल सर्वर को इस उपयोगकर्ता के आवासीय पते को जारी रखने के लिए, या X.X.X.Xउपयोगकर्ता नाम और पासवर्ड के साथ आईपी में एक डेटाबेस से कनेक्ट करने के लिए कहता है , और फिर क्वेरी चलाता हैINSERT INTO user_address ... ?
सर्वर अपने डेटाबेस कनेक्टिविटी को कैसे प्रबंधित करता है (जो वास्तव में क्लाइंट से अलग है, पहले पैराग्राफ देखें)।

अधिक जानकारी के लिए:

— hjk
स्रोत