JavaEE действительно переносим? - PullRequest
3 голосов
/ 25 апреля 2010

Я просто выполняю задание JavaEE, которое мне дали на собеседовании.

У меня есть некоторый предыдущий опыт работы с EJB, но ничего не связано с JMS и MDB. Итак, вот что я нахожу на многочисленных примерах:

  • серверы приложений связывают свои темы и очереди с различными именами JNDI - например, topic / queue, jms
  • свойство activationConfig требуется в JBoss, а в руководстве по Sun - нет.
  • после запуска моего приложения jboss предупреждает меня, что моя тема не связана (на самом деле это не так - я не связывал ее, но я ожидаю, что она будет связана автоматически - фактически, в примере для JBoss 4.0 автоматическое связывание, кажется, происходит). Предлагаемое решение - отобразить его в некоторых файлах jboss или даже использовать аннотации, специфичные для jboss.

Это может быть просто JBoss, но, поскольку он сертифицирован для реализации в спецификации, похоже, что в спецификации эти вещи не указаны. И там вся предполагаемая переносимость исчезает.

Так что мне интересно - почему получается, что JavaEE является переносимым, и вы можете взять его на себя и развернуть на другом сервере приложений, и он волшебным образом работает, если такие чрезвычайно простые вещи вообще не кажутся переносимыми.

P.S. извините за напыщенную речь, но я предполагаю, что я могу что-то делать / делать что-то не так, поэтому выскажите свое мнение.

Ответы [ 4 ]

8 голосов
/ 25 апреля 2010

Java EE, как (почти?) Любой стандарт, является тем, что разработчики стремятся рекламировать приверженность, но отчаянно не хотят придерживаться.

Задумайтесь над этим вопросом: как Red Hat зарабатывает деньги? Отдавая вещи или продавая их? Если написанный вами код может быть легко перенесен на другой сервер приложений Java EE, это помешает им зарабатывать на вас деньги. Решением этой проблемы является почтенный метод «охвата и расширения», который был приписан Microsoft, но на самом деле был инструментом выбора для поставщиков коммерческого программного обеспечения с момента публикации первого стандарта.

Если вы придерживаетесь строго API Java EE в вашем коде, то JBoss (или Geronimo (или JonAS (или ...))) запустит его так же, как и любой другой совместимый сервер приложений с В дескрипторах развертывания для конкретного сервера требуются только изменения. Это этап объятий.

Каждый сервер - в частности, коммерческий (например, JBoss)! - также имеет тенденцию добавлять дополнительные вещи в API, чтобы «сделать вещи проще». (Чтобы быть справедливым, это часто делает вещи проще.) Разработчики - особенно те, кто не очень хорошо знаком со стандартными API - часто попадают в ловушку, полагаясь на эти дополнительные API, не оборачивая их каким-либо образом, что позволяет этим расширениям затопить их код настолько, что их трудно удалить, если вы захотите сменить платформу. Это этап продления.

Назовите стандарт из любой точки истории программного обеспечения, и вы увидите, что люди обнимаются и расширяются (до такой степени, что, когда люди говорят о "смертельном объятии", я вынужден насильно отвести свои мысли от проблем блокировки поставщика до правильная терминология). Вы также обнаружите, что конечные пользователи (разработчик или кто-то еще) влюбляются в это. Java EE ничем не отличается от любой другой технологии в этом отношении.

Затем вы учитываете, насколько плохо сформулированы большинство спецификаций, и ...

2 голосов
/ 27 апреля 2010

Джоэл говорит, что " все нетривиальные абстракции в некоторой степени протекают ". Я обнаружил, что это очень применимо к JavaEE. Учтите, что исключение JMS может быть чем-то временным, например, полной очередью. Это типичная проблема быстрого производителя / медленного потребителя, и в идеале производитель должен снизить скорость, чтобы соответствовать скорости потребителя. Но ошибка также может быть фатальной, например, ошибка авторизации. В первом случае повторные попытки в конечном итоге оказываются успешными (обычно), тогда как во втором случае никакие повторные попытки не помогут, пока люди не вмешаются, чтобы исправить ошибку авторизации.

Так что вы делаете в своей переносимой программе для решения этой проблемы? Один из подходов - рассматривать каждое исключение JMS как фатальное. Закройте все ваши объекты и переинициализируйте программу. Вроде как убийство мухи кувалдой, но очень портативно. Кроме того, вы можете проверить исключение JMS, чтобы увидеть, является ли это временной или фатальной ошибкой, и предпринять соответствующие действия. Это гораздо более эффективно, но, поскольку исключения JMS зависят от поставщика, его трудно переносить. Некоторые из моих клиентов использовали подход, заключающийся в написании специфических для поставщика графических оболочек, которые перехватывают исключения JMS и выполняют с ними соответствующие ему задачи, чтобы код мог быть «переносимым» (подумайте: программный эквивалент уровня аппаратной абстракции).

И, конечно, это просто обработка исключений. Подобные проблемы существуют по всем направлениям. Рассмотрим детали переподключения. Некоторые транспорты накапливают сбой соединения с приложением или контейнером. Некоторые скрывают это от мысли, что код не должен знать об этом. Но реальность такова, что практически все приложения для обмена сообщениями должны будут предоставлять предупреждение или запись в журнал, если сеть постоянно отключена. Вы бы не хотели, чтобы приложение зависало навсегда, если произошел сбой в сети, верно? Так что, в конечном счете, даже приложению, работающему на транспорте, которое обеспечивает прозрачное переподключение, необходимо кодировать при сбое соединения. Специфические особенности и поведение транспортного провайдера будут вытекать через абстракцию JMS.

За мои деньги JavaEE делает навыки переносимыми для всех транспортных провайдеров. Приложение должно быть достаточно осведомлено о базовом транспортном провайдере, чтобы иметь дело с абстракциями, которые всплывают на поверхность. Если вы можете избежать утечек, приложение переносимо, но не более того.

1 голос
/ 25 апреля 2010

Это лишь частичный ответ, но Java EE 6, точнее EJB 3.1, наконец, указывает Переносимые глобальные имена JNDI . До Java EE 6 наименование JNDI не было стандартизировано, и каждый поставщик сервера приложений использовал свои собственные правила , что действительно было плохо для переносимости (своего рода блокировка вендора). Следовательно, в мире J2EE 1.4, если вы хотите облегчить переносимость вашего корпоративного приложения, необходимо было реализовать различные стратегии, обычно в вашем классе ServiceLocator. Внедрение внедрения зависимостей в Java EE 5 уменьшило потребность в поисках и каким-то образом «улучшило» переносимость, но, тем не менее, не является стандартом для случаев, когда требуются JNDI-поиски и полиглот ServiceLocator.

0 голосов
/ 25 апреля 2010

Базовое приложение EE может работать без изменений. Внешняя конфигурация зависит от сервера приложений.

...