Как лучше всего добавить веб-интерфейс в приложение OSGi? - PullRequest
Новая
       42

Как лучше всего добавить веб-интерфейс в приложение OSGi?

1 голос
/ 29 августа 2011

Итак, у меня есть набор OSGi-пакетов (.jars), которые выполняют "бизнес-логику". Все хорошо, и до сих пор я взаимодействовал с пакетами, используя оболочку командной строки gogo.

Я хотел бы добавить веб-интерфейс.

Мои первые мысли заключаются в том, чтобы объединить интерфейс в один и тот же контейнер / экземпляр OSGi. Я думал, что сделаю легкий встроенный пакет Jetty, который в свою очередь загружает .war. Теоретически сервлеты могут напрямую общаться с другими сервисами OSGi.

В реальном мире будет несколько экземпляров приложения, которые общаются друг с другом. Я не уверен, что лучше иметь 1 веб-интерфейс, который подключается к каждому, или 1 веб-интерфейс локально для каждого бизнес-приложения.

Нет никаких ограничений или предпочтений для технологии, только чтобы она была с открытым исходным кодом.

Мой вопрос:

  • Это отстой?
  • Есть ли лучший способ сделать это?
  • Должен ли я разделить .war и бизнес-логику на два отдельных процесса?

Ответы [ 3 ]

0 голосов
/ 30 августа 2011

Самый простой способ - зарегистрировать ваши сервлеты в OSGi HttpService, предоставляемом, например, Apache Felix HTTP Service .Я думаю, что вариант Felix встраивает Jetty, но вам не нужно беспокоиться, на уровне OSGi вы просто видите стандартный HttpService.

В сочетании с серверной библиотекой, которая генерирует JSON (я используюпакет Apache Sling commons.json ) и библиотека на стороне клиента, такая как jQuery, у вас есть мощный, но простой набор инструментов, в котором ваши сервлеты могут выступать в качестве внешних интерфейсов для ваших служб OSGi.

0 голосов
/ 30 августа 2011

Похоже, ваш веб-интерфейс - это интерфейс управления, а не пользовательский интерфейс?

Если это так, взгляните на веб-консоль Felix , вы можете легко расширить ее , написав плагин

Кроме того, сама консоль поддерживает скины, так что если это просто внутреннее приложение, то это, вероятно, будет проще всего реализовать. Есть несколько плагинов для управления / просмотра

Я бы не стал встраивать Jetty, поскольку Бетранд заявляет, что есть реализация службы HTTP, но также PAX Web , которая позволит напрямую развертывать войны.

RE: «Должен ли я разделить .war и бизнес-логику на два отдельных процесса?» Я бы не стал распространять приложение ради этого, если только (не требуется высокая доступность или балансировка нагрузки), но вам определенно следует разделить приложение на тощую войну (только пользовательский интерфейс) и отдельные сервисные пакеты.

Должно ли веб-приложение управлять всеми экземплярами или по одному на экземпляр, зависит от множества других вещей;

  • Возможно ли, что одновременно будут развернуты разные версии? (Если это так, то веб-приложение для каждого экземпляра вызовет меньше головной боли)
  • Это клиент? (отдельные экземпляры легче защитить)
  • Вам нужна сводная информация? (одно веб-приложение)

Не уверен, как вы планируете заставить приложения взаимодействовать, но Apache CXF может реализовать спецификацию удаленных сервисов через веб-сервисы, а Eclipse Communication Framework предоставляет гораздо больше транспортных протоколов.

0 голосов
/ 29 августа 2011

Взгляните на Веб-сервер Virgo , ранее Spring DM Server. В него встроен полноценный контейнер сервлетов, он полностью OSGi, а также встроенный Spring DM, если вы хотите пойти по этому пути. Я не думаю, что есть какая-либо причина разделять веб и бизнес-процессы на отдельные процессы. Независимо от того, иметь ли одно веб-приложение или одно на бизнес-пакет, это скорее вопрос дизайна: «Единый пользовательский интерфейс, который объединяет многие основные проблемы, или это все отдельные задачи?»

...