В предыдущих статьях я рассказывал о том, как я строил службу SOA «Entity» для продуктов, используя комбинацию веб-сервисов Java , Java EE и базы данных CouchDB NoSQL . В этом последнем посте из этой серии я собираюсь использовать некоторые из созданных мной технических ресурсов и реализовать несколько новых пользовательских историй, используя некоторые популярные шаблоны SOA .
Моя текущая реализация Product Entity Service очень независима от бизнес-процессов и поэтому может быть многократно использована в любом сценарии, когда потребители хотят находить или хранить информацию о продукте. Однако в существующем виде Служба Entity Service предназначена для использования в доверенной среде. Это означает, что нет ограничений на доступ к таким операциям, как «Создать», «Обновить» или «Удалить». Это хорошо в строго контролируемой корпоративной изолированной программной среде, но что, если я захочу поделиться некоторыми своими операциями по обслуживанию или информацией о продукте с недоверенными пользователями?
Давайте представим, что в дополнение к нашему внутреннему использованию Сервиса Entity Service мы также хотели удовлетворить следующую гибкую «пользовательскую историю»…
Так что: Моя опубликованная информация о продукте является точной и постоянно доступна для сторонних клиентов.
Как: директор по продажам и менеджер по ИТ.
Мы хотим: Предложить доступную только для чтения копию информации о моем продукте сторонним пользователям и системам.
Этот сценарий не является редкостью в бизнесе, и я реализовывал подобные истории пользователей в прошлом с некоторыми из моих клиентов . Но что удивительно в технологиях, которые мы используем для реализации нашей службы Entity (Java / JAX-WS и CouchDB NoSQL), так это то, что они делают разработку этого сценария очень простой.
Прежде всего, архитектурный дизайн.
Для реализации этой пользовательской истории я собираюсь обратиться к еще двум шаблонам разработки SOA для архитектуры сервисов — репликация данных о сервисах и параллельные контракты. Во втором посте мы уже говорили о подходе «сначала контракт», поэтому я не буду вдаваться в подробности, кроме как скажу, что он все еще применяется здесь. Контракт все еще является стандартизированным и отделенным контрактом .
Репликация данных службы — это шаблон, который помогает вам достичь высокого уровня автономности и доступности службы путем создания целых копий данных, необходимых службе в других частях инфраструктуры. Затем эту копию можно использовать вместо оригинала, чтобы сбалансировать нагрузку на инфраструктуру.
Одновременные контракты модель используется , когда стягиваются [существующего] Услуги не могут быть пригодны для или применим ко всем потенциальным потребителям услуг. Например, когда проблемы безопасности, протокола или доступности требуют, чтобы нечто подобное (но не одно и то же) было доступно для определенного подмножества пользователей (например, сторонних потребителей или мобильных устройств с ограниченной вычислительной мощностью или пропускной способностью).
Для реализации нашей новой пользовательской истории мы будем использовать оба этих шаблона вместе, чтобы предоставить версию службы 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 и выглядит примерно так:
{"source":"products",
"target":"https://username:[email protected]:6984/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» . Там вы найдете информацию о том, что служба Entity Services доступна только для чтения. Существуют ссылки на WSDL, сертификат WS-I и ссылку на конечную точку демо-веб-службы, размещенную на микроэкземпляре AWS.
Лучший способ испытать живую демонстрацию — это загрузить набор тестов SOAP-UI. Для этого набора тестов требуется SOAP-UI v4.5 (который можно загрузить бесплатно). Набор тестов содержит простые тесты для всех операций, доступных в сервисе.
Вы можете ознакомиться с остальной частью этой серии блогов онлайн.
Вероятно, это последняя из этой серии статей о построении сервисов сущностей с использованием Java и CouchDB. Если вы пропустили какой-либо из предыдущих постов в этой серии и хотели бы наверстать упущенное, остальные записи перечислены ниже…
- Реализация Entity Services с использованием NoSQL. Часть 1. Схема
- Реализация Entity Services с использованием NoSQL. Часть 2. Сначала контракт
- Реализация Entity Services с использованием NoSQL. Часть 3. CouchDB
- Реализация Entity Services с использованием NoSQL. Часть 4. JavaEE
Не забудьте поделиться!