Что такое сервис в программировании

СЕРВИСНОЕ ПРОГРАММИРОВАНИЕ

Эта парадигма программирования появилась как следствие рассмотрения программных компонентов, которые могут использоваться в качестве сервиса. Для них определены интерфейсы взаимодействия с разными программами и распределенными системами (CORBA, DCOM и EJB, MS.Net, IBM и тому подобное) и с веб-сервисами Интернета. В настоящее время действуют сервисноориентированная архитектура SOA (Service-Oriented Architecture), средства их поддержки (XML, SOAP, WSDL и др.) и механизмы взаимодействия обычных сервисов распределенных приложений и веб-сервисов Интернет [36-38].

Сервис. Базовые понятия

Веб-ссрвис — программа, которая идентифицируется строкой URI, свойства и методы которой описаны с помощью специального языка WSDL. Доступ к ресурсам такой системы осуществляется через протокол SOAP, который представляется XML-заиросами, которые передаются через HTTP Интернет-протокола.

Веб-сервисы близкие классам объектно-ориентированных ЯП (JAVA ЕЕ). Ключевые понятие веб-сервиса — это сообщение из одной или нескольких переменных. Методы классов задаются операциями с входным и выходным значениями сообщений. После вызова операции переменной входного сообщения протокола SOAP, интерпретируются как параметры соответствующего метода класса, который лежит в основе сервиса [96].

Сервис определяется, с одной стороны, как открытый компонент, который может быть элементом быстрой композиции в прикладные приложения. С другой стороны, сервис предлагается как готовый ресурс, который реализует некоторые дополнительные возможности, необходимые всем разнородным программам для технической поддержки, нужной потенциальным пользователям. Как правило, описания сервисов содержат в себе информацию об их возможностях, интерфейсах, поведении и характеристиках. Благодаря такому описанию пользователь может найти сервисы, выбрать нужные и интегрировать их в композиционную структуру, как готовый ресурс (http://www.w3.org/Submission/wsml).

Рассматривается три вида сервисов:

1) общие системные сервисы, которые есть в каждой общесистемной среде для поддержки процессов проектирования и реализации РПС на основе сформулированных моделей ПС, ПС и РПС;
2) объекгные сервисы, которые поддерживают объекты и классы, операции ЖЦ, услуги необходимы для разработки РПС в объектно-ориентированной среде;
3) веб-сервисы, которые базируются на информационных ресурсах Интернет и обеспечивают создание элементов РПС путем композиции или интеграции КПИ и сервисов, способных к функционированию в вебе Всемерной паутины.

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

1. Наименование Naming, которое обеспечивает возможность поиска компонентов в распределенной среде с учетом пространства имен.
2. Связи Binding предназначены для определения (связи) соответствия имя- объект и применяемая к выбранным компонентам.
3. Транзакций Transaction, который обеспечивает организацию и управление функционированием совокупности компонентов и функций сервисов.
4. Сообщения Messaging, необходимые для организации общения между компонентами, являются составным элементом в модели асинхронных транзакций.

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

1) поиск компонентов;
2) доступ к их ресурсам;
3) организация обмена информацией между компонентами;
4) динамическое управление функционированием, обусловленным совокупностью КПИ в РИС.

Модель сервисов РПС базируется на унификации и совместимости, что позволяет рассматривать РПС как набор сервисов, их функциональность и взаимодействие.

Унификация сервисов достигается путем:

1) типизации функциональности сервисов и других характеристик;
2) применения унифицированных языков для описания сервисов и их взаимодействия;
3) использование стандартных базовых технологий.

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

Средством описания механизма взаимодействия с сервисами является SOAP, а для описания функциональности сервисов — язык WSDL. Описание функциональности сервисов выполняется унифицированными языками XML, WSDL; описание структуры и семантики данных выполняется языком RDF; описание процессов представления и обработки сервисов языком BPMN, а взаимодействие с сервисами и поиска необходимых сервисов — SOAP.

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

Модель сервиса обеспечивает:

1) динамическое расширение функциональности системы за счет поиска и привлечения в сферу обработки новых сервисов;
2) повышение масштаба и улучшение возможностей коммуникации между отдельными элементами системы за счет стандартного механизма подключения сервисов через их интерфейсы;
3) повышение языкового уровня коммуникации системы с конечными пользователями.

Принципы разработки систем из готовых программных и информационных ресурсов (компонентов, сервисов, интерфейсов, данных, артефактов и т. п.) такие:

1) композиционность сложных систем типа РПС из компонентов, интерфейсов и сервисов с их свойствами, характеристиками и механизмами агрегации в более сложные структуры и правилами взаимодействия в интегрированных средах;
2) компонентность инженерии (CBSE), как деятельности создания РПС из готовых «деталей», базированная на реально существующих положениях инженерии продуктов, а именно, стандартизирован ЖЦ гребований, эксплуатации и уничтожения КПИ или СПС с использованием систем классификации и каталогизации КПИ, средств унификации, стандартизации описания КИИ и интеграции их в ПС и СПС;
3) интероперабельность КГ1 и элементов ПС, которая базирована на интерфейсах и правилах взаимодействия компонентов между собой для обеспечения интеграции и функционирования в разных гетерогенных средах;
4) вариантность как способность КПИ и компонентных ПС к изменениям путем уничтожения некоторых функциональных, незавершенных или добавления новых функциональных КПИ в конфигурационную структуру СПС, или ПС и т. п.

Сервис Интернета — это ресурс, который реализует некоторые функции (в том числе бизнес-функции), является КПИ и содержит в себе технологически независимый интерфейс с другими ресурсами. Например, сервисы транзакций, именования, безопасности в модели CORBA. Они образуют службу сервисов для создания ПС.

Основная форма реализации сервисов — это веб-сервисы, которые сохраняются и идентифицируются URL-адресами и взаимодействуют между собой посредством сети Интернета, например, RPC (Remote Procedure Call). Стремительное использование Интернета привело к тому, что традиционное интегрированное предприятие прошлых поколений все чаще замещается сетью бизнеса, которые совместно выполняют определенные функции при том, что и собственность, и менеджмент распределены между партнерами. Именно информационные потребности распределенных бизнесов вызвали к жизни веб-сервисы как адекватную форму компонентов типа КПИ.

Веб-сервис имеет URL-адрес, интерфейс и механизм взаимодействия с другим сервисом через протоколы Интернет или связки с другими программами, БД и деловыми бизнес-операциями. Обмен данными между веб-сервисом и программой осуществляется с помощью XML-документов, оформленных в виде сообщений. Веб-сервисы обеспечивают решение задачи интеграции приложе- ний разной природы, являясь при этом инструментом построения распределенных систем. Веб-сервис предоставляется провайдером сети Интернет, который имеет стандартный способ взаимодействия с распределенными (.NET, J2EE, CORBA и др.) и прикладными системами для получения некоторых услуг.

Основные средства описания и разработки новых систем средствами вебсервисов:

1) язык XML для описания и построения SOA-архитектуры;
2) язык WSDL (Web Services Description Language) для описания вебсервисов и их интерфейсов в XML, а также типов данных и сообщений, моделей взаимодействия и протоколов связи сервисов между собой;
3) SOAP (Simple Object Access Protocol) для определения форматов запросов к веб-сервисам;
4) SCA (Servise-Component Architecture) для создания более сложной системы на основе компонентов и сервисов;
5) UDDI (Universal Description, Discovery and Integration) для универсального описания, выявления и интеграции сервисов, обеспечения их хранения, упорядочения деловой сервисной информации в специальном реестре с указателями на конкретные интерфейсы веб-сервисов.

К средствам моделирования сложных систем и СПС относится система IBM ® WebSphere ® Integration Developer. Она предоставляет сервис-ориентированную архитектуру SOA (Servise Oriented Architecture), компонентну архитектуру сервисов SCA (Servise-Component Architecture) на основе вариантов использования UML. Эта система предлагает интеграцию сервисов SCA через модель интерфейсов JAVA, которая задается в WSDL, а реализация — классы JAVA ™.

Сервисы, микросервисы и пакетно-ориентированное программирование

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

Опытные программисты обычно имеют свои правила, соблюдая которые, понимают, следует ли выделять код в повторно используемый. Например, если такой(или сильно похожий) код используется в трех местах или более. Тем не менее, все, с кем мне довелось говорить на этот счет, соглашаются с тем, что такой повторно используемый код должен существовать, его создание является благом, и на это стоит тратить свое время.

Хочу поднять тему повторного использования кода в контексте создания сервис-ориентированной и микросервисной архитектуры.

Что есть повторно используемый код

Повторно используемый код — это код, выделенный в отдельную сущность, называемую в разных языках по разному — библиотека, пакет, зависимость и т.д. Обычно такой код хранится в отдельном репозитории, и имеется документация по подключению и использованию этого кода(README.md). Дополнительно, код может быть покрыт тестами, может иметься инструкция по внесению изменений(CONTRIBUTING.md) и может быть настроен CI. Различные бейджи, прикрепленные к описанию, только улучшают визуальное представление зрелости данной сущности, а количество поставленных звезд скажет о популярности данного решения. За примерами далеко ходить не надо — достаточно открыть страницу github любого из популярных фреймворков на любимом вами языке, например vue.js. В общем, способов качественного оформления библиотек вагон и маленькая тележка.

Сервисы и микросервисы

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

Сервис-ориентированная архитектура предполагает, что каждый сервис минимально связан с другими. Тем не менее, межсервисное взаимодействие не исключено, а только предполагается, что оно должно быть сведено к минимуму. Для приема запросов в сервисе обычно реализуется какое-либо стандартизированное API. Это может быть что угодно — REST, SOAP, JSONRPC или новомодный GraphQL.

Условно, сервисы можно разделить на инфраструктурные и продуктовые. Продуктовые сервисы — это те, которые реализуют логику какого-либо клиентского продукта. Например, работают с заявками на его подключение, или организуют сопровождение этого продукта на всем жизненном цикле работы с ним клиента. Инфраструктурные сервисы — это больше про базовый функционал компании(или проекта), например сервис, содержащий клиентскую информацию, или сервис, хранящий информацию о тех или иных заказах. Также к инфраструктурным можно отнести сервисы, реализующие вспомогательный функционал, например сервис информирования клиентов (отправка push-сообщений или СМСок) или сервис взаимодействия с dadata.

Чуточку пофантазируем

Допустим, существует гипотетический интернет-магазин, построенный по сервис-ориентированной архитектуре. Разработчики этого чуда инженерной мысли смогли договориться между собой и пришли к выводу, что в качестве API все их сервисы будут работать, например, по jsonrpc-протоколу. Однако, поскольку интернет-магазин большой, он не стоит на месте и активно развивается, то групп разработки там несколько, пусть будет больше двух — две проектные, одна по сопровождению уже написанного. Также, для пущего эффекта, все команды пишут на одном стеке.

Архитектура гипотетического интернет-магазина:

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

Сервис клиентской информации хранит информацию о клиентах, умеет их заводить, авторизовывать, выдавать о них необходимую информацию.

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

Сервис заказов оперирует заказами. Тут находится логика формирования заказа, его подтверждения, выбора типа оплаты и адреса доставки и т.д.

Сервис информирования клиентов умеет отправлять PUSH/SMS/email-сообщения. Тип коммуникации, допустим, зависит от настроек конкретного клиента, также клиент может настроить желаемое время получения уведомлений.

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

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

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

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

В контексте предложенной архитектуры сразу становится ясно, что для быстрой продуктовой разработки крайне необходимы готовые библиотеки. Так, важно иметь готовую реализацию jsonrpc-сервера, а также клиента к нему, поскольку это основной протокол организации межсервисного взаимодействия. Также в данном примере во весь рост встает вопрос документирования API. Очевидно, для формирования документации у команд также должен быть готовый инструмент. Если предположить, что еще есть готовый инструмент и для генерирования smd-схем для jsonrpc-серверов, то скорость разработки новых сервисов может еще больше вырасти. В итоге, внутри компании, в идеале, должен быть набор готовых библиотек, которыми пользуются все команды для выполнения типовых задач. Эти библиотеки могут быть как собственные, так и open-source’ные, главное, чтобы хорошо выполняли свои задачи. Очевидно, что команда, которая находится в общем стеке и пишет сервисы используя готовые библиотеки, будет более эффективная, нежели команда, которая постоянно велосипедит. Наличие единого фреймворка и единой базы библиотек, которые используются во всех проектных командах, я называю единой экосистемой.

А как обстоят дела в крупных компаниях?

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

Так уж вышло, что у меня есть опыт работы в компании, в которой трудятся около 200 разработчиков, пишущих на различных языках — java, c#, php, python, go, js и др. Удивительно, но общую экосистему, в контексте единого стека, имеют и используют далеко не все команды разработчиков. Казалось бы, очевидная вещь — готовить повторно используемый код, оформлять его должным образом и использовать — далеко не очевидная. Конечно, команды разработчиков решают свои задачи. Кто-то использует шаблон сервиса — набор кода, составляющее ядро их каждого нового сервиса, из которого выкидывается все ненужное и дописывается нужное.

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

Преимущества единой экосистемы

Формирование единой экосистемы позволяет решить множество сложностей, и имеет огромный потенциал повышения производительности для большой компании. Фактически, эта практика взята из Open Source сообщества — выживают и наиболее популярны лучшие решения в своей области. Сейчас достаточно открыть любой менеджер зависимостей и только удивиться обилию предлагаемых решений. А ведь именно такой подход можно реализовать и внутри компании. Преимущества же такого подхода при реализации нового сервиса следующие:

Высокая стабильность — использование покрытых тестами, хорошо документированных библиотек повышает и стабильность сервиса в целом;
Легкая ротация коллег между командами — если все команды находятся внутри единой экосистемы, то при переходе из одной команды в другую разработчик не придется тратить много времени на знакомство с используемыми инструментами, ведь он уже с ними знаком;
Концентрация на бизнес–логике — действительно, разработка нового сервиса сводится к тому, что надо подтянуть необходимые зависимости, решающие все инфраструктурные задачи, и написать только бизнес-логику;
Ускорение разработки — нет необходимости велосипедить, готово все, кроме бизнес-логики;
Упрощение тестирования — тестировать нужно только бизнес-логику, ведь библиотеки уже протестированы;

Ложка дёгтя

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

PS

А пакетно-ориентированный подход — только лишь потому, что повторно используемый код на моем стеке называется пакетом. Ну и смешно это звучит. Недавно с одним из коллег у меня состоялся такой диалог, побудивший на написание данной статьи:

— Коллега: ты превращаешься в кассира в пятерочке
— я: всмысле?)
— Коллега: скоро будешь спрашивать «пакет надо?»
— я: раскрой пожалуйста мысль. я не понимаю
— Коллега: ну уже в который раз у тебя есть готовый пакет для решения моей задачи

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

Что такое сервис-ориентированная архитектура (SOA)?

Сервис-ориентированная архитектура (SOA) – это метод разработки программного обеспечения, который использует программные компоненты, называемые сервисами, для создания бизнес-приложений. Каждый сервис предоставляет бизнес-возможности, и сервисы также могут взаимодействовать друг с другом на разных платформах и языках. Разработчики применяют SOA для многократного использования сервисов в различных системах или объединения нескольких независимых сервисов для выполнения сложных задач.

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

Каковы преимущества сервис-ориентированной архитектуры?

Сервис-ориентированная архитектура (SOA) имеет ряд преимуществ перед традиционными монолитными архитектурами, в которых все процессы выполняются как единое целое. Вот некоторые из преимуществ SOA:

Сокращение времени выхода на рынок

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

Эффективное обслуживание

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

Улучшенная адаптивность

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

Какие основные принципы сервис-ориентированной архитектуры?

Не существует четко определенных стандартных рекомендаций по реализации сервис-ориентированной архитектуры (SOA), однако есть некоторые общие основные принципы.

Обеспечение совместимости

Каждый сервис в SOA включает документы описания, которые определяют функциональность сервиса и связанные с ним условия. Любая клиентская система может запустить сервис, независимо от базовой платформы или языка программирования. Например, бизнес-процессы могут использовать сервисы, написанные как на C#, так и на Python. Поскольку нет прямых взаимодействий, изменения в одном сервисе не влияют на другие компоненты, использующие этот сервис.

Слабая взаимозависимость

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

Абстрагирование

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

Степень детализации

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

Из каких компонентов состоит сервис-ориентированная архитектура?

Существует четыре основные компонента сервис-ориентированной архитектуры.

Обслуживание

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

Реализация сервиса
Реализация сервиса – это код, который создает логику для выполнения конкретной функции сервиса, например аутентификации пользователя или вычисления счета.

Контракт на обслуживание сервиса

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

Интерфейс сервиса

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

Поставщик сервиса

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

Потребитель сервиса

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

Сервисный реестр

Реестр сервисов (или хранилище сервисов) – это доступный в сети каталог доступных сервисов. В нем хранятся документы описания сервисов от поставщиков. Документы описания содержат информацию о сервисе и о том, как с ним работать. Потребители сервисов могут легко обнаружить необходимые им сервисы, используя реестр.

Как работает сервис-ориентированная архитектура?

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

Протоколы передачи данных

Сервисы взаимодействуют с использованием установленных правил, определяющих передачу данных по сети. Эти правила называются протоколами передачи данных. Некоторые стандартные протоколы для реализации SOA:

• Простой протокол доступа к объектам (SOAP)
• RESTful HTTP
• Apache Thrift
• Apache ActiveMQ
• Служба сообщений Java (JMS)

Вы даже можете использовать более одного протокола в своей реализации SOA.

Что такое ESB в сервис-ориентированной архитектуре?

Линейка корпоративных сервисов (ESB) – это программное обеспечение, которое можно использовать при взаимодействии с системой, имеющей множество сервисов. Он устанавливает связь между сервисами и потребителями сервисов независимо от технологии.

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

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

Каковы ограничения при внедрении сервис-ориентированной архитектуры?

Ограниченные возможности масштабирования

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

Усиление взаимозависимости

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

Единая точка отказа

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

Что такое микросервисы?

Архитектура микросервисов состоит из очень маленьких и полностью независимых программных компонентов, называемых микросервисами, которые специализируются и фокусируются только на одной задаче. Микросервисы взаимодействуют через API, которые представляют собой правила, создаваемые разработчиками, чтобы позволить другим программным системам взаимодействовать с их микросервисом.

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

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

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

Сравнение SOA с микросервисами

Архитектура микросервисов – это эволюция архитектурного стиля SOA. Микросервисы устраняют недостатки SOA и делают программное обеспечение более совместимым с современными облачными корпоративными средами. Они являются легко управляемыми и благоприятствуют дублированию данных в противовес обмену данными. Это делает их полностью независимыми с собственными протоколами связи, которые открываются через облегченные API. По сути потребители должны использовать микросервис через его API, что устраняет необходимость в централизованном ESB.

Как AWS поможет вам реализовать микросервисы?

AWS – это отличное место для создания современных приложений с использованием модульных архитектурных моделей, бессерверных операционных моделей и гибких процессов разработки. Мы предлагаем наиболее полную платформу для создания высокодоступных микросервисов для обеспечения работы современных приложений любого масштаба и объема. Например, вы можете выполнять следующие действия:

• Создавать, изолировать и запускать безопасные микросервисы в управляемых контейнерах для упрощения операций и снижения накладных расходов на управление.
• Использовать AWS Lambda для запуска ваших микросервисов без инициализации и управления серверами.
• Выбирать из 15 реляционных и нереляционных баз данных AWS, специально созданных для поддержки архитектуры микросервисов.
• Легко отслеживать и контролировать микросервисы, работающие на AWS, с помощью AWS App Mesh.
• Отслеживать и устранять неполадки сложных взаимодействий микросервисов с AWS X-Ray.

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

Когда лучше всего использовать классы «Сервисы», а когда логику лучше помещать в сам класс?

Как правило, классы сервисы- это таке классы, которые не имеют состояния. Т.е передаешь им что-то, а в ответ они тебе выплевывают чего-то. Так вот, я часто вижу то, что какие-то методы можно было поместить в класс рядом с данными, а не выносить это в отдельный сервис. Так вот, когда это оправдано? Например, сейчас я наблюдаю сервис, который возвращает некий сложный объект. Что бы получить какие-то интересующие себя данные, без ручных итераций по внутренним коллекциям, я должен передать конкрутному методу сервиса этот объект и на это он вернет мне результат. Хотя. по моему, что мешает этот метод дать конкретному экземпляру? Единственный, наверное, + — это отделить данные от реализации и как следствие, можно не возиться с наследованием.

Отслеживать
задан 30 апр 2020 в 9:30
24.8k 12 12 золотых знаков 64 64 серебряных знака 163 163 бронзовых знака
В тегах стоит любой-язык , но такое ощущение, что это вопрос про «безнес-логику» на java / c#.
12 мая 2020 в 12:40

7 ответов 7

Сортировка: Сброс на вариант по умолчанию

Service – это Java класс, который предоставляет с себя основную (Бизнес-Логику). В основном сервис использует готовые DAO/Repositories или же другие сервисы, для того чтобы предоставить конечные данные для пользовательского интерфейса.

Как гласит Принцип единственной ответственности (Single Responsibility Principle):

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

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

Отслеживать
ответ дан 6 мая 2020 в 17:32
1,002 1 1 золотой знак 8 8 серебряных знаков 24 24 бронзовых знака

Такой подход используется в принципе единой ответственности. Например, у нас есть объект письма Message , и мы хотим его отправить. Можно реализовать метод send() в самом письме, а можно написать сервис MailService с методом send(Message msg) . Первый случай с точки зрения SOLID будет не верным, так как письмо не может отправить само себя, для этого есть служба (мы просим службу отправить письмо, а служба уже займется доставкой согласно каким-то своим внутренним правилам).

Отслеживать
ответ дан 6 мая 2020 в 13:38
Ivan Dudarev Ivan Dudarev
1,456 1 1 золотой знак 8 8 серебряных знаков 18 18 бронзовых знаков

Здесь очень много примеров, но я постараюсь разобрать некоторые из них:

Интерфейсы (и классы их реализующие)

Да-да-да, я знаю, что «интерфейс вообще» это не «класс вообще» (привет С++), но в чём разница м-ду абстрактным классом и интерфейсом? Абстрактный класс может содержать поля, т. е. состояние, а интерфейс (по крайней мере «чистый») – только поведение (его декларацию, которую потом реализует класс. реализатор?).

public interface ISomeInterface < int someField; // compile error void DoSmth(); // no error >

XXX-Helpers/Services

Классы вида SomeHelpers или SomeServices . Тут ничего лишнего:

public static class SomeServices < public static void Check(this SomeEnum @enum) < const SomeEnum maxEnum = SomeEnum.SomeMaxValue; if (@enum < 0 || @enum >maxEnum) throw /*. */; > >

Разве что добавлю по поводу разницы м-ду их именами, как её вижу я: SomeHelpers — internal class , SomeServices — public class . Опять же, могут быть исключения, но я их встречал несколько раз, например:

public static class DoubleHelpers < public static int Compare(double a, double b); public static bool IsZero(double value); // . >

ISomeFactory

public interface ISomeFactory < ISomeClass CreateSomeClass(/*some args*/); >

ISomeProvider

public interface ISomeProvider < ISomeClass GetObject(/*some args*/); // or ISomeClass ProvideObject(/*some args*/); >

Тут от экземпляра класса SomeObject . Здесь ISomeProvider может быть IServiceProvider , а ISomeObject – ISomeService . Теперь провайдер может возвращать не только объекты, но и сервисы. Ну или даже так:

public interface IFooProvider < IBarProvider GetProvider(); >public interface IBarProvider < IBazProvier GetProvider(); >// . // .

Формальные «сервисы»

Если мы хотим назвать класс, например, как «служба доставки», то мы его назовём как DeliveryService . Здесь «сервис» формальный – это нужно иметь ввиду.

Сами по себе сервисы «бесплодны» и могут нести роль:

Реализуемого контейнера деклараций методов
Не наследуемого контейнера реализаций методов
Получателя других объектов (или даже сервисов или других провайдеров)

Например, сейчас я наблюдаю сервис, который возвращает некий сложный объект.

Вы наблюдаете сервис, реализующий интерфейс провайдера.

Пару слов о самих провайдерах. Провайдер, как сперва может показаться, это фабрика, но не совсем. Провайдер отличается от фабрики тем, что объект типа CreateByFactory можно создать только через фабрику, а объект типа ProvideByProvider вы можете предоставить, т. е. не только создавать, но и, например, возвращать из кэша, а так же, что самое главное, объект типа ProvideByProvider обязан мочь быть воссозданным без использования провайдеров. Это важно если не хотите недопонимания и открытой ошибки в коде. Ещё раз, фабрика создаёт и не может быть кастомной, провайдер предоставляет и может быть кастомным.

Вообще, сервисы целенаправленно и зачастую используются в данных случаях (первое, что мне в голову пришло). Нет смысла просто так брать и создавать класс-сервис, чтоб «полей не было». Например, класс RandomHelpers :

public static class RandomHelpers

Здесь статический для потоков random — отличный инструмент рефакторинга, позволяющий 1 строчкой не писать код с синхронизацией и, тем самым, оптимизировать run-time, хотя мы и немного (я б сказал вообще не) просели в памяти. И вроде статический класс-сервис, но со состоянием. Серьёзно? Эти (в худшем реальном случае, наверно, за историю) съедят 100 байт, не больше. Не нужно экономить, если не просят. Так же стоит сказать, что сервис зачастую – это просто классификация (мол, все классы «без полей» — сервисы).

 +-------------------+---------------+ | Абстракция | Реализация | +----------------+-------------------+---------------+ | Есть состояние | Абстрактный класс | Обычный класс | +----------------+-------------------+---------------+ | Нет состояния | Интерфейс | Класс-сервис | +----------------+-------------------+---------------+

Отслеживать
ответ дан 6 мая 2020 в 18:50
2,730 1 1 золотой знак 12 12 серебряных знаков 30 30 бронзовых знаков

Понятие сервис несколько противоречиво в мире ООП, поэтому с ним и возникают такие сложности.

В учебнике C++ Бьярна Страуструпа написано, что ООП держится на трёх китах, один из которых это инкапсуляция. Данные и методы надо держать вместе.

Общее правило такого: если методу нужны данные из класса, поместите этот метод прямо в класс.

И этот подход работает хорошо до тех пор, пока методу нужны данные одного класса. А если двух?

На этот вопрос нет общего ответа. Иногда новый код размещают в первом классе, иногда во втором, а иногда — в новом третьем классе.

При принятии решения играют роль вот какие факторы:

Согласованность. Удобно, если в каждом случае вы принимаете похожие архитектурные решения. Программистам, которые работают над кодом, проще будет его понимать, если в коде прослеживаются закономерности. Если вы решите размещать код в каком-то из двух (трёх, пяти) классов, как это повлияет на остальной код. Не придётся ли вам в других местах вносить правки, чтобы решение оставалось согласованным.
Краткость. У начинающих архитекторов есть проблема с простыми решениями. Они могут придумать что-то такое, что заставит всю команду писать десятки «лишних» строк кода. Иногда эту штуку называют monkey code, иногда boilerplate. Как его не называй, но это хороший индикатор, что решение не самое хорошее.
Солидность. Обычно стоит прогнать решение на соответствие принципам SOLID. Метод может быть лишним в классе и нарушать Single Responsibility. Или он потребует постоянного дописывания уже готового кода, что нарушит принцип Open/Closed.

В общем и целом, когда стоит создавать службу и выносить методы туда? Когда речь идёт о процедуре или бизнес-процессе. Скажем, заказ проходит по стадиям (создан, сформирован, оплачен, собран, отправлен, доставлен). Конечно, у заказа есть его состояние, которое должно быть инкапсулировано внутри класса Заказ .

Но на каждом этапе нужно проводить большое количество проверок с объектами, которые не являются частью заказа: описания товаров, остатки на складе, промо-акции, скидки и многое другое. Всё это удобно вынести в отдельную службу, откуда и вызывать в нужный момент метод изменения состояния заказа.

Про вас случай трудно сказать, не видя кода, и не зная архитектурных ценностей, которые положены в основу проекта. Прежде, чем переносить метод в класс, я бы посмотрел на размер класса. В языках типа Java/C#/C++ размер в 300-400 строк, это мой личный максимум. Ничем не подтвержу и случаи разные бывают, тут всё субъективно.

Второе, я бы посмотрел на другие классы-сущности, которые нужны в работе метода (в параметрах, в коде, в выходном значении). Нормально, если там либо примитивные типы, либо классы, которые называют объекты-значения. Точки из координат x и y , цвета из компонентов red , green , blue . Если же там полноценные сущности, то, пожалуй, стоит оставить метод в службе.