Мы могли бы сосредоточить EJB на единственной задаче — одном лишь переводе денег, но, как было сказано ранее, EJB по свое природе "крупнее" одиночной операции. Это легко определить, попробовав ответить на вопрос, имеет ли смысл покупать или продавать компонент EJB для использования в другом подобном приложении на Java. Ясно, что сам по себе перевод денег не может быть таким отдельным компонентом, но если представить сеансовый компонент, который будет осуществлять всю логику обработки запроса клиента банковской системы, такой объем функциональных возможностей целесообразно предлагать как единое целое. Итак, мы уже определили, что перевод денег, по крайней мере в данном случае, будет одной из нескольких обязанностей сеансового компонента, обслуживающего сеанс банковской системы.
Решение, надо ли поддерживать состояния в компоненте, не всегда просто. Можно вывести следующее эмпирическое правило: если сеансовый компонент сеанса должен помнить в течение всей транзакции значительное число элементов, которые уже не хранятся в базе данных, такой компонент должен иметь диалоговое состояние и поэтому поддержка состояний требуется.
В этом конкретном случае запрос на перевод денег содержит лишь немного элементов данных, а именно переводимую сумму и два номера счетов. Можно было бы предположить, что все данные счетов также должны храниться в сеансовом компоненте, чтобы не приходилось каждый раз собирать эту информацию заново. Но на практике это не бывает необходимо или даже желательно, так как эти данные легко получить через объекты-сущности. Если держать в сеансовом компоненте слишком много данных, есть опасность их устаревания, или же приходится решать проблемы синхронизации данных.
Поэтому в данном случае мы будем использовать сеансовый компонент без состояний.
Следующий вопрос — должны ли транзакции управляться компонентом или контейнером. Вообще следует применять управление от контейнера, если только используемый сервер приложений не мешает выполнить какие-то нужные действия или если не требуется какая-то дополнительная обработка транзакций. В данном сценарии мы не делаем ничего необычного и поэтому будем использовать транзакции, управляемые контейнером.
Также следует иметь в виду, что каждое обращение к EJB потенциально является удаленным вызовом через сеть, который требует гораздо больше затрат, чем обычный вызов функции. Чтобы достичь наилучшей производительности, желательно свести к минимуму количество вызовов, требуемых для обслуживания каждого клиентского запроса. В сценарии перевода денег нерационально разбивать операцию перевода на несколько взаимодействий с сеансовым компонентом. Лучше всего, чтобы все действия выполнялись в одном вызове.
На основе рассмотренных выше ситуаций и вариантов построена исправленная диаграмма последовательностей прецедента "Перевод денег", показанная на рис. 12.19.
Резюме
Спецификация EJB является важной частью платформы J2EE и определяет обширную модель компонентов для построения компонентов масштабируемого распределенного серверного приложения уровня предприятия на Java.
В языке UML компоненты EJB потенциально могут быть представлены различными способами. В данной книге принято моделирование EJB в виде подсистемы, так как подсистема объединяет в себе лучшие черты класса и пакета. В последней версии спецификации EJB поддерживается три типа компонентов EJB.
Сеансовые компоненты — наиболее часто применяемый в настоящее время тип EJB. Важными концепциями сеансовых компонентов являются диалоговое состояние и пассивация экземпляра. Существует две разновидности сеансовых компонентов: с поддержкой состояний и не имеющие состояний. Они имеют несколько ключевых различий в структуре и поведении. Сеансовые компоненты также поддерживают транзакции, которые могут быть управляемыми компонентом или управляемыми контейнером.
Разработка EJB вообще и сеансовых компонентов в частности имеет различные особенности. Моделирование в UML помогает определить проблемы и выявить потенциальные решения.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.