2012-10-08 9 views
6

हम एक जावा-केंद्रित टूल का उपयोग करते हैं जो आंतरिक रूप से जेएमएस का उपयोग करता है और बाहरी जावा सॉफ़्टवेयर के साथ संवाद करता है। अब हमें सी # एप्लिकेशन में एक नया इंटरफेस स्थापित करना है। हमारा जेएमएस प्रदाता एक सी # कार्यान्वयन प्रदान करता है जो काम करना चाहिए लेकिन मुझे पूरा यकीन नहीं है कि जेएमएस इस मामले में जाने का तरीका है। यह कार्यान्वयन और ग्राहक के समर्थन के विवरण के लिए दोनों सी # आवेदन में एक नई विक्रेता-विशिष्ट निर्भरता पेश करेगा।क्रॉस भाषा संदेश

कुछ googling मुझे STOMP के लिए नेतृत्व किया जो कई जेएमएस-सक्षम संदेश दलालों (hornetq, activemq, ...) द्वारा समर्थित एक स्थापित वायर-स्तरीय प्रोटोकॉल प्रतीत होता है लेकिन सी # में वास्तविक ग्राहकों की एक अलग कमी दिखाई देती है। (और कुछ हद तक जावा)। बहुत गहरी खुदाई के बिना मुझे पूरी तरह से यकीन नहीं है कि "पाठ" पर जोर कब खेलता है? क्या यह बाइनरी ऑब्जेक्ट्स का समर्थन नहीं करता है?

एक और समाधान AMQP हो सकता है जो एक और वायर-स्तरीय प्रोटोकॉल है लेकिन 1.0 spec अभी तक जारी नहीं किया गया है और हम 4-वर्षीय 0.9.1 spec को लागू करने से थके हुए हैं क्योंकि ऐसा लगता है कि 1.0 में बहुत कुछ बदल गया है।

सुरक्षा, समर्थन, लेनदेन, मानकों की शिकायत, पोर्टेबिलिटी, पर विचार करते हुए अंतर-भाषा असीमित संदेश के लिए कौन सा समाधान सबसे अच्छा होगा ... ध्यान दें कि उचित WS- * के साथ साबुन इस विशेष इंटरफ़ेस के लिए एक विकल्प नहीं है।

EDIT1: मैं ऐसे Cross-platform, cross-language messaging system? के रूप में सवाल को देखा है लेकिन वे कहते हैं कि कई भाषाओं में काम करता है एक विशिष्ट उपकरण पर ध्यान केंद्रित करने लगते हैं। मैं वास्तव में एक मानक अनुपालन प्रोटोकॉल की तलाश में हूं जो एकाधिक विक्रेताओं द्वारा लागू किया जा सकता है या इसे लागू किया जा सकता है।

+0

इससे कोई फर्क नहीं पड़ता कि आप कुछ विक्रेता या संदेश मंच विशिष्ट कार्यक्षमता पेश करने जा रहे हैं। आप इसके बजाय ईमेल का उपयोग कर सकते हैं क्योंकि यह क्रॉस प्लेटफार्म है लेकिन यह एसएमटीपी विशिष्ट है। –

+0

प्रोटोकॉल-विशिष्ट एक समस्या नहीं है जब तक कि प्रोटोकॉल एक अच्छी तरह से स्थापित मानक है। यदि एसएमटीपी केवल एक विशिष्ट विक्रेता से उपलब्ध था या विक्रेता से विक्रेता से भिन्न था, तो यह एक समस्या होगी – nablex

+0

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

उत्तर

1

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

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

+0

हमारे पास हमारी सॉफ़्टवेयर टीम में कोई सी # ज्ञान नहीं है, इसलिए हमें अपने स्वयं के एडेप्टर का समर्थन करने के लिए कठोर किया जाएगा। वास्तविक संदेश बैकएंड को सारणना हमेशा समाधान का हिस्सा होगा हालांकि अबास्ट्रक्शन को सी # एप्लिकेशन टीम द्वारा प्रबंधित किया जाना होगा। – nablex

+0

यही कारण है कि मैं सामान्य एडाप्टर के एक सेट की अनुशंसा करता हूं, आपको यकीन है कि सी # में कोई समस्या नहीं है। हम एक समान समाधान बनाए रखते हैं, केवल अंतर यह है कि हम एमएसएमक्यू को संदेश उपप्रणाली के रूप में उपयोग करते हैं और खोल सी # में लिखा जाता है। और आम एडाप्टर का विचार बहुत अच्छा काम करता है, PHP और जावा लोगों को संबंधपरक डेटाबेस को लिखने और डब्लूएसडीएल विनिर्देशों के आधार पर अपनी वेब सेवाएं प्रदान करने में कोई समस्या नहीं है। यही कारण है कि मेरा मानना ​​है कि समान दृष्टिकोण आपके लिए काम करेगा। –

+0

हां लेकिन किसी को सी # -जावा पुल को बनाए रखना है जिसका अर्थ है कि हमें या तो एमएसएमक्यू पढ़ना होगा, उन्हें एक जेएमएस को लिखना होगा या हमें एक और प्रोटोकॉल मिलना चाहिए जो चाल (वेब ​​सर्विसेज और निश्चित रूप से डेटाबेस/फाइल सिस्टम नहीं) करता है। – nablex

1

मुझे नहीं पता कि मैं आपके प्रश्न को सही तरीके से समझ गया हूं लेकिन RabbitMQ एक एएमक्यूपी कार्यान्वयन है और सी # और जावा के लिए बाइंडिंग है।

"सी # एप्लिकेशन में एक नया विक्रेता-विशिष्ट निर्भरता" को रोकने के लिए, आप Messaging Component in the Spring.Net framework के साथ-साथ related AMQP for .Net प्रोजेक्ट को देखना चाहेंगे। यह आपको मैसेजिंग मिडलवेयर और आधारभूत संरचना से अलग पीओसीओ और व्यावसायिक तर्क को अलग करने की अनुमति देता है।

+0

क्योंकि AMQP 1.0 को अभी तक अंतिम रूप दिया नहीं गया है, मुझे यकीन नहीं है कि यह इस समय का सबसे अच्छा विकल्प है या नहीं? – nablex

+0

स्प्रिंग.Net के लिंक किए गए संदेश घटक में अन्य एमक्यू भी शामिल हैं (उदा। टीआईबीसीओ ईएमएस, अपाचे एक्टिव एमक्यू/एनएमएस)। – tobsen

+0

यह मूल प्रश्न के दायरे से बाहर हो सकता है लेकिन यह जावा में है क्योंकि .NET में निर्भरता उतनी बड़ी निर्भरता है? क्या आप बस मैसेजिंग घटक का उपयोग कर सकते हैं जैसे कि आप पूरे जावा ईई स्टैक के बिना जेएमएस एपीआई करेंगे? अस्वीकरण: मेरे पास सी # और न ही वसंत में कोई पृष्ठभूमि नहीं है। – nablex

संबंधित मुद्दे