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

Question

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

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

Что я нашел на данный момент:

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Существует ряд руководств о том, как это сделать, включая набор скринкастов от программистов-прагматиков.

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

Answer 3

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

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

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

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

Answer 7

С тех пор мы переписали OTP.NET.

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

Взгляните на этот пост:

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