Я надеюсь, что Combinator parsers, (http://debasishg.blogspot.com/2008/04/external-dsls-made-easy-with-scala.html), будет работать для проекта для обработки правил маршрутизации для службы REST, реализованной с помощью Scalatra, (http://tutorialbin.com/tutorials/80408/infoq-scalatra-a-sinatra-like-web-framework-for-scala).
)
Эта служба REST должна выступать в качестве прокси-сервера, чтобы внешние приложения могли получать доступ к службам в брандмауэре, поскольку она будет иметь дополнительные уровни безопасности, которые можно настраивать в соответствии с бизнес-требованиями каждой службы REST.
Так что, если человек хочет получить доступ к своему расписанию занятий, безопасность будет ниже, чем если бы вы захотели взглянуть на стенограмму кого-либо.
Я хотел бы, чтобы в DSL были указаны правила, куда обращаться за получением информации и как ее вернуть, а также какие меры безопасности необходимы.
Но первая проблема заключается в том, как динамически изменять правила маршрутизации для службы REST на основе DSL, поскольку я пытаюсь создать среду, не требующую значительной перекомпиляции для добавления новых правил, а просто напишите соответствующие сценарии и просто дайте им обработаться.
Итак, можно ли реализовать DSL с использованием Combinator Parser в Scala, который позволит JAX-RS (http://download.oracle.com/javaee/6/tutorial/doc/giepu.html) динамически изменять маршрутизацию?
UPDATE:
Я еще не разработал язык, но вот что я пытаюсь сделать:
route /transcript using action GET to
http://inside.com/transcript/{firstparam}/2011/{secondparam}
return json encrypt with public key from /mnt/publickey.txt
for /education_cost using action GET combine http://combine.com/SOAP/costeducate with
http://combine.com/education_benefit/2010 with
http://combine.com/education_benefit/2011 return html
Это две возможные идеи, когда правила запроса транскрипта отправляются на другой сайт, например, в межсетевой экран, а данные шифруются и возвращаются.
Второй вариант будет более сложным в том смысле, что результаты SOAP и двух запросов REST будут объединены, и для их объединения потребуются дополнительные команды, но идея состоит в том, чтобы поместить все это в файлы, которые можно анализировать на лету.
Если бы я использовал Groovy, то для маршрутизации можно было бы сгенерировать несколько новых классов, которые бы убрали некоторые потери производительности, но я думаю, что использование Scala будет лучшим выбором, даже если я получу удар по производительности.
Я надеюсь создать среду, которая будет более удобной в обслуживании, чтобы новые правила маршрутизации могли писать люди, которые не знают ООП или функциональных языков, но спецификации могут быть написаны с использованием Specs (* 1035). * чтобы функциональная сторона могла быть уверена, что их требования регулярно проверяются.
ОБНОВЛЕНИЕ 2:
Когда я начинаю работать над дизайном, я могу интуитивно понять некоторые варианты, но не знаю почему. Сегодня я понял, что причина того, что Groovy может быть лучше для этого, состоит в том, что я мог бы затем генерировать классы для маршрутизации, используя метапрограммирование (http://www.justinspradlin.com/programming/groovy-metaprogramming-adding-behavior-dynamically/),, тогда я мог бы использовать Scala или Groovy для динамического использования сгенерированная маршрутизация. Я не уверен, как заставить Scala генерировать классы, если они еще не существуют.
В Groovy, а также в некоторых других языках, как показано здесь (http://langexplr.blogspot.com/2008/02/handling-call-to-missing-method-in.html), если метод отсутствует, вы можете динамически сгенерировать метод, и он отныне будет существовать, поэтому он будет отсутствовать один раз.
Почти кажется, что я должен смешивать Groovy с Java, чтобы сделать эту работу, но тогда может получиться так, что часть кода на Scala, а другая на Java, для маршрутизации служб REST.