एसओए और साझा डेटाबेस

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

CustomerService:: मेरे Customers डेटाबेस तालिका में शामिल है और संबद्ध व्यापार तर्क

अधिक ठोस होने के लिए, मैं दो सेवाओं है लगता है।
OrderService: मेरी Orders तालिका और तर्क शामिल है।

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

थोड़ा अनुसंधान कर, हम कुछ प्रस्तावित समाधान पाया है:

Use replication आवश्यक डेटा जहां जरूरत की स्थानीय प्रतिलिपि बनाने के लिए। लेकिन फिर कोई encapsulation नहीं है और फिर एसओए का उपयोग करने का क्या मतलब है? इस पर on StackOverflow पर चर्चा की गई है लेकिन कोई स्पष्ट सहमति नहीं है।
Master Data Service सेट करें जो सभी डेटाबेस डेटा को समाहित करता है। मुझे लगता है कि यह राक्षस आकार (प्रत्येक संग्रहित प्रक्रिया के लिए अनिवार्य रूप से एक एपीआई कॉल के साथ) प्राप्त होगा और हर समय अद्यतन की आवश्यकता होगी। मेरे लिए यह enterprise data bus अवधारणा से संबंधित प्रतीत होता है।

यदि आपके पास इस पर कोई इनपुट है, तो कृपया मुझे बताएं।

संपादित करें: एक साल बीत चुका है, और SOA में मेरी रुचि कम हो गई है, के रूप में सामान्य रूप में अवधारणा की लोकप्रियता है। आजकल, लोग इसके बजाय रीस्टफुल सेवाओं पर ध्यान केंद्रित करना चाहते हैं।

स्रोत

2011-11-16 Gruber

आपका संपादन बिल्कुल शून्य समझ में आता है। रीस्टफुल सेवाएं एपीआई डिज़ाइन का विषय है, और व्यक्तिगत सेवाएं होने से वास्तव में एसओए की ओर चीजें धक्का देती हैं। तो एसओए से आरईएसटी में जाने के बारे में आपकी टिप्पणी अलार्म घड़ियों का उपयोग करने के लिए केला खाने से आगे बढ़ने के समान है। – Max

इनपुट के लिए धन्यवाद, लेकिन यह सुनिश्चित नहीं है कि मैं आपके साथ सहमत हूं। सेवा-उन्मुख वास्तुकला (एसओए) विकास की शुरुआत के बाद से, एसओए की तुलना की गई है और रीस्टफुल इंटरफ़ेस के मॉडल के साथ विपरीत है। [सर्च एसओए] (http://searchsoa.techtarget.com/tip/SOA-and-RESTful-interfaces- जब- क्यों-the-should-be-combined) - ग्रबर 24 मिनट पहले – Gruber

यह भी जांचें: http: // martinfowler.com/articles/enterpriseREST.html#bounded-contexts –

इस संदर्भ में "सेवा" के परिभाषित प्रधानाचार्यों में से एक यह है कि यह उस क्षेत्र में डेटा के साथ-साथ उस डेटा पर संचालन के लिए जिम्मेदार है।

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

एक ही डेटा सेवा का उपयोग करना "एसओए नहीं करना" है; यदि आपके पास एक ही स्थान है जो सभी डेटा प्रबंधित करता है, तो आपके पास स्वतंत्र सेवाएं नहीं हैं, आपके पास सिर्फ एक सेवा है।

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

इसके बजाय, उन्हें कैसे किनारों पर एक साथ की रचना करने के बारे में सोचते हैं:

जब आप एक ग्राहक के लिए एक HTML पृष्ठ प्रस्तुत करना, आप कई से HTML आपूर्ति कर सकते हैं सेवाओं और उन्हें एक-दूसरे के सामने दृष्टि से लिखें: ग्राहक विवरण ग्राहक सेवा से आते हैं, और ऑर्डर सेवा से ऑर्डर विवरण।

इसी तरह एक चालान ईमेल: डेटाबेस में शामिल होने की आवश्यकता के बिना, कई सेवाओं से प्रदान किए गए डेटा को दृश्यमान रूप से लिखें।

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

दो, आप अपने आवेदन के बाहर आसानी से बदल सकते हैं। यदि आपके पास छोटे, composable भागों हैं तो आप आसानी से भागों को नए तरीकों से पुनर्व्यवस्थित जोड़ सकते हैं।

स्रोत

2011-11-17 03:30:57

सुराग की तलाश करते समय मैं आपके विचार में नहीं आया --- यह एक दिलचस्प दृष्टिकोण है। अगर मैं 'जॉइन' की ज़रूरत को दूर कर सकता हूं तो मूल समस्या उत्पन्न नहीं होगी। हालांकि, मेरे मामले में 'जॉइन' को छेड़छाड़ करना मुश्किल लगता है क्योंकि इसका परिणाम प्रस्तुति उद्देश्यों के लिए नहीं है। लेकिन मैं इसे कुछ सोचा दूंगा। कुछ महत्वपूर्ण बात यह है कि ** एक सेवा का अपना डेटा ** और संबंधित संचालन होना चाहिए। [अन्य धागे] में इस पर असहमति रही है (http://stackoverflow.com/questions/4019902/soa-joining-data-across- बहु- सेवा)। प्रतिक्रिया के लिए धन्यवाद! – Gruber

उडी दहन के यहां एक ब्लॉग है: http://www.udidahan.com/ - उसका काम विषय पर मेरे विचारों को आकार देने में अमूल्य रहा है, और आपको वहां बहुत अधिक मूल्यवान जानकारी मिल जाएगी। –

क्या आप सुझाव दे रहे हैं कि ग्राहक सेवा केवल ग्राहक डेटा तक पहुंच सकती है, और ऑर्डर सेवा केवल ऑर्डर डेटा तक पहुंच सकती है? मैंने थॉमस एर्ल की किताबों में इसका कोई उल्लेख नहीं देखा है? क्या आप एक संदर्भ प्रदान कर सकते हैं? –

मार्गदर्शक सिद्धांत यह है कि अपरिवर्तनीय डेटा कैश करना ठीक है इसका मतलब है कि ग्राहक इकाई से सरल अपरिवर्तनीय डेटा ऑर्डर सेवा में मौजूद हो सकता है और आपको हर बार जानकारी की आवश्यकता होने पर ग्राहक सेवा में जाने की आवश्यकता नहीं है। अलग-अलग सेवाओं में सबकुछ तोड़ना और फिर इन रिमोट प्रक्रिया कॉल को हमेशा fallacies of distributed computing को अनदेखा करता है। यदि आपके पास व्यापक रिपोर्टिंग की ज़रूरत है तो आपको अतिरिक्त सेवा बनाने की आवश्यकता है। मैं उस समेकित रिपोर्टिंग सेवा को कॉल करता हूं, जो फिर से रिपोर्टिंग उद्देश्यों के लिए केवल पढ़ने के लिए डेटा प्राप्त करता है। आप कुछ साल पहले I wrote about that for InfoQ लेख देख सकते हैं

स्रोत

2011-11-18 10:30:47

मैंने आपका लेख पढ़ा। महान पढ़ें। मुझे लगता है कि आपके द्वारा वर्णित घटना-संचालित तंत्र के साथ मिलकर अन्य सेवाओं के डेटा को कैशिंग करना काम करेगा। उन सेवाओं के लिए जिनके डेटा में अक्सर परिवर्तन नहीं होता है, मुझे लगता है कि मैं सेवाओं को अपने कैश को हर रात एक बार अपडेट करने के साथ दूर हो सकता हूं, जो ईवेंट हैंडलिंग की जटिलता को दूर ले जाएगा। – Gruber

आप सीक्यूआरएस http://martinfowler.com/bliki/CQRS.html –

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

इसके अलावा, मेरा यह सवाल सहायक हो सकता है:

https://softwareengineering.stackexchange.com/questions/115958/is-it-bad-practice-for-services-to-share-a-database-in-soa

स्रोत

2011-12-01 13:29:58

जैसे पूरक पैटर्न देखना चाहते हैं। ऐसा लगता है कि इस पर लोगों के अलग-अलग विचार हैं। यदि मैं, उदाहरण के लिए, 'ग्राहक सेवा' की डेटा तालिका 'ग्राहक' (प्रदर्शन कारणों से) को' ऑर्डर सेवा 'के लिए दोहराता हूं, तो' ग्राहक 'के डिज़ाइन को बदलने की आवश्यकता होने पर मैं "स्पेगेटी" समस्या का सामना करता हूं --- मैं फिर 'ऑर्डर सेवा' कोड को अपडेट करना होगा। और एसओए के साथ मैं यही दूर जाना चाहता हूं। – Gruber

@ user1035411 मुझे नहीं लगता कि आपको डेटा दोहराना चाहिए। मुझे लगता है कि ऑर्डर सेवा को ग्राहक सेवा के डेटा तक पहुंच की अनुमति दी जानी चाहिए। विचार करने की एक और बात यह है कि आप ऑर्डर सेवा के लिए ग्राहक तालिका चाहते हैं जिसमें ग्राहक डेटा शामिल होगा जो केवल ऑर्डर सेवा के लिए प्रासंगिक है। ग्राहक नाम का उपयोग कई सेवाओं द्वारा किया जाएगा, ताकि ग्राहक में रह सकें। लेकिन क्रेडिट सीमा शायद ऑर्डर सेवा के लिए उम्मीदवार हो सकती है? यह ग्राहकों के डिजाइन को अक्सर बदलने से रोक देगा। –

मैं एसओए सिद्धांत का सम्मान करना चाहता हूं कि सेवाएं केवल अपने इंटरफेस के माध्यम से बात करें, इसलिए अगर आंतरिक रूप से बदला जाता है तो मुझे अन्य सेवाओं को अपडेट नहीं करना पड़ता है। मैं आपसे सहमत हूं कि सेवाओं को अन्य सेवाओं के डेटा को स्टोर करने की आवश्यकता हो सकती है। समस्या प्रदर्शन है और कैश किए गए डेटा को अद्यतित कैसे करें। SOAP/XML के माध्यम से बड़ी मात्रा में डेटा प्राप्त करना भारी नेटवर्क लोड उत्पन्न करता है, जबकि प्रतिकृति आमतौर पर काफी चिकनी होती है। चूंकि प्रतिकृति एसओए सिद्धांत को तोड़ती है, मुझे लगता है कि मैं दूसरी तरफ कोशिश करने जा रहा हूं और जैसा कि आप सुझाव देते हैं, केवल न्यूनतम मात्रा में डेटा स्टोर करें। – Gruber

एसओए और साझा डेटाबेस

उत्तर

संबंधित मुद्दे