АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
 Скачать 4.65 Mb.
|
Контрольные вопросы1. Охарактеризуйте понятие компонент. 2. Как соотносятся понятия программный компонент и объект? 3. Что такое CORBA? 4. Что такое брокер объектных запросов CORBA? 5. Охарактеризуйте объектную модель CORBA. 6. Перечислите и охарактеризуйте базовые сервисы CORBA. 7. Что такое EJB? 8. В чем состоит различие между EJB 1.х, EJB 2.х и EJB 3.х? 9. Охарактеризуйте понятия сеансовые компоненты, компоненты-сущности и компоненты, ориентированные на сообщения. 10. Опишите архитектурную модель EJB. 11. Поясните, каким образом компонент EJB взаимодействует с контейнером EJB. 12. Каким образом осуществляется конфигурирование EJB-компонента? 13. Что такое .NET Framework ? 14. Опишите общие принципы функционирования .NET Framework. 15. Охарактеризуйте компонентную модель .NET. 16. Что такое OSGi? 17. Охарактеризуйте архитектуру OSGi. 18. Каковы типовые сферы применения OSGi? Глава 11. СЕРВИСНО-ОРИЕНТИРОВАННЫЕ АРХИТЕКТУРЫ 11.1. Понятие сервисно-ориентированной архитектуры Сервис-ориентированная архитектура (service-oriented architecture, SOA) – это подход к созданию ИС, основанный использовании, сервисов или служб (service). Ниже термины сервис и служба рассматриваются как синонимы. СОА - это, в первую очередь, интеграционная архитектура, использование которой позволяет обеспечить гибкую интеграцию приложений в рамках ИС. При использовании СОА приложения взаимодействуют, вызывая сервисы, входящие в состав других приложений. Сервисы объединяются в более крупные последовательности, реализуя бизнес-процессы, которые могут быть доступны как сервисы. СОА можно рассматривать также как подход к построению слабосвязанных (loosely coupled) ИС, реализующих механизмы асинхронного взаимодействия. (К слабосвязанным системам обычно относят такие системы как электронная почта и системы очередей сообщений.) Термин СОА используется очень широко, однако разные специалисты понимают его по-разному. Некоторые рассматривают СОА как ИТ-инфраструктуру, ориентированную на поддержку бизнеса, другие рассматривают СОА как средство повышения эффективности бизнеса. Применительно к тематике данного учебника под СОА будем понимать слабо связанную архитектуру, предназначенную для удовлетворения бизнес потребностей организации. Это определения никаким образом не фиксирует способ реализации сервисов. Концепцию сервисов нельзя назвать абсолютно новой, следует заметить, сервисный подход использовался еще в рамках компонентных технологий, таких как CORBA. СОА можно рассматривать и как архитектурный подход к построению ИС из множества автономных сервисов, из которых можно формировать по мере надобности различные приложения. Сервисы при этом могут строиться с использование разных технологий и могут быть реализованы на разных платформах. СОА можно рассматривать как философию проектирования ИС, в соответствии с которой ИС строится на базе сервисов, которые никаким образом не завязаны на конкретного производителя или конкретную технологию. Переход на СОА архитектуры позволяет решать следующие задачи: уменьшать сроки освоения и внедрения новых ИС, быстро создавать новые ИС на базе уже существующих; уменьшать суммарную стоимость владения ИС и стоимость их интеграции в систему более высокого уровня; увеличить срок жизни ИС за счет возможности их оперативной модернизации; использовать гибкие модели ценообразования путем передачи разработки отдельных бизнес-модулей сторонним производителям (аутсорсинг); уменьшать стоимости работ по интеграции, необходимой при слиянии и поглощении компаний; реализовывать бизнес-процессы на уровне, не зависящем от приложений и платформ, используемых для поддержки процессов. Идеология СОА предполагает, что бизнес-функции и инфраструктурные функции, которые необходимы для построения распределенных систем, реализуются как сервисы, которые, в сочетании или по отдельности, обеспечивают прикладную функциональность либо другим сервисам, либо приложениям, взаимодействующим с конечным пользователем. При этом концепция СОА предполагает использование единого механизма взаимодействия сервисов. Этот механизм строится на основе концепции свободных связей и должен поддерживать использование формальных интерфейсов. Сервисы можно рассматривать как строительные блоки, которые могу использоваться как для построения как сервисов более высокого уровня, так и для построения распределенных ИС. Сервисы могут вызываться независимо внешними или внутренними потребителями для выполнения элементарных функций либо могут объединяться в цепочки для формирования более сложных функций и для быстрого создания новых функций. Используя СОА, организации могут создавать гибкие ИС, которые позволяют оперативно реализовывать быстро изменяющиеся бизнес-процессы и многократно использовать одни и те же компоненты в рамках одной ИС. Понятие сервиса. Сервисом можно назвать любую дискретную функцию, которая может быть предложена внешнему потребителю. В качестве сервиса может выступать, как отдельная бизнес-функция, так и набор функций, которые образуют бизнес-процесс. Сервисы, ориентированные на использование в составе СОА должны обладать следующими свойствами: сервисы представляют собой многократно используемые бизнес-функции; сервисы определяются с помощью формальных, не зависящих от реализации интерфейсов; для обращения к сервисам используются протоколы связи, обеспечивающие прозрачность местонахождения и инвариантность по отношению к языку и платформе. Хотя в качестве сервиса может выступать любая бизнес-функция, однако крайне желательно, чтобы имелась возможность повторного использования бизнес-функций одним или разными приложениями. Примером может служить система журналирования, которая присутствует практически в каждом приложении. Во время выполнения каждый сервис размещается в одном, и только одном, месте и удаленно вызывается всеми клиентами, которые используют данный сервис. Достоинство подобного подхода состоит в том, что изменения в интерфейс или реализацию сервиса, например, изменение кода реализации или настроек нужно вносить только в одном месте. На этапе размещения каждой сервис создается один раз, но его можно локально размещать в любой системе или наборе систем, которым он необходим. Использование такого подхода позволяет повысить гибкость в достижении нужной производительности, а также в гибкость настройки сервиса. Использование формальных не зависящих от реализации интерфейсов для определения и инкапсуляции функций сервиса особенно важно для того, чтобы его можно было использовать многократно. Интерфейс должен инкапсулировать только те аспекты поведения, которые используются при взаимодействии между клиентом и сервером. Формальное определение интерфейса или контракт используется для установления связи между поставщиком и потребителем. В нем должны быть указаны только действия с обеих сторон, необходимые для осуществления взаимодействия. СОА не принуждает пользователя использовать конкретный протокол для доступа к сервису. Идея заключается в том, что сервис не определяется используемым протоколом, напротив, описание сервиса составляется независимым от протокола способом, позволяющим использовать для доступа к сервису разные протоколы. В идеале сервис определяется только один раз при помощи его интерфейса и может иметь несколько реализаций для работы с разными протоколами доступа. Такой подход позволяет максимально расширить возможности повторного использования сервиса [146, 147]. Эталонная архитектура СОА. Наиболее полно и формально понятие СОА определено в документе (спецификации), который называется Эталонная архитектура СОА (Reference Architecture Foundation for Service Oriented Architecture) [148]. Данная спецификация предложена глобальным консорциумом OASIS (Organization for the Advancement of Structured Information Standards), который занимается вопросами разработки и принятием промышленных стандартов, преимущественно в области электронной коммерции. В соответствии с этой спецификацией СОА определяется как архитектурная парадигма, которая должна служить мостом между бизнесом и ИТ, при этом СОА не относится целиком ни к бизнесе, ни к ИТ-сферам. При этом под бизнесом понимается произвольная деятельность, которой занимаются люди, а не только коммерческая деятельность. Основное назначение эталонной архитектуры состоит в том, чтобы обеспечить некоторый общий язык, на котором могут общаться основные заинтересованные стороны (stakeholders), к которым можно отнести архитекторов, менеджеров, разработчиков. Особо следует отметить, что эталонная архитектура не описывает какую-то конкретную архитектуру, она не ориентирована на конкретную технологию, она может быть определена на нескольких уровнях. В основу этой модели положены следующие основные посылки: - используемые ресурсы могут принадлежать разным организациям; - взаимодействующие между собой люди и системы также могут принадлежать разным организациям; - при построении СОА используются распределенные системы управления и безопасности; - общение между людьми системами реализуется преимущественно посредством обмена сообщениями. Такое окружение в рамках рассматриваемой спецификации называют СОА экосистемой (SOA ecosystem). Необходимость введения данного понятия определяется тем, что часто бывает очень трудно понять принципы функционирования систем, рассматривая только ее внутреннюю структуру. Особенно сложно сделать это в случае, если отдельные автономные части активно взаимодействуют с внешним миром. Для того чтобы адекватно описать функционирование таких систем, требуется понимать контекст, в котором они функционируют. Сам термин экосистема пришел из биологии, где под ним понимают систему, в которую входят растения, животные, человек. В рамках эталонной модели СОА экосистема рассматривается как сеть дискретных процессов, систем, а также человеческие сообщества, которые создают, используют и управляют некоторыми сервисами, формируемыми по мере возникновения потребностей. Ни одна из организаций не может полностью контролировать или управлять экосистемой. Экосистема строится с использованием 3 базовых принципов; 1. СОА - это парадигма, которая должна быть положена в основу системы обмена сообщениями между участниками (заинтересованными сторонами). 2. Участники (заинтересованными стороны) продолжают оставаться владельцами ресурсов, задействованных при построении СОА экосистемы. 3. Поведение участников (заинтересованных сторон) определяются правилами, определяемыми самой СОА экосистемой, а также политиками и контрактами. Эталонная СОА архитектура в полно мере согласована с подробно рассмотренным выше стандартом ISO/IEC/IEEE 42010:2011. В рамках эталонной СОА архитектура архитектуры определяются 3 вида (views), которые совпадают с 3 точками зрения (viewpoints): Участие в СОА экосистеме, Реализация СОА экосистемы и Владение СОА экосистемой. Участие в СОА экосистеме. Эта точка зрения описывает СОА экосистему как контекст для заинтересованных сторон, которые ведут в ней бизнес, при этом род деятельности не ограничивается корпоративными применениями или системами электронной коммерции. В некоторой деятельности может быть задействовано произвольное число участников. Каждый из участников имеет свою точку зрения и свои интересы. В качестве основного интереса выступает желания эффективно и безопасно вести бизнес. Реализация СОА экосистемы. Эта точка зрения определяет инфраструктурные элементы, которые необходимы для построения и поддержания сервисно-ориентированной системы. Эта точка зрения определяет технологии, которые архитектор может использовать для построения сервисно-ориентированных систем, а также видение механизмов распределенного управления как отдельными сервисами, так и всей экосистемой. В качестве заинтересованных сторон выступают все, кто задействован в проектировании и эксплуатации экосистемы. Владение СОА экосистемой. Эта точка зрения отражает интересы, касающиеся владения и управления ресурсами. Процессы, реализующие эту сторону функционирования СОА экосистемы, обычно с трудом поддаются автоматизации. Чаще всего это человеко-ориентированные процессы, такие как создание разного рода комиссий и комитетов, которые должны управлять СОА экосистемой. Владение ресурсом, входящим в состав СОА экосистемы, предполагает возможность управлять и модернизировать ресурс. Данная точка зрения определяет, каким образом СОА экосистема должна управляться, каким образом можно убедиться в том, что система эффективно решает задачи конечного пользователя и как СОА экосистема может быть защищена от действий злоумышленников. Информация по описанным точкам зрения приведена в табл. 11.1 Таблица 11.1. Точки зрения, описывающие СОА экосистемы
11.2. Микросервисы Микросервисные архитектуры (Microservice architecture) или просто микросервисы можно определить как поход к разработке программных систем, который в последние годы набирает популярность в среде разработчиков ПО. Идея состоит в том, что приложения строится как набор сервисов с ограниченной функциональностью, которые часто называют мелкозернистыми (fine grained) сервисами, каждый из которых работает в своем процессе и общается с другими сервисами посредством простых механизмов, чаще всего через протокол http. Управление системой сервисов может быть как централизованное, когда используется некоторый движок (engine), который вызывает сервисы последовательно или параллельно, так и децентрализованным, когда сервисы взаимодействуют по принципу одноранговой системы. Каждый сервис является независимым как при развертывании, так и при масштабировании. Каждый сервис может работать в своей СОА экосистеме. Различные сервисы могут разрабатываться с использованием разных языков программирования и разными командами разработчиков. В настоящее время нет общепринятого определения понятия микросервисная архитектура, стандарты также отсутствуют. Можно говорить, что нет и четких критериев принадлежности системы к классу микросервисных систем. Степень принадлежности системы к классу микровервисных систем можно определить по следующим признакам: 1. Система не является монолитной, а строится из небольших по объему модулей. Каждый модуль реализует одну функцию, которая ориентирована на решение определенной бизнес-задачи. Модуль имеет четко определенный интерфейс, который доступен другим модулям. 2. Система не является иерархической. Все сервисы работают на одном уровне. Если число сервисов становится слишком велико, то система может строиться по сотовому принципу. Каждая сота представляет собой отдельную СОА экосистему. Соседние соты могут взаимодействовать через пограничные сервисы. 3. Модули взаимодействуют по принципу «каждый с каждым», используя относительно простые механизмы, такие как HTTP/REST или предложенный Google Protocol Buffers [149]. Существуют и другие механизмы. В принципе, могут использоваться как синхронные, так и асинхронные механизмы взаимодействия. 4. •Сервисы могут проектироваться разными группами разработчиков на разных платформах, которые работают независимо друг от друга. 5. Сервисы могут быть развернуты независимо друг от друга, в автоматическом режиме. Микросервисный подход к проектированию ИС имеет ряд достоинств, основными из которых являются следующие: - возможность строить гибкие (agile) архитектуры, которые просто модифицировать и масштабировать; - к разработке можно привлекать команды независимых разработчиков. Микросервисные архитектуры начинают находить применение во многих реальных ИС. В частности, такие известные компании как Amazon, Twitter, eBay и др. перешли от монолитных к микросервисным решениям. Опыт практического применения микросервисных архитектур показал их сильные и слабые стороны. Основными достоинствами микросервисов являются следующие: - использование микросервисных архитектур открывает перед архитекторами широкие возможности, поскольку позволяет разрабатывать и размешать сервисы независимо друг от друга; - отдельные сервисы могут быть реализованы на разных языках и на разных платформах; - каждый отдельный микросервис может разрабатываться небольшой командой разработчиков; - микросервисы относительно легко интегрировать в систему; - ИС, построенные с использованием микросервисных архитектур легко модифицируются: - при построении отдельных микросервисов можно использовать самые новые технологии, что позволяет говорить о микросервисных архитектурах как средстве интеграции технологий; - микросервисы можно рассматривать как компонент, ориентированный на повторное использование; - микросервисные решения просты для понимания разработчиками, что позволяет привлекать сторонних разработчиков. Основными недостатками микросервисных архитектур являются следующие: - микросервисые архитектуры существенно проигрывают по скорости работы по сравнению с монолитными, и возможность их использования в системах даже мягкого реального времени вызывает сомнение; - микросервисные системы сложны в отладке; - микросервисные системы по своей сути являются одноранговыми системами, поэтому при увеличении числа сервисов, входящих в состав системы организация управление большим числом сервисов появляются трудности в плане управления; - отсутствие общей теории построения микросервисных систем, приводит к тому, что декомпозиция системы на отдельные сервисы продолжает оставаться искусством. Опыт проектирования и практического применения микросервисных систем показал, что больше всего этот подход подходит для построения распределенных ИС небольшого и среднего размера, которые могут управляться централизованно. К этой группе относятся, в частности, приложения, построенные с использованием облачных сервисов. Более подробную информацию по микросервисам можно найти в [150]. |