Сервис-Ориентированная Архитектура
В программного обеспечения разработке сервис-ориентированная архитектура ( SOA ) — это архитектурный стиль, который фокусируется на дискретных сервисах, а не на монолитной конструкции . [1] SOA — хороший выбор для системной интеграции . [2] Как следствие, он также применяется в области разработки программного обеспечения , где услуги предоставляются другим компонентам компонентами приложения через протокол связи по сети. Услуга — это отдельная функциональная единица, к которой можно получить удаленный доступ, а также действовать и обновлять ее независимо, например, получить онлайн-выписку по кредитной карте. SOA также должна быть независимой от поставщиков, продуктов и технологий. [3]
Ориентация на услуги – это образ мышления с точки зрения услуг, развития на основе услуг и результатов услуг. [1]
Согласно одному из многих определений SOA, сервис имеет четыре свойства: [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 .
Архитектуры могут работать независимо от конкретных технологий и, следовательно, могут быть реализованы с использованием широкого спектра технологий, включая:
- Веб-сервисы на основе WSDL и SOAP
- Обмен сообщениями, например, с помощью ActiveMQ, JMS, RabbitMQ.
- RESTful HTTP с передачей репрезентативного состояния (REST), составляющей собственный архитектурный стиль, основанный на ограничениях.
- Служба распространения данных (DDS)
- ОПЦ-УА
- Механизм интернет-коммуникаций
- WCF (реализация веб-служб Microsoft, являющаяся частью WCF)
- Апач бережливый
- gRPC
- ЧОЛДОВНИК
Реализации могут использовать один или несколько из этих протоколов и, например, могут использовать механизм файловой системы для передачи данных в соответствии с определенной спецификацией интерфейса между процессами, соответствующими концепции SOA. Ключом являются независимые службы с определенными интерфейсами, которые можно вызывать для выполнения своих задач стандартным способом, при этом служба не знает заранее о вызывающем приложении, а приложение не имеет или не нуждается в знаниях о том, как служба фактически выполняет свои задачи. SOA позволяет разрабатывать приложения, созданные путем объединения слабосвязанных и совместимых сервисов.
Эти службы взаимодействуют на основе формального определения (или контракта, например, WSDL), которое не зависит от базовой платформы и языка программирования. Определение интерфейса скрывает реализацию языковой службы. Таким образом, системы на основе SOA могут функционировать независимо от технологий и платформ разработки (таких как Java, .NET и т. д.). Например , службы, написанные на C#, работающие на платформах .NET, и службы, написанные на Java, работающие на платформах Java EE , могут использоваться общим составным приложением (или клиентом). Приложения, работающие на любой платформе, также могут использовать службы, работающие на другой, в качестве веб-служб, которые облегчают повторное использование. Управляемые среды также могут включать в себя устаревшие системы COBOL и представлять их как программные услуги. . [26]
Языки программирования высокого уровня , такие как BPEL , и такие спецификации, как WS-CDL и WS-Coordination, расширяют концепцию сервиса, предоставляя метод определения и поддержки оркестрации мелкодетализированных сервисов в более крупномасштабные бизнес-сервисы, которые, в свою очередь, могут получить архитекторы. включать в рабочие процессы и бизнес-процессы, реализованные в составных приложениях или порталах .
Сервис-ориентированное моделирование — это структура SOA, которая определяет различные дисциплины, которые помогают практикам SOA концептуализировать, анализировать, проектировать и проектировать свои сервис-ориентированные активы. Среда сервис -ориентированного моделирования (SOMF) предлагает язык моделирования и рабочую структуру или «карту», изображающую различные компоненты, которые способствуют успешному подходу сервис-ориентированного моделирования. Он иллюстрирует основные элементы, определяющие аспекты «что делать» в схеме разработки услуг. Модель позволяет специалистам-практикам составить план проекта и определить основные этапы инициативы, ориентированной на услуги. SOMF также предоставляет общую нотацию моделирования для обеспечения согласованности между бизнесом и ИТ-организациями.
Организационные преимущества
Некоторые корпоративные архитекторы полагают, что SOA может помочь предприятиям быстрее и с меньшими затратами реагировать на меняющиеся рыночные условия. [28] Этот стиль архитектуры способствует повторному использованию на макроуровне (сервисе), а не на микроуровне (классах). Это также может упростить подключение и использование существующих ИТ-активов (устаревших).
Идея SOA заключается в том, что организация может взглянуть на проблему целостно. Бизнес имеет более общий контроль. Теоретически не было бы массы разработчиков, использующих те наборы инструментов, которые им понравились бы. Скорее, они будут кодировать в соответствии со стандартом, установленным внутри бизнеса. Они также могут разработать SOA для всего предприятия, которая инкапсулирует бизнес-ориентированную инфраструктуру. SOA также рассматривается как система автомагистралей, обеспечивающая эффективность для водителей автомобилей. Дело в том, что если бы у каждого была машина, но нигде не было бы шоссе, все было бы ограничено и неорганизовано, любая попытка добраться куда-либо быстро или эффективно. Вице-президент IBM по веб-сервисам Майкл Либоу говорит, что SOA «строит магистрали». [29]
В некоторых отношениях SOA можно рассматривать скорее как архитектурную эволюцию, чем как революцию. Он отражает многие лучшие практики предыдущих программных архитектур. В системах связи, например, практически не было разработано решений, использующих по-настоящему статические привязки для связи с другим оборудованием в сети. Принимая подход SOA, такие системы могут подчеркнуть важность четко определенных интерфейсов с высокой степенью совместимости. Другие предшественники SOA включают компонентную разработку программного обеспечения и объектно-ориентированный анализ и проектирование (OOAD) удаленных объектов, например, в CORBA .
Сервис представляет собой автономную функциональную единицу, доступную только через формально определенный интерфейс. Услуги могут представлять собой своего рода «нанопредприятия», которые легко производить и улучшать. Также службы могут представлять собой «мегакорпорации», построенные как скоординированная работа подчиненных служб.
Причины рассматривать реализацию услуг как отдельные проекты от более крупных проектов включают:
- Разделение продвигает в бизнесе концепцию, согласно которой услуги могут предоставляться быстро и независимо от более крупных и медленно реализуемых проектов, распространенных в организации. Бизнес начинает понимать системы и упрощенные пользовательские интерфейсы, обращающиеся к услугам. Это говорит о гибкости . Другими словами, это способствует бизнес-инновациям и ускоряет выход на рынок. [30]
- Разделение способствует отделению услуг от потребляющих проектов. Это способствует хорошему дизайну, поскольку услуга разрабатывается без знания ее потребителей.
- Документация и тестовые артефакты службы не встроены в детали более крупного проекта. Это важно, когда услугу необходимо повторно использовать позже.
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 г. [update]примеры использования продемонстрировали потенциал объединения технологий и принципов Web 2.0 и SOA. [41]
Микросервисы [ править ]
Микросервисы — это современная интерпретация сервис-ориентированных архитектур, используемых для построения распределенных программных систем . Сервисы в микросервисной архитектуре [42] — это процессы , которые взаимодействуют друг с другом по сети для достижения цели. Эти службы используют протоколы , не зависящие от технологии . [43] которые помогают инкапсулировать выбор языка и платформ, делая их выбор внутренним вопросом службы. Микросервисы — это новый подход к реализации и внедрению SOA, ставший популярным с 2014 года (и после внедрения DevOps ) , в котором также делается упор на непрерывное развертывание и другие гибкие практики. [44]
Не существует единого общепринятого определения микросервисов. В литературе можно найти следующие характеристики и принципы:
- детальные интерфейсы (для независимо развертываемых сервисов),
- бизнес-ориентированная разработка (например, предметно-ориентированный дизайн ),
- ИДЕАЛЬНЫЕ архитектуры облачных приложений,
- полиглотное программирование и настойчивость,
- развертывание легкого контейнера,
- децентрализованная непрерывная доставка и
- DevOps с комплексным мониторингом услуг.
ориентированные архитектуры для интерактивных приложений Сервис -
Интерактивные приложения, требующие времени отклика в реальном времени, например интерактивные 3D-приложения с малой задержкой, используют специальные сервис-ориентированные архитектуры, отвечающие конкретным потребностям такого рода приложений. К ним относятся, например, оптимизированные распределенные вычисления и связь с малой задержкой, а также управление ресурсами и экземплярами. [45] [46] [47]
См. также [ править ]
- Интерфейс прикладного программирования
- Слабая связь
- Эталонная модель OASIS SOA
- Принцип детализации услуги
- Управление SOA
- Архитектура программного обеспечения
- Сервисно-ориентированные коммуникации (SOC)
- Сервис-ориентированная разработка приложений
- Сервис-ориентированные распределенные приложения
- Язык описания веб-приложения
Ссылки [ править ]
- ^ Перейти обратно: а б «Справочник по SOA. Что такое SOA?» . Сотрудничество.opengroup.org . Проверено 30 марта 2021 г.
- ^ Основы архитектуры программного обеспечения: инженерный подход . О'Рейли Медиа. 2020. ISBN 978-1492043454 .
- ^ «Глава 1: Сервис-ориентированная архитектура (SOA)» . msdn.microsoft.com . Архивировано из оригинала 7 июля 2017 года . Проверено 21 сентября 2016 г.
- ^ «Стандарты сервис-ориентированной архитектуры — Открытая группа» . www.opengroup.org .
- ^ «Что такое SOA?» . www.opengroup.org . Архивировано из оригинала 19 августа 2016 года . Проверено 21 сентября 2016 г.
- ^ Велте, Энтони Т. (2010). Облачные вычисления: практический подход . МакГроу Хилл. ISBN 978-0-07-162694-1 .
- ^ Основы архитектуры программного обеспечения: инженерный подход . О'Рейли Медиа. 2020. ISBN 978-1492043454 .
- ^ «Миграция на сервис-ориентированную архитектуру, часть 1» . 9 декабря 2008 года. Архивировано из оригинала 9 декабря 2008 года . Проверено 21 сентября 2016 г.
{{cite web}}: CS1 maint: bot: исходный статус URL неизвестен ( ссылка ) - ^ Перейти обратно: а б Майкл Белл (2008). «Введение в сервис-ориентированное моделирование». Сервис-ориентированное моделирование: анализ, проектирование и архитектура сервисов . Уайли и сыновья. п. 3 . ISBN 978-0-470-14111-3 .
- ^ Майкл Белл (2010). Шаблоны SOA-моделирования для сервис-ориентированного обнаружения и анализа . Уайли и сыновья. п. 390 . ISBN 978-0-470-48197-4 .
- ^ Томас Эрл (июнь 2005 г.). О принципах . Сервисориентация.org
- ^ «Блог о стратегиях платформы приложений: SOA мертва; да здравствуют сервисы» . Apsblog.burtongroup.com. 5 января 2009 года. Архивировано из оригинала 15 января 2009 года . Проверено 13 августа 2012 г.
- ^ Ивонн Бальцер Улучшите планы своих проектов SOA , IBM , 16 июля 2004 г.
- ^ Команда Microsoft Windows Communication Foundation (2012 г.). «Принципы сервис-ориентированного дизайна» . msdn.microsoft.com . Проверено 3 сентября 2012 г.
- ^ Принципы Томаса Эрла из SOA Systems Inc., восемь конкретных принципов ориентации сервисов .
- ^ «4.4 Рекомендации по использованию технологий контрактов веб-сервисов — анатомия контракта веб-сервисов» . ИнформИТ . 11 июня 2021 г. Проверено 9 сентября 2021 г.
- ^ Тони Шан (2004). «Создание сервис-ориентированной платформы электронного банкинга». Международная конференция IEEE по вычислительным услугам, 2004 г. (SCC 2004). Слушания. 2004 . стр. 237–244. дои : 10.1109/SCC.2004.1358011 . ISBN 978-0-7695-2225-8 . S2CID 13156128 . 2004 г.
- ^ Дуань, Юконг, Нанджангуд Ду, Вэньцай, Ван, Юнчжи, Няньцзюнь (2014). Международная конференция IEEE по веб-сервисам, 2014 г. стр , . 329–336. дои : 10.1109/ . ICWS.2014.55 978-1-4799-5054-6 . S2CID 17957063 .
- ^ Дуань, Юконг (2012). «Опрос по сервисному контракту». 2012 г. 13-я Международная конференция ACIS по программной инженерии, искусственному интеллекту, сетям и параллельным/распределенным вычислениям . ИИЭЭ . стр. 805–810. дои : 10.1109/СНПД.2012.22 . ISBN 978-1-4673-2120-4 . S2CID 1837914 .
- ^ Олаф Циммерманн, Чезаре Паутассо, Грегор Хопе, Бобби Вульф (2016). «Десятилетие моделей корпоративной интеграции» . Программное обеспечение IEEE . 33 (1): 13–19. дои : 10.1109/MS.2016.11 .
{{cite journal}}: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ Ротем-Гал-Оз, Арнон (2012). SOA-шаблоны . Публикации Мэннинга. ISBN 978-1933988269 .
- ^ Юлиш, Клаус; Сутер, Кристоф; Войталла, Томас; Циммерманн, Олаф (2011). «Соответствие требованиям – преодоление пропасти между аудиторами и ИТ-архитекторами» (PDF) . Компьютеры и безопасность . 30 (6–7): 410–426. CiteSeerX 10.1.1.390.3652 . дои : 10.1016/j.cose.2011.03.005 .
- ^ Бранднер М., Краес М., Оллерманн Ф., Циммерманн О., Архитектура, ориентированная на веб-сервисы, в производстве в финансовой отрасли, Informatik-Spektrum 02/2004, Springer-Verlag, 2004 г.
- ^ «www.ibm.com» . ИБМ . Проверено 10 сентября 2016 г.
- ^ «О выпуске SOAP версии 1.2 (рекомендация W3C)» (на японском языке W3.org, 24 июня 2003 г.). 13 августа 2012 г. Проверено
- ^ Окишима, Харухиру (2006). «. «Пример системной архитектуры, использующей ресурсы COBOL» » (PDF) .
- ^ Корпоративный SOA . Прентис Холл, 2005 г.
- ↑ Кристофер Кох. Новый план предприятия. Архивировано 16 января 2009 г., в Wayback Machine , журнал CIO , 1 марта 2005 г.
- ^ Элизабет Миллард (январь 2005 г.). «Построение лучшего процесса». Пользователь компьютера . Страница 20.
- ^ Браян Циммерли (11 ноября 2009 г.) Преимущества SOA для бизнеса , Университет прикладных наук Северо-Западной Швейцарии, Школа бизнеса
- ^ «JSR-000089 Финальная версия спецификации API активации службы OSS 1.0» . веб.архив.орг . 26 июля 2011. Архивировано из оригинала 26 июля 2011 года . Проверено 18 мая 2024 г.
- ^ Джо МакКендрик. «Брэй: SOA слишком сложна; «просто чушь поставщика» » . ЗДНет.
- ^ Джимми Чжан (20 февраля 2008 г.) «Индексирование XML-документов с помощью VTD-XML». Архивировано 4 июля 2008 г. в Wayback Machine . XML-журнал .
- ↑ Джимми Чжан (5 августа 2008 г.) «Точка зрения i-технологий: горе производительности двоичного XML». Архивировано 9 января 2020 г. на Wayback Machine . Журнал микросервисов .
- ^ Джимми Чжан (9 января 2008 г.) «Управляйте XML-контентом простым способом». Архивировано 30 июля 2017 г. в Wayback Machine . devx.com .
- ^ «Причина, по которой SOA не обеспечивает устойчивое программное обеспечение» . jpmorgenthal.com. 19 июня 2009 года . Проверено 27 июня 2009 г.
- ^ «Службы SOA все еще слишком ограничены приложениями, которые они представляют» . zdnet.com. 27 июня 2009 года . Проверено 27 июня 2009 г.
- ^ «Уровень управления» . www.opengroup.org . Архивировано из оригинала 4 июня 2016 года . Проверено 22 сентября 2016 г.
- ^ «Как эффективно тестировать сервис-ориентированную архитектуру | WSO2 Inc» . wso2.com . Проверено 22 сентября 2016 г.
- ^ «Что такое Веб 2.0» . Тим О'Рейли. 30 сентября 2005 года . Проверено 10 июня 2008 г.
- ^ Перейти обратно: а б Кристоф Шрот; Тилль Яннер (2007). «Web 2.0 и SOA: конвергенция концепций, обеспечивающих использование Интернета услуг» . ИТ-специалист . 9 (3): 36–41. дои : 10.1109/MITP.2007.60 . S2CID 2859262 . Архивировано из оригинала 3 декабря 2013 года . Проверено 23 февраля 2008 г.
- ^ Драгони, Никола; Джяллоренцо, Саверио; Альберто Ллуч Лафуэнте; Маццара, Мануэль; Монтези, Фабрицио; Мустафин, Руслан; Сафина, Лариса (2016). «Микросервисы: вчера, сегодня и завтра». arXiv : 1606.04036v1 [ cs.SE ].
- ^ Джеймс Льюис и Мартин Фаулер. «Микросервисы» .
- ^ Балалай, А.; Гейдарнури, А.; Джамшиди, П. (1 мая 2016 г.). «Архитектура микросервисов обеспечивает DevOps: переход к облачной архитектуре» (PDF) . Программное обеспечение IEEE . 33 (3): 42–52. дои : 10.1109/MS.2016.64 . hdl : 10044/1/40557 . ISSN 0740-7459 . S2CID 18802650 .
- ^ Фрэнк Глинка; Аллайти Раед (2009). «Сервис-ориентированный интерфейс для высокоинтерактивных распределенных приложений» . Европейская конференция по параллельной обработке . Конспекты лекций по информатике. Том. 6043. стр. 266–277. дои : 10.1007/978-3-642-14122-5_31 . ISBN 978-3-642-14121-8 . Проверено 9 февраля 2021 г.
- ^ Дитер Хильдебрандт; Ян Климке (2011). «Сервис-ориентированная интерактивная 3D-визуализация массивных 3D-моделей городов на тонких клиентах» . COM.Geo '11: Материалы 2-й Международной конференции по вычислениям для геопространственных исследований и приложений . п. 1. дои : 10.1145/1999320.1999326 . ISBN 9781450306812 . S2CID 53246415 . Проверено 9 февраля 2021 г.
- ^ Махи Али; Майкл Франке (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 г.
- Мауро, Кристиан; Леймейстер, Ян Марко; Крчмар, Хельмут (январь 2010 г.). «Интеграция сервис-ориентированных устройств — анализ шаблонов проектирования SOA» (PDF) . 2010 г. 43-я Гавайская международная конференция по системным наукам . стр. 1–10. дои : 10.1109/HICSS.2010.336 . ISBN 978-1-4244-5509-6 . S2CID 457705 . Архивировано из оригинала (PDF) 24 января 2022 года . Проверено 21 сентября 2021 г.
| Базы данных органов управления : Национальные |
|---|
