Глава 5. СЕРВИСНОЕ ПРОГРАММИРОВАНИЕ
Эта парадигма программирования появилась как следствие рассмотрения программных компонентов, которые могут использоваться в качестве сервиса. Для них определены интерфейсы взаимодействия с разными программами и распределенными системами (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 ™.
Сервисы
Сервисы представляют собой особую организацию приложения. В отличие от activity они не требуют наличия визуального интерфейса. Сервисы позволяют выполнять долговременные задачи без вмешательства пользователя.
Все сервисы наследуются от класса Service и проходят следующие этапы жизненного цикла:
- Метод onCreate() : вызывается при создании сервиса
- Метод onStartCommand() : вызывается при получении сервисом команды, отправленной с помощью метода startService()
- Метод onBind() : вызывается при закреплении клиента за сервисом с помощью метода bindService()
- Метод onDestroy() : вызывается при завершении работы сервиса
Создадим простейшее приложение с сервисом. Наш сервис будет воспроизводить музыкальный файл. И вначале добавим в проект в каталог res папку raw . Для этого нажмем правой кнопкой мыши на каталог res и в контекстном меню выберем пункт New -> Android Resource Directory .
Далее укажем в качестве типа папки — raw :
И поместим в эту папку ( res/raw ) какой-нибудь mp3-файл.
Затем добавим новый класс сервиса. Назовем его MediaService . В итоге получится следующий проект:
Для воспроизведения аудио-файла определим в классе MediaService следующий код:
package com.example.soundserviceapp; import android.app.Service; import android.content.Intent; import android.media.MediaPlayer; import android.os.IBinder; public class MediaService extends Service < MediaPlayer ambientMediaPlayer; @Override public IBinder onBind(Intent intent) < throw new UnsupportedOperationException("Not yet implemented"); >@Override public void onCreate() < ambientMediaPlayer=MediaPlayer.create(this, R.raw.music); ambientMediaPlayer.setLooping(true); >@Override public int onStartCommand(Intent intent, int flags, int startId) < ambientMediaPlayer.start(); return START_STICKY; >@Override public void onDestroy() < ambientMediaPlayer.stop(); >>
Для воспроизведения музыкального файла сервис будет использовать компонент MediaPlayer .
В сервисе переопределяются все четыре метода жизненного цикла. Но по сути метод onBind() не имеет никакой реализации.
В методе onCreate() инициализируется медиа-проигрыватель с помощью музыкального ресурса, который добавлен в папку res/raw.
В методе onStartCommand() начинается воспроизведение.
Метод onStartCommand() может возвращать одно из значений, которое предполагает различное поведение в случае, если процесс сервиса был неожиданно завершен системой:
- START_STICKY : в этом случае сервис снова возвращается в запущенное состояние, как будто если бы снова был бы вызван метод onStartCommand() без передачи в этот метод объекта Intent
- START_REDELIVER_INTENT : в этом случае сервис снова возвращается в запущенное состояние, как будто если бы снова был бы вызван метод onStartCommand() с передачей в этот метод объекта Intent
- START_NOT_STICKY : сервис остается в остановленном положении
Метод onDestroy() завершает воспроизведение.
Чтобы управлять сервисом, изменим activity. Сначала добавим в файл activity_main.xml пару кнопок для управления сервисом:
И изменим код MainActivity :
package com.example.soundserviceapp; import androidx.appcompat.app.AppCompatActivity; import android.content.Intent; import android.os.Bundle; import android.view.View; public class MainActivity extends AppCompatActivity < @Override protected void onCreate(Bundle savedInstanceState) < super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); >public void click(View v) < Intent i=new Intent(this, MediaService.class); if (v.getId()==R.id.start) < startService(i); >else < stopService(i); >> >
Для запуска сервиса используется объект Intent:
Intent i=new Intent(this, MediaService.class);
Для запуска сервиса в классе Activity определен метод startService() , в который передается объект Intent. Этот метод будет посылать команду сервису и вызывать его метод onStartCommand() , а также указывать системе, что сервис должен продолжать работать до тех пор, пока не будет вызван метод stopService().
Метод stopService() также определен к классе Activity и принимает объект Intent. Он останавливает работу сервиса, вызывая его метод onDestroy()
И в конце нам надо зарегистрировать сервис в файле манифеста:
Регистрация сервиса производится в узле application с помощью добавления элемента . В нем определяется атрибут android:name , который хранит название класса сервиса. И кроме того может принимать еще ряд атрибутов:
- android:enabled : если имеет значение «true», то сервис может ли создаваться системой. Значение по умолчанию — «true».
- android:exported : указывает, могут ли компоненты других приложений обращаться к сервису. Если имеет значение «true», то могут, если имеет значение «false», то нет.
- android:icon : значок сервиса, представляет собой ссылку на ресурс drawable
- android:isolatedProcess : если имеет значение true, то сервис может быть запущен как специальный процесс, изолированный от остальной системы.
- android:label : название сервиса, которое отображается пользователю
- android:permission : набор разрешений, которые должно применять приложение для запуска сервиса
- android:process : название процесса, в котором запущен сервис. Как правило, имеет то же название, что и пакет приложения.
Запустим приложение и нажмем на кнопку запуска сервиса:
После этого начнется воспроизведение добавленной нами в приложение мелодии.
Учебники. Программирование для начинающих.
Programm.ws — это сайт, на котором вы можете почитать литературу по языкам программирования , а так-же посмотреть примеры работающих программ на С++, ассемблере, паскале и много другого..
Программирование — в обычном понимании, это процесс создания компьютерных программ.
В узком смысле (так называемое кодирование) под программированием понимается написание инструкций — программ — на конкретном языке программирования (часто по уже имеющемуся алгоритму — плану, методу решения поставленной задачи). Соответственно, люди, которые этим занимаются, называются программистами (на профессиональном жаргоне — кодерами), а те, кто разрабатывает алгоритмы — алгоритмистами, специалистами предметной области, математиками.
В более широком смысле под программированием понимают весь спектр деятельности, связанный с созданием и поддержанием в рабочем состоянии программ — программного обеспечения ЭВМ. Более точен современный термин — «программная инженерия» (также иначе «инженерия ПО»). Сюда входят анализ и постановка задачи, проектирование программы, построение алгоритмов, разработка структур данных, написание текстов программ, отладка и тестирование программы (испытания программы), документирование, настройка (конфигурирование), доработка и сопровождение.
Программирование на Ассемблере
Глава 9 ROM BIOS
Системный сервис
Два драйвера в BIOS дают самый простой системный сервис. Они предназначены для определения объема памяти ЭВМ и конфигурации внешних устройств.
Программа определения объема памяти не имеет параметров. BIOS возвращает в регистре AX объем памяти системы, измеренный в килобайтах (1024 байт). Если система имеет память 64K байт, в регистре AX возвратится число 64. Любая программа, использующая всю память системы, должна запрашивать у BIOS объем памяти, чтобы определить, где находится ее конец. Программа могла бы определить объем памяти, записав и прочитав подряд ячейки памяти, сравнивая записанное и прочитанное значение. Но, как покажет пример в следующей главе, важно писать все прикладные программы так, чтобы они использовали для определения объема памяти подпрограмму, возвращающую этот объем. Изменяя значение верхнего предела памяти, можно зарезервировать участок в верхних адресах памяти. После того, как программа изменит значение общего объема памяти, корректно написанная прикладная программа не нарушит границу памяти.
Программа проверки конфигурации внешних устройств не имеет входных параметров. Эта программа возвращает в регистре AX 16-битовый код, показывающий, какие устройства подключены к конкретной системе. В прологе распечатки этой программы в техническом руководстве по IBM PC указывается, что означает каждый бит. Эта функция BIOS — простейший способ определения, существует ли конкретное устройство в системе, или нет.
Последняя системная сервисная программа проверяет время суток. У этой программы есть две функции: чтение времени и установка времени. Время измеряется в квантах таймера, начиная с того момента, когда машина включается, и отсчитывается от полуночи. BIOS не преобразует это значение в часы, минуты и секунды. Но в листинге BIOS показаны нужные для преобразования константы. Чтобы определить время в часах, разделите 24-битовое значение таймера на 65543, число квантов таймера в часе. Чтобы определить минуты, разделите остаток от предыдущего деления на 1092, количество квантов в минуте, и так далее.
Если точность преобразования значения времени не очень критична для вас, можно воспользоваться более простым методом. Так как количество квантов, соответствующее 24 часам не помещается в одно слово, значение таймера представляется трехбайтовым целым числом. Значение старшего байта отличается не более, чем на 1% от времени в часах. Младшее слово можно разделить на 1092, чтобы определить число минут, а деление остатка на 18 дает число секунд.
Функция времени дня использует аппаратное прерывание, прерывание по кванту таймера. Это прерывание имеет уровень 0 в контроллере прерываний 8259, и имеет вектор прерывания 8 в микропроцессоре 8088. Эта программа получает управление каждые 55 миллисекунд. Основное назначение этой программы — увеличение счетчика квантов таймера программы времени дня. Если программа выключит прерывания на значительный промежуток времени, то весьма вероятно, что время суток перестанет быть правильным.
Прерывание от таймера используется также программой обслуживания дисковода. Двигатели дисковода включены не постоянно; BIOS включает двигатели только на время доступа к дискете. Но BIOS не выключает двигатель сразу же после выполнения операции. Есть некоторый интервал времени между включением двигателя и тем моментом, когда он разгонится и будет вращаться достаточно быстро, для того, чтобы можно было читать данные. Если программа обращается к дисководу почти сразу после предыдущего обращения, лучше оставить двигатель включенным, а не выключать и включать его. Программа обработки аппаратного прерывания от таймера учитывает это. Обработчик дискового прерывания загружает число в переменную, которая называется MOTOR_COUNT, когда завершается операция обмена с дискетой. Прерывание от таймера уменьшает значение этого счетчика. Когда значение переменной MOTOR_COUNT достигает 0, выключается двигатель дисковода. Программа обслуживания дисковода проверяет этот счетчик, перед обращением к дискете. Если двигатель еще не включен, нужна задержка, пока двигатель не разгонится. Обычно двигатель дисковода продолжает работать две секунды после завершения предыдущей операции. Это время — один из параметров дисковода, и вы можете изменить его значение. Выбор этого значения поддерживает баланс между повышением производительности и снижением износа поверхности дискеты.
Все эти три сервисные программы BIOS передают числа из ячеек памяти в вызывающую программу. Можно избежать использования BIOS путем непосредственного чтения этих ячеек. Но зачастую проще вызвать BIOS, чем организовывать адресацию к сегменту DATA используемому в BIOS. С «наивной» точки зрения, проще использовать программу BIOS.
Что такое сервис-ориентированная архитектура (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 и микросервисами уже сегодня.