Является ли JavaEE действительно портативным?

Question

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

У меня есть опыт работы с EJB, но ничего не связано с JMS и MDB. Так вот что я нашел через многочисленные примеры:

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

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

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

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

Answer 1

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

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

Если вы придерживаетесь строго к EE API, Java в коде, то JBoss (или Джеронимо (или Jónás (или ...))) будет работать его, а также любой другой совместимый сервер приложений с единственным изменением является необходимых для дескрипторов развертывания сервера. Это этап охвата.

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

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

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

Answer 2

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

Answer 3

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

Answer 4

Джоэл говорит «all non-trivial abstractions are, to some degree, leaky». Я нашел, что это очень применимо к JavaEE. Считайте, что исключение JMS может быть чем-то временным, таким как полная очередь. Это типичная проблема с быстрым производителем/медленным потребителем, и в идеале производитель будет дросселировать, чтобы соответствовать скорости потребителя. Но ошибка также может быть фатальной, например, сбой авторизации. В первом случае повторные попытки в конечном итоге преуспевают (обычно), тогда как во втором случае никакая повторная попытка не поможет, пока люди не вмешаются, чтобы исправить отказ авторизации.

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

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

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