ओवेन सेल्फ-होस्ट

Question

में सत्र परिवर्तनीय समकक्ष मेरे पास एक ओविन प्रक्रिया में होस्ट किया गया एक नमूना वेब एपीआई है (स्वयं होस्ट किया गया है, आईआईएस में नहीं)। मुझे अपने नियंत्रक में एक जेडब्ल्यूटी टोकन मिलता है और मैं इसे एप्लिकेशन के किसी अन्य हिस्से में पुनः प्राप्त करने में सक्षम होना चाहता हूं, एक वर्ग जो NserviceBus IMutateOutgoingTransportMessages लागू करता है। मेरे अन्य वेब एप्लिकेशन पीओसी (आईआईएस में होस्ट किया गया) में, मैंने एक साधारण सत्र चर का उपयोग किया और यह ठीक काम करता है। लेकिन मैं जानना चाहता हूं कि मेरे नए ओविन स्वयं होस्टेड वातावरण में ऐसा करने का सबसे अच्छा तरीका क्या होगा? स्थिर वर्ग में स्थिर संपत्ति?

Answer 1

यह प्रश्न आपकी विशिष्ट आवश्यकताओं के विस्तृत ज्ञान के बिना वास्तव में व्यापक और उत्तर देने में मुश्किल है।

• आप पहले से ही, प्रत्येक अनुरोध प्रवेश कर रहे हैं शायद ब्राउज़र sessionStorage (या यहां तक ​​localStorage) में टोकन भंडारण, लेकिन यह पर्याप्त नहीं है
• आप बाहर टोकन प्राप्त करने की जरूरत है: यहाँ अपने मुद्दे मेरी व्याख्या है की या नहीं किसी भी अनुरोध चक्र के संबंध में
• आपका आवेदन राज्यविहीन होने की जरूरत नहीं है (यदि नहीं, तो इस शायद यहां आप उत्तर की तलाश में किया जाना चाहिए)

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

थ्रेड सुरक्षा समस्याएं इस तरह के वर्ग के सभी हैंडलिंग और कार्यान्वयन पर लागू होंगी। Immutable Collections का उपयोग करना और एक प्रेरणा के रूप में कार्यात्मक प्रोग्रामिंग प्रथाओं में मदद मिल सकती है।

यदि टिंगरिंग टोकन में कोई समस्या उत्पन्न होती है (और शायद वे एक सुरक्षा परिप्रेक्ष्य से, यदि कुछ और नहीं है), तो आपको यह पता लगाना होगा कि टोकन उनके स्वागत से बाहर नहीं निकलते हैं, भले ही चक्र किसी कारण से हो पूरा नहीं।

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

कैश जैसी कार्यप्रणाली Owin स्वयं के द्वारा होस्ट अनुप्रयोगों के लिए पहले से ही उपलब्ध के कार्यान्वयन कर रहे हैं, और शायद उन में से एक अपने आप को सब कुछ को लागू करने के लिए एक शॉर्टकट रूप में काम करेगा।

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

Answer 2

मुझे एक ऐसे सर्वर पर एक समान दुविधा का सामना करना पड़ रहा है जिसे मैं वर्तमान में एक ग्राहक के लिए विकसित कर रहा हूं। मेरी समस्या यह है कि सर्वर को विरासत, बहुप्रचारित डीएलएल, (एसडीके उर्फ) के साथ कॉल (और लाइव कनेक्शन बनाए रखना) बनाना चाहिए।

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

मैं तो (SDK एकीकरण के लिए आईआईएस + WCF सेवा पर एक पृष्ठ + जाल एपीआई) एक बहु-भाग प्रणाली की कोशिश की।लेकिन यह सभी ऐप के बीच होने वाले 2 तरीके एसिंक संचार के कारण प्रबंधन के लिए एक असली दुःस्वप्न है। फिर: विफलता।

तो मैं एक कंसोल ऐप (अब के लिए) में एक स्वयं की मेजबानी वाली ओविन + वेबएपीआई सेवा पर वापस लौट आया। मेरी समस्या यह है कि कुछ कॉल लंबी हैं और कार्यकर्ता धागे में संसाधित की जाती हैं। मैं हेडर्स के माध्यम से प्रत्येक AJAX कॉल में सिग्नलआर क्लाइंट आईडी पास करने में कामयाब रहा। वेब एपीआई नियंत्रक में जब मैं आईडी निकाल सकता हूं। लेकिन जब कार्य एसिंक हो जाता है, तो मुझे एसिंक कार्य को प्रबंधित करने वाले वर्ग से आईडी (एकता इंजेक्शन सेवा के माध्यम से) प्राप्त करने की आवश्यकता होती है। यह वह जगह है जहां मेरी समस्या आपके के समान है। आईआईएस होस्ट किए गए ऐप्स में, हमारे पास HttpContext है। यह प्रत्येक ग्राहक कॉल पर संदर्भित है, और पाइपलाइन में किसी भी थ्रेड परिवर्तन का पालन करता है ... लेकिन स्वयं होस्टेड ओडब्ल्यूआईएन डब्ल्यूसीएफ ऐप्स में नहीं ...

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

मैं सोच रहा था कि क्या आपको इस दिलचस्प समस्या का समाधान मिला है?

मैं एक और समांतर धागा/SO प्रश्न शुरू करने के बजाय अपने धागे को जोड़ना पसंद करता हूं।