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

Размещено на http://www.allbest.ru/

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

Мытникова Екатерина Анатольевна

Сервис-ориентированная архитектура (Service-oriented architecture, SOA) представляет собой эволюцию распределенных вычислений, спроектированных по принципу запрос/ответ для синхронных и асинхронных программных систем. Бизнес-логика или внутренние функции отдельной программной системы в таком случае представляются как модульные и публикуемые сервисы для пользователя этой системы. Основным преимуществом этих сервисов является характерная слабая связанность, то есть интерфейс не зависит от реализации. Разработчики и интеграторы приложения имеют возможность создавать приложения, объединяя между собой один и более сервисов без знания того, как устроены эти сервисы изнутри. Например, сервис может быть разработан на.NET или J2EE, а его потребитель -- на совершенно иной платформе или языке программирования [5, 6].

Сервис-ориентированная архитектура имеет следующие ключевые характеристики:

· Каждый SOA-сервис имеет свой интерфейс, описанный в универсальном формате XML с использованием WSDL (Web Services Description Language), который является стандартом, используемым для описания сервисов.

· SOA-сервисы общаются между собой сообщениями, формально определены с помощью XML-схемы, иначе называемой XSD (XML Schema Definition). Связь между потребителями и источниками сервисов, как правило, осуществляется в неоднородной среде, без особых знаний о том, кто опубликовал тот или иной сервис.

· SOA-сервисы содержатся в реестре, который выступает в качестве каталога. Поэтому потребитель сервиса может легко найти нужный ему сервис и запросить его вызов. Universal Description, Discovery and Integration (UDDI) -- это стандарт, используемый в реестре сервисов для их описания, определения и интеграции.

· Каждый SOA-сервис имеет качественную характеристику (Quality of Service, QoS). Некоторыми из основных элементов QoS являются такие требования безопасности, как авторизация, аутентификация, надежность обмена сообщениями, а также политики доступа на совершение вызовов этого сервиса.

Почему SOA?

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

Потребители сервисов могут вызывать нужные им сервисы путем простой отправки сообщений. Эти сообщения, как правило, видоизменяются и перенаправляются на шину сервисов (Service Bus) и далее к целевому сервису. Такая архитектура обеспечивает использование интерпретатора бизнес-логики, который позволяет одной и той же бизнес-логике существовать как в одном сервисе, так и в нескольких. Сервис-ориентированная архитектура предоставляет возможность управления всей инфраструктурой сервисов, что позволяет анализировать затраты на содержание сервисов, записывать служебные данные и т.п. В дополнение к этому, сервис-ориентированная архитектура предлагает предприятиям возможность принятия гибких решений при проведении бизнес-процессов, что также позволяет изменить или заменить один сервис, не затрагивая остальные во время выполнения.

SOA-инфраструктура

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

WSDL, UDDI и SOAP -- это фундаментальные части SOA-инфраструктуры. WSDL используется для описывания сервисов, UDDI для регистрации и поиска сервисов, протокол SOAP -- как способ формирования данных между потребителем и провайдером сервиса, используемый по умолчанию. Таким образом, потребитель сервиса имеет возможность найти нужный сервис в реестре UDDI, получить WSDL, описывающий этот сервис и, наконец, вызвать этот сервис, используя SOAP протокол.

WS-I Basic Profile, разработанный и сопровождаемый Web services Interoperability Organization, является другой важной частью, необходимой для тестирования сервисов и их взаимодействия. Поставщики сервисов могут использовать Basic Profile для тестирования совместимости сервиса на различных платформах и технологиях.

Хотя J2EE и.NET платформы являются основными для написания SOA-приложений, это не означает, что только ими и ограничивается круг. Просто такие платформы обеспечивают лучшую основу для разработчиков, позволяя понимать и интерпретировать всю суть принципов SOA-архитектуры, а также привносят свои лучшие черты в мир SOA, доказанные опытом реализации проектов по всему миру: масштабируемости, надежности, доступности и производительности. Новые спецификации, такие как Java API for XML Bindings (JAXB), используемый для отображения XML документов для классов Java, Java API for XML Registry (JAXR), используемый для стандартного общения с реестрами UDDI, а также Java API for Remote Procedure Call (XML-RPC), используемый для удаленного вызова сервисов, облегчает разработку и развертывание веб-сервисов, которые могут быть перенесены между различными окружениями J2EE, одновременно взаимодействую с сервисами на других платформах, таких как.NET.

Существуют критические значимые внутренние системы на предприятиях, которые используются для поддержания таких требований, как безопасность и надежность. Предприятия применяют SOA как средство разработки и развертывания приложения, и базовые составляющие веб-сервисов, такие как WSDL, UDDI и SOAP не могут удовлетворить этим повышенным требованиям. Как было упомянуто выше, эти требования являются частью QoS. Многочисленные определения, относящиеся к QoS, разрабатываются в таких организациях по стандартизации, как W3C.

Если предприятие решает использовать SOA, то сервисы могут быть интегрированы для структурирования разрозненных данных и приложений. Интеграция приложения означает, что требования процесса, такие как асинхронное взаимодействие, параллельные вычисления, трансформация данных должны быть приведены к единому виду. BPEL4WS или WSBPEL (Web Services Business Process Execution Language) -- это определение, которое является частью оркестрации сервисов. Предприятия, использующие сервис-ориентированную архитектуру в своей ИТ-инфраструктуре, имеют возможность создавать монолитные приложения, используя набор уже существующих приложений, которые предоставляют свои функциональные возможности через собственные интерфейсы ввода/вывода данных.

По мере увеличения на предприятии количества сервисов и бизнес-процессов, управление инфраструктурой позволяет системному администратору управлять запуском сервисов в неоднородном окружении, что является крайне важным. Web Services for Distributed Management (WSDM) определяет, что любые сервисы, реализованные в соответствии со специальным стандартом, могут управляться специализированным совместимым решением вручную.

Бизнес-процессы

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

Если смотреть на бизнес-процесс с технической точки зрения, то составляющие его элементы можно разделить на следующие:

· Входные данные (input) -- данные, которые нужно обработать, чтобы затем сформировать выходные данные (результат).

· Выходные данные (output) -- все данные, полученные из процесса. Выходные данные представляют собой бизнес-цели и показатели, необходимые для бизнес-деятельности.

· События (events) -- уведомления о возникновении чего-либо важного, например, визуальная индикация. Они могут возникать до, во время выполнения и после выполнения процесса.

· Подпроцесс (subprocess) -- более мелкий процесс или этап в рамках процесса. Подпроцесс используется тогда, когда невозможно представить объем работы одним набором действий. Он имеет те же элементы, что и процесс.

· Действие (activity) -- наименьший элемент работы в процессе.

· Показатели производительности (performance metrics) -- атрибуты, представляющие эффективность процесса для определения его соответствия необходимой производительности. Эти показатели помогают определить производительность и сравнить ее с требующимися значениями. Они также выделяют потенциальные области совершенствования процесса, реализуя в конечном итоге цикл улучшений, обещанный архитектурой SOA.

Преимущества

Хотя концепция SOA принципиально не нова, SOA отличается от существующих альтернатив [3] тем, что большинство поставщиков программного обеспечения одобрило и приняло эту концепцию и имеет в своем распоряжении платформенные ресурсы для использования SOA. С повсеместным набором стандартов, SOA дает лучший вариант последующего использования единожды выполненных инвестиций предприятия и позволяет создавать новые приложения, которые могут быть построены из сторонних приложений, новых или разработанных ранее и другими компаниями.

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

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

Не стоит также забывать, что в сервис-ориентированных архитектурах должны быть спроектированы сервисы системы безопасности [1, 2, 4].

сервис ориентированный архитектура

Список литературы

1. Егорова Ю.Н., Мытникова Е.А., Мытников А.Н., Егорова О.А. Программный комплекс оценки угроз информационной безопасности информационных систем как эффективное средство формирования профессиональных компетентностей бакалавров по дисциплине «Информационная безопасность» // Современные наукоемкие технологии. - 2016. - № 4-1. - С. 109-113.

2. Егорова Ю.Н., Мытников А.Н., Мытникова Е.А., Егорова О.А. Разработка системы управления информационными рисками // Информационные технологии, в экономике, образовании и в бизнесе: VIII материалы Международной научно-практической конференции. (16 декабря 2014 г.); отв. ред. А.А. Зарайский. - Саратов: Издательство ЦПМ «Академия бизнеса», 2014. - С. 40-45.

3. Желтов П.В., Димитриев А.П., Курябина Е.А. Взаимодействие процедур в современных системах управления производством // В книге: Динамика нелинейных дискретных электротехнических и электронных систем Материалы VIII Всероссийской научно-технической конференции. - 2009. - С. 86-87.

4. Иванов П.А., Мытников А.Н. Регулирование риска неправомерного доступа к компьютерной информации в распределенных автоматизированных системах при разработке инновационных проектов // Синергия Наук. - 2017. - № 8. - С. 376-384.

5. Фадеев С.Г. Жизненный цикл исходного кода программного обеспечения // Современные проблемы науки и образования. - 2014. -№ 6. - С. 175.

6. Фадеев С.Г. К вопросу о внесении изменений в сторонний исходный код // Вестник научных конференций. - 2015. - № 4-4 (4). - С. 149-150.

Размещено на Allbest.ru