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

Ответ 1

EJB построены поверх RMI. Оба подразумевают Java-клиенты и beans. Если ваши клиенты должны быть написаны во что-то еще (например,.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, Смола или любой другой сервлет/двигатель JSP.

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

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

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

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

• Задержка. Фаулер первый закон распределенных объектов: "Не надо!" Архитектура, состоящая из множества мелкозернистых распределенных SOAP-сервисов, будет элегантной, красивой и медленной, как меласса. Подумайте внимательно, прежде чем распространять.
• Маршаллинг из XML в объекты и обратно потребляет циклы ЦП, которые не обеспечивают каких-либо бизнес-преимуществ, кроме того, что позволяет вашим клиентам говорить протокол-агностик.
• SOAP - это стандарт, который становится все более раздутым и сложным с каждым днем, но в нем много поддержки инструмента. Продавцам это нравится, потому что это помогает стимулировать продажи ESB. REST прост, но не так хорошо понят. Он не поддерживается инструментами.

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

Ответ 2

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

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

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

Ответ 3

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

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