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

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

Что такое сервисная архитектура?

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

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

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

В сервисной архитектуре есть несколько важных компонентов, в том числе:

Интерфейс приложения

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

Услуги

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

В SOA есть два основных вида сервисов:

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

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

Безопасность

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

Слой процесса

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

Управление

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

Мониторинг деловой активности

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

Оценка оперативных данных

Оценка операционных данных (ODS) может предлагать просмотр нескольких услуг в режиме реального времени. Использование ODS может отделить уровни доступа от пользовательских интерфейсов, позволяя перемещать услуги между поставщиками. ODS может быть особенно полезен в сервисной архитектуре, потому что он устраняет необходимость извлечения данных, таких как списки клиентов или продуктов, из отдельных серверных сервисов.

Заинтересованные стороны

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

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

Как правило, сервисная архитектура использует веб-сервисы для обеспечения ценности для своих пользователей. Это делает его доступным для использования в различных приложениях и отраслях. Вот несколько примеров использования сервисной архитектуры:

• Розничные продавцы. Розничные продавцы могут использовать программы SOA для отслеживания своих запасов, регулирования процессов доставки и управления клиентами.

• Электроэнергетические компании. Электроэнергетические компании могут использовать сервисную архитектуру для интеграции своих систем и оптимизации своих процессов для повышения эффективности.

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

• Здравоохранение: SOA может помочь поставщикам медицинских услуг управлять данными о пациентах для своих многочисленных участников, таких как представители службы поддержки клиентов, страховые компании, кабинеты врачей и пользователи веб-сайтов. Сервисная архитектура позволяет провайдерам хранить данные в одном и том же источнике, управляя доступом через несколько приложений.

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