सूचना प्रणालियों के एकीकरण के लिए सिमेंटिक वेब टेक्नोलॉजीज

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

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

सिस्टम बनाते समय, मैं इस धारणा से आगे बढ़ा कि कई सूचना प्रणालियों को बहुत जल्दी (कई सेकंड के अंतराल के साथ) एक-दूसरे को अपने डेटा स्टोर में होने वाले परिवर्तनों के बारे में सूचित करना चाहिए। इसलिए, वास्तुकला दृढ़ता से संदेश कतार बस जैसा दिखता है, जिसकी मुख्य विशेषता यह है कि संदेश सामग्री आरडीएफ सिंटैक्स में व्यक्त की जाती है, अर्थात यह ट्रिपल है। प्रत्येक पूर्णांक प्रणाली के हिस्से पर, क्लाइंट एक्सचेंज मॉड्यूल है जो प्राप्त संदेशों की व्याख्या करता है और यदि आवश्यक हो, तो इस सिस्टम के डेटा वेयरहाउस में उचित परिवर्तन करता है। क्लाइंट मॉड्यूल सक्रिय है, अर्थात्, यदि रिपॉजिटरी में परिवर्तन हुए हैं जो अन्य प्रणालियों को रिपोर्ट करने की आवश्यकता है, तो यह आरडीएफ में इन परिवर्तनों के बारे में जानकारी को एन्कोड करता है और इसे बस पर एक संदेश के रूप में भेजता है।
बस में राउटर की भूमिका केंद्रीय मध्यस्थ सर्वर द्वारा की जाती है, जिसमें विभिन्न प्रकार के डेटा, वितरण की गारंटी, डेटा अखंडता की निगरानी के अधिकार के बारे में जानकारी होती है (और, यदि आवश्यक हो, तो इसे पुनर्स्थापित करने का प्रयास करता है), और कई अन्य उपयोगी कार्य भी करता है। नीचे दिया गया आंकड़ा एक्सचेंज में शामिल सॉफ़्टवेयर घटकों का एक आरेख दिखाता है। दो एक्सचेंज सिस्टम के उदाहरण के रूप में, एक तरफ PHP / MySQL में एक निश्चित वेब एप्लिकेशन, और दूसरी तरफ 1C कॉन्फ़िगरेशन। मध्यस्थ सर्वर को PHP / MySQL में भी लागू किया जाता है, हालांकि, इसे अधिक उपयुक्त प्लेटफॉर्म पर फिर से लिखा जाएगा। डेटाबेस के लिए, क्लाइंट घटक पहले से ही ध्यान नहीं रखता है कि किस डेटाबेस के साथ काम करना है - MySQL, PostgreSQL या Oracle।

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

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

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

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