Интеграция серверного Java-приложения с сервером приложений, например TomCat, GlassFish и т. - PullRequest
0 голосов
/ 21 июня 2011

Я работаю над серверным приложением, которое выполняет следующие действия:

  1. Считывание данных с измерительного устройства, к которому обращаются через последовательный интерфейс (javax.comm, RXTX) или сокеты.
  2. Обмен данными (чтение и запись) с другим серверным приложением с использованием сокетов.
  3. Вставка данных из (1) и (2) в базу данных с использованием JDBC.
  4. Предложение данных изшаги (1) - (3) к веб-приложению на основе JavaScript.

Мой текущий прототип является автономным приложением Java и реализует задачу (4), записывая данные в файл XML, который доставляется клиенту через веб-сервер (Apache), но ясчитают это взломом, а не чистым решением.

Это серверное приложение должно запускаться и работать также без присутствия веб-клиентов.

Я хотел бы интегрировать это серверное приложение в сервер приложений Java, но у меня нет большого опытас этими технологиями и не знаю с чего начать.Я попробовал несколько простых примеров для TomCat и GlassFish, но это не принесло мне дальнейшего развития, поскольку все они построены вокруг синхронного обслуживания веб-запросов и остановились там, где мне было бы интересно.

  • Можно ли запустить такое приложение в TomCat или GlassFish?

  • Если да, то с чего бы начать (примерыкакие базовые классы ...)?

  • Имеет ли смысл разделять приложение и реализовывать только задачу (4) в сервлете, остальное в обычном приложении, связьчерез сокеты и т. д .?

  • Будут ли другие серверы, например, JBoss, лучшим выбором и если да, то почему?

Редактировать:Причины, по которым я хочу использовать контейнер Java EE:

  • Я хотел бы иметь чистый внешний интерфейс для шага (4).

  • В долгосрочной перспективе приложение должно масштабироваться до огромного количества одновременно работающих клиентов (не менее нескольких 10.000), поэтому требуется стандартный способ масштабирования и управления приложениями.

Ответы [ 2 ]

1 голос
/ 21 июня 2011

В общем случае не стоит реализовывать все это в контейнере сервлетов, таком как Tomcat.

Контейнер сервлета предназначен для обслуживания запросов от клиента. Похоже, у вас есть процесс, который будет выполняться постоянно или хотя бы периодически. Вы можете сделать это в Tomcat, но, вероятно, проще сделать это снаружи. Оставьте Tomcat, чтобы делать то, что он хорош, обслуживая запросы от браузеров. Счастливее всего, если запросы недолговечны.

Так что я бы поступил так, как вы предлагаете, и сделал только шаг 4 в контейнере. Вы можете легко опросить базу данных, заполненную на шаге 3, поэтому нет необходимости создавать веб-службы для заполнения контейнера сервлета.

На шаге 4 вам нужно будет предоставить некоторые сервисы от Tomcat, будь то отдых, мыло, что угодно. Клиенты javascript могут затем опросить эти службы. Это все полностью выполнимо с Tomcat.

Для масштабируемости не должно быть проблем с использованием Tomcat. Если все, что он делает, это перекачивает данные из базы данных в клиент, вероятно, нет причин выбирать контейнер J2EE. Если вам не нужно сложное управление транзакциями или безопасность, попробуйте использовать что-нибудь с открытым исходным кодом. Похоже, вы можете получить то, что вы хотите от Tomcat (и спящий режим и весеннюю безопасность, если это необходимо). Если у вас начнутся проблемы с производительностью, исправление, вероятно, будет таким же для JBoss & Tomcat: вам нужно больше серверов.

Мой совет: придерживайтесь простых решений с открытым исходным кодом и переходите на сервер приложений, только если вы сочтете это необходимым.

1 голос
/ 21 июня 2011

Я бы свободно связывал решение и не пытался делать все в контейнере Java EE / Servlet, поскольку обмен данными с использованием сокетов (управляемых самим приложением) обычно не требуется для контейнера Java EE / Servlet.

Выполнение этого в контейнере Java EE также может быть излишним, поскольку это не похоже на типичное корпоративное приложение, где важны такие вещи, как безопасность и управление транзакциями, и приложение может извлечь выгоду из сервисов, предоставляемых контейнером Java EE / Servlet.

...