✖


Jump to content

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

Послушайте эту статью

В обеспечения разработке программного сервис-ориентированная архитектура ( 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] (Консорциум World Wide Web) в 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 содержит хорошие примеры. Поскольку они являются исчерпывающими, сотрудники обычно используют только важные подмножества. файл 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]

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

  • детальные интерфейсы (для независимо развертываемых сервисов),
  • бизнес-ориентированная разработка (например, предметно-ориентированный дизайн ),
  • ИДЕАЛЬНЫЕ архитектуры облачных приложений,
  • полиглотное программирование и настойчивость,
  • развертывание легкого контейнера,
  • децентрализованная непрерывная доставка и
  • DevOps с комплексным мониторингом услуг.

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

[ редактировать ]

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

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ Перейти обратно: а б «Справочник по SOA. Что такое SOA?» . Сотрудничество.opengroup.org . Проверено 30 марта 2021 г.
  2. ^ Основы архитектуры программного обеспечения: инженерный подход . О'Рейли Медиа. 2020. ISBN  978-1492043454 .
  3. ^ «Глава 1: Сервис-ориентированная архитектура (SOA)» . msdn.microsoft.com . Архивировано из оригинала 7 июля 2017 года . Проверено 21 сентября 2016 г.
  4. ^ «Стандарты сервис-ориентированной архитектуры — Открытая группа» . www.opengroup.org .
  5. ^ «Что такое SOA?» . www.opengroup.org . Архивировано из оригинала 19 августа 2016 года . Проверено 21 сентября 2016 г.
  6. ^ Велте, Энтони Т. (2010). Облачные вычисления: практический подход . МакГроу Хилл. ISBN  978-0-07-162694-1 .
  7. ^ Основы архитектуры программного обеспечения: инженерный подход . О'Рейли Медиа. 2020. ISBN  978-1492043454 .
  8. ^ «Миграция на сервис-ориентированную архитектуру. Часть 1» . 9 декабря 2008 года. Архивировано из оригинала 9 декабря 2008 года . Проверено 21 сентября 2016 г. {{cite web}}: CS1 maint: bot: исходный статус URL неизвестен ( ссылка )
  9. ^ Перейти обратно: а б Майкл Белл (2008). «Введение в сервис-ориентированное моделирование». Сервис-ориентированное моделирование: анализ, проектирование и архитектура сервисов . Уайли и сыновья. п. 3 . ISBN  978-0-470-14111-3 .
  10. ^ Майкл Белл (2010). Шаблоны SOA-моделирования для сервис-ориентированного обнаружения и анализа . Уайли и сыновья. п. 390 . ISBN  978-0-470-48197-4 .
  11. ^ Томас Эрл (июнь 2005 г.). О принципах . Сервисориентация.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 Рекомендации по использованию технологий контрактов веб-сервисов — анатомия контракта веб-сервисов» . ИнформИТ . 11 июня 2021 г. Проверено 9 сентября 2021 г.
  17. ^ Тони Шан (2004). «Создание сервис-ориентированной платформы электронного банкинга». Международная конференция IEEE по вычислительным услугам, 2004 г. (SCC 2004). Слушания. 2004 . стр. 237–244. дои : 10.1109/SCC.2004.1358011 . ISBN  978-0-7695-2225-8 . S2CID   13156128 . 2004 г.
  18. ^ Дуань, Юконг; Нарендра, Нанджангуд; Ду, Вэньцай; Ван, Юнчжи; Чжоу, Няньцзюнь (2014). «Изучение брокерской деятельности в сфере облачных услуг с точки зрения интерфейса». Международная конференция IEEE по веб-сервисам , 2014 г. ИИЭЭ . стр. 329–336. дои : 10.1109/ICWS.2014.55 . ISBN  978-1-4799-5054-6 . S2CID   17957063 .
  19. ^ Дуань, Юконг (2012). «Опрос по сервисному контракту». 2012 г. 13-я Международная конференция ACIS по программной инженерии, искусственному интеллекту, сетям и параллельным/распределенным вычислениям . ИИЭЭ . стр. 805–810. дои : 10.1109/СНПД.2012.22 . ISBN  978-1-4673-2120-4 . S2CID   1837914 .
  20. ^ Олаф Циммерманн, Чезаре Паутассо, Грегор Хопе, Бобби Вульф (2016). «Десятилетие моделей корпоративной интеграции» . Программное обеспечение IEEE . 33 (1): 13–19. дои : 10.1109/MS.2016.11 . {{cite journal}}: CS1 maint: несколько имен: список авторов ( ссылка )
  21. ^ Ротем-Гал-Оз, Арнон (2012). SOA-шаблоны . Публикации Мэннинга. ISBN  978-1933988269 .
  22. ^ Юлиш, Клаус; Сутер, Кристоф; Войталла, Томас; Циммерманн, Олаф (2011). «Соответствие требованиям – преодоление пропасти между аудиторами и ИТ-архитекторами» (PDF) . Компьютеры и безопасность . 30 (6–7): 410–426. CiteSeerX   10.1.1.390.3652 . дои : 10.1016/j.cose.2011.03.005 .
  23. ^ Бранднер М., Краес М., Оллерманн Ф., Циммерманн О., Архитектура, ориентированная на веб-сервисы, в производстве в финансовой отрасли, Informatik-Spektrum 02/2004, Springer-Verlag, 2004 г.
  24. ^ «www.ibm.com» . ИБМ . Проверено 10 сентября 2016 г.
  25. ^ «О выпуске SOAP версии 1.2 (рекомендация W3C)» (на японском языке W3.org, 24 июня 2003 г.). Проверено 13 августа 2012 г.
  26. ^ Окишима, Харухиру (2006). «. «Пример системной архитектуры, использующей ресурсы COBOL» » (PDF) .
  27. ^ Корпоративный SOA . Прентис Холл, 2005 г.
  28. ↑ Кристофер Кох. Новый план предприятия. Архивировано 16 января 2009 г., в Wayback Machine , журнал CIO , 1 марта 2005 г.
  29. ^ Элизабет Миллард (январь 2005 г.). «Построение лучшего процесса». Пользователь компьютера . Страница 20.
  30. ^ Браян Циммерли (11 ноября 2009 г.) Преимущества SOA для бизнеса , Университет прикладных наук Северо-Западной Швейцарии, Школа бизнеса
  31. ^ «JSR-000089 Финальная версия спецификации API активации службы OSS 1.0» . 26 июля 2011. Архивировано из оригинала 26 июля 2011 года . Проверено 18 мая 2024 г.
  32. ^ Джо МакКендрик. «Брэй: SOA слишком сложна; «просто чушь поставщика» » . ЗДНет.
  33. ^ Джимми Чжан (20 февраля 2008 г.) «Индексирование XML-документов с помощью VTD-XML». Архивировано 4 июля 2008 г. в Wayback Machine . XML-журнал .
  34. ^ Джимми Чжан (5 августа 2008 г.) «Точка зрения i-технологий: горе производительности двоичного XML». Архивировано 9 января 2020 г. на Wayback Machine . Журнал микросервисов .
  35. ^ Джимми Чжан (9 января 2008 г.) «Управляйте XML-контентом простым способом». Архивировано 30 июля 2017 г. на Wayback Machine . devx.com .
  36. ^ «Причина, по которой SOA не обеспечивает устойчивое программное обеспечение» . jpmorgenthal.com. 19 июня 2009 года . Проверено 27 июня 2009 г.
  37. ^ «Службы SOA все еще слишком ограничены приложениями, которые они представляют» . ЗДНет . 27 июня 2009 года . Проверено 27 июня 2009 г.
  38. ^ «Уровень управления» . www.opengroup.org . Архивировано из оригинала 4 июня 2016 года . Проверено 22 сентября 2016 г.
  39. ^ «Как эффективно тестировать сервис-ориентированную архитектуру | WSO2 Inc» . wso2.com . Проверено 22 сентября 2016 г.
  40. ^ «Что такое Веб 2.0» . Тим О'Рейли. 30 сентября 2005 года . Проверено 10 июня 2008 г.
  41. ^ Перейти обратно: а б Кристоф Шрот; Тилль Яннер (2007). «Web 2.0 и SOA: конвергенция концепций, обеспечивающих использование Интернета услуг» . ИТ-специалист . 9 (3): 36–41. дои : 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 . 33 (3): 42–52. дои : 10.1109/MS.2016.64 . hdl : 10044/1/40557 . ISSN   0740-7459 . S2CID   18802650 .
  45. ^ Фрэнк Глинка; Аллайти Раед (2009). «Сервис-ориентированный интерфейс для высокоинтерактивных распределенных приложений» . Европейская конференция по параллельной обработке . Конспекты лекций по информатике. Том. 6043. стр. 266–277. дои : 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. дои : 10.1145/1999320.1999326 . ISBN  9781450306812 . S2CID   53246415 . Проверено 9 февраля 2021 г.
  47. ^ Махи Али; Майкл Франке (2016). «Механизмы сервис-ориентированного интерактивного мультимедиа (SOIM) за счет оптимизированного совместного использования ресурсов» . Симпозиум IEEE по сервис-ориентированной системной инженерии (SOSE) 2016 г. стр. 231–237. дои : 10.1109/СОСЕ.2016.47 . hdl : 1854/LU-7215326 . ISBN  978-1-5090-2253-3 . S2CID   9511734 . Проверено 9 февраля 2021 г.
Викискладе есть медиафайлы, связанные с сервис-ориентированной архитектурой .
Послушайте эту статью ( 54 минуты )
Продолжительность: 54 минуты 28 секунд.
Разговорная иконка Википедии
Этот аудиофайл был создан на основе редакции этой статьи от 27 октября 2011 г. ( 27 октября 2011 г. ) и не отражает последующие изменения.
( Аудио помощь · Больше устных статей )
Retrieved from "https://en.wikipedia.org/w/index.php?title=Service-oriented_architecture&oldid=1236468830"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 37f22cac40b65b521176c042ef8e091a__1721846580
URL1:https://arc.ask3.ru/arc/aa/37/1a/37f22cac40b65b521176c042ef8e091a.html
Заголовок, (Title) документа по адресу, URL1:
Service-oriented architecture - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)