Кулурис определил распределенные системы как «системы, в которых аппаратные и/или программные компоненты, существующие в компьютерной сети, взаимодействуют и координируют свои действия путем обмена сообщениями».
Эта концепция стала популярной в последние годы благодаря нескольким факторам. Первым фактором, способствовавшим развитию распределенных систем, стало появление высокоскоростных локальных сетей. Еще одним важным фактором был технологический прогресс в производительности персональных компьютеров и разработка программного обеспечения для поддержки распределенных приложений. Распределенные системы связаны с концепцией Сети и Интернета. С развитием Интернета и появлением новых областей, взаимодействий, потребностей и приложений появляется концепция Веб 2.0. Этот термин был придуман Тимом О'Рейли в 2004 году для обозначения второго поколения в истории Интернета, основанного на сообществах пользователей и особом наборе услуг, таких как социальные сети, блоги, вики или фольксономии, которые поощряют сотрудничество и быстрое обмен информацией между пользователями.
Первые архитектуры, которые можно считать сервис-ориентированными (SOA), были основаны на CORBA (архитектуре Common Object Request Broker), которая действовала как уровень абстракции для соединения различных элементов архитектуры и создания сервисов. Другими более ранними технологиями были DCOM (распределенная объектная модель компонентов) или RPC (протокол удаленных процедур). В связи с необходимостью эффективного проектирования и реализации распределенных систем в Интернете возникает несколько проблем, некоторые из которых связаны с самой разработкой (производительность, взаимодействие с пользователем и т. д.), а другие — с дополнительными, основанными на возможности повторного использования и совместимости сервисов. Из этих потребностей возникают веб-службы, которые предоставляют стандартизированные механизмы для соединения различных пользователей с информационными серверами.
СЕРВИС-ОРИЕНТИРОВАННАЯ АРХИТЕКТУРА
Согласно SOA (сервисно-ориентированная архитектура) — это программные архитектуры, которые определяют использование сервисов для поддержки бизнес-требований, целью которых является достижение минимально возможной связи между программными агентами. Услуга — это единица работы, выполняемая поставщиком услуги для достижения конечного результата, желаемого потребителем услуги. И поставщик услуг, и потребитель услуг — это роли, которые играют программные агенты, а не владельцы программного обеспечения. В общем смысле сервис-ориентированная архитектура — это программное решение, позволяющее предприятию организовывать и использовать различные процессы. Благодаря SOA программные приложения больше не представляют собой массивные блоки функций и процессов. Вместо этого эти приложения состоят из собранных модульных сервисов. Помните, что услуга — это простая программная функция (например, отмена компакт-диска). Он может запускаться по запросу любой системой, независимо от операционной системы, платформы, языка программирования или географического положения.
Революционным в SOA является не сама концепция, которая существует уже давно, а тот факт, что ее можно реализовать через WWW (Всемирную паутину). Точно так же, как веб-страницы загружаются на любой платформе, веб-сервисы работают одинаково независимо от платформы, поскольку они созданы с использованием
универсальные стандарты.
Идея SOA проистекает непосредственно из объектно-ориентированного программирования, которое предполагает связь между данными и их обработкой. Таким образом, они формально определяют службы через интерфейсы, которые не зависят от базовой платформы и языка программирования. Эти интерфейсы скрывают особенности своей реализации, что делает их независимыми от Разработчик и язык программирования. С помощью этих архитектур можно проектировать и внедрять системы с высокой степенью масштабируемости, которые отражают бизнес-логику и в то же время облегчают взаимодействие между различными проприетарными или сторонними системами. Причина, по которой мы хотим, чтобы кто-то другой сделал работу за нас, заключается в том, что они являются экспертами. Использование сервиса обычно дешевле и эффективнее, чем делать это самостоятельно. Поэтому большинство из нас понимает, что мы не можем быть экспертами во всем. То же правило можно применить и к созданию программных систем.
Интерфейсы очень важны, если они плохо определены или не работают, система не работает. Интеграция большего количества интерфейсов стоит дорого, а также увеличивает вероятность ошибок в распределенных приложениях. Удаленные интерфейсы — самая медленная часть большинства распределенных приложений. При всем этом вместо создания новых интерфейсов для каждого приложения имеет смысл повторно использовать общие интерфейсы для всех приложений.
Итак, поскольку у нас есть только несколько доступных универсальных интерфейсов, мы должны включать в сообщения семантику, специфичную для приложения. Мы можем отправлять любые сообщения через наши интерфейсы, но есть некоторые правила, которым нужно следовать, чтобы сказать, что архитектура сервис-ориентирована.
– Во-первых, сообщения должны быть описательными, а не инструктивными, поскольку за решение проблемы отвечает поставщик услуг. Например, это было бы похоже на ситуацию, когда вы идете в ресторан и говорите официанту, что вы хотите выпить и какие у вас предпочтения, но мы не должны объяснять повару, как готовить ваши блюда, шаг за шагом.
‐ Во-вторых, поставщики услуг не смогут понять ваш запрос, если их сообщения не написаны в формате, структуре и лексике, понятных всем участникам. Таким образом, ограничение словарного запаса и структуры сообщений является
необходимые для эффективного общения. Чем уже сообщение, тем легче его понять.
- В-третьих, крайне важна возможность продления. Мир постоянно меняется, как и среда, в которой живет программное обеспечение. Эти изменения требуют соответствующих изменений в системном ПО, потребителях услуг, поставщиков и сообщений, которыми они обмениваются. Если сообщения не расширяемы, потребители и поставщики привязаны к определенной версии службы. Ограничение и расширяемость тесно связаны, вам нужны оба, и увеличение одного означает уменьшение другого. В идеале добиться правильного баланса.
– В-четвертых, SOA должен иметь механизм, который позволяет потребителю обнаруживать поставщика услуг в контексте услуги, запрашиваемой потребителем. Механизм должен быть гибким, а не централизованным реестром.
- В-пятых, служба без сохранения состояния: каждое сообщение, отправляемое потребителем поставщику, должно содержать всю информацию, необходимую поставщику для его обработки. Это ограничение делает поставщика услуг более масштабируемым, поскольку поставщику не нужно хранить информацию о состоянии между запросами. Это можно назвать «услугой массового производства», поскольку каждый запрос может быть обработан в общих чертах. Это ограничение также обеспечивает большую наглядность, поскольку любое программное обеспечение для мониторинга может независимо проверять запрос и извлекать его намерения. Это также позволяет легко восстанавливаться после частичных сбоев, поскольку нет промежуточных состояний, что делает службу более надежной.
- В-шестых, идемпотентные запросы (без изменений): повторные запросы, полученные программным агентом, имеют тот же эффект, что и одиночный запрос. Это требование позволяет поставщикам и потребителям повысить общую надежность сети. сервис, просто повторяя запрос, если произошел какой-либо сбой.
Так что можно сказать, что SOA — это не инструмент, а набор стандартов для создания новых приложений, более динамичных и менее зависимых. SOA упрощает систематический доступ к бизнес-логике и информации в нескольких службах, а также может организовать несколько удаленных служб для создания одной. большинство определения идентифицируют использование веб-служб, которые мы увидим в следующей главе, при реализации сервис-ориентированной архитектуры. Однако его можно реализовать с помощью любой другой сервисной технологии.