Веб-сервисы vs EJB vs RMI, преимущества и недостатки?

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

в чем преимущество EJB над RMI, или наоборот?

Как насчет веб-сервисов (SOAP, REST)?

3 54
javascript terminology amazon-web-services distributed-transactions ejb

3 ответа:

компоненты EJB построены на РМИ. Оба подразумевают Java-клиентов и бобов. Если ваши клиенты должны быть написаны в чем-то другом (например, .NET, PHP и т. д.) идите с веб-службами или чем-то еще, что говорит о платформе-агностическом проводном протоколе, например HTTP или XML через HTTP или SOAP.

Если вы выберете RMI, вам не нужен сервер приложений Java EE EJB. Вы должны поддерживать синхронизацию клиентских и серверных JVM; вы не можете обновить клиент без обновления сервера. Вы должны написать все услуги что сервер приложений EJB предоставляет для вас (например, пул соединений, службы именования и каталогов, пул, очередь запросов, транзакции и т. д.).

RMI довольно низкий уровень, когда вы думаете об этом. Зачем тебе возвращаться в Корбу?

лучший выбор-это EJB 3.0 в сравнении с весной. Это зависит от того, нравится ли вам разработка POJO, хотите ли вы выбрать реляционные технологии помимо ORM и JPA, среди прочего.

вы можете заплатить за приложение Java EE сервер (например, сервер WebLogic, WebSphere и) или использовать с открытым исходным кодом, одна (с JBoss, GlassFish и, в большинстве случаев, и в частности, ActiveMQ), или вы можете придерживаться весной и развернуть на Tomcat, причал, смолы или любого другого сервлетов/JSP двигателя.

Spring предлагает большой выбор, будучи агностиком технологий: персистентность (Hibernate, iBatis, JDBC, JDO, JPA, TopLink), удаленное взаимодействие (HTTP, Hessian, Burlap, RMI, SOAP web service) и т. д.

EJB 3.0-это спецификация со многими поставщиками; весна может быть только с весны Источник.

Я бы порекомендовал Весна. Он очень прочный, имеет много тяги, никуда не денется. Он оставляет все ваши варианты открытыми.

веб-сервисы хороши в теории, но есть некоторые gotchas, которые вам нужно следить за:

  1. задержки. Первый закон распределенных объектов Фаулера :"не надо!"Архитектура, состоящая из множества мелкозернистых распределенных мыльных сервисов, будет элегантной, красивой и медленной, как патока. Подумайте хорошенько, прежде чем распространять.
  2. маршаллинг от XML к объектам и обратно потребляет циклы ЦП, которые не обеспечивают никакой бизнес-ценности, кроме того, что позволяют вашим клиентам говорить о платформенно-агностическом протоколе.
  3. SOAP-это стандарт, который с каждым днем становится все более раздутым и сложным, но у него есть много поддержки инструментов. Продавцы любят его, потому что он помогает управлять продажами ESBs. Отдых прост, но не так хорошо понятен. Это не поддерживается инструменты.

модуль веб-службы Spring очень хорош, но будьте осторожны при выборе этого способа развертывания. Пишу с точки зрения интерфейсов сервиса POJO-объект. Это позволит вам получить концептуальную изоляцию, которую вы хотите, отложить выбор развертывания до последнего момента и позволить вам изменить свое мнение, если первая мысль не работает хорошо.

115

между EJB и RMI, EJB, безусловно, будет лучше - у него есть все, что имеет RMI и многое другое через контейнер (объединение объектов, управление транзакциями и т. д.)

между EJB и веб-службами веб-службы дадут вам больше переносимости, если вы хотите иметь возможность вызывать их из приложений, отличных от java, в будущем. EJB снова дает вам такие вещи, как управление транзакциями и объединение пулов, которые вы не можете получить "из коробки" с веб-службами.

лично, если бы я был делая это, я бы, вероятно, использовал EJB или какую-то подобную структуру удаленных объектов (spring remoting также приходит на ум). Если вам нужна возможность вызывать объекты из приложения, отличного от java, вы всегда можете использовать простые прокси-серверы веб-служб по мере необходимости.

10

Re: web services (SOAP, REST) Если ваши внутренние серверы не будут выставлены публично, то вы не получаете никакой выгоды от использования независимых от платформы интерфейсов веб-служб, таких как SOAP/REST.
На самом деле вы будете нести штраф со всеми накладными расходами, добавленными тегами XML, обертывающими данные через удаленный вызов, не говоря уже о том, что вы будете получать от маршалинга и разнесения XML на объекты java.
Хотя любой распределенный вызов будет требуется некоторый уровень сериализации-даже RMI / EJB, но цена больше при сериализации в удобочитаемый XML.

возможно, вам вообще не нужно кодировать удаленные вызовы на java, вы можете использовать свой сервис с простым экземпляром apache httpd, который настроен для балансировки нагрузки на нескольких серверах java с помощью mod_jk или mod_proxy.
Эти модули могут использоваться для балансировки нагрузки через сервлет контейнеров, таких как Tomcat/Jetty или EJB-контейнеров например, jboss / glassfish.

4