Моя текущая реализация Product Entity Service очень независима от бизнес-процессов и поэтому может быть многократно использована в любом сценарии, когда потребители хотят находить или хранить информацию о продукте. Однако в существующем виде Служба Entity Service предназначена для использования в доверенной среде. Это означает, что нет ограничений на доступ к таким операциям, как «Создать», «Обновить» или «Удалить». Это хорошо в строго контролируемой корпоративной изолированной программной среде, но что, если я захочу поделиться некоторыми своими операциями по обслуживанию или информацией о продукте с недоверенными пользователями?
Давайте представим, что в дополнение к нашему внутреннему использованию Сервиса Entity Service мы также хотели удовлетворить следующую гибкую «пользовательскую историю»…
Так что: Моя опубликованная информация о продукте является точной и постоянно доступна для сторонних клиентов.
Как: директор по продажам и менеджер по ИТ.
Мы хотим: Предложить доступную только для чтения копию информации о моем продукте сторонним пользователям и системам.
Этот сценарий не является редкостью в бизнесе, и я реализовывал подобные истории пользователей в прошлом с некоторыми из моих клиентов . Но что удивительно в технологиях, которые мы используем для реализации нашей службы Entity (Java / JAX-WS и CouchDB NoSQL), так это то, что они делают разработку этого сценария очень простой.
Прежде всего, архитектурный дизайн.
Для реализации этой пользовательской истории я собираюсь обратиться к еще двум шаблонам разработки SOA для архитектуры сервисов — репликация данных о сервисах и параллельные контракты. Во втором посте мы уже говорили о подходе «сначала контракт», поэтому я не буду вдаваться в подробности, кроме как скажу, что он все еще применяется здесь. Контракт все еще является стандартизированным и отделенным контрактом .
Репликация данных службы — это шаблон, который помогает вам достичь высокого уровня автономности и доступности службы путем создания целых копий данных, необходимых службе в других частях инфраструктуры. Затем эту копию можно использовать вместо оригинала, чтобы сбалансировать нагрузку на инфраструктуру.
Шаблон Concurrent Contracts используется, когда «[существующий] контракт на обслуживание может не подходить или не применим ко всем потенциальным потребителям услуг». Например, когда проблемы безопасности, протокола или доступности требуют, чтобы нечто подобное (но не одно и то же) было доступно для определенного подмножества пользователей (например, сторонних потребителей или мобильных устройств с ограниченной вычислительной мощностью или пропускной способностью).
Для реализации нашей новой пользовательской истории мы будем использовать оба этих шаблона вместе, чтобы предоставить версию службы Entity Service «только для чтения». Однако, предоставляя вторую версию службы Product Entity «только для чтения», вы также можете сказать, что мы частично реализуем шаблон SOA с избыточной реализацией , поскольку мы предлагаем второй избыточный вариант для некоторых ключевых операций службы.
Получающаяся архитектура выглядит примерно так (нажмите, чтобы увеличить)…
Договор на обслуживание.
Первоначальная служба Product Entity Service предлагала пять операций — « Получить», «Найти», «Создать», «Обновить» и «Удалить», но предлагать все эти возможности сторонним лицам не нужно и, вероятно, будет довольно проблематично (с точки зрения безопасности, целостности и т. Д.). Мы, конечно, не хотим, чтобы какие-либо внешние пользователи создавали или обновляли информацию о наших продуктах без нашего разрешения.
Поэтому в нашем контракте на веб-службу для новой « Службы сущности продукта только для чтения » я полностью удалил операции « Создать» , « Обновить» и « Удалить», предоставив только « Получить и найти» . Все типы данных остаются неизменными (один и тот же Product.xsd описывает сущность продукта и т. Д.). Сохранение типов данных одинаково важно, потому что я намеренно применяю схемы канонической схемы и схемы централизации и использую принцип стандартизированного контракта на обслуживание, чтобы избежать преобразования.
Java-код
С этой новой службой только для чтения я все еще работаю по контракту, поэтому я создал новый проект Maven , первой задачей которого во время сборки является импорт WSDL-контакта службы продукта только для чтения и создание из него набора JAX. -Сервисные интерфейсы и объекты данных.
С этого момента я могу повторно использовать часть кода, который я уже разработал, для «полной» службы Entity Service. Путем рефакторинга моей предыдущей кодовой базы в модули, я даже могу заставить Maven рассматривать исходный код как зависимость для этого нового сервиса. По сути, интересующие меня фрагменты — это EJB и DAO, которые я создал для бизнес-логики и логики операций Get и Find .
Повторно используя существующий код и создав сервер Glassfish в облаке Amazon , я могу в кратчайшие сроки запустить новую услугу и быть на полпути к завершению истории пользователя. Все, что мне сейчас нужно, это некоторые реплицированные данные продукта для работы с …
Запуск репликации данных.
Couch DB предлагает фантастическую систему репликации корпоративного класса из коробки и бесплатно. Это делает реализацию SOA-шаблона Service Data Replication очень простой.
Встроенный репликатор данных Couch DB может реплицировать целые базы данных документов между любыми двумя экземплярами CouchDb, которые доступны в сети или через Интернет. В этом случае я создал базу данных CouchDb у хост- провайдера под названием IrisCouch . Они могут предоставить мне защищенные экземпляры CouchDB или разных размеров по требованию и позаботятся обо всей необходимой инфраструктуре и требованиях к резервному копированию. Для маленьких пользователей они даже делают это бесплатно.
Чтобы настроить репликацию, мне просто нужно использовать инструмент командной строки CURL для выдачи конкретных инструкций по HTTP для моего локального экземпляра CouchDB. Эти инструкции говорят моей локальной службе CouchDB о необходимости репликации данных моего Продукта с моей удаленной базой данных CouchDB в IrisCouch через Интернет.
Инструкция по репликации базы данных представляет собой документ JSON и выглядит примерно так:
|
1
2
3
4
|
{'source':'products', 'create_target':true, 'continuous':true} |
По сути, эта инструкция JSON гласит « реплицируйте документы локальной базы данных Products на удаленный экземпляр iriscouch, навсегда ». Сразу после выполнения команды CouchDB начинает работать и начинает реплицировать мои локальные данные в мой удаленный экземпляр базы данных. Это включает в себя обновления и удаления, а также любые «проектные документы», хранящиеся в базе данных продуктов. Эта точная копия Продуктов сразу же становится доступной моей Службе Entity Product для чтения, которая находится в облаке Amazon EC2.
С этого момента потребители услуг, использующие операции Get или Find для этого сервиса, увидят точную копию данных, которые используются внутри компании. Информация будет обновляться путем репликации.
Наконец, пользовательский приемочный тест.
Итак, насколько хорошо мы справились с требованиями нашей новой пользовательской истории?
Размещая версию службы Product Entity Service только для чтения в облаке Amazon, мы создали веб-сервис вне сайта, который очень доступен. Предоставляемые им данные являются точной копией данных, которые мы используем на месте с минимальной задержкой между двумя копиями при нормальных условиях.
Если моя локальная сеть выйдет из строя, облачная версия Product Entity Service, доступная только для чтения, будет работать независимо, и, поскольку мы используем облачную инфраструктуру Amazon, она может получить практически неограниченные ресурсы времени выполнения, если это необходимо. Наличие никогда не должно быть проблемой. Мы можем добавить больше машин в любое время и предложить балансировку нагрузки и, возможно, разбросать машины по нескольким континентам.
Я предполагаю, что директор по продажам будет рад, что наши клиенты всегда могут видеть информацию в нашем каталоге продукции, а сами клиенты должны быть очень довольны комплексным и надежным обслуживанием, которое они теперь получают. Наконец, ИТ-менеджер будет рад, что сетевая безопасность остается неизменной и что новая служба, размещенная за пределами площадки, будет стоить практически ничего и будет очень надежной.
Осталось только опубликовать конечную точку службы продукта только для чтения для наших клиентов и поддержать их в использовании. В целом довольно удачный день в офисе.
Хотите попробовать Службу Продукта Только для чтения для себя?
Подробную информацию о конечных точках можно найти в репозитории простых сервисов SOA Growers. Перейдите по ссылке «Сервисный репозиторий» и найдите «R20121231? выпуск. Там вы можете найти ссылки на WSDL службы, сертификат WS-I и ссылку на конечную точку демонстрационного веб-сервиса, размещенную на микроэкземпляре AWS.
Лучший способ испытать живую демонстрацию — это загрузить набор тестов SOAP-UI. Для этого набора тестов требуется SOAP-UI v4 (который можно загрузить бесплатно). Набор тестов содержит простой тест всех операций, доступных в сервисе.
Познакомьтесь со всей серией блогов онлайн …
Вероятно, это последняя из этой серии статей о построении сервисов сущностей с использованием Java и CouchDB. Если вы пропустили какой-либо из предыдущих постов в этой серии и хотите наверстать упущенное, остальные записи перечислены ниже…
- Реализация Entity Services с использованием NoSQL. Часть 1. Схема
- Реализация Entity Services с использованием NoSQL. Часть 2. Сначала контракт
- Реализация Entity Services с использованием NoSQL. Часть 3. CouchDB
- Реализация Entity Services с использованием NoSQL. Часть 4. JavaEE
Ссылка: Внедрение Entity Services с использованием NoSQL. Часть 5. Улучшение автономии с использованием облака от нашего партнера по JCG Бена Уилкока из блога SOA, BPM, Agile & Java .