मेरे पास सी # में लिखी एक मौजूदा लाइब्रेरी है जो बहुत कम स्तर के टीसीपी/आईपी एपीआई को लपेटती है और एक सर्वर (मालिकाना बाइनरी प्रोटोकॉल) से वायर के आने वाले संदेशों को .NET ईवेंट के रूप में प्रकट करती है। मैं किसी ऑब्जेक्ट पर विधि कॉल भी प्रदान करता हूं जो सुविधाजनक .NET प्रकारों (जैसे System.DateTime) को बाइनरी एन्कोडिंग और निश्चित-लंबाई संरचनाओं के लिए मार्शलिंग की जटिलताओं को नियंत्रित करता है जो API को (सर्वर पर आउटगोइंग संदेशों के लिए) की आवश्यकता होती है। इस .NET लाइब्रेरी के शीर्ष पर बनाए गए मौजूदा अनुप्रयोगों (आंतरिक रूप से और तृतीय पक्षों द्वारा उपयोग किए जाने वाले दोनों) की एक उचित संख्या है।सी # से जावा तक पोर्टिंग करने से बेहतर विकल्प?
हाल ही में, हम किसी ऐसे व्यक्ति से संपर्क कर चुके हैं जो टीसीपी/आईपी खुद को सारणीबद्ध करने के सभी स्तरों को नहीं करना चाहता, लेकिन उनका पर्यावरण सख्ती से गैर-विंडोज़ है (मुझे लगता है * निक्स, लेकिन मैं नहीं हूं 100% निश्चित), और उन्होंने सूचित किया है कि उनका आदर्श जावा से कुछ कॉल करने योग्य होगा।
सबसे अच्छा तरीका है उनकी आवश्यकताओं को समर्थन करने के लिए, मेरे लिए बिना क्या है: (एक अप्रबंधित DLL कि हम वर्तमान में पी/में विसंपीड़न के लिए आह्वान सहित)
- पोर्ट जावा के लिए कोड आगे जाकर दो अलग-अलग कोड-ठिकानों को बनाए रखने (यानी बनाने ही बग फिक्स और दो बार सुविधा वृद्धि)
एक बात मैं करने पर विचार किया जा सकता है एक बार कोर टीसीपी/आईपी कार्यक्षमता के सबसे दोबारा लिखने के कुछ और में क्रॉस-प्लेटफ़ॉर्म (सी/सी ++) और n इस के शीर्ष पर एक पतली परत होने के लिए मेरी .NET लाइब्रेरी को बदलें (पी/Invoke?), और फिर इसके ऊपर एक समान पतली जावा परत भी लिखें (जेएनआई?)।
सकारात्मक:
- मैं ज्यादातर अपने समय लेखन बातें केवल एक बार खर्च करते हैं।
विपक्ष:
- कोड से अधिकांश अब अप्रबंधित होगा - दुनिया के अंत नहीं है, लेकिन (मेरे लिए) को देखने के एक बिंदु से उत्पादकता आदर्श नहीं।
- लंबे समय तक विकास समय (कर सकते हैं C/C++ के रूप में जल्दी के रूप में सिर्फ जावा के लिए पोर्टिंग नहीं बंदरगाह सी # सॉकेट कोड)
- इस बिंदु पर, अंतर्निहित एपीआई ज्यादातर लपेटा जाता है [कैसे सच है? है] और पुस्तकालय है बहुत स्थिर है, इसलिए शायद बहुत सारे नए विकास नहीं हैं - यह संभवतः जावा पर वर्तमान कोड को बंद करने के लिए बुरा नहीं हो सकता है और फिर कभी-कभी भविष्य में दो बार नए बग-फिक्स या नए फ़ील्ड का पर्दाफाश करना पड़ता है।
- मेरे मौजूदा क्लाइंट अनुप्रयोगों के लिए संभावित अस्थिरता, जबकि संस्करण वे उनके नीचे भारी परिवर्तनों पर चल रहे हैं। (मेरे सिर के ऊपर से मैं 32/64 बिट मुद्दों, अंतहीनता के मुद्दों, और बंदरगाह के दौरान फसल की सामान्य बग आदि के बारे में सोच सकता हूं)
एक और विकल्प जिसे मैंने संक्षेप में माना है वह किसी तरह से rigging है जावा पर मोनो, ताकि मैं पहले से मौजूद सभी मौजूदा सी # कोड का लाभ उठा सकूं। हालांकि, जावा डेवलपर्स के लिए डेवलपर अनुभव कितना आसान होगा, हालांकि मुझे इसका उपभोग नहीं करना पड़ेगा। मुझे पूरा यकीन है कि अधिकांश कोड मोनो के तहत बिना किसी परेशानी के चलते चलना चाहिए (डिकंप्रेशन पी/इनवॉक बार जिसे शायद सी # पर पोर्ट किया जाना चाहिए)।
मैं आदर्श रूप से अपने कोड और क्लाइंट जावा ऐप के बीच टीसीपी/आईपी, पाइप इत्यादि की एक और परत जोड़ना नहीं चाहता हूं अगर मैं इसकी मदद कर सकता हूं (इसलिए जावा-साइड डब्ल्यूएस-डेथस्टार के लिए डब्ल्यूसीएफ संभवतः बाहर है) ।मैंने कभी जावा के साथ कोई गंभीर विकास नहीं किया है, लेकिन मुझे इस तथ्य में कुछ गर्व है कि पुस्तकालय वर्तमान में अपने आवेदन में एकीकृत करने के लिए किसी तीसरे पक्ष के डेवलपर के लिए केक का टुकड़ा है (जब तक वह चल रहा है .NET पाठ्यक्रम:)), और मैं किसी भी जावा डेवलपर्स के लिए समान उपयोग का उपयोग करने में सक्षम होना चाहता हूं जो समान अनुभव चाहते हैं।
तो यदि किसी के पास प्रस्तावित 3 विकल्पों पर राय है (जावा & पोर्ट को दो बार बनाए रखें, सी को पोर्ट करें और .NET और जावा के लिए पतली भाषा बाइंडिंग लिखें या जावा और मोनो को एकीकृत करें, या कोई भी अन्य सुझाव मुझे उन्हें सुनना अच्छा लगेगा।
धन्यवाद
संपादित करें: ग्राहक (टूटी टेलीफोन उर्फ बिक्री विभाग के अर्थात हटाने) पर डेवलपर के साथ सीधे बात कर रहा करने के बाद आवश्यकताओं काफी बदल गया है कि इस सवाल का अब कोई मेरी तत्काल स्थिति के लिए बहुत अच्छी तरह से लागू होता है। हालांकि, मैं उम्मीदों में खुले सवाल को छोड़ दूंगा कि हम कुछ और अच्छे सुझाव उत्पन्न कर सकते हैं।
मेरे विशेष मामले में, क्लाइंट वास्तव में सोलारिस के अतिरिक्त विंडोज मशीन चलाता है (जो इन दिनों नहीं है?) और पुस्तकालय के शीर्ष पर एक एप्लिकेशन (विंडोज सेवा) लिखने और बहुत कुछ प्रदान करने के लिए खुश है उनके लिए कोड करने के लिए अधिक सरल और छोटे टीसीपी/आईपी एपीआई। हम उनके सरल संदेशों को उस प्रारूप में अनुवादित करेंगे जो डाउनस्ट्रीम सिस्टम समझता है, और इनकमिंग प्रतिक्रियाओं का उपयोग उनके लिए वापस करने के लिए करता है, ताकि वे अपने जावा एप्लिकेशन के माध्यम से इस डाउनस्ट्रीम सिस्टम के साथ इंटरफ़ेस जारी रख सकें।
कुछ हफ़्ते के लिए इस बारे में सोच के बाद वापस मूल परिदृश्य के लिए हो रही है, मैं कुछ और टिप्पणियों की क्या ज़रूरत है:
शीर्ष पर अलग भाषा बाइंडिंग के साथ एक पोर्टेबल सी-आधारित पुस्तकालय शायद होगा अगर आप आगे जानते थे कि जाने के लिए आपको कई भाषाओं/प्लेटफार्मों का समर्थन करना होगा।
* निक्स पर, क्या एक प्रक्रिया एक जावा रनटाइम और एक मोनो रनटाइम दोनों को होस्ट कर सकती है? मैं .NET के पुराने संस्करणों में जानता हूं, आपके पास एक ही प्रक्रिया में दो अलग-अलग .NET रनटाइम नहीं हो सकते हैं, लेकिन मेरा मानना है कि उन्होंने इसे .NET 4 के साथ ठीक कर दिया है? यदि यह संभव है, तो दोनों के बीच एक संवाद कैसे होगा? आदर्श रूप से आप एक स्थिर विधि कॉल और प्रतिक्रियाओं को बढ़ाने के लिए एक प्रतिनिधि के रूप में सरल कुछ चाहते हैं।
अगर वहाँ जावा & मोनो के बीच कोई आसान प्रत्यक्ष इंटरफ़ेस का समर्थन (तरीकों & प्रतिनिधियों, आदि) है, एक संदेश स्वरूप के रूप में प्रोटोकॉल बफ़र या अपाचे बचत के साथ ZeroMQ की तरह कुछ प्रयोग करने पर विचार हो सकता है। यह अलग-अलग परिवहन के लिए ज़ीरोएमक्यू के समर्थन के कारण नेटवर्क में प्रक्रिया, इंटर-प्रोसेस और नेटवर्क पर काम करेगा।
मैंने आपके उत्तर को सही के रूप में चिह्नित किया है, क्योंकि मेरी आवश्यकताओं को बदलना समाप्त हो गया है। हालांकि, मैं इससे बहुत संतुष्ट नहीं हूं - अभी भी परिदृश्य हो सकते हैं जहां व्यापक आवश्यकता विश्लेषण के बाद इस तरह के इंटरऑप की आवश्यकता होती है, इसलिए मुझे उम्मीद है कि एक बेहतर उत्तर स्वयं उपस्थित होगा। –
संक्षिप्त उत्तर: नहीं, मुझे नहीं लगता कि सी # से जावा तक पोर्टिंग करने से बेहतर विकल्प हैं :) लेकिन यह उचित समाधान नहीं हो सकता है कि क्लाइंट को कोड की आवश्यकता है, वह कितना भुगतान करने के इच्छुक है, आदि । –