Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Сервис-ориентированная архитектура: основные понятия




Значение SOA

Сервис-ориентированная архитектура

Подготовлено: по материалам зарубежных сайтов
Перевод: Intersoft Lab

Сегодня наблюдается устойчивый рост интереса к концепции сервис-ориентированной архитектуры (service-oriented architecture, сокр. SOA). Свидетельство тому - оценки аналитических компаний и усилия крупных поставщиков программного обеспечения по продвижению этого подхода.

По словам Клива Финкельштейна (Clive Finkelstein), автора инфотехники (information engineering), до появления концепции SOA при разработке систем в качестве отправного момента для программирования бизнес-логики использовались диаграммы рабочих потоков и блок-схемы систем. Разработанные вручную программы тщательно тестировались, после чего внедрялись. Сегодня ситуация изменилась коренным образом: современные инструменты управления бизнес-процессами позволяют обойтись без ручной разработки и тестировании. Так, с помощью методов моделирования можно проверять корректность исполнения бизнес-логики, представленной в диаграммах, а затем автоматически получать описания этих диаграмм на XML-языках управления бизнес-процессами.

По мнению Клива Финкельштейна, такая технология управления бизнес-процессами является большим шагом вперед с точки зрения повышения эффективности разработки систем; по значимости ее можно сравнить с созданием в конце 50-х годов компиляторов языка высокого уровня. Действительно, данный подход позволяет упростить вызов Web-сервисов из любого местоположения и их выполнение на основе бизнес-правил. Кроме того, при изменении этих правил, корректируется соответствующая логика в диаграммах: диаграммы автоматически генерируются заново. Таким образом, закладываются предпосылки для перехода от медленного ручного кодирования, используемого сейчас при создании систем, к автоматизированному. Благодаря этому компании смогут реализовывать изменение бизнес-правил за минуты или часы, а не за месяцы или годы.

Очень часто становление того или иного подхода сопровождается появлением неверных или ошибочных трактовок, как это было, например, с концепцией федеративного Хранилища данных. Не миновала "сия чаша" и сервис-ориентированную архитектуру. Так, по крайне мере, считает представитель компании BEA Джерими Уэстерман (Jeremy Westerman). Именно поэтому в одной из своих статей, посвященных SOA, он специально останавливается на "проблемных местах" и приводит подробные пояснения:

  1. SOA не является чем-то новым: IT-отделы компаний успешно создавали и развертывали приложения, поддерживающие сервис-ориентированную архитектуру, уже много лет - задолго до появления XML и Web-сервисов.
  2. SOA - это не технология, а способ проектирования и организации информационной архитектуры и бизнес-функциональности.
  3. Покупка самых новых продуктов, реализующих XML и Web-сервисы, не означает построения приложений в соответствии с принципами SOA.

Джерими Уэстерман дает следующее определение SOA: это парадигма, предназначенная для проектирования, разработки и управления дискретных единиц логики (сервисов) в вычислительной среде. Применение этого подхода требует от разработчиков проектирования приложений как набора сервисов, даже если преимущества такого решения сразу неочевидны. Разработчики должны "выйти за границы" своих приложений и подумать, как воспользоваться уже существующими сервисами, или изучить, как их сервисы могут быть использованы их коллегами.

SOA "подталкивает" к использованию альтернативных технологий и подходов (таких как обмен сообщениями) для построения приложений посредством связывания сервисов, а не посредством написания нового программного кода. В этом случае, при надлежащем проектировании, применение сообщений позволяет компаниям своевременно реагировать на изменение рыночных условий - "настраивать" процесс обмена сообщениями, а не разрабатывать новые приложения.

Слова Джерими Уэстермана в определенной степени перекликаются с точкой зрения Клива Финкельштейна. "Родоначальник инфотехники" сетует, что до недавних пор термин "сервис-ориентированная архитектура" был синонимом "Web-сервис". Клив Финкельштейн определяет SOA следующим образом - вызов Web-сервисов с помощью средств и языков управления бизнес-процессами. Он считает, что SOA - это термин, который появился для описания исполняемых компонентов - таких как Web-сервисы - которые могут вызываться другими программами, выступающими в качестве клиентов или потребителей этих сервисов. Эти сервисы могут быть полностью современными - или даже устаревшими - прикладными программами, которые можно активизировать как черный ящик. От разработчика не требуется знать, как работает программа, необходимо лишь понимать, какие входные и выходные данных нужны, и как вызываются эти программы для исполнения.

В самом общем виде SOA предполагает наличие трех основных участников: поставщика сервиса, потребителя сервиса и реестра сервисов (см. рис. 1). Взаимодействие участников выглядит достаточно просто: поставщик сервиса регистрирует свои сервисы в реестре, а потребитель обращается к реестру с запросом.

Рис. 1. Общая схема SOA

Для использования сервиса необходимо следовать соглашению об интерфейсе для обращения к сервису - интерфейс должен не зависеть от платформы. SOA реализует масштабируемость сервисов - возможность добавления сервисов, а также их модернизацию. Поставщик сервиса и его потребитель оказываются несвязанными - они общаются с помощью сообщений. Поскольку интерфейс должен не зависеть от платформы, то и технология, используемая для определения сообщений, также должна не зависеть от платформы. Поэтому, как правило, сообщения являются XML-документами, которые соответствуют XML-схеме.

Любой разговор о SOA невольно переходит на рассуждение о роли и месте Web-сервисов. Несмотря на то, что основные положения SOA сложились задолго до появления Web-сервисов, сегодня Web-сервисы занимают центральное место в SOA (см. рис. 1). Так, Джерими Уэстерман отмечает, что использование XML и Web-сервисов "поднимает SOA на более высокий уровень".

Действительно, открытые стандарты, описывающие XML и Web-сервисы, позволяют применять SOA ко всем технологиям и приложениям, установленным в компании. Как известно, Web-сервисы базируются на широко распространенных и открытых протоколах: HTTP, XML, UDDI, WSDL и SOAP. Именно эти стандарты реализуют основные требования SOA - во-первых, сервис должен поддаваться динамическому обнаружению и вызову (UDDI, WSDL и SOAP), во-вторых, должен использоваться независящий от платформы интерфейс (XML). Наконец, HTTP обеспечивает функциональную совместимость.

Наконец, сегодня Web-сервисы рассматриваются как эффективный инструмент для интеграции, в том числе для взаимодействия процессов, выполняемых в различных компаниях. Особое место среди различных спецификаций, предназначенных для описания систем и приложений на уровне бизнес-процессов, занимает язык BPEL4WS (подробнее см. "Бизнес-процессы и XML").




Поделиться с друзьями:


Дата добавления: 2017-01-14; Просмотров: 259; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.009 сек.