Erlang vs The Real/Вне мира, как общаться?

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

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

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