LINUX.ORG.RU

[Common Lisp][интеграция] Аналог JMS для лиспа.

 ,


0

3

Продолжаем тему интеграции систем на Common Lisp. С интеграцией со внешним миром вроде разобрались в прошлой теме: единственным жизнеспособным, стандартным и не костыльным вариантом являются веб-сервисы. Поддержка CORBA слабая.

Теперь рассмотрим задачу интеграции распределённых систем, когда обе системы написаны на Common Lisp, путём отправки асинхронных сообщений. В Java для этого есть такая замечательная штука как JMS. Ключевые возможности JMS такие:

  • publish-subscribe и point-to-point семантика,
  • безопасность как уровня транспорта так и на доступ к topic'ам,
  • гарантия доставки,
  • транзактность,
  • durability.

Есть ли что-то такого же уровня для Common Lisp? Я тут наткнулся на библиотеку ZeroMQ для CL, её я так понимаю написал наш mv, за что ему конечно спасибо... но ZeroMQ - безброкерная система, так что она пролетает по части гарантии, транзактности и durability (сохранения сообщений при отвале клиента и доставка при переподключении).

UPD: По просьбам трудящихся, замечу, что мы ориентируемся на стабильные промышленные ОС (Linux, Solaris) на x86 и RISC железе. Настоятельно прошу не предлагать экспериментальные и маргинальные решения вроде миграции на Plan 9, спаять лисп-машину и т.п.



Последнее исправление: Ignatik (всего исправлений: 1)

Кстати я тут вычитал насчёт CORBA, мнение самих лисперов...

Вкратце, суть такова: из связки CL + CORBA ничего хорошего выйти не может в принципе :) так что archimag был в чём-то прав, Common Lisp не годится для CORBA. Воистину, «made with secret alien technology» :)))

Ignatik
() автор топика

Если есть 9p, то для того, что ты хочешь, достаточно уметь работать с файлами. В КЛ это есть.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

> Если есть 9p, то для того, что ты хочешь, достаточно уметь работать с файлами. В КЛ это есть.

Просветите, что такое «9p», девять рублей? :)

Ignatik
() автор топика

Вот все, что ты пишешь - ты это скажи человеку, который заставляет тебя использовать Common Lisp.

kermzyxer
()
Ответ на: комментарий от kermzyxer

Т.е. проблема обмена асинхронными сообщениями в Common Lisp, решается установкой Plan 9? Самому-то не смешно?

Надо было в самом топике написать, что расчёт делается на стабильные промышленные ОС, а не на экспериментальные... не думал, что это настолько неочевидно

Ignatik
() автор топика
Ответ на: комментарий от kermzyxer

> Вот все, что ты пишешь - ты это скажи человеку, который заставляет тебя использовать Common Lisp.

Вообще-то это моя собственная инициатива :)

Ignatik
() автор топика
Ответ на: комментарий от anonymous

> Тут один местный клоун биндинги к COM писал.

См. UPD: речь идёт о промышленных ОС, так что Windows с его MQ отпадает

Ignatik
() автор топика
Ответ на: комментарий от ugoday

> Некоторым людям прежде чем начать люто, бешенно спорить было бы не плохо пройти в гугль и заняться самообразованием.

Вы тоже смотрите UPD: маргинальные ОС отпадают

Ignatik
() автор топика
Ответ на: комментарий от Ignatik

Ты уже сходил в гугль? Нет? Так хер ли ты тут упды мне пишешь?

ugoday ★★★★★
()
Ответ на: комментарий от Ignatik

На сколько я понял, Common Lisp совершенно не подходит для твоих целей. Советую посмотреть на Clojure. Вот, что пишут на оф.сайте:

Protected Clojure is a dynamic programming language that targets the Java Virtual Machine (and the CLR, and JavaScript). It is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language - it compiles directly to JVM bytecode, yet remains completely dynamic. Every feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection.

Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs.

I hope you find Clojure's combination of facilities elegant, powerful, practical and fun to use.

kermzyxer
()
Ответ на: комментарий от kermzyxer

> Советую посмотреть на Clojure.

Да, Clojure я уже потихоньку интересуюсь

На сколько я понял, Common Lisp совершенно не подходит для твоих целей


Ну я бы предостерёг от преждевременных выводов... а для каких, по-вашему, подходит?

Ignatik
() автор топика
Ответ на: комментарий от anonymous

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

Угодай, ты правда дурачок?

anonymous
()
Ответ на: комментарий от Ignatik

Подоходит для создания двадцати флеймов на лоре.

anonymous
()
Ответ на: комментарий от anonymous

> Угодай, ты правда дурачок?

судя по его предложению использовать X11 для веба, он упорот радикально

anonymous
()
Ответ на: комментарий от anonymous

Нет, я предлагал _не_ использовать веб для Х11. А вы этого не поняли потому что бараны.

ugoday ★★★★★
()
Ответ на: комментарий от mv

> Посмотри de.setf.amqp

Да похоже то что надо, спасибо

Ignatik
() автор топика
Ответ на: комментарий от Ignatik

> Ну я бы предостерёг от преждевременных выводов... а для каких, по-вашему, подходит?
Не знаю =) Точно не для тех, в которых требуются уже готовые комплексные решения с сопровождением.
1) Research.
2) Внутреннее использование.

kermzyxer
()

Видимо, автор вдохновлялся темой «Что круче: Лисп или Хаскелль?» ))

kermzyxer
()

>ZeroMQ для CL, её я так понимаю написал наш mv

И сразу видно что ты не в теме, вернее выучил маркетинговый баззворд JMS.

Начнем с того, что JMS — всего лишь API, более того, без какой-либо гарантии совместимости между реализациями. Так что ответ на твой вопрос очевиден: аналогов JMS для CL нет и не предвидится.

Теперь насчет собственно MQ, которые ты и имел в виду. Есть несколько открытых реализаций протокола AMQP, здесь ситуация обратная: обеспечивается определенная совместимость между реализациями, но API — разное.

ZeroMQ поддердивает некоторые версии спецификации AMQP, и даже сделано компанией-дизайнером AMQP, но данная компания от процесса самоустранилась и спеку AMQP 1.0 поддерживать не собирается, потому что ей нужна простая и шустрая библиотека.

Есть и другие открытые реализации, например RabbitMQ и Apache Qpid. И что-то мне подсказывает что именно его вы и используете через JMS. Есть закрытые реализации. Полноценные MQ со всеми полагающимися свистелками и перделками.

Ессно, биндинги к конкретному вендор-специфичному API вам придется писать самим, скорее всего. А так как спецификация FFI, равно как и вендорское AMQP API не отличаются стандартизованностю, то работенка эта будет непростая.

Macil ★★★★★
()
Ответ на: комментарий от Macil

> И сразу видно что ты не в теме, вернее выучил маркетинговый баззворд JMS.

И сразу видно, что вы батенька хам...

Начнем с того, что JMS — всего лишь API, более того, без какой-либо гарантии совместимости между реализациями.


JMS - это именно API, которое как раз гарантирует совместимость, и все вышеописанные фичи. Вы похоже сами немножко не в теме, почитали бы про JMS предварительно

а за разъяснения относительно AMQP - спасибо, вопрос решён уже

Ignatik
() автор топика
Ответ на: комментарий от Ignatik

>которое как раз гарантирует совместимость

Еще раз говорю: JMS НЕ гарантирует совместимость между РЕАЛИЗАЦИЯМИ JMS. Т.е. если система A использует WebSphere MQ через JMS, а система B использет Qpid через JMS, то взаимодействовать они между собой НЕ смогут.

Кроме того, ты должен понимать что API ничего гарантировать НЕ может: гарантии дает только реализация.

И я надеюсь ты понимаешь, что в крупном проекте переход с одной реализации JMS на другую будет очень сильно болезненным. Совместимы-то они совместимы... Но есть ньюансы.

Так что не нужно здесь петь дифирамбы JMS.

Macil ★★★★★
()
Ответ на: комментарий от Macil

> Еще раз говорю: JMS НЕ гарантирует совместимость между РЕАЛИЗАЦИЯМИ JMS. Т.е. если система A использует WebSphere MQ через JMS, а система B использет Qpid через JMS, то взаимодействовать они между собой НЕ смогут.

А всё, теперь понял. Я сперва думал, что имелось в виду «одна реализация JMS обеспечивает транзактность и durability, а другая нет». Так-то да, протоколы и кодеки у всех разные. Кстати, возможно, существует какой-нибудь JMS-ретранслятор, который решает проблему?

И я надеюсь ты понимаешь, что в крупном проекте переход с одной реализации JMS на другую будет очень сильно болезненным. Совместимы-то они совместимы... Но есть ньюансы.


Понимаю. Хотя и на практике, тьфу-тьфу, не приходилось перепрыгивать с одного брокера на другой. А какие например ньюансы? на будущее

Так что не нужно здесь петь дифирамбы JMS.


А никто и не поёт :)

Ignatik
() автор топика
Ответ на: комментарий от Ignatik

> Плохая идея, ECL сильно ругают, и похоже не зря

Да вобщем зря. У него есть несколко спорных заморочек, которые описаны в доках. Но для встраивания вполне пригоден.

antares0 ★★★★
()

Ну бери RabbitMQ и развлекайся. Хотя я с ним поигравшись с пол-года пришел к выводу, что он кактус.

По-идее, нужно брать транзакционное хранилище и прикручивать к нему ZeroMQ. Но этот мега-план так и не был мной реализован. Можешь попробовать, может что-то выйдет.

dizza ★★★★★
()
Ответ на: комментарий от antares0

Да вобщем зря. У него есть несколко спорных заморочек, которые описаны в доках. Но для встраивания вполне пригоден.

В ECL нету некоторых нужных вещей. Например unicode.

k_andy ★★★
()
Ответ на: комментарий от k_andy

> В ECL нету некоторых нужных вещей. Например unicode

Есть. Другой вопрос что старые версии по умолчанию собирались без него. Последние по моему должны быть сразу с unicode-ом.

antares0 ★★★★
()

>гарантия доставки,
это ж где такое? И чем вебсервисы не подходят в случае двух лисп cистем?

Есть и другие открытые реализации, например RabbitMQ и Apache Qpid. И что-то мне подсказывает что именно его вы и используете через JMS. Есть закрытые реализации. Полноценные MQ со всеми полагающимися свистелками и перделками.

Ессно, биндинги к конкретному вендор-специфичному API вам придется писать самим, скорее всего. А так как спецификация FFI, равно как и вендорское AMQP API не отличаются стандартизованностю, то работенка эта будет непростая.



что за чушь? с любой вендорной JMS системой можно общаться используя исключительно классы из JMS API, вовсе необязательно использовать вендор-специфик классы.

Еще раз говорю: JMS НЕ гарантирует совместимость между РЕАЛИЗАЦИЯМИ JMS. Т.е. если система A использует WebSphere MQ через JMS, а система B использет Qpid через JMS, то взаимодействовать они между собой НЕ смогут.


если два вендора реализуют в своих продуктах JMS, то один и тот же код может успешно общаться с обеими системами.

Кроме того, ты должен понимать что API ничего гарантировать НЕ может: гарантии дает только реализация.

именно API и гарантирует совместимость на уровне API

Т.е. если система A использует WebSphere MQ через JMS, а система B использет Qpid через JMS, то взаимодействовать они между собой НЕ смогут.


У тебя в примере получилось две несвязных системы. Конечно, они работать не будут друг с другом. Но если ты попробуешь систему A натравить на Qpid, подменив при этом только библиотеку, она будет работать! Если корректно написана. Ситуация такая же как с JDBC. Чей бы драйвер ты не подкинул, один и тот же код будет работать с любым JDBC драйвером. (разумеется нормальный код с нормальным драйвером)

вендорское AMQP API не отличаются стандартизованностю


AMQP Client APIs
Java (JMS 1.1 compliant)

где ж оно не отличается? отличается как раз. Этим вообще вся джава отличается - стандартизированностью.

JFreeM ★★★☆
()
Ответ на: комментарий от k_andy
$ ecl --version
ECL 11.1.1

$ ecl
> char-code-limit
256

Грешен видимо спутал с git-срезами, но с --enable-unicode

> (lisp-implementation-type)
"ECL"
> (lisp-implementation-version)
"11.1.1"
> (find :unicode *features*)
:UNICODE
> char-code-limit
1114112

antares0 ★★★★
()
Ответ на: комментарий от antares0

Грешен видимо спутал с git-срезами, но с --enable-unicode

А вот это радует.

k_andy ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.