ВОПРОС

Библиотека сервис-ориентированной архитектуры ( SOALIB ) используется для распространения повторно используемого программного обеспечения сервис-ориентированной архитектуры (SOA). ^{[ 1 ]}^{[ 2 ]} аналогично другим вычислительным библиотекам . SOA состоит из слабосвязанных взаимодействующих сервисов, которые используют обмен сообщениями на основе протокола простого доступа к объектам (SOAP) и передачи репрезентативного состояния (REST). Библиотека в вычислительной технике — это набор скомпилированных модулей, протестированных и готовых к повторному использованию. Аналогичная концепция используется для SOA: любая технология, используемая для разработки службы, также может распространяться в виде библиотеки. Библиотека SOA на основе Java может распространяться в форматах файлов Web ARchive (WAR) или Enterprise Archive (EAR). Приложения C , C++ и .NET могут распространяться как общий объект (в Unix и Linux ), динамически подключаемая библиотека (в Windows) или как исполняемый файл.

История

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

Создавая библиотеки сервис-ориентированной архитектуры, каждая из которых представляет собой слабосвязанный сервис, можно разрабатывать сложные приложения с использованием этих сервисов. Поскольку новые приложения зависят от всех слабосвязанных сервисов, пока один из них придерживается слабой связи, конечное приложение также будет слабосвязанным. Хотя конечное приложение действительно зависит от множества иерархических слабосвязанных систем, оно остается слабосвязанным, поскольку вся иерархия основана на атомарных сервисах.

Цели

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

Шаги

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

Независимость от платформы

учитывать возможность кроссплатформенности Важно . В настоящее время существует множество способов сделать платформу хоста служб независимой от платформы. Примерами являются создание сервисов на Java, где JVM доступна для хоста, на котором сервер будет работать как сервис. Альтернативой является создание приложений с полным соответствием ANSI C/C++, чтобы ни один из компонентов кода не зависел от сторонних библиотек. Обычно это означает создание приложений C/C++ с использованием инструментов GNU и компиляторов GNU C, поскольку компиляторы GNU портированы на большинство операционных систем и платформ. Другой альтернативой является использование C# .NET в качестве языка веб-службы, в которой используется среда Common Language Runtime. ^{[ 3 ]} портируется на целевую операционную систему и платформу. Доступно множество других вариантов, но наиболее распространенные подходы к независимости от платформы уже упомянуты.

Шаги

Полная независимость от платформы, насколько это возможно.
Автоматические тесты на каждой платформе.

Мультивендорная база данных

Область применения библиотеки ограничена, если она не поддерживает базы данных. Составные и интеграционные сервисы должны создаваться так, чтобы использовать преимущества слабосвязанных атомарных сервисов, работающих с базами данных. После добавления поддержки доступа к базе данных необходимо добавить уровень метаданных , чтобы сопоставить различные типы форматов данных в базе данных с единым набором типов данных, которые будут иметь одинаковое значение для всех баз данных. Это самая сложная часть, но на данный момент JDBC , ^{[ 4 ]} ODBC , ADO и другие стандартные драйверы баз данных уже выполняют часть задачи. Каждая база данных может хранить данные в разных форматах. Некоторые данные могут быть зашифрованы, некоторые могут храниться с прямым порядком байтов , другие — с прямым порядком байтов и так далее. Следовательно, данные в какой-то момент должны быть преобразованы службами, и это должно быть сделано во время выполнения из-за меняющегося характера данных. Все базы данных разные, поэтому ни один API не может использовать все возможности всех баз данных. Следовательно, службы также должны использовать специфические функции базы данных.

Шаги

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

Синхронизация данных

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

Шаги

Синхронизация «любой к любому».
Изменить механизм захвата.
Одно- и двунаправленная синхронизация данных.
Пользовательское сопоставление с ссылочной целостностью.
Гетерогенная синхронизация.

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

Все библиотеки должны быть безопасными. Если библиотеки имеют реализацию SOA в виде веб-сервисов, то они должны иметь WS-Security , ^{[ 5 ]} WS-Политика ^{[ 6 ]} и соответствие другим стандартам типа WS. Если он основан на REST или других протоколах, он должен соответствовать соответствующим стандартам. Все библиотеки должны как минимум поддерживать SSL .

Шаги

Поддержка всех основных архитектур безопасности, основанных на стандартах.
Поддержка Secure Socket Layer.
Вариант зашифрованного хранения на сервере.

Совместимость

Функциональная совместимость — одна из наиболее важных причин, почему SOA так важна. Библиотека SOA также должна включать необходимый API, который можно использовать для быстрой разработки для конкретной платформы.

Шаги

Поддержка всех основных языков программирования: Java , Java ME , C , C++ , C#.NET , ^{[ 7 ]} VB.NET. , ^{[ 8 ]} PHP ^{[ 9 ]}
Поставляется со всеми необходимыми клиентскими API.
Все API должны быть протестированы на соответствие службам SOA привязки.

Создание приложений атом за атомом

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

Общие рекомендации

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

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

Ниже представлена иерархия, в которой должны разрабатываться все сервис-ориентированные приложения.

Иерархия

В идеале подход к проектированию приложений SOA должен быть следующим:

Интегрированные услуги — на основе составных и атомарных сервисов.
- Составные службы — основаны только на атомарных службах.
  - Атомные службы — нет зависимости, эта служба — атом.

Структуры, которых следует избегать

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

См. также

Ссылки

^ Архив документов (14 января 2009 г.). «Понимание сервис-ориентированной архитектуры» . Learn.microsoft.com . Проверено 27 сентября 2022 г.
^ Sun Microsystems, апрель 2005 г. [1] Сервис-ориентированная архитектура (SOA) и веб-службы: путь к интеграции корпоративных приложений (EAI).
^ геваррен. «Обзор среды Common Language Runtime (CLR) — .NET» . Learn.microsoft.com . Проверено 27 сентября 2022 г.
^ Сан Микросистемс. [2] Источник для разработчиков Java.
^ «Безопасность веб-служб OASIS (WSS) TC | OASIS» . www.oasis-open.org . Проверено 27 сентября 2022 г.
^ «Политика веб-служб 1.2 — Платформа (WS-Policy)» . www.w3.org . Проверено 27 сентября 2022 г.
^ Архив документов (4 сентября 2009 г.). "Функции" . Learn.microsoft.com . Проверено 27 сентября 2022 г.
^ Джиллре (15 ноября 2016 г.). «Начало разработки — Visual Studio 2015» . Learn.microsoft.com . Проверено 27 сентября 2022 г.
^ «PHP: препроцессор гипертекста» . www.php.net . Проверено 27 сентября 2022 г.

Внешние ссылки

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

[1] Архив документов (14 января 2009 г.). «Понимание сервис-ориентированной архитектуры» . Learn.microsoft.com . Проверено 27 сентября 2022 г.

[2] Sun Microsystems, апрель 2005 г. [1] Сервис-ориентированная архитектура (SOA) и веб-службы: путь к интеграции корпоративных приложений (EAI).

[3] геваррен. «Обзор среды Common Language Runtime (CLR) — .NET» . Learn.microsoft.com . Проверено 27 сентября 2022 г.

[4] Сан Микросистемс. [2] Источник для разработчиков Java.

[5] «Безопасность веб-служб OASIS (WSS) TC | OASIS» . www.oasis-open.org . Проверено 27 сентября 2022 г.

[6] «Политика веб-служб 1.2 — Платформа (WS-Policy)» . www.w3.org . Проверено 27 сентября 2022 г.

[7] Архив документов (4 сентября 2009 г.). "Функции" . Learn.microsoft.com . Проверено 27 сентября 2022 г.

[8] Джиллре (15 ноября 2016 г.). «Начало разработки — Visual Studio 2015» . Learn.microsoft.com . Проверено 27 сентября 2022 г.

[9] «PHP: препроцессор гипертекста» . www.php.net . Проверено 27 сентября 2022 г.

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]