वेबस्पेयर एमक्यू ऑब्जेक्ट नामकरण सम्मेलन

Question

कतार प्रबंधकों, कतारों (स्थानीय, रिमोट, ट्रांसमिट, मृत पत्र कतार ...), चैनल आदि के लिए वेबस्पेयर एमक्यू नामकरण सम्मेलनों के लिए अनुशंसित दिशानिर्देश क्या हैं। मुझे आईबीएम के developerWorks पर एक मिला देखें कि वहां कुछ और व्यापक है या नहीं। धन्यवाद।

Answer 1

यह एक नए Mission:Messaging कॉलम के लिए एक अच्छा विषय की तरह लगता है लेकिन मैं यहां संघीय संस्करण लिखूंगा। मैं यह ध्यान देकर अपने उत्तर का प्रस्ताव दूंगा कि मेरी कई सिफारिशें उन लोगों के विपरीत हैं जो आपको कहीं और मिल सकती हैं। कुछ मामलों में ऐसा इसलिए होता है क्योंकि एमक्यू का सामान्य रूप से उपयोग किया जाने वाला तरीका वर्षों से बदल गया है। अन्य मामलों में ऐसा इसलिए होता है क्योंकि परंपरागत ज्ञान ने कभी भी शुरुआत करने के लिए अच्छा काम नहीं किया। (उदाहरण के लिए TO.QMGR नामक क्लस्टर चैनल।) सभी मामलों में, मैं उन सम्मेलनों को प्राथमिकता देता हूं जो व्यापक स्थितियों पर लागू होते हैं। इसका मतलब है कि विशिष्ट मामलों के लिए इन नियमों के अपवादों को आमतौर पर खोजना संभव है लेकिन फिर भी वे व्यापक रूप से लागू होते हैं।

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

डॉट कैरेक्टर . को विभाजक के रूप में उपयोग करें।
प्रमाणीकरण नियम अलग-अलग के रूप में डॉट वर्णों का उपयोग करके नामों का विश्लेषण करते हैं। उदाहरण के लिए, कतार का नाम MY.EXAMPLE.QUEUE.NAMEMY.*.*.* या MY.** जैसे नियमों से मेल खाता है लेकिन MY.* नहीं है क्योंकि डॉट्स नाम नोड विभाजक वर्णों को इंगित करते हैं। अपने नामकरण नोड विभाजक के रूप में लगातार अंडरस्कोर के बजाय अपने आप को एक पक्ष बनाओ और डॉट्स का उपयोग करें।

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

उदाहरण के लिए, यदि आप एक नामकरण परंपरा है कि चैनल नाम SRCQMGR.DESTQMGR की तरह लग रहे चाहिए बनाने तो यह संभव है एक स्क्रिप्ट के लिए एक RCVR या SDR चैनल का नाम पढ़ सकते हैं और दो कतार प्रबंधकों को जोड़ता है के नाम प्राप्त करने के लिए। हालांकि, स्क्रिप्ट एक चैनल नाम के साथ क्या करती है जैसे GA.PAYROLL.OPS? क्या यह कतार प्रबंधक OPS कतार प्रबंधक से कनेक्ट है? या यह कतार प्रबंधक PAYROLL.OPS कतार प्रबंधक से कनेक्ट है? एक इंसान तुरंत संदर्भ के आधार पर बताने में सक्षम हो सकता है लेकिन स्क्रिप्ट्स जो भी आप चाहते हैं उसके बजाए उन्हें बताए जाने के लिए कुख्यात हैं। इसी तरह की स्थितियां उत्पन्न होती हैं जब कतार के नामों की शुरुआत और अंत के नाम और नोड्स की एक चर संख्या दोनों पर स्थिति-निर्भर क्वालीफायर होते हैं।

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

नाम
एक SOA दुनिया में रखी गई वस्तु की विशेषताओं को शामिल न करें, कतारों और विषयों गंतव्य के विभिन्न प्रकार के होते हैं और अक्सर परस्पर विनिमय कर रहे। संदेशों को जो कुछ भी लगता है उसे जोड़ने के लिए कुछ कतार नहीं है (या देखभाल!) अगर वे वास्तव में कतार या विषय पर जा रहे हैं। एक कतार जिसमें संदेशों के लिए इसे सुनने वाला एक एप्लिकेशन प्रशासनिक सदस्यता द्वारा खिलाया जा सकता है जो वास्तव में एक या अधिक विषयों से प्रकाशनों में रस्सी कर रहा है।

हम वास्तव में किस चीज की परवाह करते हैं, यह संदेश की प्रकृति है - वे क्या कार्य करते हैं - यह नहीं कि हम स्थानीय कतार या उपनाम कतार से कनेक्ट हैं या नहीं। तो .QA, .QL, .TPC (विषय के लिए) जैसे क्वालीफायर जोड़ना और आगे नहीं समझ में आता है। इसी प्रकार, एक चैनल नाम पर .RCVR जोड़ना 5 उपयोगी वर्ण बेकार करता है जो QMgr नाम का वर्णन करने के लिए बेहतर इस्तेमाल किया जा सकता था। इससे भी बदतर, ये प्रथाएं ऑब्जेक्ट नामों में टोपोलॉजी को सेंकती हैं, जिससे सिस्टम कम लचीला और अधिक भंगुर होता है।

चैनल के नाम

प्वाइंट टू प्वाइंट चैनल के नाम RCVR के लिए SRCQMGR.DESTQMGR तरह
उपयोग के नाम, RQSTR, SDR, और SVR चैनलों। यह भाषा है कि बाएँ से सही पढ़ा ओर पक्षपाती क्योंकि इरादा डेटा से प्रवाह एक QMgr के लिए एक और QMgr

क्लस्टर चैनलों CLUSNAME.QMNAME तरह
उपयोग नामों का वर्णन करने के है। पुराने ज्ञान ने TO.QMNAME जैसे नामों का उपयोग करने के लिए कहा लेकिन यदि आपने कभी ओवरलैपिंग क्लस्टर को कार्यान्वित किया है तो यह एक ही चैनल को कई क्लस्टर के लिए उपयोग करने का कारण बनता है। यह बुरा है क्योंकि आप किसी दूसरे को प्रभावित किए बिना एक क्लस्टर पर रखरखाव कभी नहीं कर सकते हैं। CLUSNAME.QMNAME का उपयोग करना यह सुनिश्चित करता है कि प्रत्येक QMgr में प्रत्येक क्लस्टर के लिए समर्पित CLUSRCVR चैनल है जिसमें यह भाग लेता है।

क्लाइंट चैनल
"नाम में वस्तु की विशेषताओं को शामिल नहीं करते" करने के लिए अपवाद यकीनन SVRCONN चैनल है। ऐसा इसलिए है क्योंकि चैनल नेटवर्क की तार्किक परत के बजाय भौतिक से बहुत बंधे हैं। इसलिए एक एसवीआरकॉन चैनल नाम में QMgr नाम डालना आम तौर पर ठीक है। यदि लोग अंत में .SVRCONN जोड़ना चाहते हैं, तो मैं बहुत दृढ़ता से ऑब्जेक्ट नहीं करता हूं।

क्लाइंट चैनलों के बारे में याद रखने की बात यह है कि यदि आप क्लाइंट चैनल परिभाषा तालिका (सीसीडीटी) का उपयोग करते हैं तो उस तालिका में अद्वितीय अनुक्रमणिका चैनल का नाम है। इसका मतलब है कि आपके पास एकाधिक QMgrs पर एक ही चैनल का नाम नहीं हो सकता है और अभी भी एक सीसीडीटी का उपयोग कर सकते हैं। चूंकि सीसीडीटी एसएसएल/टीएलएस चैनल के विवरण को कॉन्फ़िगर करने का एक तरीका है, इसलिए इसे "पूरी तरह से सुरक्षित WMQ" प्रोजेक्ट के साथ आने तक इसकी पूरी तरह से सराहना नहीं की जाती है। शुरुआत से SVRCONN चैनलों के लिए अद्वितीय चैनल नामों का उपयोग करके, आप भविष्य में नेटवर्क को प्रमाणित कर सकते हैं। आम तौर पर ये नाम APP.QMNAME जैसा दिखते हैं या यह स्पष्ट करने के लिए कि आप क्लस्टर या पॉइंट-टू-पॉइंट चैनल, APP.QMNAME.SVRCONN या इसी तरह से काम नहीं कर रहे हैं।

कतार प्रबंधक के नाम

कोई डॉट्स QMgr नाम पिछले नियमों के
एक निहितार्थ है कि क्लस्टर और कतार प्रबंधक नाम केवल एक नोड शामिल होना चाहिए और इसलिए एक . वर्ण होना कभी नहीं करना चाहिए में। ऐसा इसलिए है क्योंकि चैनल नाम आमतौर पर क्लस्टर और/या QMgr नाम से व्युत्पन्न होते हैं। तो ऊपर दिए गए उदाहरण में, RCVR चैनल नाम जैसे GA_PAYROLL.OPS दोनों मनुष्यों और स्क्रिप्ट्स को बताएंगे कि प्रश्न में चैनल GA_PAYROLL नामक QMgr को OPS नामक QMgr से जोड़ता है। 9 वर्ण या उससे कम
चैनल नामों में से

नाम केवल 20 वर्ण हो सकता है। डॉट सेपरेटर के लिए एक घटाएं, दो और राउंड डाउन से विभाजित करें, आपको कतार प्रबंधक के लिए अधिकतम 9 वर्ण प्राप्त होते हैं। अगर वहाँ एक संभावना है कि आप विभिन्न चैनलों सेवा की कक्षाओं के लिए (बड़े छोटे संदेशों बनाम के लिए, निर्धारित कर सकते हैं उदाहरण के लिए, तो QMgr नाम के लिए 8 वर्ण या उससे कम करने के लिए वापस ड्रॉप है। यह आदि QM1.QM2.A, QM1.QM2.B की ओर जाता है,

QMgr नाम भौतिक परत
सेवा-उन्मुख दुनिया में, हम वास्तव में कतारों और विषयों जैसे गंतव्य नामों की परवाह करते हैं। हम कतार प्रबंधक नामों के बारे में बहुत कम ख्याल रखते हैं क्योंकि ये कतारों और विषयों के लिए केवल जीवन समर्थन हैं। ग्राहक ऐप्स डॉन के बारे में बहुत अधिक परवाह नहीं है, जो कनेक्ट करने के लिए QMgr, जब तक वे अनुरोध भेज सकते हैं और जवाब प्राप्त कर सकते हैं। WMQ बहुत आसानी से जवाब में भर जाता है-आउटपुट अनुरोधों पर QMgr नाम के लिए यह दुर्लभ है कि किसी एप्लिकेशन को इसके बारे में जानना आवश्यक है।

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

कभी भी QMgr नामों का पुन: उपयोग न करें!
दुर्भाग्यवश दुर्भाग्यवश एक क्यूएमग्री को एक स्थान से दूसरे स्थान पर "स्थानांतरित" करना या एक ही नाम के साथ प्राथमिक और आपदा रिकवरी QMgr रखना बहुत आम है। इस अभ्यास का आमतौर पर मतलब है कि आवेदन का कुछ हिस्सा QMgr नाम पर निर्भर है और इसलिए नाम का पुन: उपयोग करना "आसान" है। आईबीएम ने QMID को QMgr नामों का पुन: उपयोग करके पेश की गई कुछ समस्याओं का समाधान करने के तरीके के रूप में पेश किया। ठेठ उपयोग का मामला यह है कि एक नोड पुनर्निर्मित हो जाता है और क्यूएमजीआर को एक बार खरोंच से पुनर्निर्मित किया जाता है। क्लस्टर जानता है कि यह एक नया QMgr है क्योंकि QMID बदल गया है, लेकिन रूटिंग और अन्य परिचालनों के लिए उपयोग किया जाने वाला नाम वही रहता है।

हालांकि यह उस सीमित उपयोग मामले में मदद करता है, लेकिन यह उन मुद्दों का समाधान नहीं करता है जब एक ही नाम के साथ दोनों QMgrs एक ही समय में ऑनलाइन होते हैं। न ही यह समस्या को हल करता है कि एक प्रतिष्ठित प्रमाणपत्र प्राधिकरण एक ही विशिष्ट नाम के साथ कई कर्ट जारी नहीं करेगा जो एकाधिक QMgrs के लिए एक ही प्रमाण पत्र का पुन: उपयोग करता है।

याद रखें कि QMgrs कतारों और विषयों के लिए केवल जीवन समर्थन हैं और आदर्श रूप से उनके उपयोग के अनुप्रयोगों के लिए अज्ञात होंगे। एक नामकरण सम्मेलन चुनें जो आपको आवश्यकतानुसार सैकड़ों या हजारों द्वारा अद्वितीय नामों के साथ नए QMgrs को स्पिन करने की अनुमति देता है, ताकि आपको QMgr नामों का पुन: उपयोग करने की आवश्यकता न हो।

अन्य वस्तुओं इरादा-खुलासा नाम
या दूसरे शब्दों में कहें, यह क्या करता के लिए वस्तु का नाम रख कर नहीं यह क्या है

का प्रयोग करें। उदाहरण के लिए, यदि आप उपन्यासों के लिए स्थानीय कतारों और .QA के लिए .QL जैसे क्वालिफ़ायर शामिल हैं (तो बहुत से लोग हैं), तो टोपोलॉजी में कोई भी परिवर्तन उन पंक्तियों का उपयोग करके अनुप्रयोगों को प्रभावित करेगा। इसके बजाय, उनके द्वारा प्रस्तुत कार्यों के लिए कतारों का नाम दें।

जाओ बाएँ-से-सही, सबसे विशिष्ट
वस्तु के नाम, विशेष रूप से कतारों के लिए सबसे सामान्य, पदानुक्रम का निर्माण किया जाना चाहिए सबसे सामान्य क्वालीफायर के साथ शुरुआत और सबसे विशिष्ट क्वालीफायर के लिए आगे बढ़ने। उदाहरण के लिए, कई दुकानें APP.FUNC.SUBFUNC.VER का उपयोग करती हैं जहां APP स्वामित्व वाले एप्लिकेशन की आईडी है, फिर फ़ंक्शन और सबफंक्शन के साथ एक या अधिक नोड्स। कई दुकानें अंत में एक संस्करण क्वालीफायर जोड़ती हैं ताकि सेवा के नए संस्करण मौजूदा कतार में सेवा बदलने और एक ही समय में सभी ग्राहकों को बदलने के बजाय अलग-अलग शेड्यूल पर अपने ग्राहकों को माइग्रेट कर सकें।

बात यह है कि संदेशों को पढ़ता कतार
का मालिक अगर मैं एक सेवा समाप्ति बिंदु एक कतार का प्रतिनिधित्व करती है तो वस्तुओं के बीच एक बहुत-से-एक रिश्ता है कि बात में प्रावधान है कि करने के लिए सेवा कॉल कर सकते है सेवा। कतार सेवा और उस सेवा को प्रदान करने वाली चीज़ से जुड़ी हुई है। ग्राहक कम या ज्यादा गुमनाम हैं। इसलिए, यदि किसी भी हितधारक अनुप्रयोग को कतार में "स्वयं" कहा जा सकता है, तो यह सेवा प्रदाता ऐप है जो संदेश को खपत करता है।

संदेश प्रकाशित करने वाली चीज़ विषय का मालिक है। की तरह।
संबंध विषयों के साथ सीधा नहीं है। यहां यह उन संदेशों के उपभोक्ता हैं जो आम तौर पर अज्ञात होते हैं। उस अर्थ में यदि विषय का नाम किसी भी एप्लिकेशन को प्रतिबिंबित करता है, तो यह प्रकाशक की सबसे अधिक संभावना है। हालांकि, यहां तक ​​कि प्रकाशक भी अज्ञात हो सकते हैं, या कम से कम उनमें से कई हो सकते हैं और सभी एक ही समय में प्रकाशित नहीं हो सकते हैं। विषयों के साथ यह अधिक समझ में आता है कि विषय वृक्ष नोड्स डेटा या कार्यक्षमता के पदानुक्रम के लिए संरचित होते हैं। ये नाम प्रकाशन ऐप्स के नामों से मेल खाते हैं, इसलिए कभी-कभी प्रकाशक इस विषय को "किसी और के रूप में संयोग से बाहर" विषय का मालिक बनता है। पर

रखो स्थितीय क्वालिफायर छोड़ दिया
कहाँ नाम क्वालिफायर के चर संख्या है, छोड़ दिया, जहां स्क्रिप्ट और स्वचालन उन्हें पार्स कर सकते हैं पर स्थितीय लोगों डाल दिया। कुछ दुकानें जहां और समापन क्वालीफायर दोनों APP.FUNC.SUBFUNC1_SUBFUNC2.VER जैसे नाम के परिवर्तनीय अनुभाग में विभाजक के लिए अंडरस्कोर का उपयोग करके इसके साथ स्थितित्मक सौदा कर रहे हैं। लिपियों और प्राधिकरणों को हमेशा नाम में एक निश्चित संख्या में नोड्स देखते हैं लेकिन यदि कोई व्यक्ति भूल जाता है और अतिरिक्त नोड या दो के साथ नाम बनाता है तो यह दृष्टिकोण भंगुर हो सकता है। संदेश स्तंभ:

अतिरिक्त पठन
यह सामान्य नियम के सबसे लेकिन उनके पीछे दर्शन के कुछ मिशन में कब्जा किया गया है का सार।विशेष रूप से:

• Embracing cultural change in the WebSphere MQ community
• Migration, failover, and scaling in a WebSphere MQ cluster
• लेख Planning for SSL on the WebSphere MQ network नाम मानकों प्रतिष्ठित चर्चा के रूप में वे