एसओए: एकाधिक सेवाओं में डेटा में शामिल होना

Question

कल्पना कीजिए कि हमारे पास 2 सेवाएं हैं: उत्पाद और ऑर्डर। एसओए की मेरी समझ के आधार पर, मुझे पता है कि प्रत्येक सेवा में अपना डेटा स्टोर (एक अलग डेटाबेस, या एक ही डेटाबेस में टेबल का समूह) हो सकता है। लेकिन किसी अन्य सेवा के डेटा स्टोर को सीधे स्पर्श करने की कोई सेवा नहीं है।

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

मेरा प्रश्न है: इस वास्तुकला के साथ, मैं "समान" पृष्ठ पर ऑर्डर और उत्पाद विवरणों की सूची कैसे प्रदर्शित कर सकता हूं?

मेरी समझ यह है कि मुझे ऑर्डर सेवा से ऑर्डरइटम की सूची मिलनी चाहिए। प्रत्येक ऑर्डरइटम में एक उत्पाद आईडी है। अब, यदि मैं प्रत्येक उत्पाद के बारे में विवरण पुनर्प्राप्त करने के लिए ProductService को एक अलग कॉल करता हूं, तो यह बहुत अक्षम होगा।

आप इस समस्या से कैसे संपर्क करेंगे?

चीयर्स, Mosh

Answer 1

मैंने कुछ शोध किया और इसके लिए 2 अलग-अलग समाधान पाए।

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

2- वैकल्पिक रूप से, एक सेवा पहचानकर्ताओं की एक सूची की आपूर्ति करके किसी अन्य सेवा से वस्तुओं की "सूची" से पूछ सकती है। यह किसी दिए गए ऑब्जेक्ट का विवरण प्राप्त करने के लिए लक्षित सेवा में एक अलग कॉल करने से रोकता है। इसे कार्यान्वित करना आसान है लेकिन प्रदर्शन के अनुसार, समाधान 1 जितना तेज़ नहीं है। इसके अलावा, यदि लक्ष्य सेवा उपलब्ध नहीं है, तो स्रोत सेवा अपना काम नहीं कर सकती है।

आशा है कि इससे अन्य लोगों को इस मुद्दे पर आने में मदद मिलेगी।

Mosh

Answer 2

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

Answer 3

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

Answer 4

एक और दृष्टिकोण है कि SOA सेवाओं के बाहर रहता है डेटा स्रोत न किसी तरह का होगा। इस डेटा स्रोत को डेटा, आपके परिचालन डेटा स्रोत या यहां तक ​​कि डेटा वेयरहाउस का कैश माना जा सकता है।निष्कर्षण पैकेज सेवाओं (और/या वास्तविक समय तंत्र के कुछ प्रकार) से डेटा निर्यात कर सकते हैं। आप इस डेटा स्रोत से पूछ सकते हैं कि आप कैसे चाहते हैं।

इस दृष्टिकोण का लाभ यह है कि एसओए ब्लैक बॉक्स बनाए रखा जाता है और आप एक सेवा को स्वैप कर सकते हैं यह जानकर कि आपने इसे कैसे जोड़ा है।

नुकसान अतिरिक्त जटिलता और रखरखाव ओवरहेड है।

Answer 5

डीबी एकीकरण (जो कि वास्तव में आप क्या कर रहे हैं जब दो सेवाओं को डीबी में एक टेबल साझा करते हैं) इतने सारे स्तर पर गलत है! यह पूरी तरह से सॉफ्टवेयर इंजीनियरिंग के प्रमुख सिद्धांतों में से कुछ टूट जाता है

ढीला संयोजन, कैप्सूलीकरण चिंताओं

की जुदाई एक सेवा चाहिए होना पूरी तरह से स्वतंत्र है, अर्थात् (उस नाम कमाने के लिए):

1. यह अपने डेटा
2. की स्थिरता और सुसंगतता सुनिश्चित करने के लिए दूसरों पर भरोसा नहीं करना चाहिए, इसे अपने डेटा की सुरक्षा की गारंटी के लिए दूसरों पर भरोसा नहीं करना चाहिए
3. यह बाह्य कार्यान्वयन (केवल इंटरफेस)

दो सेवाओं का हिस्सा है कि डीबी स्तर पर डेटा पूर्व के किसी भी गारंटी देने में असमर्थ हैं पर निर्भर नहीं करना चाहिए।

तथ्य यह है कि आप दोनों सेवाओं को "नियंत्रित" पूरी तरह से अप्रासंगिक है। आज आप नियंत्रित करते हैं ... कल आप सेवाओं में से किसी एक को आउटसोर्स या प्रतिस्थापित करना चाहेंगे। यह उचित इंटरफ़ेस सुनिश्चित करने के समान सरल होना चाहिए।

दोनों सेवाओं की कल्पना करें जो इसमें कुछ फ़ील्ड (वर्कर) के साथ एक टेबल साझा करते हैं। अब एक सेवा को उस क्षेत्र को संख्यात्मक में बदलने की जरूरत है ... दूसरी सेवा काम करना बंद कर देता है - ढीला युग्मन नाली नीचे चला जाता है।

अधिकांश समय यह चाल सेवा क्षेत्र को सही ढंग से परिभाषित करने में स्पष्ट रूप से परिभाषित होती है और यह स्पष्ट रूप से निर्धारित करती है कि कोई सेवा क्या करती है और यह क्या नहीं करती है। आपको सब कुछ एक सेवा में बदलने से बचना चाहिए। अपनी सेवा ग्रैन्युलरिटी को उच्च पर सेट करें और सेवाएं हर जगह पॉपिंग शुरू हो जाएंगी और एकीकरण सिरदर्द बढ़ेगा।

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

Answer 6

यह दुर्भाग्यपूर्ण है कि "क्या मैं साझा डेटाबेस का उपयोग कर सकता हूं या एसओए में नहीं" कथन खोज में बिगड़ रहा हूं, जो पूरी तरह से अप्रासंगिक है और मूल प्रश्न का उत्तर देने में मदद नहीं करता है।

अधिकांशतः वास्तविक दुनिया की स्थिति में डेटा पहले से ही विभिन्न प्रणालियों में संग्रहीत होता है। उदाहरण के लिए ग्राहक डेटा सीआरएम से आ रहा है, एसएपी से उत्पाद डेटा, अभी तक एक और अलग स्रोत से अनुबंध डेटा।

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

प्रदर्शन कारणों से स्थानीय रूप से डेटा संग्रहीत करना मतलब डेटा को दोहराना है, जो अक्सर एक खतरनाक उद्यम से अधिक होता है, जब तक कि आपके पास ठोस कैशिंग रणनीति न हो। मुझे लगता है कि मौजूदा अनुप्रयोग परिदृश्य का सामना करते समय मोश ने कुछ समझदार जवाब दिए हैं।