Эрланг против Реального / Внешнего мира, как общаться?

Question

Я изучаю эрланг, и мне очень нравится Mnesia db. Я хочу построить какое-нибудь реальное приложение на C # / F #, используя erlang в качестве бэкэнда.

Я ищу хорошее решение для связи с узлами erlang из внешнего мира.

Что я нашел до сих пор:

(A) OTP.net , библиотека с открытым исходным кодом .net, реализующая «родной» протокол связи erlang

Проблемы здесь:

• Библиотека не очень зрелая
• Мне не нравится объектная модель, портированная из Java (слишком много почти точных копий классов BCL)
• Мне не нравится использование потоковой модели для соединений.
• Требуется много открытых портов TCP
• Отсутствие безопасности

(B) Используйте порты / сокеты в erlang и реализуйте собственный протокол.

Проблемы здесь:

• У меня нет опыта
• Трудно поддерживать / расширять для будущих версий

Есть ли у вас какие-либо советы, опыт в этой теме?

Должен ли я работать с библиотекой OTP.net, чтобы она соответствовала моим потребностям, или пытаться реализовать новый протокол с нуля?

А как насчет решения JSON или REST? Есть ли какая-нибудь библиотека erlang, которая бы сработала?

Answer 1

Решение для порта / сокета - хорошая идея, и оно не так сложно, как может показаться. Буферы протокола Google это то, что вам нужно. Это очень простой в использовании, эффективный и ремонтопригодный. Он имеет реализации для C #, erlang, java, python и многих других (см. OtherLanguages ​​ и руководство разработчика )

Вы можете использовать буферы протокола для определения структуры протокола запроса и ответа. Затем используйте его для связи между Erlang и любым другим поддерживаемым языком. учебник объяснит все это. После этого все, что вам нужно сделать, это отправить ответ через порт.

Преимущество этого подхода в том, что:

1. Вы можете легко расширять и изменять протокол в будущем
2. Это намного эффективнее, чем REST подход
3. В настоящее время используется Google для почти все его внутренние RPC протоколы и форматы файлов

Answer 2

Если вы хотите реализовать REST API в Erlang, вам нужно сделать только одно. Используйте отличный MochiWeb Kit для создания собственного HTTP-сервера, который реализует ваш протокол.

Не паникуйте, это действительно проще, чем кажется.

Существует множество учебных пособий о том, как это сделать, включая набор скринкастов от Pragmatic Programmers.

Он поставляется с полным набором библиотек json, так что все будет в порядке!

Answer 3

Хотя я согласен с тем, что какое-то решение REST полезно, используете ли вы Yaws или Mochikit, вы обнаружите, что пытаетесь определить некоторый промежуточный «язык» для генерации запросов, которые Mnesia сможет обрабатывать.

Поэтому я предлагаю этот совет; какой бы проект вы ни имели в виду для себя, просто внедрите его в erlang и используйте доступные инструменты. Вы будете вознаграждены разными способами.

Опять же, вы всегда можете попробовать CouchDB.

Answer 4

Существует также библиотека JSON для Erlang, которую вы, возможно, захотите изучить. Я этим не пользовался, поэтому ничего не могу сказать по опыту.

Answer 5

Конечно, вы можете сделать REST с Erlang, см. Например. http://www.infoq.com/articles/vinoski-erlang-rest - если это соответствует потребностям ваших приложений, REST является отличным подходом. (Pycon Italia Tre, на следующей неделе во Флоренции, проведет сессии по сотрудничеству Erlang / Python, см. Www.pycon.it, если вы находитесь около Тосканы; -).

Answer 6

Мы переписали OTP.NET

Эта библиотека во много раз более зрелая, так как была переписана с нуля для .NET / CLR, (в отличие от своего предшественника, который был только что преобразован из Java)

Посмотрите на этот пост:

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

Answer 7

Мы делаем это, используя YAWS и простую реализацию http-запроса / ответа на стороне клиента. Реализация YAWS просто делегирует вызов соответствующему процессу gen_server после извлечения аргументов.

Единственным недостатком этого подхода является то, что он не такой быстрый (буферы протокола Google были бы лучше) - и поддержание соединения «живым» на языке HTTP помогло сократить все затраты на установку и уменьшить количество устаревших сокетов. соединения. Если вы возвращаете большие наборы данных, вам нужно быть немного более креативным с потоковой передачей результатов. Для большинства наших запросов данных это не было проблемой - ответ легко помещался в памяти.

Некоторые плюсы, если сырая производительность протокола не такая уж большая проблема:

• Вы можете подключиться к модели безопасности (HTTPS или аутентификация)
• Вы можете вызывать API из любого, который может сделать веб-запрос (у нас было много старого Perl-кода и листов Excel, разбросанных вокруг - сортировка их была тривиальной)