SOAP-прокси в Scala - что мне нужно?

Question

Я пытаюсь написать в Scala программу, которая будет принимать SOAP-запросы, получать ответ от реального сервера (или читать его с локального диска) и возвращать данные исходному клиенту.

Я новичок в экосистеме java / scala, поэтому понятия не имею, какие библиотеки выбрать. Я слышал, что обработка XML в Scala довольно удобна, поэтому я не знаю, стоит ли мне использовать какую-нибудь корпоративную мыльную библиотеку / инфраструктуру, например jax-ws, jboss-ws, axis, cxf, xmlbeans и т. Д.

В принципе, мне просто нужно

• библиотека, которая принимает запросы (в настоящее время я смотрю на jetty , но я бы предпочла что-то, что изначально поддерживает актеров. scala-http , кажется, покрывает это , но не готовый к производству или в обслуживании, в этом отношении)
• некоторая библиотека для запроса данных с другого сервера (что-то вроде curl, libwww-perl для java / scala)
• система сборки (ant? Sbt?)
• IDE (я привык к затмению, но поддержка IntelliJ в scala должна быть лучше)
• инструмент для его тестирования (в настоящее время я использую SoapUI )

Answer 1

SOAP - действительно отвратительная спецификация с большим потенциалом необычного поведения.Несмотря на то, что поддержка XML в Scala поможет вам написать такую ​​библиотеку с нуля, она все равно потребует значительных усилий (в зависимости от того, сколько спецификации вам нужно).

Аналогично, у Jetty годы разработки.за этим;иметь дело с требованиями к производительности и другим неожиданным поведением, которое вы, вероятно, не рассматривали ... Даже самая известная веб-платформа Scala, Lift, работает по этой причине на веб-сервере Java.Он по-прежнему очень хорошо работает с актерами.

Итак, в данный момент времени , вам почти наверняка лучше использовать проверенное решение с веб-сервером Java иготовая библиотека Java SOAP.Усилия по добавлению тонкой оболочки Scala вокруг них будут намного меньше усилий по созданию этих вещей с нуля.

Для системы сборки sbt - самый мощный инструмент, доступный в настоящее время для Scala, но вам может понадобитьсявернуться к Maven, если это необходимо для генерации кода выбранной вами библиотекой SOAP.

Наконец, для выбора редактора.Если вы довольны использованием Emacs, тогда плагин Ensime просто поражает .Если вам больше нравится обычная среда Java IDE, то IntelliJ в настоящее время представляется наиболее стабильным вариантом, хотя следует помнить, что это может измениться очень быстро.

Answer 2

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

Когда придет время заняться трансляцией протоколов, вы навлечете на себя гнев парсеров XML. К сожалению, насколько мне известно, не существует хорошего, высокопроизводительного синтаксического анализатора, занимающего мало места, который изначально обрабатывает асинхронный ввод-вывод; многие из них, вероятно, существуют, но встроены в коммерческие продукты. См. эту тему для получения дополнительной информации.

Однако вы можете «обмануть» за счет использования дополнительных потоков, используя синтаксический анализатор SAX, который обычно полагается на блокировку ввода-вывода, для использования вывода конвейера «push-me-pull-you». Поскольку части HTTP вашего сервера не блокируют, вы, вероятно, можете позволить себе использовать несколько десятков потоков только для перемещения байтов вокруг.

Как это случилось, я был там и сделал это . :)

Answer 3

Только частичный ответ.

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

• HttpClient для выполнения HTTP-запросов
• Сборка системы, если у вас нет опыта работы с ant Я бы порекомендовал sbt
• В IDE у меня был хороший успех с IntelliJ несколько месяцев назад. Я считаю, что «Затмение» улучшилось, но я не знаю, насколько.
• SoapUI все равно будет работать отлично