EJB-компоненты построены поверх RMI. Оба подразумевают Java-клиенты и компоненты. Если ваши клиенты должны быть написаны в другом месте (например, .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.
Я бы порекомендовал Весна . Это очень твердо, имеет много тяги, никуда не денется. Он оставляет все ваши варианты открытыми.
Веб-сервисы хороши в теории, но есть некоторые ошибки, на которые нужно обратить внимание:
- Задержка. Первый закон распределенных объектов Фаулера: «Не надо!» Архитектура, состоящая из множества детализированных SOAP-сервисов, будет элегантной, красивой и медленной, как патока. Тщательно подумайте, прежде чем распространять.
- Переход от XML к объектам и обратно потребляет циклы ЦП, которые не обеспечивают никакой коммерческой ценности, кроме того, что позволяют вашим клиентам использовать протокол, не зависящий от платформы.
- SOAP - это стандарт, который с каждым днем становится все более раздутым и сложным, но он имеет много инструментальной поддержки. Производителям это нравится, потому что это помогает стимулировать продажи ESB. ОТДЫХ прост, но не так хорошо понят. Это не поддерживается инструментами.
Модуль веб-службы Spring очень хорош, но будьте осторожны при выборе развертывания таким способом. Пишите в терминах сервисных интерфейсов POJO. Это позволит вам получить концептуальную изоляцию, которую вы хотите, отложить выбор развертывания до последнего момента и позволить вам передумать, если первая мысль не сработает.