Послушайте эту статью
Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

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

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

Обзор [ править ]

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

Определение понятий [ править ]

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

В октябре 2009 г. был опубликован манифест по сервис-ориентированной архитектуре. В нем были сформулированы шесть основных ценностей, которые перечислены ниже: [8]

  1. Ценности бизнеса придается большее значение, чем технической стратегии.
  2. Стратегическим целям придается большее значение, чем выгодам от конкретных проектов.
  3. Внутренней совместимости придается большее значение, чем индивидуальной интеграции.
  4. Общие службы имеют большее значение, чем реализация для конкретных целей.
  5. Гибкости уделяется больше внимания, чем оптимизации.
  6. Эволюционному совершенствованию придается большее значение, чем стремлению к изначальному совершенству.

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

Принципы [ править ]

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

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

Выкройки [ править ]

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

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

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

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

Подходы к реализации [ править ]

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

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

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

  • Веб-сервисы на основе WSDL и SOAP
  • Обмен сообщениями, например, с ActiveMQ, JMS, RabbitMQ
  • RESTful HTTP с передачей репрезентативного состояния (REST), составляющей собственный архитектурный стиль на основе ограничений
  • OPC-UA
  • WCF (реализация веб-сервисов Microsoft, являющаяся частью WCF)
  • Apache Thrift
  • gRPC
  • SORCER

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Критика [ править ]

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

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

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

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

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

Расширения и варианты [ править ]

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

Основная статья: Событийная архитектура

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

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

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

Web 2.0 [ править ]

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

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

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

Микросервисы [ править ]

Основная статья: Микросервисы

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

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

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

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

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

См. Также [ править ]

  • Интерфейс прикладного программирования
  • Слабая связь
  • Эталонная модель SOA OASIS
  • Принцип детализации сервиса
  • Управление SOA
  • Архитектура программного обеспечения
  • Сервисно-ориентированная связь (SOC)
  • Сервисно-ориентированная разработка приложений
  • Сервисно-ориентированные распределенные приложения

Ссылки [ править ]

  1. ^ «Глава 1: Сервис-ориентированная архитектура (SOA)» . msdn.microsoft.com . Архивировано из оригинала 7 июля 2017 года . Проверено 21 сентября 2016 года .
  2. ^ «Стандарты сервис-ориентированной архитектуры - открытая группа» . www.opengroup.org .
  3. ^ "Что такое SOA?" . www.opengroup.org . Архивировано из оригинального 19 августа 2016 года . Проверено 21 сентября 2016 года .
  4. ^ Велте, Энтони Т. (2010). Облачные вычисления: практический подход . Макгроу Хилл. ISBN 978-0-07-162694-1.
  5. ^ «Переход на сервис-ориентированную архитектуру, часть 1» . 9 декабря 2008 года. Архивировано 9 декабря 2008 года . Проверено 21 сентября 2016 года .CS1 maint: bot: исходный статус URL неизвестен ( ссылка )
  6. ^ а б Майкл Белл (2008). «Введение в сервис-ориентированное моделирование». Сервис-ориентированное моделирование: анализ, проектирование и архитектура сервисов . Wiley & Sons. п. 3 . ISBN 978-0-470-14111-3.
  7. ^ Майкл Белл (2010). Шаблоны моделирования SOA для сервис-ориентированного обнаружения и анализа . Wiley & Sons. п. 390 . ISBN 978-0-470-48197-4.
  8. ^ «Манифест SOA» . www.soa-manifesto.org . Проверено 21 сентября 2016 года .
  9. ↑ Томас Эрл (июнь 2005 г.). О принципах . Serviceorientation.org
  10. ^ «Блог о стратегиях платформы приложений: SOA мертв; Да здравствует сервис» . Apsblog.burtongroup.com. 5 января 2009 года архив с оригинала на 15 января 2009 года . Проверено 13 августа 2012 года .
  11. ↑ Ивонн Бальцер, улучшите планы проекта SOA , IBM , 16 июля 2004 г.
  12. ^ Команда Microsoft Windows Communication Foundation (2012). «Принципы сервис-ориентированного дизайна» . msdn.microsoft.com . Проверено 3 сентября 2012 года .
  13. ^ Принципы Томаса Эрла из SOA Systems Inc. Восемь конкретных принципов сервисной ориентации
  14. ^ М. Хади Valipour; Бавар АмирЗафари; Х. Ники Малеки; Негин Данешпур (2009). «Краткий обзор концепций архитектуры программного обеспечения и сервис-ориентированной архитектуры». 2009 2-я Международная конференция IEEE по компьютерным наукам и информационным технологиям . С. 34–38. DOI : 10.1109 / ICCSIT.2009.5235004 . ISBN 978-1-4244-4519-6. S2CID  14980694 .
  15. ↑ Тони Шэн (2004). «Создание сервисно-ориентированной платформы электронного банкинга ». Международная конференция IEEE по сервисным вычислениям, 2004 г. (SCC 2004). Ход работы. 2004 . С. 237–244. DOI : 10,1109 / SCC.2004.1358011 . ISBN 978-0-7695-2225-8. S2CID  13156128 .2004 г.
  16. ^ Дуань, Юконг; Нарендра, Нанджангуд; Ду, Вэньцай; Ван, Юнчжи; Чжоу, Няньцзюнь (2014). «Изучение брокерской деятельности облачных сервисов с точки зрения интерфейса». 2014 IEEE Международная конференция по веб - служб . IEEE . С. 329–336. DOI : 10.1109 / ICWS.2014.55 . ISBN 978-1-4799-5054-6. S2CID  17957063 .
  17. ^ Дуань, Юконг (2012). «Обзор договора на оказание услуг». 2012 13-я Международная конференция ACIS по программной инженерии, искусственному интеллекту, сетям и параллельным / распределенным вычислениям . IEEE . С. 805–810. DOI : 10,1109 / SNPD.2012.22 . ISBN 978-1-4673-2120-4. S2CID  1837914 .
  18. ^ Олаф Циммерманн, Чезаре Паутассо, Грегор Хопе, Бобби Вульф (2016). «Десятилетие моделей интеграции предприятия». Программное обеспечение IEEE . 33 (1): 13–19. DOI : 10.1109 / MS.2016.11 .CS1 maint: multiple names: authors list (link)
  19. Перейти ↑ Rotem-Gal-Oz, Arnon (2012). Шаблоны SOA . Публикации Мэннинга. ISBN 978-1933988269.
  20. ^ Юлиш, Клаус; Сутер, Кристоф; Войталла, Томас; Циммерманн, Олаф (2011). «Соблюдение нормативных требований - Преодоление пропасти между аудиторами и ИТ-архитекторами» (PDF) . Компьютеры и безопасность . 30 (6–7): 410–426. CiteSeerX 10.1.1.390.3652 . DOI : 10.1016 / j.cose.2011.03.005 .  
  21. ^ Бранднер, М., Craes, М., Oellermann Ф., Zimmermann, О., Web Services-ориентированной архитектуры в производстве в финансовой отрасли, Informatik-Spektrum 02/2004, Springer-Verlag, 2004
  22. ^ "www.ibm.com" . Проверено 10 сентября 2016 года .
  23. ^ «SOAP Version 1.2 の 公開 に つ い て (W3C 勧 告)» (на японском языке). W3.org . Проверено 13 августа 2012 года .
  24. ^ Окишима, Харухиру (2006). "." Пример системной архитектуры, использующей ресурсы COBOL " " (PDF) .
  25. ^ Корпоративная SOA . Прентис Холл, 2005
  26. ↑ Christopher Koch A New Blueprint For The Enterprise , журнал CIO , 1 марта 2005 г.
  27. ↑ Элизабет Миллард (январь 2005 г.). «Создание лучшего процесса». Пользователь компьютера . Стр.20.
  28. ^ Brayan Зиммер (11 ноября 2009) Бизнес Преимущество SOA , Университет прикладных наук Северо - Западный Швейцарии, Школа бизнеса
  29. ^ JSR-000089 OSS Service Activation API Specification 1.0 Final Release . sun.com
  30. ^ Джо МакКендрик. «Брэй: SOA слишком сложна;« просто поставщик BS » » . ZDNet.
  31. ↑ Джимми Чжан (20 февраля 2008 г.) «Индексирование XML-документов с помощью VTD-XML». Архивировано 4 июля 2008 г. на Wayback Machine . XML журнал .
  32. ↑ Джимми Чжан (5 августа 2008 г.) «Точка зрения i-Technology: Беда в производительности двоичного XML» . Журнал микросервисов .
  33. ↑ Джимми Чжан (9 января 2008 г.) «Управляйте содержимым XML способом Ximple» . devx.com .
  34. ^ «Причина, по которой SOA не обеспечивает устойчивое программное обеспечение» . jpmorgenthal.com. 19 июня 2009 . Проверено 27 июня 2009 года .
  35. ^ «Сервисы SOA все еще слишком ограничены приложениями, которые они представляют» . zdnet.com. 27 июня 2009 . Проверено 27 июня 2009 года .
  36. ^ "Уровень управления" . www.opengroup.org . Проверено 22 сентября 2016 года .
  37. ^ «Как эффективно протестировать сервис-ориентированную архитектуру | WSO2 Inc» . wso2.com . Проверено 22 сентября 2016 года .
  38. ^ «Что такое Web 2.0» . Тим О'Рейли. 30 сентября 2005 . Проверено 10 июня 2008 года .
  39. ^ a b Кристоф Шрот; Тилль Джаннер (2007). «Web 2.0 и SOA: сближение концепций, обеспечивающих Интернет услуг» . ИТ-специалист . 9 (3): 36–41. DOI : 10.1109 / MITP.2007.60 . S2CID 2859262 . Проверено 23 февраля 2008 года . 
  40. ^ Драгони, Никола; Джаллоренцо, Саверио; Альберто Люч Лафуэнте; Маццара, Мануэль; Монтези, Фабрицио; Мустафин, Руслан; Сафина, Лариса (2016). «Микросервисы: вчера, сегодня, завтра». arXiv : 1606.04036v1 [ cs.SE ].
  41. ^ Джеймс Льюис и Мартин Фаулер. «Микросервисы» .
  42. ^ Balalaie, A .; Heydarnoori, A .; Джамшиди, П. (1 мая 2016 г.). «Архитектура микросервисов позволяет DevOps: переход на облачную архитектуру» (PDF) . Программное обеспечение IEEE . 33 (3): 42–52. DOI : 10.1109 / MS.2016.64 . ЛВП : 10044/1/40557 . ISSN 0740-7459 . S2CID 18802650 .   
  43. ↑ Франк Глинка; Аллаити Рэд (2009). «Сервисно-ориентированный интерфейс для высоко интерактивных распределенных приложений» . Европейская конференция по параллельной обработке . Конспект лекций по информатике. 6043 : 266–277. DOI : 10.1007 / 978-3-642-14122-5_31 . ISBN 978-3-642-14121-8. Проверено 9 февраля 2021 года .
  44. ^ Дитер Хильдебрандт; Ян Климке (2011). «Сервисно-ориентированная интерактивная 3D визуализация массивных 3D моделей городов на тонких клиентах» . COM.Geo '11: Материалы 2-й Международной конференции по вычислениям для геопространственных исследований и приложений : 1. doi : 10.1145 / 1999320.1999326 . ISBN 9781450306812. S2CID  53246415 . Проверено 9 февраля 2021 года .
  45. ^ Махи Али; Майкл Франке (2016). «Механизмы интерактивного мультимедиа, ориентированные на сервисы (SOIM), на основе оптимизированного совместного использования ресурсов» . Симпозиум IEEE 2016 г. по сервис-ориентированной системной инженерии (SOSE) : 231–237. DOI : 10,1109 / SOSE.2016.47 . ISBN 978-1-5090-2253-3. S2CID  9511734 . Проверено 9 февраля 2021 года .
Послушайте эту статью ( 54 минуты )
Разговорный значок Википедии
Этот аудиофайл был создан на основе редакции этой статьи от 27 октября 2011 г. и не отражает последующих правок. (2011-10-27)
( Аудио справка  · Больше устных статей )