Веб-сервисы по сравнению с EJB по сравнению с RMI, преимуществами и недостатками?
Мой веб-сервер был бы перегружен быстро, если бы вся работа была сделана там. Я собираюсь встать второй сервер позади него, обработать данные.
Каково преимущество EJB по RMI, или наоборот?
Что относительно веб-сервисов (SOAP, ОТДЫХ)?
3 ответа
EJB строятся поверх RMI. Оба подразумевают Java-клиентов и bean-компонентов. Если ваши клиенты должны быть написаны на чем-то другом (например, .NET, PHP и т. Д.), Используйте веб-службы или что-то еще, что говорит о независимом от платформы проводном протоколе, например HTTP или XML через HTTP или SOAP.
Если вы выберете RMI, вам не понадобится сервер приложений Java EE EJB. Вы должны поддерживать синхронизацию клиентских и серверных JVM; вы не можете обновить клиент, не обновив сервер. Вы должны написать все службы, которые предоставляет вам сервер приложений EJB (например, пулы соединений, службы имен и каталогов, пулы, очереди запросов, транзакции и т. Д.).
RMI - это довольно низкий уровень, если задуматься. Зачем возвращаться к CORBA?
Лучше EJB 3.0, чем Spring. Это зависит от того, нравится ли вам разработка POJO, помимо прочего, вам нужен выбор реляционных технологий, помимо ORM и JPA.
Вы можете заплатить за сервер приложений Java EE (например, WebLogic, WebSphere) или использовать сервер с открытым исходным кодом (JBOSS, Glassfish, OpenEJB и ActiveMQ), или вы можете придерживаться Spring и развернуть его на Tomcat, Jetty, Resin или любой другой движок сервлетов / JSP.
Spring предлагает широкий выбор, поскольку он не зависит от технологий: постоянство (Hibernate, iBatis, JDBC, JDO, JPA, TopLink), удаленное взаимодействие (HTTP, Hessian, Burlap, RMI, веб-служба SOAP) и т. Д.
EJB 3.0 - это спецификация многих поставщиков; Spring можно получить только из Spring Source.
Я бы порекомендовал Spring . Он очень прочный, имеет отличную тягу, никуда не денется. Это оставляет все ваши возможности открытыми.
Веб-сервисы хороши в теории, но есть некоторые подводные камни, на которые следует обратить внимание:
- Задержка. Первый закон Фаулера о распределенных объектах: «Не делайте этого!» Архитектура, состоящая из множества мелкозернистых распределенных сервисов SOAP, будет элегантной, красивой и медленной, как патока. Тщательно подумайте, прежде чем раздавать.
- Маршалинг от XML к объектам и обратно потребляет циклы ЦП, которые не приносят никакой пользы для бизнеса, кроме того, что позволяют вашим клиентам использовать протокол, не зависящий от платформы.
- SOAP - это стандарт, который с каждым днем становится все более раздуваемым и сложным, но он имеет множество инструментов для поддержки. Поставщикам это нравится, потому что это помогает стимулировать продажи ESB. REST прост, но не так хорошо понятен. Это не поддерживается инструментами.
Модуль веб-службы Spring очень хорош, но будьте осторожны, выбирая вариант развертывания таким образом. Пишите в терминах сервисных интерфейсов POJO. Это позволит вам получить желаемую концептуальную изоляцию, отложить выбор развертывания до последнего момента и позволит вам передумать, если первая мысль не сработает.
Между EJB и RMI, EJB, безусловно, будет лучше - в нем есть все, что есть у RMI и многое другое через контейнер (пул объектов, управление транзакциями и т.д.)
Между EJB и веб-сервисами, веб-сервисы дадут вам больше переносимости, если вы хотите иметь возможность вызывать их из не Java приложений в будущем. EJB опять же дает вам такие вещи, как управление транзакциями и объединение в пул, которые вы можете не получить "из коробки" с веб-сервисами.
Лично я бы, наверное, использовал EJB или какой-нибудь аналогичный фреймворк для удаленных объектов (на ум приходит также весеннее удаленное подключение). Если вам нужна возможность вызывать объекты из не Java-приложений, вы всегда можете установить на EJB простые прокси-сервисы по мере необходимости.
Re: веб-службы (SOAP, REST)
Если ваши внутренние серверы не будут публично открыты, тогда вы не получаете никакой выгоды от использования независимых от платформы интерфейсов веб-служб, таких как SOAP / REST.
На самом деле вы понесете штраф за все накладные расходы, добавленные тегами XML, обертывающими данные в удаленном вызове, не говоря уже о ударе, который вы получите от маршалинга и демаршалинга XML. к java-объектам.
Хотя любой распределенный вызов потребует некоторого уровня сериализации - даже RMI / EJB, но цена выше при сериализации в читаемый человеком XML.
Возможно, вам вообще не понадобится кодировать удаленные вызовы на java, вы можете запустить свою службу с помощью простого экземпляра apache httpd, который настроен на балансировку нагрузки между несколькими серверами Java с использованием mod_jk или mod_proxy .
Эти модули могут использоваться для балансировки нагрузки между контейнерами сервлетов, такими как tomcat / jetty, или контейнерами ejb, такими как jboss / glassfish.