इस लेख के साथ, मैं इस उत्पाद के लिए विकास के संदर्भ में IBM WebSphere ESB (इसके बाद - ESB) को समर्पित एक श्रृंखला खोलना चाहूंगा। और, सबसे पहले, आपको इस तरह की प्रौद्योगिकियों के साथ बेहतर जानना होगा।
एंटरप्राइज सर्विस बस (उद्यम सेवा बस) - मिडलवेयर जो सेवा-उन्मुख वास्तुकला के सिद्धांतों के आधार पर विभिन्न सूचना प्रणालियों के बीच एक केंद्रीकृत और एकीकृत घटना-उन्मुख संदेश प्रदान करता है।
बेशक, आप विशेष सॉफ्टवेयर के बिना इस दृष्टिकोण के आधार पर एक कॉर्पोरेट प्रणाली का निर्माण कर सकते हैं (शायद आम तौर पर अभी भी कुछ विकसित करने की आवश्यकता है), और सेवा बस को कॉल करें जो परिणाम है। लेकिन आईबीएम के उत्पाद में न केवल केंद्रीकृत संदेश और इस प्रक्रिया के नियंत्रण के लिए एक ऑफ-द-शेल्फ डिवाइस है, बल्कि विशेष रूप से ईएसबी के लिए लचीली सेवा-उन्मुख अनुप्रयोगों के विकास के लिए क्षमताओं का एक पूरा सेट है। सारांश में, आईबीएम वेबस्फेयर ईएसबी की निम्नलिखित विशेषताओं और लाभों पर प्रकाश डाला जा सकता है:
- वास्तुकला संबंधों का क्रम और एकरूपता
- केंद्रीकृत प्रबंधन
- सर्वर-साइड अनुप्रयोग कॉन्फ़िगरेशन
- सेवा-उन्मुख वास्तुकला सिद्धांतों की भावना में सेवा घटक वास्तुकला (एससीए) प्रौद्योगिकी का कार्यान्वयन
- विकसित कार्यक्रम कोड की प्रोटोकॉल स्वतंत्रता
- व्यापक बस और आवेदन विन्यास विकल्प
इसी समय, ईएसबी लेनदेन नियंत्रण, डेटा रूपांतरण, सुरक्षा और गारंटीकृत संदेश वितरण प्रदान करता है। एक बिंदु के माध्यम से सभी सेवा सेवाओं तक पहुंच आपको सेवाओं के संचार को केंद्रीय रूप से कॉन्फ़िगर करने की अनुमति देती है। आप मास एरर हैंडलिंग के लिए असफल घटनाओं को केंद्र में रख सकते हैं।
क्लासिक ईएसबी बिल्ड टोपोलॉजी एक क्लस्टर है जो क्षैतिज मापनीयता और गलती सहिष्णुता प्रदान करता है। आधिकारिक सिफारिशों के अनुसार, क्लस्टर सदस्यों की संख्या बढ़ने से स्टैंड-अलोन टोपोलॉजी के साथ सर्वर क्षमता बढ़ाने की तुलना में उत्पादकता अधिक कुशलता से बढ़ती है। इसके अलावा, सेवा को बंद किए बिना क्लस्टर को रिबूट किया जा सकता है (या इसका कुछ भाग विफल हो सकता है)।
आमतौर पर, ईएसबी को आईबीएम बीपीएम में एक सेवा परत के रूप में उपयोग किया जाता है, लेकिन यह एक शक्तिशाली एकीकरण उपकरण के रूप में कॉर्पोरेट सिस्टम के इंटरैक्शन के लिए एक मॉडल बनाने में अग्रणी भूमिका निभा सकता है (मतलब ईएसबी आईबीएम वेबस्फेयर एप्लिकेशन सर्वर के लिए ऐड-ऑन के रूप में)।
यह वास्तव में, ईएसबी से आवश्यक है, क्योंकि यह एक "सेवा संग्रह बिंदु" है - यदि आपको ऐसी सेवा की आवश्यकता है जो अन्य सेवाओं (संभवतः बाहरी) के साथ काम करेगी, तो इन सेवाओं के बीच एकीकरण ईएसबी पर करने के लिए सबसे तर्कसंगत है। बाहरी या विषम सेवाओं के लिए, आप ईएसबी सेवा के साथ "रैपर" बना सकते हैं। आइए हम सेवाओं के लिए "एकल आवास" का उपयोग करने की थोड़ी सुविधा का वर्णन करें:
क्रमप्रणाली जितनी बड़ी होगी, उतना ही महत्वपूर्ण उसका क्रम और एकरूपता। यदि हम एक बड़े उद्यम के सिस्टम के एक जटिल के बारे में बात कर रहे हैं, तो इसे निश्चित रूप से एक बड़े आकार की प्रणाली कहा जा सकता है। बेशक, आप हमेशा एक प्रशासक पा सकते हैं जो सैकड़ों सर्वरों की इंटरैक्शन स्कीम को ध्यान में रखता है, या प्रत्येक प्रोग्राम मॉड्यूल के लिए असंबंधित प्रलेखन के संस्करणों का एक गुच्छा है, जो बताता है कि यह कैसे और कैसे बातचीत करता है।
लेकिन एक सेवा (ESB) होना बहुत आसान है, जो आपको स्वयं के माध्यम से सभी इंटरैक्शन को पूरा करने की अनुमति देता है। इस दृष्टिकोण के साथ, किसी भी सबसिस्टम में इंटरैक्शन आर्किटेक्चर का हिस्सा पहले से ही स्पष्ट है - सिस्टम, सर्वर और एप्लिकेशन के बीच कनेक्शन में कोई गड़बड़ नहीं है: सब कुछ ईएसबी से जुड़ा हुआ है और ईएसबी सब कुछ के साथ जुड़ा हुआ है।
केंद्रीकृत प्रबंधनसिस्टम को केंद्रीय रूप से कॉन्फ़िगर करना हमेशा अधिक सुविधाजनक होता है - चाहे वह कॉन्फ़िगरेशन हो, मूविंग सर्वर का अनुकूलन हो, फॉल्ट टॉलरेंस, लोड बैलेंसिंग, एरर हैंडलिंग या मॉनिटरिंग और एनालिटिक्स हो।
उदाहरण के लिए, डेटाबेस सर्वर को स्थानांतरित करते समय, आपको सभी मौजूदा एप्लिकेशन सर्वरों के कॉन्फ़िगरेशन में आने की आवश्यकता नहीं होती है, और विशेष रूप से विशिष्ट अनुप्रयोगों की सेटिंग में, ईएसबी में एक पर्यावरण चर होना पर्याप्त है, जिसमें डेटाबेस पते का संकेत दिया गया है, और फिर केवल एक बिंदु पर परिवर्तन करने की आवश्यकता होगी।
या यदि बाहरी सिस्टम में से एक लंबे समय के लिए अनुपलब्ध था, और इसके लिए कोई अनुरोध नहीं खोना चाहिए, तो आप असफल घटनाओं को संसाधित करने के लिए सेवा का उपयोग कर सकते हैं जब यह सुविधाजनक हो तो संदेशों को "फेंक" दें।
यदि आपको किसी भी सिस्टम में एक साथ अनुरोधों की संख्या को समायोजित करने, या इन अनुरोधों की निगरानी करने, लोड का विश्लेषण करने, बाधाओं की तलाश करने की आवश्यकता है - आपको ईएसबी सर्वर के कंसोल पर मैसेजिंग कंट्रोल सेंटर पर जाने की आवश्यकता है।
सर्वर साइड कॉन्फ़िगरेशनसेवाओं के लिए "एकल आवास", कॉन्फ़िगरेशन के दृष्टिकोण से, आपको कई उपयोगी लक्ष्यों को प्राप्त करने की अनुमति देता है। सबसे पहले, यह कॉन्फ़िगरेशन का पुन: उपयोग (कोड और मॉड्यूल का पुन: उपयोग करने के लिए समान है, जो SOA में इतना उपयोगी है), क्योंकि विभिन्न मॉड्यूल और अनुप्रयोग समान डेटाबेस कनेक्शन मापदंडों, संसाधनों, प्रमाणीकरण मापदंडों, पर्यावरण चर, आदि का उपयोग कर सकते हैं। ।
दूसरे, सर्वर साइड पर कॉन्फ़िगर करते समय, यह एप्लिकेशन वातावरण है जो इसे कई तरीकों से प्रभावित कर सकता है, जो आपको अलग-अलग छोरों (परीक्षण और उत्पादक) के बीच अनुप्रयोगों को स्थानांतरित करने की अनुमति देता है, यहां तक कि धुन और यहां तक कि बग को ठीक करने के लिए एप्लिकेशन को बिना परिवर्तन किए।
यदि आप इन सभी लाभों का उपयोग करते हैं, तो अनुप्रयोगों को एक सच्चे गिरगिट की क्षमता मिलती है - वे इतने लचीले होते हैं कि वे उस वातावरण का हिस्सा बन जाते हैं जिसमें वे काम करते हैं, और साथ ही साथ उनकी महत्वपूर्ण कार्यक्षमता लाते हैं।
लेकिन IBM WebSphere ESB के लिए अनुप्रयोगों का लचीलापन उनके वातावरण तक सीमित नहीं है। विकास क्षमताएं इसमें एक बहुत बड़ा योगदान देती हैं। चूंकि सिस्टम को न केवल चलाने की आवश्यकता है, बल्कि इसे विकसित करने और विकसित करने की भी आवश्यकता है, इन दिलचस्प बिंदुओं को याद नहीं किया जाना चाहिए:
एससीएयह वास्तुकला इस सिद्धांत पर आधारित है कि एक घटक अन्य घटकों के लिए उपलब्ध सेवा के रूप में अपनी कार्यक्षमता प्रदान करता है। एक मॉड्यूल के भीतर, घटक प्रोग्राम ब्लॉक (जावा कोड) हैं जो संबंधित इंटरफ़ेस द्वारा वर्णित एक निश्चित कार्यक्षमता को पूरी तरह से लागू करते हैं। घटक निष्पादन के तर्क को इंटरफेस और संदर्भ एस (पार्टनर संदर्भ) पर एक संरचना में जोड़कर कार्यान्वित किया जाता है।
इस तरह के एक मॉड्यूल संरचना को विकसित करना, सत्यापित करना, विकसित करना, संशोधित करना और इसे बनाए रखना बहुत सुविधाजनक है। घटकों में कार्यान्वित कार्यक्षमता की परमाणुता आपको कोड स्तर तक छोड़ने के बिना, समग्र रूप से घटकों पर काम करने की अनुमति देती है। दूसरी ओर, यह एक संक्रियात्मक संदर्भ में घटकों के कार्यान्वयन के मद्देनजर तार्किक रूप से आवश्यक है।
प्रत्येक घटक में एक इंटरफ़ेस (एस) होता है, जिसका कार्यान्वयन वह प्रदान करता है। इस प्रकार, घटकों को एक साथ जोड़ना, उनकी आंतरिक विशेषताओं को जानने की कोई आवश्यकता नहीं है - यह पर्याप्त है कि वे आवश्यक इंटरफेस को लागू करें।
इस वास्तुकला का उपयोग करना, "मैनुअल" प्रवाह नियंत्रण के बिना समानांतर संचालन की आवश्यकता वाले सभी कार्यों को हल करना भी संभव है (उदाहरण के लिए, आप विलंबित प्रतिक्रिया के साथ कई घटकों को अतुल्यकालिक कॉल कर सकते हैं)।
गैर-जावा घटक, उदाहरण के लिए, निर्यात और आयात प्रकार, आपको बाहरी उपयोग के लिए सेवाएं प्रदान करने या बाहरी सेवाओं का उपयोग करने की अनुमति देते हैं; मध्यस्थता प्रवाह घटक अन्य घटकों के बीच संदेशों का आदान-प्रदान करने के लिए निम्न-स्तरीय पहुंच प्रदान करता है और विषम इंटरफेस के साथ काम करते समय विभिन्न परिवर्तनों के लिए अनुमति देता है।
इंटरफेस के अलावा, आईबीएम बिजनेस ऑब्जेक्ट फ्रेमवर्क बहुत उपयोगी सुविधाएँ प्रदान करता है। व्यावसायिक वस्तुओं (बीओ), जिसे xsd- योजनाओं द्वारा दर्शाया गया है, का उपयोग इंटरफेस में डेटा ट्रांसफर के लिए, दोनों घटकों के बीच और मॉड्यूल के बीच संचार के लिए वस्तुओं के रूप में किया जाता है। वे सीधे एकीकृत हैं, उदाहरण के लिए, वेब सेवाओं का वर्णन करने के लिए एक wsdl योजना में। उदाहरण के लिए, यदि मॉड्यूल "A" एक वेब सेवा के रूप में अपनी कार्यक्षमता प्रदान करता है, तो मॉड्यूल "B" के लिए यह इंटरफेस और इसे उपयोग करने के लिए तैयार किए गए BO को जोड़ने के लिए पर्याप्त है, और यह पूरी तरह से किसी भी अतिरिक्त जावा बनाने के साथ इस तरह की सेवा के साथ काम करने में सक्षम होगा डेटा ट्रांसफर के लिए -objects। डेटाबेस के साथ डेटा का आदान-प्रदान करते समय बीओ का उपयोग करना सुविधाजनक होता है, यदि यह डेटा अन्य घटकों द्वारा उपयोग किया जाता है (यह, निश्चित रूप से, "डीएओ" पैटर्न पर काउंटर चलाता है, लेकिन अनावश्यक जावा-ऑब्जेक्ट्स और पुनर्लेखन डेटा के संचालन को "आगे और पीछे") समाप्त करता है।
प्रोटोकॉल स्वतंत्रताजैसा कि आप देख सकते हैं, निर्यात और आयात घटकों का उपयोग करके प्रोटोकॉल-स्वतंत्र कोड प्राप्त किया जाता है। चूंकि इन घटकों के साथ संचार इंटरफेस और संदर्भ से गुजरता है, इसलिए प्रोग्राम कोड इंटरैक्शन के लिए उपयोग किए जाने वाले प्रोटोकॉल से पूरी तरह से स्वतंत्र है। किसी भी समर्थित प्रोटोकॉल और किसी भी वांछित इंटरफेस के माध्यम से एक और एक ही कार्यक्षमता को आसानी से सुलभ बनाया जा सकता है। निम्नलिखित आंकड़ा एक घटक को SCA- बद्ध निर्यात के अलावा दिखाता है जो पहले से ही इसका इंटरफ़ेस HTTP, JMS और वेब सेवा के रूप में प्रदान करता है।
सुविधा स्पष्ट है - लचीलापन, बहुमुखी प्रतिभा, कोड का पुन: उपयोग, विकास की गति और संशोधन।
वैसे, SCA बाइंडिंग एक विशेष प्रोटोकॉल का उपयोग करता है और एक ही सर्वर / क्लस्टर के भीतर मॉड्यूल के बीच संचार के लिए अभिप्रेत है। इस बाइंडिंग के माध्यम से इंटरैक्शन अन्य प्रोटोकॉल की तुलना में कम संसाधन गहन और तेज है।
का विन्याससर्वर और एप्लिकेशन कॉन्फ़िगरेशन IBM कंसोल सर्वर के माध्यम से किया जाता है।
ईएसबी में, सामान्य रूप में आईबीएम वेबस्फेयर के रूप में, कुछ विशिष्ट विशेषताएं और कलाकृतियां हैं। उदाहरण के लिए, समान आयात और निर्यात का उपयोग करते समय, आप मक्खी पर संबंधित सेवाओं के अंत-बिंदुओं को कॉन्फ़िगर कर सकते हैं। सेवा कॉल के लिए, आप विभिन्न प्रकार के नियमों के साथ नीति सेट कॉन्फ़िगर कर सकते हैं (उदाहरण के लिए, आप WS-AT तंत्र के लिए समर्थन स्थापित कर सकते हैं, जो आपको उसी लेनदेन में वेब सेवा को कॉल करने की अनुमति देता है जिसमें ग्राहक काम करता है; लेकिन पूर्णता पूर्ण लेख के लिए एक विषय है), प्रमाणीकरण पैरामीटर सेट करें, प्रमाण पत्र और अधिक कनेक्ट करें।
कॉन्फ़िगरेशन के माध्यम से, आप असाधारण स्थितियों के लिए स्वचालित रूप से जवाब देने के लिए कुछ तंत्र को कॉन्फ़िगर कर सकते हैं (उदाहरण के लिए, त्रुटियों के होने पर घटक निष्पादन की स्वचालित पुनरावृत्ति)। आप मक्खी पर घटक अनुरेखण को कॉन्फ़िगर कर सकते हैं या लॉगिंग स्तरों को बदल सकते हैं। असफल घटनाओं के प्रबंधन के लिए एक सेवा भी उपलब्ध है, जिसे बड़े पैमाने पर त्रुटि से निपटने के लिए जानबूझकर उपयोग किया जा सकता है।
खैर, निश्चित रूप से, आप जावा 2 ईई विनिर्देश के अनुसार बहुत सी अन्य चीजों को कॉन्फ़िगर कर सकते हैं, जो कभी-कभी काफी सख्ती से आईबीएम एप्लीकेशन सर्वर में लागू किया जाता है।
उपरोक्त सभी ईएसबी एक सुविधाजनक, शक्तिशाली और लचीले एकीकरण उपकरण के रूप में दावा करते हैं, यद्यपि हमेशा सीखना आसान नहीं होता है। भविष्य में, आपको बस यह सीखने की ज़रूरत है कि इसका उपयोग कैसे किया जाए।
निम्नलिखित छवियों का उपयोग लेख में किया गया है: 1 2 3 4 5