वास्तुकला - एकाधिक वेब ऐप्स का एक ही डेटा

Question

मैं निम्नलिखित जावा वेब अनुप्रयोग के लिए एक उपयुक्त वास्तुकला के लिए पूछ रहा हूँ पर काम:

लक्ष्य कई वेब अनुप्रयोगों जो सभी एक ही डेटा पर काम का निर्माण करना है। मान लीजिए कि एक बैंकिंग प्रणाली जिसमें खाता डेटा को विभिन्न वेब अनुप्रयोगों द्वारा एक्सेस किया जा सकता है; इसे ग्राहकों (ऑनलाइन बैंकिंग) द्वारा सेवा व्यक्तिगत (ज्यादातर पढ़ा जाता है) और खाता प्रशासन विभाग (व्यवस्थापक उपकरण) द्वारा एक्सेस किया जा सकता है। ये एप्लिकेशन अलग-अलग मशीनों पर अलग-अलग वेब अनुप्रयोगों के रूप में चलते हैं लेकिन वे समान डेटा और सामान्य डेटा मैनिपुलेशन और खोज क्वेरी का एक सेट उपयोग करते हैं।

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

एक अखंड दृष्टिकोण:

एक तस्वीर प्राप्त करने के लिए, यहाँ संभव दृष्टिकोण हम के बारे में सोचा से कुछ हैं। सभी जरूरतों को पूरा करने वाला एक विशाल वेब एप्लिकेशन बनाएं (यह वास्तव में एक विकल्प नहीं है)

बी एपीआई दृष्टिकोण। डेटा एक्सेस/मैनिपुलेशन के लिए कोर डेटाबेस एक्सेस एपीआई (जेएआर) बनाएं। प्रत्येक वेब एप्लिकेशन एक अलग WAR के रूप में निर्मित होता है जो डेटाबेस तक पहुंचने के लिए एपीआई का उपयोग करता है। कोई अलग कोर आवेदन नहीं है।

सी आरएमआई दृष्टिकोण। कोर एप्लिकेशन एक स्टैंडअलोन एप्लिकेशन (संभवतः एक डब्ल्यूएआर) के रूप में चलता है और आरएमआई (या एचटीपीएनवॉकर) के माध्यम से सेवाएं प्रदान करता है।

डी डब्ल्यूएस दृष्टिकोण। सी की तरह ही, वेब सेवाओं

ई ओएसजीआई दृष्टिकोण के साथ आरएमआई को प्रतिस्थापित करें। ओएसजीआई मॉड्यूल के रूप में सभी घटकों को बनाएं और जो ओएसजीआई कंटेनर में चलें। संभवतः स्प्रिंगसोर्स डीएम सर्वर या मॉड्यूलफ्यूजन का उपयोग करें। यह दृष्टिकोण कुछ कारणों से हमारे लिए एक विकल्प नहीं था ...

आशा है कि मैं समस्या को स्पष्ट कर सकता हूं। हम बस विकल्प बी के साथ जा रहे हैं, लेकिन मुझे इसके साथ बहुत भरोसा नहीं है। आपकी राय क्या हैं? कोई अन्य समाधान? प्रत्येक समाधान की कमी क्या हैं?

Answer 1

बी, सी, और डी एक ही चीज़ को पूरा करने के लिए सभी अलग-अलग तरीके हैं।

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

एक अन्य समाधान जिसे आप विचार करना चाहते हैं, उसे प्रत्येक उपभोक्ता को अपने डेटाबेस को सिंक में रखने के लिए प्रतिकृति का उपयोग करके अपना डेटाबेस दे रहा है।

Answer 2

मुझे लगता है कि आपको विपरीत दिशा में जाना है - नीचे से। बेशक, आपको यह सत्यापित करने के लिए आगे और पीछे जाना होगा कि सबकुछ चल रहा है, लेकिन यहां सामान्य दिशा है:

अपने डेटा के बारे में सोचें - डीबी योजना, लेनदेन कैसे महत्वपूर्ण हैं (उदाहरण के लिए बैंकिंग सिस्टम में सब कुछ लेनदेन के बारे में है) आदि

फिर परिभाषित आम अभिगम विधि - वितरित लेनदेन इंजन के लिए संग्रहित प्रक्रियाओं के सेट से ...

अगला कदम एक व्यापार तर्क/प्रस्तुति है - क्या सामान्यीकृत किया जा सकता है और अनुकूलन का विषय क्या है।

और अंतिम चरण इंटरफेस, दृश्य और रिपोर्ट

Answer 3

मुझे लगता है कि आप एक अलग आवेदन है कि सभी ग्राहक एप्लिकेशन अपने डेटा परत के रूप में इस्तेमाल करेगा की आवश्यकता है। इसका कारण यह है कि आप यह सुनिश्चित करना चाहते हैं कि वे सभी डेटाबेस को उसी तरह एक्सेस कर रहे हैं। ऐसी कुछ रेस स्थितियां भी हैं जिन्हें आप डेटाबेस डेटाबेस लेन-देन में प्राप्त करने में सक्षम नहीं हो सकते हैं। दूसरा कारण यह है कि आरपीसी के रूप में डेटाबेस का उपयोग एक ज्ञात एंटीपाटर है। यदि आपके सभी ऐप्स सीधे डेटाबेस तक पहुंचते हैं, तो आप लगभग अनिवार्य रूप से कुछ "ईवेंट" तालिका के साथ समाप्त हो जाएंगे जो विभिन्न अनुप्रयोगों के मतदान समय-समय पर ... ऐसा नहीं करते हैं।

Answer 4

प्रदत्त प्रतिक्रियाओं के अलावा, यदि आप एक ही समय में डेटाबेस के साथ काम कर रहे कई अनुप्रयोगों पर विचार कर रहे हैं, तो अपने समाधान के हिस्से के रूप में वितरित कैश पर विचार करें। वितरित कैश की सुंदरता यह है कि वितरित होने के अलावा, इसे एक साथ कई अनुप्रयोगों तक पहुंचा जा सकता है। मुझे यकीन नहीं है कि यह सभी जावा विविधताओं के लिए सच है, जैसे कि एशैच, आदि, क्योंकि मैं जावा पृष्ठभूमि से नहीं आया हूं।

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

Answer 5

ऐसा लगता है कि ए और ई तस्वीर से बाहर हैं जैसा कि आपने विभिन्न कारणों से अपने प्रश्न में कहा है। विकल्प ए एक बड़ा आवेदन होगा जो भविष्य में रखरखाव को कठिन बना देगा।

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

तो मुझे लगता है इस समस्या को मूल रूप से निम्नलिखित दो विकल्पों में करने पर निर्भर करता:

1) व्यापार और डीएओ परत कक्षाएं एक आम जार सभी वेब एप्लिकेशन की तैनाती में शामिल के रूप में शामिल करें।

लाभ:

• तैनाती आसान है।
• एप्लिकेशन प्रारंभ में बेहतर प्रदर्शन करेंगे क्योंकि अन्य सर्वरों के लिए कोई दूरस्थ पहुंच नहीं है।

नुकसान:

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

2) एक अलग अनुप्रयोग सर्वर में व्यापार सेवा और डीएओ परत कक्षाओं को तैनात करें और दूरस्थ रूप से व्यवसाय विधियों का पर्दाफाश करें।

लाभ:

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

नुकसान:

• अधिक जटिल तैनाती।
• बनाए रखने और निगरानी करने के लिए एक और सर्वर।
• धीमा हो सकता है क्योंकि नेटवर्क पर कॉल किए जाएंगे हालांकि यह किसी समस्या का अधिक नहीं होना चाहिए।

दोनों मामलों में यदि इंटरफ़ेस क्लाइंट कोड बदलते हैं तो उन्हें बदलने की आवश्यकता होगी ताकि यह निर्णय में कोई कारक न हो। लेनदेन को व्यापार सेवा विधि स्तर पर संभाला जाना चाहिए ताकि यह एक कारक न हो।

मुझे लगता है कि यह अनुप्रयोगों के आकार पर निर्भर करता है और उपरोक्त विकल्प 2 की अतिरिक्त जटिलता को वारंट करने के लिए समाधान को कितना स्केलेबल करने की आवश्यकता है।