CodeGym /Java Blog /अनियमित /भाग 2। चलिए सॉफ्टवेयर आर्किटेक्चर के बारे में कुछ बात करत...
John Squirrels
स्तर 41
San Francisco

भाग 2। चलिए सॉफ्टवेयर आर्किटेक्चर के बारे में कुछ बात करते हैं

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

क्लाइंट-सर्वर आर्किटेक्चर

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

क्लाइंट-सर्वर आर्किटेक्चर के घटक

आइए देखें कि यह सब क्या है। क्लाइंट -सर्वर आर्किटेक्चर एक डिज़ाइन पैटर्न है जिसका उपयोग वेब एप्लिकेशन बनाने के लिए किया जाता है। इस वास्तुकला में तीन घटक होते हैं: भाग 2। आइए सॉफ्टवेयर आर्किटेक्चर के बारे में कुछ बात करें - 3
  1. ग्राहक - इसके नाम से, हम बता सकते हैं कि यह घटक कुछ सेवा (वेब ​​​​अनुप्रयोग) का उपयोग करता है, कुछ जानकारी का अनुरोध करने के लिए सर्वर से संपर्क करता है।

  2. सर्वर - यह वह जगह है जहां आपका वेब एप्लिकेशन या उसका सर्वर भाग स्थित है। यह आवश्यक उपयोगकर्ता जानकारी संग्रहीत करता है या इसका अनुरोध कर सकता है। इसके अतिरिक्त, जब कोई क्लाइंट अनुरोध भेजता है, तो वह सर्वर होता है जो अनुरोधित जानकारी लौटाता है।

  3. नेटवर्क - यह हिस्सा सरल है। यह क्लाइंट और सर्वर के बीच सूचनाओं के आदान-प्रदान की सुविधा प्रदान करता है।

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

  • एक सर्वर मॉड्यूल - एक वेब एप्लिकेशन जो एक सर्वर पर होस्ट किया जाता है और उपयोगकर्ताओं से संदेश प्राप्त करता है, उन्हें संसाधित करता है, और फिर उन्हें प्राप्तकर्ताओं को भेजता है

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

त्रिस्तरीय वास्तुकला

यह एक आर्किटेक्चरल पैटर्न है जो एक तीसरे मॉड्यूल - डेटा स्टोरेज का परिचय देता है । इस पैटर्न में, तीन स्तरों को आमतौर पर परतें या स्तर कहा जाता है: भाग 2। आइए सॉफ्टवेयर आर्किटेक्चर के बारे में कुछ बात करें - 6
  1. क्लाइंट लेयर यूजर इंटरफेस है, जिसे प्रेजेंटेशन टियर भी कहा जाता है। यह एक वेब ब्राउज़र हो सकता है जो HTML पेज प्राप्त करता है, या JavaFX का उपयोग करके लिखा गया एक ग्राफिकल यूजर इंटरफेस हो सकता है। मुख्य बात यह है कि यह परत उपयोगकर्ता को सर्वर को अनुरोध भेजने और उसकी प्रतिक्रियाओं को संसाधित करने देती है।

  2. लॉजिक लेयर वह सर्वर है जो अनुरोधों/प्रतिक्रियाओं को संसाधित करता है। अक्सर इसे सर्वर लेयर भी कहा जाता है। यह वह जगह भी है जहाँ सभी तार्किक संचालन होते हैं: गणितीय गणनाएँ, डेटा संचालन, अन्य सेवाओं के लिए कॉल या डेटा संग्रहण, आदि।

  3. डेटा लेयर डेटाबेस सर्वर है: हमारा सर्वर इसके साथ इंटरैक्ट करता है। यह परत एप्लिकेशन के संचालन के लिए आवश्यक सभी सूचनाओं को संग्रहीत करती है।

इस प्रकार, हमारा सर्वर डेटा तक पहुँचने की पूरी जिम्मेदारी लेता है और उपयोगकर्ता को इसे सीधे एक्सेस करने की अनुमति नहीं देता है।

त्रि-स्तरीय वास्तुकला के लाभ

इस तरह की वास्तुकला हमें कई फायदे देती है, जिनमें शामिल हैं:
  1. एसक्यूएल इंजेक्शन के खिलाफ सुरक्षा की क्षमता (यह सर्वर पर हमला है; इसमें एसक्यूएल कोड भेजना शामिल है, जब निष्पादित किया जाता है, हमलावर को हमारे डेटाबेस को प्रभावित करने की अनुमति देता है)।

  2. उस डेटा को अलग करना जिस पर हम उपयोगकर्ता की पहुंच को नियंत्रित करना चाहते हैं।

  3. क्लाइंट को भेजने से पहले डेटा को संशोधित करने की क्षमता।

  4. स्केलेबिलिटी (एक ही डेटाबेस का उपयोग करने वाले कई सर्वरों में हमारे एप्लिकेशन का विस्तार करने की क्षमता।

  5. उपयोगकर्ता कनेक्शन की गुणवत्ता पर कम कठोर आवश्यकताएं। सर्वर पर एक प्रतिक्रिया उत्पन्न करते समय, हम अक्सर एक डेटाबेस से बहुत सारी अलग-अलग जानकारी प्राप्त करते हैं और इसे प्रारूपित करते हैं, केवल वही छोड़ते हैं जो उपयोगकर्ता को चाहिए। ऐसा करने से उस जानकारी की मात्रा कम हो जाती है जो हम ग्राहक को अपनी प्रतिक्रिया में भेजते हैं।

वास्तुशिल्प पैटर्न कितनी बार इस्तेमाल किया जाना चाहिए?

यदि आप फ़ैक्टरी विधि डिज़ाइन पैटर्न से परिचित हैं, तो आप शायद सोच रहे होंगे कि इसका उपयोग कब करना है। कभी-कभी यह तय करना मुश्किल होता है कि क्या करना है: नए ऑपरेटर का उपयोग करके या फ़ैक्टरी विधि का उपयोग करके ऑब्जेक्ट बनाएं। लेकिन समय के साथ समझ आती है। जब वास्तु पैटर्न की बात आती है तो चीजें थोड़ी अलग होती हैं। एंटरप्राइज़ फ्रेमवर्क को प्रोग्रामर को कुछ आम तौर पर स्वीकृत पैटर्न के आधार पर एक प्रोजेक्ट बनाने की अनुमति देने के लिए डिज़ाइन किया गया है। तदनुसार, स्प्रिंग फ्रेमवर्क सीखने से पहले, आपको क्लाइंट-सर्वर आर्किटेक्चर, थ्री-टियर आर्किटेक्चर और एमवीसी आर्किटेक्चर को निश्चित रूप से समझना चाहिए। चिंता न करें: हम अभी MVC आर्किटेक्चर के बारे में बात करेंगे। भाग 3. HTTP/HTTPS भाग 4. मावेन की मूल बातें भाग 5. सर्वलेट्स और जावा सर्वलेट एपीआई। एक साधारण वेब एप्लिकेशन लिखना भाग 6. सर्वलेट कंटेनर भाग 7. एमवीसी (मॉडल-व्यू-कंट्रोलर) पैटर्न का परिचय
टिप्पणियां
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION