2009-04-30 13 views
13

मैं एरलांग सीख रहा हूं और मैं मैनेशिया डीबी से बहुत प्रभावित हूं। मैं बैकएंड के रूप में एरलांग का उपयोग कर सी #/एफ # में कुछ असली दुनिया एप्लिकेशन बनाना चाहता हूं।एरलांग बनाम असली/बाहरी दुनिया, संवाद कैसे करें?

मैं बाहरी दुनिया से एरलांग नोड्स के साथ संवाद करने के लिए एक अच्छा समाधान खोज रहा हूं।

क्या मैं अब तक पाया:

(ए) OTP.net, एक खुला स्रोत .net 'देसी' erlang कम्युनिकेशन प्रोटोकॉल को लागू करने के लिए यहाँ

समस्याएं पुस्तकालय:

  • पुस्तकालय है बहुत परिपक्व नहीं
  • मुझे जावा से पोर्ट ऑब्जेक्ट मॉडल पसंद नहीं है (बीसीएल कक्षाओं की बहुत अधिक सटीक प्रतिकृतियां)
  • मुझे कनेक्शन के लिए थ्रेडिंग मॉडल उपयोग पसंद नहीं है।
  • कई खुले TCP पोर्ट की आवश्यकता होती है सुरक्षा के
  • अभाव

(बी) erlang में बंदरगाहों/सॉकेट का उपयोग करें और एक कस्टम प्रोटोकॉल लागू। यहाँ

समस्याएं:

  • मैं किसी भी अनुभव
  • हार्ड बनाए रखने/भविष्य के संस्करणों

के लिए विस्तार करने के लिए की जरूरत नहीं है आप इस विषय में किसी भी सलाह, अनुभव है?

क्या मुझे अपनी जरूरतों को पूरा करने के लिए ओटीपीनेट लाइब्रेरी पर काम करना चाहिए या स्क्रैच से एक नया प्रोटोकॉल लागू करने का प्रयास करना चाहिए?

JSON या REST समाधान के बारे में क्या? क्या कोई एरलांग लाइब्रेरी है जो चाल करेगी?

उत्तर

16

पोर्ट/सॉकेट समाधान एक अच्छा विचार है और ऐसा लगता है कि यह मुश्किल नहीं है। Google's protocol buffers सिर्फ वही है जो आपको चाहिए। उपयोग, कुशल और रखरखाव करने के लिए यह बहुत आसान है। यह सी #, erlang, जावा, अजगर और कई और अधिक के लिए कार्यान्वयन (OtherLanguages और developer guide देखें)

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

इस दृष्टिकोण का लाभ यह है कि:

  1. आप आसानी से विस्तार करने और भविष्य
  2. में प्रोटोकॉल को बदल सकते हैं यह बहुत बाकी दृष्टिकोण
  3. यह वर्तमान में प्रयोग किया जाता है की तुलना में अधिक कुशल है के लिए Google द्वारा लगभग सभी आंतरिक आरपीसी प्रोटोकॉल और फ़ाइल स्वरूप
+3

ईमानदारी से सब कुछ ठीक से decouple करने के लिए, आप RabbitMQ का उपयोग कर मिश्रण में कुछ AMQP फेंक देना चाहिए। फिर आप किसी विशिष्ट भाषा में किसी भी चीज़ पर भरोसा नहीं करते हैं। –

+0

यदि यह किसी के लिए सहायक है: http://code.google.com/p/protoc-gen-erl/ – Unoti

2

निश्चित रूप से, आप एरलांग के साथ आरईएसटी कर सकते हैं, उदाहरण के लिए देखें। http://www.infoq.com/articles/vinoski-erlang-rest - यदि आपके ऐप्स की ज़रूरतों के लिए उपयुक्त है, तो आरईएसटी एक उत्कृष्ट दृष्टिकोण है। (फ्लोरेंस में अगले सप्ताह, पिकॉन इटालिया ट्रे, में एरलांग/पायथन सहयोग पर सत्र हैं, यदि आप टस्कनी के पास हैं तो www.pycon.it देखें ;-)।

+0

Pycon जानकारी के लिए धन्यवाद! –

2

एरलांग के लिए JSON library भी है, जिसे आप देखना चाहते हैं। मैंने इसका इस्तेमाल नहीं किया है, इसलिए मैं अनुभव से इसके बारे में कुछ भी नहीं कह सकता।

+0

मैंने उस लाइब्रेरी का उपयोग एक जेसन आरपीसी सर्वर के सर्वर हिस्से को लिखने के लिए किया है, जो पीछे की ओर बैठा है। यह बहुत अच्छा काम किया। मैंने इसे सी # क्लाइंट से संवाद करने के लिए और जावास्क्रिप्ट के माध्यम से एक अजाक्सी वेबसाइट बनाने के लिए इस्तेमाल किया। मैंने सिर्फ कच्चे जेसन एन्कोड/डीकोड कार्यक्षमता का उपयोग किया क्योंकि jsonrpc भागों तब उपलब्ध नहीं थे। –

4

यदि आप एरलांग में एक आरईएसटी एपीआई लागू करना चाहते हैं तो केवल एक चीज है। अपने प्रोटोकॉल को लागू करने वाला अपना HTTP सर्वर बनाने के लिए उत्कृष्ट MochiWeb Kit का उपयोग करें।

घबराओ मत, यह वास्तव में दिखाई देने से आसान है।

व्यावहारिक प्रोग्रामर से screencast set सहित इसे करने के तरीके के बारे में कई ट्यूटोरियल हैं।

यह जेसन पुस्तकालयों के एक पूर्ण सेट के साथ आता है, तो आप ठीक हो जाएंगे!

2

जबकि मैं मानता हूं कि कुछ आरईएसटी समाधान उपयोगी है, चाहे आप यास या मोचिकिट का उपयोग करें, आप खुद को कुछ मध्यवर्ती "भाषा" परिभाषित करने की कोशिश करेंगे ताकि मैनेशिया प्रक्रिया करने में सक्षम हो सके।

इसलिए मैं यह सलाह देता हूं; जो भी प्रोजेक्ट आपके लिए दिमाग में है, बस इसे एर्लांग में कार्यान्वित करें और उपलब्ध टूल्स का उपयोग करें। आपको कई तरीकों से पुरस्कृत किया जाएगा।

फिर फिर आप हमेशा कॉच डीबी को आजमा सकते हैं।

0

हम वाईएडब्ल्यूएस का उपयोग करके और क्लाइंट साइड पर एक साधारण http अनुरोध/प्रतिक्रिया कार्यान्वयन करते हैं। YAWS कार्यान्वयन केवल तर्कों को निकालने के बाद उपयुक्त gen_server प्रक्रिया में कॉल को प्रतिनिधि करता है।

इस दृष्टिकोण के साथ एकमात्र नकारात्मक पक्ष यह है कि यह तेज़ नहीं है (Google प्रोटोकॉल बफर बेहतर होगा) - और HTTP अनुक्रम में कनेक्शन "जीवित" रखने से सभी सेटअप लागत को कम करने में मदद मिली और बालों की संख्या कम हो गई सॉकेट कनेक्शन। यदि आप डेटा के बड़े सेट लौट रहे हैं तो आपको परिणामों को स्ट्रीम करने के साथ थोड़ा अधिक रचनात्मक होना होगा। हमारे अधिकांश डेटा अनुरोधों के लिए जो कोई मुद्दा नहीं था - प्रतिक्रिया आसानी से स्मृति में फिट हो सकती है।

कुछ तेजी यदि प्रोटोकॉल के कच्चे प्रदर्शन है कि एक मुद्दे के ज्यादा नहीं है:

  • तुम एक सुरक्षा मॉडल (HTTPS या प्रमाणीकरण)
  • तुम कुछ भी से कर सकते हैं कि एपीआई कॉल कर सकते हैं में हुक कर सकते हैं एक वेब अनुरोध करना (हम पुराने पर्ल कोड और चारों ओर लटक एक्सेल शीट की बहुत सारी था - उन्हें बाहर तुच्छ छँटाई था)
0

हम के बाद से फिर से लिखा है OTP.NET

यह लाइब्रेरी कई गुना अधिक परिपक्व है, क्योंकि इसे स्क्रैच से फिर से लिखा गया है।नेट/CLR, (अपने पूर्ववर्ती के विपरीत है कि बस जावा से परिवर्तित कर दिया गया)

इस पोस्ट पर एक नज़र डालें:

http://blog.aumcode.com/2013/10/nfx-native-interoperability-of-net-with.html

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