stringtranslate.com

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

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

Ориентация на услуги – это способ мышления в терминах услуг и развития на основе услуг, а также результатов услуг. [1]

Согласно одному из многочисленных определений SOA, сервис обладает четырьмя свойствами: [4]

  1. Логически он представляет собой повторяющуюся бизнес-деятельность с определенным результатом.
  2. Он автономен.
  3. Для потребителей это « черный ящик» , то есть потребителю не обязательно знать о внутренней работе сервиса.
  4. Он может состоять из других служб. [5]

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

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

Обратите внимание, что сервисно-ориентированную архитектуру не следует путать с сервисно-ориентированной архитектурой, поскольку это два разных архитектурных стиля. [7]

Обзор

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

Определение концепций

Связанное с этим модное слово « сервис-ориентация» способствует слабой связи между сервисами. SOA разделяет функции на отдельные единицы или сервисы, [9] которые разработчики делают доступными по сети, чтобы позволить пользователям объединять и повторно использовать их в производстве приложений. Эти сервисы и их соответствующие потребители взаимодействуют друг с другом, передавая данные в четко определенном, общем формате или координируя деятельность между двумя или более сервисами. [10]

SOA можно рассматривать как часть континуума, который простирается от старой концепции распределенных вычислений [9] [11] и модульного программирования , через SOA и далее к практикам гибридных приложений , SaaS и облачных вычислений (которые некоторые считают потомками SOA). [12]

Принципы

Не существует отраслевых стандартов, касающихся точного состава сервисно-ориентированной архитектуры, хотя многие отраслевые источники опубликовали свои собственные принципы. Некоторые из них [13] [14] [15] включают следующее:

Стандартизированный договор на обслуживание [16]
Услуги соответствуют стандартному соглашению о связи, которое в совокупности определяется одним или несколькими документами описания услуг в рамках данного набора услуг.
Автономность ссылок на услуги (аспект слабой связанности)
Взаимосвязь между службами сведена к минимуму до уровня, на котором они только знают о своем существовании.
Прозрачность местоположения услуг (аспект слабой связанности)
Услуги могут быть вызваны из любой точки сети, где они расположены, независимо от их местонахождения.
Долговечность службы
Услуги должны быть разработаны так, чтобы быть долговечными. По возможности услуги должны избегать принуждения потребителей к изменениям, если им не требуются новые функции; если вы звоните в службу сегодня, вы должны иметь возможность позвонить в ту же службу завтра.
Абстракция услуг
Сервисы работают по принципу черных ящиков, то есть их внутренняя логика скрыта от потребителей.
Автономность обслуживания
Службы независимы и контролируют инкапсулированную ими функциональность с точки зрения времени разработки и времени выполнения.
Безгражданство в сфере услуг
Службы не имеют состояния, то есть либо возвращают запрошенное значение, либо выдают исключение, что минимизирует использование ресурсов.
Детализация услуг
Принцип, гарантирующий, что услуги имеют адекватный размер и объем. Функциональность, предоставляемая услугой пользователю, должна быть релевантной.
Нормализация обслуживания
Сервисы декомпозируются или консолидируются (нормализуются) для минимизации избыточности. В некоторых случаях это может быть невыполнимо. Это те случаи, когда требуется оптимизация производительности, доступ и агрегация. [17]
Компоновка услуг
Сервисы могут использоваться для составления других сервисов.
Обнаружение услуг
Услуги дополняются коммуникативными метаданными, с помощью которых их можно эффективно обнаруживать и интерпретировать.
Возможность повторного использования услуг
Логика разделена на различные сервисы для обеспечения повторного использования кода.
Инкапсуляция услуг
Многие сервисы, которые изначально не планировалось использовать в рамках SOA, могут быть инкапсулированы или стать частью SOA.

Узоры

Каждый строительный блок SOA может играть любую из трех ролей:

Поставщик услуг
Он создает веб-сервис и предоставляет свою информацию в реестр сервисов. Каждый поставщик обсуждает множество «как» и «почему», например, какой сервис выставить напоказ, чему придать большее значение: безопасности или доступности, по какой цене предлагать сервис и многое другое . Поставщик также должен решить, в какой категории сервис должен быть указан для данного брокерского сервиса [18] и какие соглашения с торговыми партнерами требуются для использования сервиса.
Брокер услуг, реестр услуг или репозиторий услуг
Его основная функция — сделать информацию о веб-сервисе доступной любому потенциальному запрашивающему. Тот, кто реализует брокера, определяет область действия брокера. Публичные брокеры доступны везде и всюду, но частные брокеры доступны только ограниченному количеству публики. UDDI был ранней, больше не активно поддерживаемой попыткой предоставить обнаружение веб-сервисов .
Заказчик/потребитель услуг
Он находит записи в реестре брокера, используя различные операции поиска, а затем привязывается к поставщику услуг, чтобы вызвать одну из его веб-служб. Какая бы услуга ни была нужна потребителям услуг, они должны отнести ее к брокерам, связать ее с соответствующей службой и затем использовать. Они могут получить доступ к нескольким службам, если служба предоставляет несколько служб.

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

Шаблоны композиции сервисов имеют два широких, высокоуровневых архитектурных стиля: хореография и оркестровка . Шаблоны интеграции предприятия более низкого уровня, которые не привязаны к определенному архитектурному стилю, продолжают быть актуальными и приемлемыми в разработке SOA. [20] [21] [22]

Подходы к реализации

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

Разработчики обычно создают SOA, используя стандарты веб-сервисов. Одним из примеров является SOAP , который получил широкое признание в отрасли после рекомендации версии 1.2 от W3C [25] (Консорциум Всемирной паутины) в 2003 году. Эти стандарты (также называемые спецификациями веб-сервисов ) также обеспечивают большую совместимость и некоторую защиту от привязки к проприетарному программному обеспечению поставщика. Однако можно также реализовать SOA, используя любую другую технологию на основе сервисов, например Jini , CORBA , Internet Communications Engine , REST или gRPC .

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

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

Эти сервисы взаимодействуют на основе формального определения (или контракта, например, WSDL), которое не зависит от базовой платформы и языка программирования. Определение интерфейса скрывает реализацию сервиса, специфичного для языка. Таким образом, системы на основе SOA могут функционировать независимо от технологий и платформ разработки (таких как Java, .NET и т. д.). Сервисы, написанные на C#, работающие на платформах .NET, и сервисы, написанные на Java, работающие на платформах Java EE , например, могут потребляться общим составным приложением (или клиентом). Приложения, работающие на любой платформе, также могут потреблять сервисы, работающие на другой, как веб-сервисы, которые облегчают повторное использование. Управляемые среды также могут обертывать устаревшие системы COBOL и представлять их как программные сервисы. . [26]

Языки программирования высокого уровня, такие как BPEL , и спецификации, такие как WS-CDL и WS-Coordination, расширяют концепцию сервиса, предоставляя метод определения и поддержки оркестровки мелкозернистых сервисов в более крупнозернистые бизнес-сервисы, которые архитекторы, в свою очередь, могут включать в рабочие процессы и бизнес-процессы, реализованные в составных приложениях или порталах .

Сервисно-ориентированное моделирование — это фреймворк SOA, который определяет различные дисциплины, которые направляют практиков SOA для концептуализации, анализа, проектирования и разработки их сервисно-ориентированных активов. Фреймворк сервисно-ориентированного моделирования (SOMF) предлагает язык моделирования и рабочую структуру или «карту», ​​изображающую различные компоненты, которые способствуют успешному подходу сервисно-ориентированного моделирования. Он иллюстрирует основные элементы, которые определяют аспекты «что делать» схемы разработки сервиса. Модель позволяет практикам разрабатывать план проекта и определять вехи сервисно-ориентированной инициативы. SOMF также предоставляет общую нотацию моделирования для решения проблемы согласованности между бизнес- и ИТ-организациями.

Элементы SOA, Дирк Крафциг, Карл Банке и Дирк Слама [27]
Мета-модель SOA, The Linthicum Group, 2007

Организационные преимущества

Некоторые корпоративные архитекторы полагают, что SOA может помочь компаниям быстрее и экономически эффективнее реагировать на меняющиеся рыночные условия. [28] Этот стиль архитектуры способствует повторному использованию на макроуровне (сервис), а не на микроуровне (классы). Он также может упростить взаимосвязь с существующими (унаследованными) ИТ-активами и их использование.

Идея SOA заключается в том, что организация может рассматривать проблему целостно. Бизнес имеет более общий контроль. Теоретически не было бы массы разработчиков, использующих любые наборы инструментов, которые им нравятся. Вместо этого они бы кодировали в соответствии со стандартом, установленным в бизнесе. Они также могут разрабатывать SOA для всего предприятия, которая инкапсулирует ориентированную на бизнес инфраструктуру. SOA также была проиллюстрирована как система автомагистралей, обеспечивающая эффективность для водителей автомобилей. Суть в том, что если бы у всех была машина, но нигде не было бы автомагистралей, все было бы ограничено и дезорганизовано в любой попытке добраться куда-либо быстро или эффективно. Вице-президент IBM по веб-сервисам Майкл Либоу говорит, что SOA «строит автомагистрали». [29]

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

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

Причины, по которым внедрение услуг следует рассматривать как отдельные проекты от более крупных проектов, включают:

  1. Разделение продвигает концепцию для бизнеса, что услуги могут быть предоставлены быстро и независимо от более крупных и медленно продвигающихся проектов, распространенных в организации. Бизнес начинает понимать системы и упрощенные пользовательские интерфейсы, вызывающие услуги. Это выступает за гибкость . То есть, это способствует инновациям в бизнесе и ускоряет время выхода на рынок. [30]
  2. Разделение способствует отделению услуг от потребляющих проектов. Это поощряет хороший дизайн, поскольку услуга разрабатывается без знания того, кто ее потребители.
  3. Документация и тестовые артефакты сервиса не встроены в детали более крупного проекта. Это важно, когда сервис необходимо повторно использовать позже.

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

Примеры могут оказаться полезными для документирования сервиса до уровня, на котором он становится полезным. Документация некоторых API в Java Community Process дает хорошие примеры. Поскольку они являются исчерпывающими, сотрудники обычно используют только важные подмножества. Файл 'ossjsa.pdf' в JSR-89 является примером такого файла. [31]

Критика

SOA была объединена с веб-сервисами ; [32] однако веб-сервисы являются лишь одним из вариантов реализации шаблонов, которые составляют стиль SOA. При отсутствии собственных или бинарных форм удаленного вызова процедур (RPC) приложения могут работать медленнее и требовать больше вычислительной мощности, что увеличивает затраты. Большинство реализаций действительно влекут за собой эти накладные расходы, но SOA может быть реализована с использованием технологий (например, Java Business Integration (JBI), Windows Communication Foundation (WCF) и служба распределения данных (DDS)), которые не зависят от удаленных вызовов процедур или трансляции через XML или JSON. В то же время появляющиеся технологии анализа XML с открытым исходным кодом (такие как VTD-XML ) и различные XML-совместимые бинарные форматы обещают значительно улучшить производительность SOA. [33] [34] [35]

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

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

Еще одной серьезной проблемой SOA является отсутствие единой среды тестирования. Нет инструментов, которые предоставляют требуемые функции для тестирования этих сервисов в сервисно-ориентированной архитектуре. Основные причины трудностей: [39]

Расширения и варианты

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

Интерфейсы прикладного программирования

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

Веб 2.0

Тим О'Рейли ввел термин « Web 2.0 » для описания воспринимаемого, быстро растущего набора веб-приложений. [40] Тема, которая получила широкое освещение, включает в себя взаимосвязь между Web 2.0 и сервисно-ориентированными архитектурами. [ какие? ]

SOA — это философия инкапсуляции логики приложения в сервисы с единообразно определенным интерфейсом и предоставления их публичного доступа через механизмы обнаружения. Понятие сокрытия сложности и повторного использования, а также концепция слабосвязанных сервисов вдохновили исследователей на разработку сходств между двумя философиями, SOA и Web 2.0, и их соответствующими приложениями. Некоторые утверждают, что Web 2.0 и SOA имеют существенно разные элементы и, таким образом, не могут считаться «параллельными философиями», в то время как другие считают эти две концепции взаимодополняющими и рассматривают Web 2.0 как глобальную SOA. [41]

Философии Web 2.0 и SOA обслуживают различные потребности пользователей и, таким образом, выявляют различия в отношении дизайна, а также технологий, используемых в реальных приложениях. Однако, по состоянию на 2008 год , примеры использования продемонстрировали потенциал объединения технологий и принципов как Web 2.0, так и SOA. [41]

Микросервисы

Микросервисы — это современная интерпретация сервисно-ориентированных архитектур, используемых для построения распределенных программных систем . Сервисы в микросервисной архитектуре [42] — это процессы , которые взаимодействуют друг с другом по сети для достижения цели. Эти сервисы используют протоколы, не зависящие от технологий , [43] которые помогают инкапсулировать выбор языка и фреймворков, делая их выбор внутренним для сервиса. Микросервисы — это новый подход к реализации и внедрению SOA, который стал популярным с 2014 года (и после введения DevOps ), и который также подчеркивает непрерывное развертывание и другие гибкие практики. [44]

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

Сервисно-ориентированные архитектуры для интерактивных приложений

Интерактивные приложения, требующие времени отклика в реальном времени, например, интерактивные 3D-приложения с малой задержкой, используют определенные сервисно-ориентированные архитектуры, отвечающие конкретным потребностям такого рода приложений. К ним относятся, например, оптимизированные распределенные вычисления и коммуникации с малой задержкой, а также управление ресурсами и экземплярами. [45] [46] [47]

Смотрите также

Ссылки

  1. ^ ab "SOA Source Book - What Is SOA?". collaboration.opengroup.org . Получено 30 марта 2021 г. .
  2. ^ Основы архитектуры программного обеспечения: инженерный подход . O'Reilly Media. 2020. ISBN 978-1492043454.
  3. ^ "Глава 1: Сервисно-ориентированная архитектура (SOA)". msdn.microsoft.com . Архивировано из оригинала 7 июля 2017 г. . Получено 21 сентября 2016 г. .
  4. ^ «Стандарты сервисно-ориентированной архитектуры — The Open Group». www.opengroup.org .
  5. ^ "Что такое SOA?". www.opengroup.org . Архивировано из оригинала 19 августа 2016 г. Получено 21 сентября 2016 г.
  6. ^ Велте, Энтони Т. (2010). Облачные вычисления: практический подход . McGraw Hill. ISBN 978-0-07-162694-1.
  7. ^ Основы архитектуры программного обеспечения: инженерный подход . O'Reilly Media. 2020. ISBN 978-1492043454.
  8. ^ "Переход на сервисно-ориентированную архитектуру, часть 1". 9 декабря 2008 г. Архивировано из оригинала 9 декабря 2008 г. Получено 21 сентября 2016 г.{{cite web}}: CS1 maint: бот: исходный статус URL неизвестен ( ссылка )
  9. ^ ab Майкл Белл (2008). "Введение в сервисно-ориентированное моделирование". Сервисно-ориентированное моделирование: анализ услуг, проектирование и архитектура . Wiley & Sons. стр. 3. ISBN 978-0-470-14111-3.
  10. ^ Майкл Белл (2010). Шаблоны моделирования SOA для сервисно-ориентированного обнаружения и анализа . Wiley & Sons. стр. 390. ISBN 978-0-470-48197-4.
  11. ^ Томас Эрл (июнь 2005 г.). О принципах . Serviceorientation.org
  12. ^ "Блог о стратегиях платформы приложений: SOA мертва; да здравствуют сервисы". Apsblog.burtongroup.com. 5 января 2009 г. Архивировано из оригинала 15 января 2009 г. Получено 13 августа 2012 г.
  13. ^ Ивонн Балзер Улучшайте планы проектов SOA, IBM , 16 июля 2004 г.
  14. ^ Команда Microsoft Windows Communication Foundation (2012). «Принципы сервисно-ориентированного проектирования». msdn.microsoft.com . Получено 3 сентября 2012 г.
  15. ^ Принципы Томаса Эрла из SOA Systems Inc. восемь конкретных принципов сервис-ориентации
  16. ^ "4.4 Руководство по использованию технологий контрактов на веб-услуги - Анатомия контракта на веб-услуги". InformIT . 11 июня 2021 г. Получено 9 сентября 2021 г.
  17. ^ Тони Шан (2004). «Создание сервисно-ориентированной платформы электронного банкинга». Международная конференция IEEE по вычислительным услугам, 2004. (SCC 2004). Труды. 2004. стр. 237–244. doi :10.1109/SCC.2004.1358011. ISBN 978-0-7695-2225-8. S2CID  13156128.2004
  18. ^ Дуань, Юконг; Нарендра, Нанджангуд; Ду, Вэньцай; Ван, Юнчжи; Чжоу, Няньцзюнь (2014). «Изучение брокерства облачных услуг с точки зрения интерфейса». Международная конференция IEEE по веб-сервисам 2014 г. IEEE . стр. 329–336. doi :10.1109/ICWS.2014.55. ISBN 978-1-4799-5054-6. S2CID  17957063.
  19. ^ Дуань, Юконг (2012). «Обзор контракта на обслуживание». 2012 13-я Международная конференция ACIS по программной инженерии, искусственному интеллекту, сетям и параллельным/распределенным вычислениям . IEEE . С. 805–810. doi :10.1109/SNPD.2012.22. ISBN 978-1-4673-2120-4. S2CID  1837914.
  20. ^ Олаф Циммерманн, Чезаре Паутассо, Грегор Хохпе, Бобби Вульф (2016). «Десятилетие шаблонов интеграции предприятий». IEEE Software . 33 (1): 13–19. doi : 10.1109/MS.2016.11 .{{cite journal}}: CS1 maint: несколько имен: список авторов ( ссылка )
  21. ^ Ротем-Гал-Оз, Арнон (2012). Шаблоны SOA . Manning Publications. ISBN 978-1933988269.
  22. ^ Юлиш, Клаус; Сутер, Кристоф; Войталла, Томас; Циммерманн, Олаф (2011). «Соответствие требованиям по дизайну — преодоление пропасти между аудиторами и ИТ-архитекторами» (PDF) . Компьютеры и безопасность . 30 (6–7): 410–426. CiteSeerX 10.1.1.390.3652 . doi :10.1016/j.cose.2011.03.005. 
  23. ^ Бранднер М., Краес М., Оллерманн Ф., Циммерманн О., Архитектура, ориентированная на веб-сервисы, в производстве в финансовой отрасли, Informatik-Spektrum 02/2004, Springer-Verlag, 2004 г.
  24. ^ "www.ibm.com". IBM . Получено 10 сентября 2016 г. .
  25. ^ «SOAP версии 1.2 の公開について (W3C 勧告)» (на японском языке). W3.org. 24 июня 2003 года . Проверено 13 августа 2012 г.
  26. ^ Окисима, Харухиру (2006). ". "Исследование архитектуры системы, использующей активы COBOL"" (PDF) .
  27. ^ Enterprise SOA . Prentice Hall, 2005
  28. ↑ Кристофер Кох. Новый план для предприятия. Архивировано 16 января 2009 г. в Wayback Machine , журнал CIO Magazine , 1 марта 2005 г.
  29. ^ Элизабет Миллард (январь 2005 г.). «Building a Better Process». Computer User . Страница 20.
  30. ^ Брайан Циммерли (11 ноября 2009 г.) Преимущества SOA для бизнеса, Университет прикладных наук Северо-Западной Швейцарии, Школа бизнеса
  31. ^ "JSR-000089 OSS Service Activation API Specification 1.0 Final Release". 26 июля 2011 г. Архивировано из оригинала 26 июля 2011 г. Получено 18 мая 2024 г.
  32. ^ Джо Маккендрик. «Брей: SOA слишком сложная; просто чушь поставщика». ZDNet.
  33. ↑ Джимми Чжан (20 февраля 2008 г.) «Индексирование XML-документов с помощью VTD-XML». Архивировано 4 июля 2008 г. на Wayback Machine . XML Journal .
  34. ↑ Джимми Чжан (5 августа 2008 г.) «Точка зрения i-Technology: The Performance Woe of Binary XML» Архивировано 9 января 2020 г. в Wayback Machine . Журнал Microservices .
  35. ↑ Джимми Чжан (9 января 2008 г.) «Manipulate XML Content the Ximple Way» Архивировано 30 июля 2017 г. на Wayback Machine . devx.com .
  36. ^ «Причина, по которой SOA не обеспечивает устойчивое программное обеспечение». jpmorgenthal.com. 19 июня 2009 г. Получено 27 июня 2009 г.
  37. ^ "Сервисы SOA все еще слишком ограничены приложениями, которые они представляют". ZDNet . 27 июня 2009 г. Получено 27 июня 2009 г.
  38. ^ "Governance Layer". www.opengroup.org . Архивировано из оригинала 4 июня 2016 г. Получено 22 сентября 2016 г.
  39. ^ "Как эффективно тестировать сервисно-ориентированную архитектуру | WSO2 Inc". wso2.com . Получено 22 сентября 2016 г. .
  40. ^ "Что такое Web 2.0". Тим О'Рейли. 30 сентября 2005 г. Получено 10 июня 2008 г.
  41. ^ ab Christoph Schroth; Till Janner (2007). "Web 2.0 и SOA: Конвергенция концепций, обеспечивающих Интернет услуг". IT Professional . 9 (3): 36–41. doi :10.1109/MITP.2007.60. S2CID  2859262. Архивировано из оригинала 3 декабря 2013 г. Получено 23 февраля 2008 г.
  42. ^ Драгони, Никола; Джяллоренцо, Саверио; Альберто Ллуч Лафуэнте; Маццара, Мануэль; Монтези, Фабрицио; Мустафин, Руслан; Сафина, Лариса (2016). «Микросервисы: вчера, сегодня и завтра». arXiv : 1606.04036v1 [cs.SE].
  43. ^ Джеймс Льюис и Мартин Фаулер. «Микросервисы».
  44. ^ Балалайе, А.; Хейдарноори, А.; Джамшиди, П. (1 мая 2016 г.). «Архитектура микросервисов позволяет DevOps: миграция в облачную архитектуру» (PDF) . IEEE Software . 33 (3): 42–52. doi :10.1109/MS.2016.64. hdl : 10044/1/40557 . ISSN  0740-7459. S2CID  18802650.
  45. ^ Фрэнк Глинка; Аллайти Рэд (2009). «Сервисно-ориентированный интерфейс для высокоинтерактивных распределенных приложений». Европейская конференция по параллельной обработке . Конспект лекций по информатике. Том 6043. С. 266–277. doi :10.1007/978-3-642-14122-5_31. ISBN 978-3-642-14121-8. Получено 9 февраля 2021 г. .
  46. ^ Дитер Хильдебрандт; Ян Климке (2011). «Сервисно-ориентированная интерактивная 3D-визуализация больших 3D-моделей городов на тонких клиентах». COM.Geo '11: Труды 2-й Международной конференции по вычислениям для геопространственных исследований и приложений . стр. 1. doi :10.1145/1999320.1999326. ISBN 9781450306812. S2CID  53246415 . Получено 9 февраля 2021 г. .
  47. ^ Mahy Aly; Michael Franke (2016). «Сервисно-ориентированные интерактивные медиа-движки (SOIM), обеспечиваемые оптимизированным распределением ресурсов». Симпозиум IEEE 2016 года по сервисно-ориентированной системной инженерии (SOSE). стр. 231–237. doi :10.1109/SOSE.2016.47. hdl : 1854/LU-7215326 . ISBN 978-1-5090-2253-3. S2CID  9511734 . Получено 9 февраля 2021 г. .
На Викискладе есть медиафайлы по теме Сервисно-ориентированная архитектура .
Послушайте эту статью ( 54 минуты )
Разговорный значок Википедии
Этот аудиофайл был создан на основе редакции этой статьи от 27 октября 2011 года и не отражает последующие правки. ( 2011-10-27 )
( Аудиопомощь  · Больше устных статей )