Действительно трудно оправдать реинжиниринг того, что «работает» как есть. Вы проводите много работы, возвращаясь к тому, с чего начали.
Это сказал.
Переход от EJB 2.1 Session Beans к EJB 3 довольно тривиален. Для нас, когда мы осуществили переход, большинство наших EJB-компонентов были развернуты отдельно, а не в объединенном EAR. Но у вас нет этой проблемы. Даже с EJB 3 у вас вполне может быть файл (или файлы) ejb-jar.xml.
Но, я думаю, все еще есть выгода, а стоимость очень низкая. Вы можете постепенно делать это, bean за bean против «все сразу», что хорошо, просто перемещая большую часть информации в текущих файлах ejb-jar.xml в аннотации в приложении. Если ничего другого, это обеспечивает видимость (например, требования к транзакциям и т. Д.) В коде, а не «скрывается» в файлах ejb-jar.xml.
Нет причин развертывать «уровень приложения» на отдельном jvm / сервере. Вызывает ли веб-уровень удаленные сеансовые компоненты? против местного? Вы можете видеть или не видеть ускорение при переключении на локальные вызовы (многие «совместно расположенные» развертывания могут быть выполнены аналогично локальному вызову на некоторых серверах, если они настроены правильно, не знаю, если вы уже делаете это).
Наибольший риск переключения на локальный заключается в том, что при удаленном вызове ваши аргументы «защищены» от изменения, поскольку они сериализуются по сети. В локальной семантике, если вы намеренно или нет изменяете значение аргумента (например, изменяете значение свойства в бине), это изменение будет отражено в вызывающей стороне. Это может или не может быть проблемой. Если они уже используют семантику локальных вызовов даже для «удаленного» компонента, они уже столкнулись с этой проблемой.
Что касается JPA против SQL, я бы оставил все как есть. Не стоит переделывать весь уровень данных, чтобы перейти на JPA, и если вы действительно хотите использовать преимущества времени выполнения JPA (по сравнению со временем разработки), особенно кэширования и т. Д., Вам придется преобразовать ПОЛНЫЙ уровень данных (или, по крайней мере, большой). куски взаимосвязанных частей) все сразу. Действительно рискованно и подвержено ошибкам.
В случае проблемы с "дублирующимися банками" это артефакт упаковки и сборки, а не развертывания. Чтобы устранить проблему неоднозначности, вам нужно поработать в своей среде разработки, чтобы использовать общий репозиторий JAR, и помнить о том, что если вы обновите JAR для одного, вы обновите его для всех. Люди осуждают, что это необоснованное требование, заставляя обновлять все приложение в случае изменения фляги. Для огромных, разрозненных приложений, конечно. Но для приложений в одной JVM нет, это не так. Как бы нам ни хотелось, чтобы каждый маленький кусочек был изолированным миром в изобильном супе, который мы называем средой загрузчика классов Java, это просто неправда. И чем больше мы можем упростить это, тем лучше для нас с точки зрения сложности и обслуживания. Для обычных jar-файлов вы МОЖЕТЕ рассмотреть возможность объединения этих jar-файлов на сервер приложений и вне приложения. Мне не нравится этот подход, но он имеет применение, если вы можете заставить его работать на вас. Это, безусловно, уменьшает размер развертывания.
Клиентская сторона, это не так сложно преобразовать из Struts 1 в Struts 2, так как они оба очень похожи на высоком уровне (в частности, они обе являются фреймворками действий). Ключевым моментом здесь является то, что обе структуры могут жить бок о бок друг с другом, что позволяет, опять же, постепенные изменения. Вы можете медленно перенести старый код поверх, или вы можете только реализовать новый код в новой среде. Это отличается от попытки смешать и сопоставить структуру действий и структуру компонентов. Это буквально ситуация "собаки и кошки, живущие вместе". Если бы я пошел по этому пути, я бы просто развернул компоненты компонентов в их собственных WAR и пошел дальше. Управление состоянием компонентов каркасов делает взаимодействие с ними на стороне сервера действительно проблематичным. Если вы решили реализовать через новую WAR, убедитесь, что вы потратили немного времени на выполнение какого-то «единого входа», чтобы люди «вошли» в каждый модуль соответствующим образом. Пока приложения не имеют общего состояния сеанса, это действительно необходимо для интеграции. И после того, как вы решили добавить новую подсистему через новую WAR, вы можете использовать любую технологию, какую захотите, на стороне клиента.
Кэширование - это другая проблема. Разные кэши решают разные проблемы. Одно дело кэшировать и запоминать некоторые маленькие кусочки в системе (например, рендеринг JSP) или использовать распределенный кеш для передачи сеансов между экземплярами во время восстановления после сбоя или балансировки нагрузки. Другое дело иметь доменный слой на основе кеша, где постоянство и кеширование очень и очень тесно связаны. Это гораздо сложнее. Просто держать все это прямо в голове - это больно.
В первом случае вы можете в значительной степени распределять приложение по мере необходимости, и такие типы кэшей могут быть в значительной степени автономными, а не частью скоординированной всеобъемлющей инфраструктуры кэширования.
Последний, другой. Там вам нужно в значительной степени переделать всю модель данных, даже для частей, которые вы вообще не кэшируете, так как вы хотите обеспечить постоянный доступ к данным и их представлениям кэша.
Это фактически то, что делает JPA с двумя уровнями кэширования, и поэтому, как я упоминал ранее, это не то, что вы можете случайно добавить в приложение, за исключением, в основном, автономных блоков вашей системы. Когда у вас есть разные модули, использующие одни и те же внутренние ресурсы, согласованность и согласованность кэша становится реальной проблемой, и поэтому вы хотите, чтобы они были интегрированы в обе системы.
Ум, это можно сделать. Хитрость заключается в простой интеграции уровня доступа к данным, и вы можете начать кэширование на этом уровне. Но если у вас есть люди, которые делают прямые вызовы SQL, они должны идти.
Наконец, я думаю, что используемый термин - это эволюция, а не революция. Переход на EJB 3 или 3.1 Я не думаю, что это должно быть болезненно, так как это в значительной степени Just Works with EJB 2.1, что является благом. Вы МОЖЕТЕ иметь "смешанную" среду. Самая болезненная интеграция была бы, если бы вы использовали бины Entity, но вы этого не сделали, так что это хорошо. И для всех скептиков EJB эта обратная совместимость, которая распространяется на почти 10 лет EJB, - это то, что позволяет вам на самом деле сохранить большую часть кода, но все еще двигаться вперед.