ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 11.01.2024
Просмотров: 747
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
292 3. Сервисы должны быть слабосвязаны. Никто не может преду- гадать, в какую сторону будет развиваться IT-инфраструктура. Реше- ния могут развиваться, взаимодействовать, заменять друг друга. В связи с этим основной задачей является сохранение целостности си- стемы в рамках такого развития, независимо от происходящих изме- нений.
Система сервисов является слабосвязанной, если сервис может приобретать знания о другом сервисе, оставаясь независимым от внутренней реализации логики данного сервиса. Это достигается по- средством использования контрактов сервисов.
Слабосвязанность программных компонентов, лежащая в осно- ве СОА, позволяет значительно упростить координацию распреде- ленных систем и их реконфигурацию. Основная цель использования концепции слабосвязанных программных систем – это уменьшение количества зависимостей между компонентами. При уменьшении количества связей, уменьшается объем возможных последствий, воз- никающих в связи со сбоями или системными изменениями.
Слабосвязанность – это не синоним «инкапсуляции» объектно- ориентированной концепции построения программных систем. Про- граммная система может полностью соответствовать требованиям инкапсуляции, но быть сильносвязанной на семантическом уровне.
4. Сервисы должны абстрагировать внутреннюю логику. Каж- дый сервис должен действовать как «черный ящик», скрывающий свои детали от окружающего мира. Нет четкого определения, какой объем логики должен помещаться в отдельном сервисе. Взаимодей- ствие на уровне интерфейсов является одним из требований для обес- печения слабой связанности.
5. Сервисы должны быть совместимы. Сервис может как са- мостоятельно реализовывать логику, так и применять другие сервисы для ее реализации. Сервисы должны быть спроектированы таким об- разом, чтобы поддерживать возможность их использования в качестве элементов другого сервиса. Принцип совместимости не зависит от того, использует ли сервис для выполнения своей работы другие сер- висы.
293
В качестве примера такого взаимодействия сервисов выступает концепция оркестрации сервисов. В этом случае, сервис- ориентированный процесс (который в принципе может быть опреде- лен как композиция сервисов) управляется сервисом родительского процесса, который включает в себя другие сервисы, являющиеся участниками данного процесса.
Кроме того, принцип совместимости также определяет вид сер- висных операций. Совместимость– это, по сути, просто другая форма повторного использования, и поэтому операции должны быть стан- дартными, а для наибольшей совместимости должны обладать необ- ходимым уровнем детализации.
6. Сервисы должны быть автономными. Свойство автономно- сти требует, чтобы область бизнес-логики и ресурсов, используемых сервисом были ограничены явными пределами. Это позволяет серви- су самому управлять всеми своими процессами. Также это устраняет зависимость от других сервисов, что освобождает сервис от связей, которые могут препятствовать его применению и развитию. Вопрос автономности – наиболее важный аргумент при распределении биз- нес-логики на отдельные сервисы.
Автономность не обязательно предоставляет сервису исключи- тельное право собственности на бизнес-логику, которую он инкапсу- лирует. Есть только гарантия того, что во время исполнения сервис контролирует любую логику, которую он реализует. Поэтому мы можем выделить два типами автономности:
Автономность на уровне сервиса: границы ответственно- сти сервисов отделены, но они могут использовать общие ресурсы.
Например, сервис обертки, который инкапсулирует унаследованную программную систему, которая также кем-то используется (незави- симо от данного сервиса), обладает автономностью данного типа. Он управляет унаследованной системой, но также совместно использует ресурсы с другими существующими клиентами.
Чистая автономность: бизнес-логика и ресурсы находятся под полным контролем сервиса. Как правило, такой вид автономно-
294 сти используется, когда для реализации сервиса бизнес-логика созда- ется с нуля.
7. Сервисы не должны использовать информацию о состоянии.
Сервисы должны сводить к минимуму объем информации о состоя- нии, и время, в течение которого они ею обладают. Информация о состоянии– это определенные данные, характеризующие текущую де- ятельность. Например, пока сервис обрабатывает сообщение, он вре- менно зависит от состояния (stateful). Если сервис несет ответствен- ность за сохранение состояния в течение более длительного времени, его способность оставаться доступным для других клиентов будет за- труднена.
Независимость от состояния(statelessness) позволяет повысить возможности масштабируемости и повторного использования сер- висов. Чтобы сервис как можно меньше зависел от состояния, его операции должны быть разработаны с учетом соображений обработки информации без данных о состоянии.
Основной особенностью СОА, поддерживающей независимость от состояния, является использование сообщений-документов. Чем выше сложность сообщения, тем более независимым и самодостаточ- ным оно остается.
8. Сервисы должны поддерживать обнаружение. Обнаружение сервисов позволяет избежать случайного создания избыточного сер- виса, обеспечивающего избыточную логику. Метаданные сервиса должны подробно описать не только общую цель сервиса, но и функ- циональность, реализуемую его операциями.
На уровне СОА, обнаружение характеризует способность архи- тектуры обеспечить механизмы поиска, такие как реестр или каталог.
На уровне сервиса, принцип обнаружения относится к процессу про- ектирования отдельного сервиса, так чтобы данный сервис настолько подавался обнаружению, насколько это возможно.
295
Веб-сервисы.
XML Веб-сервисы (Веб-службы) – это программные компонен- ты, с помощью которых можно создавать независимые масштабируе- мые слабосвязанные приложения.
В основе технологии веб-сервисов лежит процесс обмена сооб- щениями в формате XML-документов. Передача сообщений проис- ходит с использованием протоколов HTTP, XML, XSD, SOAP, WSDL,
UDDI.
Спецификация определяет три основных стандарта, используе- мых для поддержки представления, поиска и обмена информацией между веб-сервисами – это WSDL, UDDI и SOAP, образующие так называемый «треугольник СОА».
Процесс взаимодействия между клиентом и поставщиком веб- сервиса представлен на рисунке 5.3.
Рис. 5.3. Процесс взаимодействия между клиентом и поставщиком веб-сервиса
Протокол SOAP предназначен для организации взаимодействия удаленных систем при помощи асинхронного обмена XML- отформатированными документами, состоящими из трех частей: кон- верта (обертки), заголовка и тела. SOAP формирует базовый слой стека протоколов веб-сервисов, обеспечивая инфраструктуру обмена сообщениями между ними.
SOAP (Simple Object Access Protocol) – простой протокол досту- па к объектам. SOAP – это протокол для обмена информацией в рас-
296 пределенной системе. SOAP использует XML для определения обо- лочки структуры сообщения. Такая оболочка независима от семанти- ки реализации.
SOAP определяет метод передачи сообщения из одной точки распределенной информационной системы в другую. Это возможно благодаря оболочке обмена сообщениями на основе XML, которая является независимой от модели программирования и наращиваемой, а также она может использоваться различными сетевыми протокола- ми.
Одной из особенностей SOAP является использование его в лю- бом транспортном протоколе, например: TCP, HTTP, SMTP. Для того, чтобы поддерживать взаимодействие в SOAP определены взаимосвя- зи со стандартными протоколами. Таким образом, SOAP обеспечива- ет гибкую оболочку для взаимосвязи различных протоколов, а также реализует явное связывание для HTTP.
Другая характеристика– это независимость от модели програм- мирования. Здесь можно выделить следующее: SOAP является раз- решенным для всех моделей программирования и не зависит от RPC
(удаленный вызов процедур).
В SOAP определена модель обработки однонаправленных со- общений. Все множество сообщений возможно объединить в общий процесс обмена сообщениями. Но возникают ситуации, когда получа- телю необходимо послать отправителю ответ. С помощью SOAP можно реализовать любое количество схем обмена сообщениями, и схема «запрос-ответ» одна из них.
Для обмена сообщениями SOAP может использовать различные протоколы, т.к. оболочка SOAP-сообщения не зависит от протокола.
В стандартном взаимодействии протоколов уже определены правила, по которым SOAP-сообщение передается от отправителя получателю, т.е. подобное взаимодействие описывает возможность согласовать
SOAP и другой протокол, в котором описана собственная оболочка сообщения и, возможно, отличными от SOAP заголовками. SOAP взаимодействует с различными базовыми протоколами, такими как:
HTTP, TCP, SMTP и некоторыми другими.
297
Благодаря этим характеристикам SOAP используется в тех рас- пределенных системах, в которых ранее обмен данными был труден или невозможен.
Для того чтобы приложение могло использовать Web-сервис, необходимо детальное описание интерфейса взаимодействия. Для описания интерфейсов взаимодействия был предложен WSDL (Web
Services Description Language) – это язык для описания Web-сервисов.
В основе языка WSDL лежит XML.
Язык WSDL (Web Services Description Language) описывает сер- висы в виде неких абстрактных ресурсов, способных принимать на вход документы определенных типов и инициировать отправление документов других типов. WSDL используется для описания веб- сервисов и для определения их расположения. WSDL определяет сер- вис с двух точек зрения: абстрактной и конкретной.
На абстрактном уровне сервис задается в терминах посылаемых и принимаемых им сообщений, которые описываются средствами
XML Schema в виде, независимом от конкретного транспортного про- токола. На конкретном уровне определяются привязки к транспорт- ным форматам и точкам физического размещения.
Для описания интерфейса в WSDL-документ может входить различная информация, например, возможные операции, протокол взаимодействия и др. Обычно в документе WSDL можно выделить три логические части:
Раздел определения типов данных– в данном разделе определяется вид XML-сообщений;
Раздел абстрактных операции – здесь указывается список операций, которые возможно производить с сообщениями;
Раздел для связывания сервисов – в этом разделе указыва- ется метод, которым сообщение доставляется.
Протокол UDDI (Universal Description Discovery & Integration) представляет собой стандарт на внутреннее устройство и внешние интерфейсы базы данных (репозитория), хранящей описания серви- сов. Все описания в БД хранятся в виде XML-записей. Последняя версия UDDI обеспечивает репликацию репозиториев со сложными
298 моделями их подчиненности друг другу, построение репозитория из нескольких узлов (и репликацию данных между ними), глобальную уникальность записей и ключей, API публикации описаний и подпис- ки на изменения, средства обеспечения целостности данных, интер- национализации записей, шифрования содержимого. В то время как версия UDDI 2.0 предназначалась для поддержки каталогов элек- тронного бизнеса, версия 3.0 ориентирована и на внутрикорпоратив- ное использование для построения корпоративных систем в рамках идеологии сервис-ориентированной архитектуры. Поэтому она до- пускает создание реестров нескольких типов (общедоступный, част- ный и с разделяемым доступом).
299
1 ... 10 11 12 13 14 15 16 17 18
Глава 6. ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ РЕПЛИКАЦИИ
В СОВРЕМЕННЫХ СУБД
6.1. Репликация в MS SQL Server
Репликация - это механизм распространения данных из основ- ной базы данных(издатель) к базам данным- подписчикам, является одной из техник масштабирования баз данных.
Состоит эта техника в том, что данные с одного сервера базы данных постоянно копируются (реплицируются) на один или не- сколько других (называемые репликами). Таким образом появляется возможность распределить нагрузку с одного сервера на несколько.
Статья (article) — это объекты, которые мы будем реплициро- вать, такие как таблицы, процедуры, функции и т. д.
Публикация(publication) — это набор статей, или проще гово- ря окончательный набор объектов для репликации.
Фильтры — набор условий для статьи. В репликации возможно использовать фильтры на таблицы, вьюшки, что позволяет нам реп- лицировать только необходимые данные, благодаря этому уменьша- ется передаваемый трафик, уменьшается избыточность, уменьшается хранимый объем данных.
Экземпляр SQL Server, содержащий базу данных, из которой распространяются данные, называется издателем (Publisher). В одной базе данных можно определить одну или более публикаций
(Publication), которые логически объединяются в одну или более ста- тей (Article). Статья представляет собой особый объект в базе данных публикации, который требуется переслать в другую базу данных. До- пустимые типы объектов в статьях включают в себя определяемые пользователем таблицы, хранимые процедуры и представления.
Для репликации необходима отдельная база данных для хране- ния метаданных и пересылаемых данных. Такая база данных называ- ется базой данных распространителя (Distribution Database), а экзем- пляр SQL Server, на котором она хранится, - распространителем
(Distributor). Распространитель может быть тем же экземпляром SQL
300
Server, что и издатель, отдельными экземпляром или экземпляром, на который пересылаются данные. Решение о размещении базы данных распространителя обычно базируется на рассмотрении таких момен- тов как загруженность или доступность (например, если репликация транзакций сочетается с зеркалированием баз данных).
Сервер, получающий данные от издателя, называется подписчи- ком (Subscriber). Подписчиком может быть тот же экземпляр SQL
Server, что и издатель, экземпляр, являющийся распространителем, или отдельный экземпляр SQL Server. Подписчик определяется с по- мощью добавления подписки на определенную публикацию. База данных подписчика может содержать как реплицированные, так и не- реплицированные объекты, и хранить более одной подписки от раз- ных публикаций.
Подписка может быть определена как принудительная (push), при этом данные принудительно пересылаются от распространителя в базу данных подписчика, или как подписка по запросу (pull), когда данные запрашиваются подписчиком. Принудительные подписки бо- лее распространены при развертывании репликации моментальных снимков (snapshot replication) и репликации транзакций (transactional replication). Подписки по запросу обычно используются при реплика- ции слиянием (merge replication), так как подписчик может чаще от- ключаться от коммуникаций и требовать проверки данных, обновля- емых по запросу. Решение о выборе вида подписки также может ба- зироваться на емкости и объеме избыточной нагрузки серверов, участвующих в топологии репликации.
Типы репликации
Существует три основных типа репликации: репликация мо- ментального снимка, репликация транзакций и репликация слиянием.
Встречаются и базирующиеся на этих типах различные вариации, например, одноранговая репликация (peer-to-peer replication).
Репликация моментального снимка позволяет распространять данные на определенный момент времени. Снимок пересылается и более не обновляется процессом репликации, пока не будет сделан новый снимок, который будет отправлен подписчику. Репликация