एकाधिक अनुप्रयोगों के बीच व्यापार तर्क कैसे साझा करें

Question

हमें विभिन्न आकारों, क्षेत्रों और जीवन-काल के कई जावा वेब आधारित अनुप्रयोगों (उसी कंपनी के लिए) को विकसित और बनाए रखना है। उनमें से कुछ बहुत बड़े हैं और अन्य केवल साधारण पृष्ठ हैं जो केवल कुछ महीनों (या दिन) जी सकते हैं, कुछ पहले से ही कार्यान्वित किए गए हैं और उन्हें रिफैक्टरिंग की आवश्यकता है।

हालांकि एक बात आम है, हालांकि उन्हें एक ही जानकारी तक पहुंच की आवश्यकता है।

समस्या

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

हमारे डेटा स्रोत हैं (हालांकि यह किसी भी हो सकता है):

• AS400 (एक डाटाबेस के रूप में डीबी 2 का प्रयोग करके)
• डॉक्युमेंटम दस्तावेज़ प्रबंधक
• मोंगो डीबी
• बाहरी वेब सेवाओं
• अन्य विरासत स्रोत

हम आमतौर पर ग्लास का उपयोग करते हैं हमारे निर्माण उपकरण के रूप में एप्लिकेशन सर्वर और मेवेन के रूप में sfish।

लक्ष्य

हमारा लक्ष्य एक व्यापार परत या लाइब्रेरी हमारे सभी ऐप्लिकेशन में पहुंच सकते हैं कि बनाने के लिए है और यह है:

• कॉम्पैक्ट
• लगातार
• आसान
उपयोग करने के लिए
• बनाए रखने में आसान मनुष्य से सुलभ y विभिन्न ग्राहकों

क्या हम अब तक

पाया है हम सप्ताह के लिए संघर्ष कर रहा है और अभी भी हम कुछ भी पूरी तरह से संतोषजनक नहीं मिल रहा। कुछ समाधान:

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

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

• अंदर सबकुछ के साथ एक ईयर प्रोजेक्ट बनाएं और स्थानीय पहुंच का उपयोग करें: अच्छा, यह दूरस्थ संस्करण से तेज़ है लेकिन यह बनाए रखने के लिए नरक है।

• ओएसजीआई के लिए जाएं: हम इस से थोड़ा डरते हैं क्योंकि यह ईजेबी जितना लोकप्रिय नहीं है और हमने कभी इसका गंभीरता से उपयोग नहीं किया है।

वहाँ इस तरह की समस्या के लिए एक आम बात है?

बहुत धन्यवाद!

Answer 1

मैं सभी तर्क 1 ईएआर प्रोजेक्ट में रखने और स्थानीय पहुंच का उपयोग करने की अनुशंसा नहीं करता। यदि आपके पास एक ही स्थान पर बहुत अधिक कोड है, तो इसे बनाए रखना, परीक्षण करना, तैनाती करना कठिन होगा।

मैं सामान्य निर्भरताओं के साथ mutlti-module maven प्रोजेक्ट बनाउंगा। निर्भरता में से एक - व्यवसाय तर्क और डीएओ एक्सेस के साथ सेवा, जो एपीआई का पर्दाफाश करेगी। मेवेन प्रोजेक्ट के साथ आप पीओएम फाइलों का आसान नियंत्रण संस्करण कर सकते हैं। विभिन्न परियोजनाएं सामान्य सेवा के विभिन्न संस्करणों के साथ काम कर सकती हैं। मेवेन आपके लिए संस्करण नियंत्रण संभाल लेंगे। हालांकि इसे कुछ विन्यास और कार्यान्वयन के प्रयासों की आवश्यकता है।

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

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