कई प्रणालियों को एकीकृत करने के लिए सबसे अच्छा तरीका है?

Question

ठीक है जहां मैं काम करता हूं हमारे पास पिछले कुछ दशकों में लिखे गए सिस्टमों की पर्याप्त संख्या है जो हम बनाए रखते हैं।

सिस्टम कई ऑपरेटिंग सिस्टम (लिनक्स, सोलारिस, विंडोज), एकाधिक डेटाबेस (ऑरैकल, सिबेज और माइस्क्ल के कई संस्करण), और यहां तक ​​कि कई भाषाओं (सी, सी ++, जेएसपी, पीएचपी, और मेजबान) में विविध हैं। दूसरों का) उपयोग किया जाता है।

प्रत्येक सिस्टम एक ही डेटा को एकाधिक सिस्टम में दर्ज करने की लागत पर भी काफी स्वायत्त है।

प्रबंधन ने हाल ही में निर्णय लिया है कि हमें जांच करनी चाहिए कि सभी सिस्टम खुशी से एक-दूसरे से बात करने और डेटा साझा करने के लिए क्या करेंगे।

ध्यान रखें कि जब भी हम किसी भी व्यक्तिगत सिस्टम में सॉफ़्टवेयर परिवर्तन कर सकते हैं, तो किसी एक सिस्टम (या अधिक) का पूर्ण पुनर्लेखन कुछ प्रबंधन का मनोरंजन करने की संभावना नहीं है।

यहां कई डेवलपर्स का पहला विचार सीधे आगे था: यदि सिस्टम ए को सिस्टम बी से डेटा चाहिए तो इसे सिस्टम बी के डेटाबेस से कनेक्ट करना चाहिए और इसे प्राप्त करना चाहिए। इसी तरह यदि इसे बी डेटा देने की आवश्यकता है तो इसे बस बी के डेटाबेस में डालना चाहिए।

उपयोग किए गए डेटाबेस (और संस्करण) की गड़बड़ी के कारण, अन्य डेवलपर्स का मानना ​​था कि हमारे पास एक से अधिक डेटाबेस होना चाहिए, ताकि अन्य कनेक्शनों को जोड़कर अन्य सभी प्रणालियों से तालिकाओं को संयोजित किया जा सके। ऐसा करके वे उम्मीद करते हैं कि हम कुछ तालिकाओं को मजबूत करने और अनावश्यक डेटा प्रविष्टि से छुटकारा पाने में सक्षम हो सकते हैं।

यह उस समय के बारे में है जब मुझे पूरी गड़बड़ी पर मेरी राय के लिए लाया गया था।

सिस्टम संचार के साधन के रूप में डेटाबेस का उपयोग करने का पूरा विचार मुझे मजाकिया लगता है। व्यापार तर्क को कई प्रणालियों में रखा जाना चाहिए (यदि सिस्टम ए सिस्टम बी में डेटा जोड़ना चाहता है तो यह सम्मिलित करने से पहले डेटा से संबंधित बी के नियमों को बेहतर ढंग से समझता है), कई प्रणालियों को खोजने के लिए डेटाबेस मतदान के कुछ रूपों को सबसे अधिक करना होगा उनके डेटा में कोई भी परिवर्तन, निरंतर रखरखाव सिरदर्द होगा, क्योंकि डेटाबेस स्कीमा में कोई भी बदलाव अब कई प्रणालियों का प्रचार करता है।

मेरा पहला विचार समय लेने और विभिन्न प्रणालियों के लिए एपीआई/सेवाओं को लिखना था, जिसे एक बार लिखे जाने के लिए आसानी से डेटा को पास/पुनर्प्राप्त करने के लिए आसानी से उपयोग किया जा सकता था। अन्य कई डेवलपर्स का मानना ​​है कि डेटाबेस का उपयोग करने की तुलना में अत्यधिक और कहीं अधिक काम है।

तो इन प्रणालियों को एक-दूसरे से बात करने के बारे में जाने का सबसे अच्छा तरीका क्या होगा?

Answer 1

अलग-अलग प्रणालियों को एकीकृत करना मेरा दिन का काम है।

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

केंद्रीय डेटाबेस का विचार जरूरी नहीं है ... लेकिन प्रयासों की मात्रा शायद सिस्टम को स्क्रैच से पुनः लिखने की परिमाण के क्रम में है। निश्चित रूप से ऐसा कुछ नहीं है जिसे मैं कम से कम आपके द्वारा वर्णित रूप में वर्णित करता हूं। यह सफल हो सकता है, लेकिन यह बहुत कठिन है और पॉइंट-टू-पॉइंट एकीकरण दृष्टिकोण की तुलना में यह बहुत अधिक अनुशासन लेता है। यह सुनकर मजाकिया लगता है कि यह उसी सांस में सुझाव दिया गया है कि 'गायब' दृष्टिकोण सिर्फ अन्य प्रणालियों में सीधे डेटा को घुमाने के दृष्टिकोण के रूप में है।

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

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

शुभकामनाएं।

संपादित करें:

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

Answer 2

ऐसा लगता है कि आप राय की तलाश कर रहे हैं, इसलिए मैं अपना प्रदान करूंगा।

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

Answer 3

लगता है जैसे आप Message Queuing और message-oriented middleware की जांच कर सकते हैं।

MSMQ और Java Message Service उदाहरण होने के नाते।

Answer 4

धक्का/पोकिंग डेटाबेस के माध्यम से सीधे इंटरफेसिंग एक प्रणाली के बहुत से आंतरिक विवरण को दूसरे में प्रकट करता है। स्पष्ट नुकसान हैं: एक प्रणाली को अपग्रेड करना दूसरे को तोड़ सकता है। इसके अलावा, एक प्रणाली दूसरे के डेटाबेस तक कैसे पहुंच सकती है, इस बारे में तकनीकी सीमाएं हो सकती हैं (विचार करें कि यूनिक्स पर सी में लिखे गए एप्लिकेशन को Windows 2003 सर्वर पर चल रहे SQL सर्वर 2005 डेटाबेस से कैसे इंटरैक्ट किया जाएगा)।

पहली बात यह है कि आपको निर्णय लेना है कि "मास्टर डेटाबेस" निवास होगा, और मिडलवेयर के लिए उतना ही आवश्यक गोंद प्रदान करेगा। एपीआई स्तर मिडलवेयर-एकीकरण (जैसे कोर्बा) की ओर जाने के बजाय, मैं आपको संदेश ओरिएंटेड मिडलवेयर पर विचार करने का सुझाव दूंगा। एमएस बिज़टॉक, सन का ईगेट और ओरेकल का फ़्यूज़न कुछ विकल्प हो सकता है।

एक नए डेटाबेस का आपका विचार सही दिशा में एक कदम है। आप Enterprise Entity Aggregation पैटर्न पर थोड़ा सा पढ़ना चाहेंगे।

मिडलवेयर के साथ "डेटा एकीकरण" का संयोजन जाने का तरीका है।

Answer 5

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

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

Answer 6

यदि आप मिडलवेयर + सिंगल सेंट्रल डाटाबेस रणनीति की ओर जा रहे हैं, तो आप इसे कई चरणों में प्राप्त करने पर विचार करना चाहेंगे।

1. विभिन्न प्रणालियों जो प्रत्येक प्रणाली मिडिलवेयर की
2. कार्यान्वयन जो इन API एक्सेस करता है और करने के लिए सभी प्रणालियों लिए एक इंटरफेस प्रदान के लिए कार्यक्षमता को बेनकाब करने के लिए सेवाओं/एपीआई का कार्यान्वयन: यहाँ एक तार्किक कदम रखा प्रक्रिया है जो माना जा सकता है है अन्य सिस्टम से डेटा/सेवाओं तक पहुंच (उपलब्ध होने पर केंद्रीय स्रोत से डेटा एक्सेस करता है, अन्यथा इसे किसी अन्य सिस्टम से प्राप्त करता है)
3. डेटा के बिना केवल डाटाबेस का कार्यान्वयन,
4. मिडलवेयर स्तर पर कैशिंग/डेटा-स्टोरेज सेवाओं का कार्यान्वयन जो केंद्रीय डाटाबेस में डेटा स्टोर/कैश कर सकता है जब भी उस डेटा को किसी भी सिस्टम से एक्सेस किया जाता है उदा। अगर सिस्टम ए के रिकॉर्ड्स 1-5 को मिडलवेयर के माध्यम से सिस्टम बी द्वारा लाया जाता है, तो मिडलवेयर डाटा कैशिंग सर्विसेज इन रिकॉर्ड्स को केंद्रीकृत डेटाबेस में स्टोर कर सकता है और अगली बार इन रिकॉर्ड्स को केंद्रीय डेटाबेस
5. पर समेकित किया जा सकता है समानांतर में डेटा सफाई हो सकती है
6. तुम भी एक दैनिक आधार पर केंद्रीय डेटाबेस के लिए कई सिस्टम से डेटा पुश करने के लिए एक आयात तंत्र (स्वचालित या मैन्युअल)

इस तरह बना सकते हैं, प्रयास कई मील के पत्थर भर में वितरित किया जाता है और डेटा धीरे-धीरे संग्रहीत किया जाता है केंद्रीय डेटाबेस में पहले-पहुंच-पहले-संग्रहीत आधार पर।