На данный момент стоит отметить, что нет необходимости вообще использовать Java EE для его исследований и разработок. Мне не нужны функции безопасности или транзакции, предоставляемые сервером JEE, таким как Glassfish, и я мог бы использовать что-то более легкое, например, Tomcat или Jetty. Тем не менее, мне нравится удобство и возможности JEE, и многие приложения, которые начинают жизнь на стандартном сервере приложений Java, таком как Tomcat, в конечном итоге либо прививают функции JEE в Tomcat (например, JAX-WS), либо переходят на полноценный сервер JEE, такой как Стеклянная рыба.
Пользователям Tomcat часто требуются функции JEE — это было главной причиной запуска проекта TomEE в Apache. Этот проект добавляет функции веб-профиля JEE в стандартный стек Tomcat, чтобы он мог обрабатывать такие вещи, как EJB и JAX-WS.
Разделение бизнес-логики на бобы.
Мое приложение уже имеет 2 отдельных слоя. Первый (с точки зрения потребителя) — это уровень веб-службы, задачей которого является предоставление всех операций веб-службы и других специфических задач службы, таких как обработка пользовательских заголовков SOAP и метаданных сообщений, которые помогают при таких проблемах, как идемпотентность. Последний уровень — это уровень доступа к базе данных, который отвечает за связь с базой данных и за сохранение и извлечение сущностей моего Продукта.
Третий и последний слой, который я сейчас добавляю, — это средний уровень, который связывает два предыдущих — уровень бизнес-логики. Этот уровень будет отвечать за реализацию правил и решений Службы Entity Service, таких как обеспечение наличия, добавления или проверки любой семантически важной информации перед выполнением операции сохранения.
Одним из примеров этой семантически важной информации является «состояние» продуктов. В моей модели я позволяю Продуктам переходить через ряд состояний, чтобы поддерживать строгий жизненный цикл продукта. Этапы следующие и являются примерно линейными по природе (каждое состояние следует за последним)…
- ПРЕДВАРИТЕЛЬНАЯ
- STOCKABLE
- ходкий
- СНЯТО
- СНЯТО
На моем уровне бизнес-логики мой компонент Product Manager гарантирует, что состояние каждой сущности имеет смысл для каждой операции службы. Например, если вы вызываете операцию createProduct () с продуктом, данный продукт должен иметь состояние «Временный». Если этого не произойдет, моя логика изменит это так, что это делает
Подобные правила уникальны для каждого бизнеса, поэтому они не подходят для любого решения. В реальном мире идеальный механизм правил или что-то подобное было бы идеальным, так как это позволило бы обеспечить некоторую дополнительную гибкость в определении и применении этих правил. Тем не менее, для моих основных потребностей в исследованиях и разработках, это жестко запрограммированное решение прекрасно и адекватно демонстрирует причину, по которой хорошо обеспечить уровень бизнес-логики, чтобы вы могли отделить «проблемы» бизнес-логики от логики обработки сообщений и базы данных.
Одна модель данных, чтобы управлять ими всеми.
Есть одна вещь, которая объединяет все эти слои, и это объекты данных (или сущность), которыми они управляют. Сущности продукта представлены XML, описаны XSD и на них ссылается WSDL. Эти определения превращаются в Java-объекты с помощью JAX-WS, и эти же Java-объекты используются во всем коде, что позволяет избежать любого преобразования модели данных .
Этот метод известен как «избегание преобразований» — одно из основных преимуществ этого конкретного стиля технологии разработки сущностей на основе NoSQL.
Преобразование предотвращение — это лучшая практика, которая улучшает возможность повторного использования и компоновки сервиса — soapatterns.org.
По сути, благодаря этой разработке сервиса мне удалось использовать одни и те же объекты данных Java на каждом уровне, но при этом я придерживался подхода, основанного на контракте. Это действительно хорошая новость для разработчиков. Я также избежал необходимости в слоях преобразования модели данных, которые часто становятся необходимыми, когда у вас есть несовместимые модели данных между сообщениями и базами данных (плохие новости для продавцов ESB).
Использование NoSQL также позволило мне полностью избежать SQL DDL для таблиц и отношений данных, и мне не нужны никакие сложные сопоставления объектов, такие как те, которые требуются для обработки традиционного ORM. Я даже могу изменить свою модель данных с течением времени без каких-либо регулярных поломок (отлично подходит для управления версиями).
Замечания по поводу простоты использования JEE.
Чтобы сократить трудности, связанные с развертыванием и настройкой, связанные с JEE, я использовал новые механизмы развертывания и упаковки, которые позволяют размещать EJB-компоненты и веб-приложения в одном файле WAR приложения. Это делает использование JEE легким и значительно упрощает сборку Maven, так как я использую только один проект и дескрипторы нулевого развертывания (даже web.xml отсутствует!).
JEE с EJB 3.1 не может быть проще, поскольку теперь он основан на использовании некоторых очень простых аннотаций Java. Например, указание EJB без состояния может быть таким же простым, как добавление аннотации @Stateless к классу. При этом вы указываете серверу приложений развернуть класс в пуле, чтобы сделать его высокодоступным, и обернуть вызовы его методов в транзакции. Как компонент без сохранения состояния, он не будет иметь понятия сеанса и не будет поддерживать никакого состояния между вызовами (идеально для служб без сохранения состояния ).
|
1
2
|
@Statelesspublic class ProductsManager |
Чтобы использовать этот bean-компонент из другой части вашего приложения (например, из класса @WebService ), вы просто должны добавить ссылочную переменную правильного типа класса и аннотировать эту переменную аннотацией @EJB . Это говорит серверу приложений «внедрить» и экземпляр правильного типа из предварительно заполненного пула компонентов во время выполнения, используя механизм, называемый внедрением зависимостей.
|
1
2
3
4
5
|
@WebService(...)public class ProductsEntityService implements Products { @EJB private ProductsManager bean; ... |
Другие полезные функции JEE.
Бины, управляемые сообщениями, отлично подходят для реализации событийно-ориентированного обмена сообщениями, когда между производителями и потребителями сообщений требуется постоянная и асинхронная связь. Однако я, вероятно, не буду использовать их для этого конкретного исследования и разработки, так как для моих требований сценарий использования слишком слаб, чтобы оправдать усилия (кого бы я уведомил о новых продуктах?). Кроме того, аннотация bean-компонента @MessageDriven сделала эту возможность очень простой в использовании, и это хорошо зарекомендовавшая себя и очень надежная функция, основанная на JMS .
EJB 3.1 также допускает ряд новых и полезных типов bean-компонентов. Синглтон-бины — это синглтон-классы, которые управляются сервером и задаются с помощью аннотации @Singleton (удобно, если такие вещи, как кластерные синглтоны, вызывают у вас беспокойство). А аннотацию @Schedule можно использовать для генерации регулярных событий на основе расписания (например, каждую пятницу в полдень), которое может быть удобно для составления отчетов и т. Д.
Резюме
Итак, у меня теперь есть полностью работающий n-уровневый веб-сервис, который способен сохранять, управлять и извлекать сущности Продукта с использованием базы данных NoSQL. В следующий раз я расскажу о внедрении еще нескольких шаблонов SOA с использованием этих технологий. Подпишитесь на мой блог, чтобы получить уведомление, когда это произойдет.
Продолжите к части 5 .
Ссылка: Внедрение Entity Services с использованием NoSQL. Часть 4. Java EE от нашего партнера по JCG Бена Уилкока из блога SOA, BPM, Agile & Java .