सॉफ्टवेअर आर्किटेक्चर एखाद्या अनुप्रयोगामध्ये तयार केलेल्या संरचनेचा संदर्भ देते, म्हणजे संपूर्ण प्रोग्रामचे मॉड्यूल आणि घटक आणि ते कसे संवाद साधतात. प्रोग्रामर बर्याच काळापासून चांगल्या आर्किटेक्चरवर काम करत आहेत, म्हणून आम्ही बर्याच आर्किटेक्चरल नमुन्यांबद्दल ऐकले आहे हे आश्चर्यकारक नाही. तुम्हाला ते समजून घेणे आवश्यक आहे: वेब ऍप्लिकेशन लिहिताना, चांगल्या आर्किटेक्चरसह येणे महत्वाचे आहे, कारण वेब ऍप्लिकेशनमध्ये नियमित ऍप्लिकेशनपेक्षा जास्त घटक आणि मॉड्यूल्स असतात. आर्किटेक्चरल नमुनाकाही सॉफ्टवेअर डिझाइन समस्या सोडवण्याचा एक स्मार्ट मार्ग आहे. फॅक्टरी पद्धत, अमूर्त फॅक्टरी, बिल्डर, प्रोटोटाइप, सिंगलटन आणि शक्यतो इतर यासारखे डिझाइन नमुने तुम्हाला कदाचित भेटले असतील. आम्ही त्यांचा वापर कोड लिहिताना, वर्ग तयार करताना आणि वर्ग कसा संवाद साधतील याचे नियोजन करतो. सर्व्हर, डेटा आणि इतर घटकांसह वापरकर्त्याच्या परस्परसंवादाची योजना आखताना, आर्किटेक्चरल नमुने उच्च पातळीवर अमूर्ततेवर वापरले जातात. चला काही नमुने आणि ते कसे वापरायचे ते पाहू या.
क्लायंट-सर्व्हर आर्किटेक्चर
या नमुन्याबद्दल सर्व काही सोपे आणि स्पष्ट आहे अशी छाप नावामुळे निर्माण होते. परंतु चला काही मुद्दे स्पष्ट करूया, जेणेकरून जेव्हा तुम्ही स्प्रिंगचा अभ्यास करण्यास सुरुवात कराल तेव्हा तुम्हाला समजेल की आम्ही कशाबद्दल बोलत आहोत. समजा तुम्ही एक चॅट अॅप लिहिले आहे आणि तुम्ही आणि मित्राने ते वापरण्यास सुरुवात केली आहे. ज्ञात आयपी पत्ते वापरून थेट इंटरनेटद्वारे एकमेकांना संदेश पाठवून, तुम्ही अतिशय सोप्या पद्धतीचा अवलंब करू शकता:
सुरुवातीला, जोपर्यंत तुमचा दुसरा मित्र चॅटमध्ये सामील होण्यास सांगत नाही तोपर्यंत सर्व काही ठीक आहे असे दिसते. म्हणून जेव्हा तुम्ही तुमच्या म्युच्युअल मित्राला चॅटमध्ये जोडण्याचा निर्णय घेता, तेव्हा तुम्हाला वास्तुशास्त्रीय समस्येचा सामना करावा लागतो: प्रत्येक चॅट सहभागीसाठी, तुम्हाला वापरकर्त्यांची संख्या आणि नवीन वापरकर्त्यांच्या IP पत्त्याबद्दल वर्तमान माहिती प्रदान करणे आवश्यक आहे. आणि जेव्हा संदेश पाठवला जातो तेव्हा तो सर्व सहभागींना वितरित करणे आवश्यक आहे. या सर्वात स्पष्ट समस्या उद्भवतील. कोडमध्येच आणखी एक समस्या लपलेली असेल. ते टाळण्यासाठी, आपल्याला सर्व्हर वापरण्याची आवश्यकता आहे, जे वापरकर्त्यांबद्दल सर्व माहिती संग्रहित करेल, त्यांच्या पत्त्यांसह. संदेश फक्त सर्व्हरवर पाठवणे आवश्यक आहे. ते, यामधून, प्रत्येक प्राप्तकर्त्याला संदेश पाठवते. जेव्हा तुम्ही तुमच्या चॅट अॅपमध्ये सर्व्हरचा भाग जोडण्याचा निर्णय घेता, तेव्हा तुम्ही क्लायंट-सर्व्हर आर्किटेक्चर तयार करण्यास सुरुवात करता.
क्लायंट-सर्व्हर आर्किटेक्चरचे घटक
बघूया काय आहे ते. क्लायंट -सर्व्हर आर्किटेक्चर हा वेब अॅप्लिकेशन्स तयार करण्यासाठी वापरला जाणारा डिझाइन पॅटर्न आहे. या आर्किटेक्चरमध्ये तीन घटक असतात:
-
क्लायंट — त्याच्या नावावरून, आम्ही सांगू शकतो की हा घटक काही सेवा (वेब अनुप्रयोग) वापरतो, काही माहितीची विनंती करण्यासाठी सर्व्हरशी संपर्क साधतो.
-
सर्व्हर - येथे तुमचा वेब अनुप्रयोग किंवा त्याचा सर्व्हर भाग स्थित आहे. ते आवश्यक वापरकर्ता माहिती संग्रहित करते किंवा विनंती करू शकते. याव्यतिरिक्त, जेव्हा एखादा क्लायंट विनंती पाठवतो तेव्हा तो सर्व्हर असतो जो विनंती केलेली माहिती परत करतो.
-
नेटवर्क - हा भाग सोपा आहे. हे क्लायंट आणि सर्व्हरमधील माहितीची देवाणघेवाण सुलभ करते.
-
क्लायंट मॉड्यूल — साइन इन करण्यासाठी आणि संदेश पाठवणे/प्राप्त करण्यासाठी ग्राफिकल इंटरफेस समाविष्ट आहे
-
सर्व्हर मॉड्यूल — एक वेब अनुप्रयोग जो सर्व्हरवर होस्ट केला जातो आणि वापरकर्त्यांकडून संदेश प्राप्त करतो, त्यावर प्रक्रिया करतो आणि नंतर प्राप्तकर्त्यांना पाठवतो
जेव्हा आम्हाला इंटरनेटवरील उपयुक्त (किंवा फारशी उपयुक्त नसलेली) माहिती पहायची असते, तेव्हा आम्ही ब्राउझर उघडतो, शोध बारमध्ये एक क्वेरी टाकतो आणि प्रतिसादात शोध इंजिनकडून माहिती मिळवतो. या साखळीमध्ये, ब्राउझर क्लायंट आहे. आम्ही सर्व्हरला काय शोधत आहोत याबद्दल माहितीसह विनंती पाठवते. सर्व्हर विनंतीवर प्रक्रिया करतो, सर्वात संबंधित परिणाम शोधतो, ब्राउझर (क्लायंट) समजू शकतील अशा स्वरूपनात पॅकेज करतो आणि त्यांना परत पाठवतो. शोध इंजिनासारख्या जटिल सेवांमध्ये बरेच सर्व्हर असू शकतात. उदाहरणार्थ, ऑथोरायझेशन सर्व्हर, माहिती शोधण्यासाठी सर्व्हर, प्रतिसाद व्युत्पन्न करण्यासाठी सर्व्हर इ. परंतु क्लायंटला यापैकी कशाचीही माहिती नसते आणि त्याची चिंता नसते: क्लायंटसाठी, सर्व्हर एक एकीकृत संस्था आहे. क्लायंटला फक्त एंट्री पॉइंटबद्दल माहिती असते, म्हणजेच, सर्व्हरचा पत्ता ज्यावर विनंत्या पाठवल्या पाहिजेत. आम्ही तपासलेला अर्ज आठवाया मालिकेचा मागील भाग . हे रिअल टाइममध्ये सर्व देशांमधील सरासरी हवेच्या तापमानाचे निरीक्षण करण्यासाठी होते. त्याचे आर्किटेक्चर असे काहीतरी दिसते: 
आमचा अनुप्रयोग सर्व्हरवर स्थित आहे. समजा की दर पाच सेकंदांनी ते स्थानिक हवामान केंद्रांद्वारे संचालित सर्व्हरला विनंत्या पाठवते, सर्व्हरवरून विशिष्ट देशासाठी तापमान माहिती प्राप्त करते आणि ही माहिती संग्रहित करते. जेव्हा क्लायंट आम्हाला "जगातील वर्तमान हवेचे तापमान पाहण्यासाठी" विचारतो, तेव्हा आम्ही देशानुसार क्रमवारी लावलेली सर्वात अलीकडे संग्रहित माहिती परत करतो. अशाप्रकारे, आमचा अनुप्रयोग सर्व्हर (जेव्हा तो वापरकर्त्याच्या विनंत्यांवर प्रक्रिया करतो) आणि क्लायंट (जेव्हा तो इतर सर्व्हरकडून माहिती प्राप्त करतो) म्हणून कार्य करतो.
| येथे एक महत्त्वाचा मुद्दा आहे: सर्व्हरची संकल्पना विशिष्ट संगणकाबद्दल नाही, तर नेटवर्क घटकांमधील संबंधांबद्दल आहे . |
त्रिस्तरीय आर्किटेक्चर
हा एक आर्किटेक्चरल पॅटर्न आहे जो तिसऱ्या मॉड्यूलचा परिचय देतो — डेटा स्टोरेज . या पॅटर्नमध्ये, तीन स्तरांना सामान्यतः स्तर किंवा स्तर म्हणतात:
-
क्लायंट स्तर हा वापरकर्ता इंटरफेस आहे, ज्याला सादरीकरण स्तर देखील म्हणतात. हे HTML पृष्ठे प्राप्त करणारा वेब ब्राउझर किंवा JavaFX वापरून लिहिलेला ग्राफिकल यूजर इंटरफेस असू शकतो. मुख्य गोष्ट अशी आहे की हा स्तर वापरकर्त्यास सर्व्हरला विनंत्या पाठवू देतो आणि त्याच्या प्रतिसादांवर प्रक्रिया करतो.
-
लॉजिक लेयर हा सर्व्हर आहे जो विनंत्या/प्रतिसादांवर प्रक्रिया करतो. अनेकदा याला सर्व्हर लेयर असेही म्हणतात. येथेच सर्व तार्किक ऑपरेशन्स होतात: गणिती गणना, डेटा ऑपरेशन्स, इतर सेवांसाठी कॉल किंवा डेटा स्टोरेज इ.
-
डेटा स्तर हा डेटाबेस सर्व्हर आहे: आमचा सर्व्हर त्याच्याशी संवाद साधतो. हा स्तर ऍप्लिकेशन ऑपरेट करण्यासाठी आवश्यक असलेली सर्व माहिती संग्रहित करतो.
तीन-स्तरीय आर्किटेक्चरचे फायदे
यासारखे आर्किटेक्चर आम्हाला अनेक फायदे देते, यासह:
-
एसक्यूएल इंजेक्शनपासून संरक्षण करण्याची क्षमता (हा सर्व्हरवरील हल्ला आहे; यात SQL कोड पाठवणे समाविष्ट आहे, जे कार्यान्वित केल्यावर, आक्रमणकर्त्याला आमच्या डेटाबेसवर परिणाम करण्यास अनुमती देते).
-
आम्ही वापरकर्ता प्रवेश नियंत्रित करू इच्छित असलेल्या डेटाचे पृथक्करण.
-
क्लायंटला पाठवण्यापूर्वी डेटा सुधारण्याची क्षमता.
-
स्केलेबिलिटी (आमच्या अनुप्रयोगाचा एकापेक्षा जास्त सर्व्हरवर विस्तार करण्याची क्षमता जे समान डेटाबेस वापरतील.
-
वापरकर्ता कनेक्शनच्या गुणवत्तेवर कमी कठोर आवश्यकता. सर्व्हरवर प्रतिसाद व्युत्पन्न करताना, आम्हाला बर्‍याचदा डेटाबेसमधून बरीच वेगळी माहिती मिळते आणि ती फॉरमॅट केली जाते, फक्त वापरकर्त्याला आवश्यक असलेली माहिती सोडून. असे केल्याने आम्ही क्लायंटला आमच्या प्रतिसादात पाठवलेल्या माहितीचे प्रमाण कमी होते.