ГОСТ Р ИСО/МЭК 29363-2013
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Информационная технология
ФУНКЦИОНАЛЬНАЯ СОВМЕСТИМОСТЬ ВЕБ-СЛУЖБ
Профиль WS-I простой привязки SOAP. Версия 1.0
Information technology. Web Services Interoperability. WS-I Simple SOAP Binding Profile Version 1.0
ОКС 35.100.05
Дата введения 2015-01-01
Предисловие
Предисловие
1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Информационный аналитический вычислительный центр" (ООО "ИАВЦ") на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ приказом Федерального агентства по техническому регулированию и метрологии от 08 ноября 2013 г. N 1541-ст
4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 29363:2008* "Информационные технологии. Функциональная совместимость веб-служб. Профиль WS-I простой привязки SOAP. Версия 1.0" (ISO/IEC 29362:2008 "Information technology - Web Services Interoperability - WS-I Simple SOAP Binding Profile Version 1.0", IDT)
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке на сайт . - .
5 ВВЕДЕН ВПЕРВЫЕ
6 ПЕРЕИЗДАНИЕ. Январь 2019 г.
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Введение
Настоящий стандарт определяет профиль WS-I (Организация функциональной совместимости веб-служб - Web Services Interoperability Organization) простой привязки SOAP (Simple Object Access Protocol - простой протокол доступа к объектам) версии 1.0 (далее - "профиль"), состоящий из набора открытых спецификаций веб-служб, с разъяснениями и усилениями тех спецификаций, которые предназначены для обеспечения функциональной совместимости.
Настоящий стандарт подготовлен Организацией функциональной совместимости веб-служб - Web Services Interoperability Organization (WS-I) и принят Объединенным техническим комитетом СТК 1 ИСО/МЭК "Информационные технологии" в соответствии с процедурой, установленной для опубликованных технических спецификаций, параллельно с его одобрением национальными органами ИСО и МЭК.
1 Область применения и введение
1.1 Область применения
Настоящий стандарт определяет профиль WS-I (Организация функциональной совместимости веб-служб - Web Services Interoperability Organization) простой привязки SOAP (Simple Object Access Protocol - простой протокол доступа к объектам) версии 1.0 (далее - профиль), состоящий из набора открытых спецификаций веб-служб, с разъяснениями и усилениями тех спецификаций, которые предназначены для обеспечения функциональной совместимости.
В разделе 1 приведено описание профиля и объяснены его отношения с другими профилями.
В разделе 2 объяснено, что означает совместимость с профилем.
В последующих разделах рассмотрен компонент профиля, который состоит из двух частей: общего описания, в котором детализированы спецификации компонентов и вопросы их расширяемости, и рассмотрены отдельные части спецификаций компонентов. Необходимо отметить, что взаимосвязь между номерами разделов в настоящем стандарте и номерами разделов в спецификациях, на которые приведены ссылки, отсутствует.
1.2 Отношения с другими профилями
Данный профиль разработан исходя из тех требований основного профиля 1.0, которые связаны с преобразованием конверта в последовательную форму и его представления в сообщении, включая все исправления опечаток, обнаруженные до настоящего времени. Эти требования вынесены из основного профиля для того, чтобы другие профили были скомпонованными с ним.
Требование соответствия и к основному профилю, и к профилю простой привязки SOAP 1.0 приблизительно эквивалентно требованию соответствия к основному профилю.
1.3 Условные обозначения
Ключевые слова "ДОЛЖЕН" (MUST), "НЕ ДОЛЖЕН" (MUST NOT), "ТРЕБУЕМЫЙ" (REQUIRED), "БУДЕТ" (SHALL), "НЕ БУДЕТ" (SHALL NOT), "СЛЕДУЕТ" (SHOULD), "НЕ СЛЕДУЕТ" (SHOULD NOT), "РЕКОМЕНДУЕМЫЙ" (RECOMMENDED), "МОЖЕТ" (MAY) и "ДОПОЛНИТЕЛЬНЫЙ" (OPTIONAL) в настоящем стандарте должны интерпретироваться в соответствии с RFC2119.
Нормативные положения для требований профиля (т.е. те, которые влияют на соответствие, как описано в "Требованиях соответствия") представлены следующим способом:
Rnnnn Текст положения,
где nnnn - уникальное среди требований профиля число, в результате чего образуется уникальный идентификатор требования.
Таким образом, идентификаторы требований могут рассматриваться как квалифицированное пространство имен, совместимое с QNames из Пространства имен в XML. Если идентификатор требования не содержит никакого явного префикса пространства имен (например, "R9999" в отличие от "bp10:R9999"), то он должен рассматриваться как принадлежащий пространству имен, определяемому соответствующим универсальным идентификатором ресурса (URI) раздела документа, в котором он присутствует. Если эти условия соблюдены, то префикс следует интерпретировать согласно фактическим отображениям пространства имен, как показано далее.
Некоторые требования используются для пояснения соответствующих спецификаций, но не накладывают дополнительных ограничений на реализацию. Для удобства такие пояснения обозначаются следующим способом: с.
Отдельные требования являются результатом постоянно продолжающейся работы по стандартизации спецификаций, на которые они ссылаются. Для удобства такие положения, которые могут претерпеть изменения, обозначаются как: xxxx, где xxxx является идентификатором спецификации (например, "WSDL20" для версии 2.0 WSDL). Необходимо отметить, что, поскольку эта работа не завершена на момент публикации настоящего стандарта, спецификация, к которой относится требование, может измениться, и данная информация приводится только для удобства разработчиков.
В данной спецификации используется несколько префиксов пространств имен, которым соответствуют универсальные идентификаторы ресурсов URI. Необходимо отметить, что выбор любого префикса пространства имен произволен и не является семантически существенным:
- wsdl - "http://schemas.xmlsoap.org/wsdl/"
- soapbind - "http://schemas.xmlsoap.org/wsdl/soap/"
- uddi - "urn:uddi-org:api_v2"
1.4 Идентификация профиля и управление версиями
Данный документ идентифицирован наименованием (в данном случае - "Профиль простой привязки SOAP") и номером версии (здесь - 1.0). В совокупности они идентифицируют конкретный экземпляр профиля.
Номера версий составлены из основной и дополнительной частей в форме "основной.дополнительный". Они могут использоваться, чтобы определить приоритет экземпляра профиля; больший номер версии (с учетом и основного, и дополнительного компонентов) указывает, что данный экземпляр новее, и поэтому заменяет более ранние экземпляры.
Для экземпляров профилей с одинаковыми именами (например, "Пример профиля 1.1" и "Пример профиля 5.0") проблемы функциональной совместимости рассматриваются в одной и той же общей области действия, хотя при некоторых разработках может потребоваться, чтобы точная область действия профиля была различна для различных экземпляров.
Данная информация может также быть использована, чтобы определить, являются ли два экземпляра профиля обратно совместимыми, т. е. можно ли считать, что соответствие более раннему экземпляру профиля подразумевает соответствие более позднему. Экземпляры профиля с одним и тем же именем и номером основной версии (например, "Пример профиля 1.0" и "Пример профиля 1.1") МОГУТ считаться совместимыми. Совместимость в другом направлении не подразумевается, т. е. нельзя предполагать, что соответствие более позднему экземпляру профиля подразумевает соответствие более раннему.
2 Соответствие профилю
Соответствие профилю определено точным выполнением набора требований, определенных в рамках области применения профиля для определенной цели. Настоящий раздел объясняет эти термины и описывает, как определяется и используется соответствие.
2.1 Требования соответствия
Требования устанавливают критерии соответствия профилю. Они обычно ссылаются на существующую спецификацию и добавляют усовершенствования, усиления, интерпретации и разъяснения к ней, чтобы улучшить функциональную совместимость. Все требования в профиле считаются нормативными. Требования в спецификациях, на которые профиль ссылается в области действия (см. "Область соответствия"), также должны рассматриваться как нормативные. В случае, если требования в профиле и в спецификациях, на которые они ссылаются, противоречат друг другу, требования профиля имеют приоритет с целью обеспечения соответствия профиля.
Уровни обязательности требования, обозначенные в соответствии с RFC2119 (например, ДОЛЖЕН, МОЖЕТ, СЛЕДУЕТ и т.п.), указывают на природу требования и его воздействия на соответствие. Для удобства каждое требование имеет индивидуальный идентификатор (например, R9999).
Пример - R9999 Виджетам (WIDGETs) СЛЕДУЕТ (SHOLUD) быть круглой формы.
Это требование, идентифицированное как R9999, применяется к целевому ВИДЖЕТУ (WIDGET) (см. далее) и предъявляет условное требование к совокупности виджетов, т.е. хотя это требование в большинстве случаев должно быть удовлетворено, чтобы реализация соответствовала профилю, имеются отдельные ситуации, когда могут быть уважительные причины нарушения требования. Такие причины объясняются непосредственно в требовании или в сопровождающем его тексте.
Каждое положение требований содержит одно и только одно ключевое слово уровня обязательности требования [например, "ДОЛЖЕН" (MUST)] и одно ключевое слово цели соответствия [например, "СООБЩЕНИЕ" (MESSAGE)]. Ключевое слово цели соответствия показано жирным шрифтом [например, "СООБЩЕНИЕ" (MESSAGE)]. Другие цели соответствия, показанные нежирным шрифтом, используются строго для их определения, а НЕ для цели соответствия. Для объяснения требования или группы требований может быть включен дополнительный текст (например, обоснование и примеры); однако текст, не входящий непосредственно в положения требований, не должен рассматриваться при определении соответствия.
Определения терминов профиля считаются надежными для целей определения соответствия.
Ни одно из требований профиля, независимо от уровня его обязательности, не должно быть истолковано как ограничивающее возможность реализации соответствующих контрмер безопасности в ответ на реальные или предполагаемые угрозы (например, на атаку отказа в обслуживании).
2.2 Цели соответствия
Цели соответствия определяют, к каким артефактам применяются требования. Примерами целей являются: сообщение SOAP, описание WSDL (Web Services Description Language - язык описания веб-служб и доступа к ним), данные реестра UDDI (Universal Description Discovery & Integration - инструмент для расположения описаний веб-служб) или стороны, например, процессор SOAP, конечный пользователь.
Это позволяет определить соответствие в различных контекстах для гарантии однозначной интерпретации применимости требований и обеспечения проверки артефактов (например, сообщений SOAP и описаний WSDL) и функциональных возможностей различных сторон на соответствие веб-службе (например, конкретным клиентам и службам).
Для обеспечения однозначности и упрощения тестирования целями соответствия в требованиях являются, где это возможно, физические артефакты.
В профиле используются следующие цели соответствия:
КОНВЕРТ (ENVELOPE) - преобразование в последовательную форму элемента soap:Envelope и его содержимого (см. ИСО/МЭК 29361).
СООБЩЕНИЕ (MESSAGE) - элементы протокола, посредством которых осуществляется передача КОНВЕРТА (например, сообщение SOAP/HTTP) (см. ИСО/МЭК 29361).
ОПИСАНИЕ (DESCRIPTION) - описания типов, сообщений, интерфейсов и их конкретных протоколов, привязки форматов данных, и сетевых точек доступа, связанных с веб-службами (например, описания WSDL) (см. ИСО/МЭК 29361).
РЕАЛИЗАЦИЯ (INSTANCE) - программное обеспечение, которое осуществляет выполнение связывания wsdl:port или uddi:bindingTemplate (см. ИСО/МЭК 29361).
ПОЛУЧАТЕЛЬ (RECEIVER) - программное обеспечение, которое использует сообщение в соответствии со связанными с ним протоколом или протоколами (например, процессоры SOAP) (см. ИСО/МЭК 29361).
2.3 Область соответствия
Область применения профиля ограничивается технологиями, для которых он предназначен. Другими словами, профиль всего лишь пытается улучшить функциональную совместимость в пределах своей собственной области применения. Обычно область применения профиля ограничена спецификациями, на которые он ссылается.
Область применения профиля уточняется далее возможными расширениями. Технические спецификации зачастую обеспечивают механизмы расширения и неопределенные или открытые параметры конфигурации. Если в профиле определено возможное расширение, то такой механизм или параметр не входит в область применения профиля, и его использование или неиспользование выходит за рамки требований соответствия.
Обратите внимание, что профиль все же может выдвинуть требования по использованию расширений. Кроме того, конкретные случаи использования расширения могут быть еще более ограничены другими профилями для улучшения функциональной совместимости при использовании сочетания профилей.
Поскольку использование возможных расширений может нарушить функциональную совместимость, их использование должно быть согласовано или задокументировано потребителями веб-служб в некоторой форме, например, в виде дополнительного соглашения.
Область применения профиля определена техническими условиями, перечисленными в Приложении А, и уточняется возможными расширениями, указанными в Приложении В.
2.4 Декларация о соответствии
Декларации о соответствии профилю могут быть сделаны с использованием механизмов, описанных в спецификации "Механизмы вложения деклараций о соответствии", в случае, если были удовлетворены применимые требования профиля, связанные со следующими целями:
WSDL 1.1 Механизм вложения деклараций для конкретных реализаций веб-служб (Claim Attachment Mechanism for Web Services Instances) -
ПОЛУЧАТЕЛЬ ЭКЗЕМПЛЯРА ОПИСАНИЯ СООБЩЕНИЯ.
WSDL 1.1 Механизм вложения деклараций для конструкций описания (Claim Attachment Mechanism for Description Constructs) -
ОПИСАНИЕ.
UDDI Механизм вложения деклараций для конкретных веб-служб (Claim Attachment Mechanism for Web Services Instances -
ПОЛУЧАТЕЛЬ ЭКЗЕМПЛЯРА ОПИСАНИЯ СООБЩЕНИЯ.
URI декларации о соответствии для этого профиля http://wsi.org/profiles/attachments/1.0.
3 Обмен сообщениями
Данный раздел профиля включает следующие ссылки на спецификации и определяет возможные в них расширения:
Простой протокол доступа к объектам версии 1.0 [Simple Object Access Protocol (SOAP) 1.1].
Расширяемый язык разметки (XML) 1.0 (вторая редакция) (Extensible Markup Language (XML) 1.0 (Second Edition)).
Пространства имен в XML 1.0 (Namespaces in XML 1.0).
RFC2616: протокол HTTP версии 1.1 (Hypertext Transfer Protocol - HTTP/1.1).
3.1 Сериализация сообщения (Message Serialization)
Для передачи сообщений SOAP 1.1 определяет структуру XML-конверт. Профиль налагает требования на использование этой структуры и определяет следующие ограничения на ее использование.
3.1.1 Сериализация конверта XML (XML Envelope Serialization)
R9700 СООБЩЕНИЕ ДОЛЖНО сериализировать конверт как особое информационное наполнение тела объекта HTTP.
R9701 СООБЩЕНИЕ ДОЛЖНО сериализировать конверт как XML 1.0.
R9702 В СООБЩЕНИИ ДОЛЖНО присутствовать поле "Content-Type" HTTP-заголовка.
R9703 Поле "Content-Type" HTTP-заголовка СООБЩЕНИЯ ДОЛЖНО иметь значение, тип медиа (media type) которого - "text/xml".
3.1.2 Объявления пространства имен XML
Хотя опубликованное исправление NE05 (см. http://www.w3.org/XML/xml-names-19990114-errata) допускает присутствие такого объявления пространства имен, некоторые более старые системы обработки считают такие объявления ошибкой.
R9704 В КОНВЕРТ НЕ СЛЕДУЕТ помещать объявление пространства имен xmlns:xml="http://www .w3.org/XML/1998/namespace".С
3.1.3 Маркеры последовательности байтов юникода (Unicode BOMs)
XML 1.0 допускает включение маркеров последовательности байтов (ВОМ) при кодировке UTF-8, поэтому получатели конвертов должны быть готовы принять их. Маркер последовательности байтов обязателен для XML при кодировании как UTF-16.
R4001 ПОЛУЧАТЕЛЬ ДОЛЖЕН принимать конверты, в которые включены маркеры последовательности байтов юникода (ВОМ).С
3.1.4 Декларация XML (XML Declaration)
Наличие или отсутствие декларации XML не влияет на функциональную совместимость. В отдельных реализациях объявления XML могут всегда предшествовать их XML-сериализации.
R1010 ПОЛУЧАТЕЛЬ ДОЛЖЕН принимать сообщения с конвертами, которые содержат декларацию XML.С
3.1.5 Кодирование символов
Для обеспечения функциональной совместимости профиль требует, чтобы процессоры XML поддерживали кодирование символов UTF-8 и UTF-16.
Как следствие, в сочетании с требованием SOAP 1.1 использования в конвертах типа медиа (media type) "text/xml", у которого кодировка символов по умолчанию "us-ascii", параметр "charset" должен всегда присутствовать в "content-type" конверта. Далее псевдоатрибут кодирования объявления XML всегда игнорируется в пределах сообщения в соответствии с требованиями как XML 1.0, так и RFC3023, "XML типы медиа" (XML Media Types).
Для определения правильной кодировки символов сообщения должен использоваться параметр "charset" поля Content-Type HTTP-заголовка. При отсутствии параметра "charset" должно использоваться значение набора символов по умолчанию, которым является "us-ascii".
R1012 СООБЩЕНИЕ ДОЛЖНО сериализировать конверт, используя кодировку символов либо UTF-8, либо UTF-16.
R1018 Значение поля "Content-Type" HTTP-заголовка СООБЩЕНИЯ ДОЛЖНО указать на правильную кодировку символов, используя параметр "charset" С
R1019 ПОЛУЧАТЕЛЬ ДОЛЖЕН проигнорировать псевдоатрибут кодирования декларации XML в конверте сообщения
4 Описание
Данный раздел профиля содержит ссылку на следующую спецификацию и определяет возможные расширения в ее пределах:
WSDL 1.1, Section 3
WSDL 1.1 определяет расширение привязки SOAP для описания сообщений, сериализированных как конверты SOAP. Профиль определяет требования по использованию этой структуры и накладывает ограничения на ее использование, изложенные далее.
4.1 Привязки (Bindings)
4.1.1 Расширения привязки SOAP (SOAP Binding Extensions)
Профиль ограничивает выбор привязки WSDL, четко определенной и обычно используемой WSDL привязкой SOAP. В WSDL 1.1 определено, что расширения привязки для HTTP GET/POST и MIME, а также для любых других технологий вложений, профилем не допускаются.
R9802 Элемент wsdl:binding в ОПИСАНИИ ДОЛЖЕН использовать только привязку WSDL SOAP, как определено в разделе 3 WSDL 1.1.
R9800 В ОПИСАНИИ расширения привязки WSDL HE ДОЛЖНЫ использоваться элементы и атрибуты, которые вызывают несовместимость с профилем сообщений в процессе их передачи.С
R9801 Расширения WSDL привязок MIME и HTTP GET/POST, а также DIME (Direct Internet Message Encapsulation - прямая инкапсуляция интернет-сообщений) НЕ ДОЛЖНЫ присутствовать в ОПИСАНИИ привязки SOAP.C
Необходимо отметить, что это предъявляет требование к конструкции совместимых элементов привязки wsdl:binding. Это требование не является требованием к описанию в целом; в частности оно не исключает присутствие несовместимых элементов привязки wsdl:binding в документах WSDL.
Возможны случаи, когда отправитель может иметь возможность отправлять сообщения, используя SOAP с вложениями, однако не способен получать и обрабатывать такие сообщения.
R2901 В ОПИСАНИИ в каждом из элементов wsdl:input или wsdl:output соответствующего wsdl:binding ДОЛЖНА использоваться или привязка WSDL MIME, как описано в разделе 5 WSDL 1.1, или привязка WSDL SOAP, как описано в разделе 3 WSDL 1.
4.1.2 Несвязанное содержимое элемента portType
WSDL 1.1 не определяет явно, допустимо ли для wsdl:binding оставить неопределенной привязку для частей контента, определенных wsdl:portType.
R2209 Привязка wsdl:binding в ОПИСАНИИ ДОЛЖНА связывать каждую часть wsdl:part сообщения wsdl:message, на которые ссылается в wsdl:portType, с одним из soapbind:body, soapbind:header, soapbind:fault, soapbind:headerfault или mime:content.
portType определяет абстрактный интерфейс (contract) с именованным набором операций и соответствующих абстрактных сообщений. Хотя это и не запрещено, ожидается, что каждая часть абстрактного входящего, исходящего сообщения или сообщения об ошибке, специфицированого в PortType, связана с soapbind:body или soapbind:header (и прочими) или с mime:content соответствующим образом с использованием привязки MIME, как это определено в разделе 5 WSDL 1.1. Несвязанные части wsdl:parts должны игнорироваться потребителем.
Приложение А. Ссылки на спецификации
Приложение А
В профиль включены ссылки на требования следующих спецификаций, за исключением тех случаев, когда требования заменяются требованиями самого профиля:
Простой протокол доступа к объектам (Simple Object Access Protocol (SOAP) 1.1).
Расширяемый язык разметки (XML) 1.0 (вторая редакция) (Extensible Markup Language (XML) 1.0 (Second Edition)).
Пространства имен в XML 1.0 (Namespaces in XML 1.0).
RFC2616: Протокол передачи гипертекста HTTP/1.1 (Hypertext Transfer Protocol - HTTP/1.1)
Язык описания веб-сервисов WSDL 1.1, Раздел 3.0 (WSDL 1.1, Section 3.0).
Приложение В. Возможные расширения
Приложение В
Это приложение идентифицирует возможные расширения, как определено в "Области применения профиля" для спецификаций компонентов профиля.
Данные механизмы находятся вне области применения профиля; их использование может повлиять на функциональную совместимость и потребовать частного соглашения сторон с веб-сервисами.
Расширения отсутствуют.
Приложение С. Нормативные ссылки
Приложение С
В дополнение ко всем профильным спецификациям, перечисленным в Приложении А, в материале использовались также ссылки на следующие спецификации:
RFC2119 Ключевые слова для использования в RFC для указания уровня требования, http://ietf.org/rfc/rfc2119, S. Bradner, Март 1997.
Базовый профиль WS-I, версия 1.0, http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html, К. Ballinger et al., Апрель 2004.
Пространства имен в XML 1.0 (второе издание):
http://www.w3.org/TR/2006/REC-xml-names-20060816, Т. Bray et al., Август 2006.
Механизм вложения декларации о соответствии WS-I, версия 1.0 http://www.ws-i.org/Profiles/ConformanceClaims-1.0-2004-11-15.html, М. Nottingham et al., ноябрь 2004.
Приложение D. Благодарности
Приложение D
Настоящий стандарт является результатом работы рабочей группы по базовому профилю WS-I, в которую входили:
Mark Allerton (Crystal Decisions Corp), Steve Anderson (OpenNetwork), George Arriola (Talking Blocks, Inc.), Siddharth Bajaj (Verisign), Keith Ballinger (Microsoft Corp.), David Baum (Kantega AS), llya Beyer (KANA), Rich Bonneau (IONA Technologies), Don Box (Microsoft Corp.), Andrew Brown (Verisign), Heidi Buelow (Quovadx), David Burdett (Commerce One, Inc.), Luis Felipe Cabrera (Microsoft Corp.), Maud Cahuzac (France Telecom), Mike Chadwick (Kaiser Permanente), Martin Chapman (Oracle Corporation), Richard Chennault (Kaiser Permanente), Roberto Chinnici (Sun Microsystems), Dipak Chopra (SAP AG), Jamie Clark (OASIS), David Cohen (Merrill Lynch), Ugo Corda (SeeBeyond Tech), Paul Cotton (Microsoft Corp.), Joseph Curran (Accenture), Alex Deacon (Verisign), Mike DeNicola (Fujitsu Limited), Paul Downey (ВТ Group), Jacques Durand (Fujitsu Limited), Aladin Eajani (Hummingbird, Ltd.), Michael Eder (Nokia), Dave Ehnebuske (IBM), Mark Ericson (Mindreef Inc), Colleen Evans (Microsoft Corp.), Tim Ewald (Microsoft Corp.), Chuck Fay (FileNET Corp.), Chris Ferris (IBM), Daniel Foody (Actional Corporation), Satoru Fujita (NEC Corporation), Shishir Garg (France Telecom), Yaron Goland (BEA Systems Inc), Marc Goodner (SAP AG), Pierre Goyette (Hummingbird, Ltd.), Hans Granqvist (Verisign), Martin Gudgin (Microsoft Corp.), Marc Hadley (Sun Microsystems), Norma Hale (Webify Solutions Inc), Bob Hall (Unisys Corporation), Scott Hanselman (Corillian), Muir Harding (Autodesk Inc.), Loren Hart (Verisign), Andrew Hately (IBM), Harry Holstrom (Accenture), Lawrence Hsiung (Quovadx), Hemant Jain (Tata Consultancy), Steve Jenisch (SAS Institute), Erik Johnson (Epicor Software), Bill Jones (Oracle Corporation), Anish Karmarkar (Oracle Corporation), Dana Kaufman (Forum Systems), Takahiro Kawamura (Toshiba), Oldre Kepka (Systinet), Bhushan Khanal (WRQ Inc.), Sandy Khaund (Microsoft Corp.), Jacek Kopecky (Systinet), Sanjay Krishnamurthi (Informatica), Sundar Krishnamurthy (Verisign), Eva Kuiper (Hewlett-Packard), Sunil Kunisetty (Oracle Corporation), Christopher Kurt (Microsoft Corp.), Lars Laakes (Microsoft Corp.), Canyang Kevin Liu (SAP AG), Ted Liu (webMethods Inc.), Donna Locke (Oracle Corporation), Brad Lund (Intel), Michael Mahan (Nokia), Ron Marchi (EDS), Jonathan Marsh (Microsoft Corp.), Eric Matland (Hummingbird, Ltd.), Barbara McKee (IBM), Derek Medland (Hummingbird, Ltd.), David Meyer (Plumtree Software Inc.), Jeff Mischkinsky (Oracle Corporation), Ray Modeen (MITRE Corp.), Tom Moog (Sarvega Inc.), Gilles Mousseau (Hummingbird, Ltd.), Greg Mumford (MCI), Jim Murphy (Mindreef Inc), Bryan Murray (Hewlett-Packard), Richard Nikula (BMC Software, Inc.), Eisaku Nishiyama (Hitachi, Ltd.), Mark Nottingham (BEA Systems Inc), David Orchard (BEA Systems Inc), Vivek Pandey (Sun Microsystems), Jesse Pangburn (Quovadx), Eduardo Pelegri-Llopart (Sun Microsystems), Mike Perham (Webify Solutions Inc), Eric Rajkovic (Oracle Corporation), Shaan Razvi (MITRE Corp.), Rimas Rekasius (IBM), Mark Richards (Fidelity), Graeme Riddell (Bowstreet), Sam Ruby (IBM), Tom Rutt (Fujitsu Limited), Saikat Saha (Commerce One, Inc.), Roger Sanborn (Crystal Decisions Corp), Matt Sanchez (Webify Solutions Inc), Krishna Sankar (Cisco Systems Inc.), Jeffrey Schlimmer (Microsoft Corp.), Don Schricker (Micro Focus), Dave Seidel (Mindreef Inc), AKIRA SHIMAYA (NTT), David Shoaf (Hewlett-Packard), Yasser Shohoud (Microsoft Corp.), David Smiley (Ascential Software), Seumas Soltysik (IONA Technologies), Joseph Stanko (Plumtree Software Inc.), Andrew Stone (Accenture), Julie Surer (MITRE Corp.), YASUO TAKEMOTO (NTT), Nobuyoshi Tanaka (NEC Corporation), Jorgen Thelin (Microsoft Corp.), Sameer Vaidya (Talking Blocks, Inc.), William Vambenepe (Hewlett-Packard), Claus von Riegen (SAP AG), Rick Weil (Eastman Kodak Company), Scott Werden (WRQ Inc.), Ajamu Wesley (IBM), Ian White (Micro Focus), Dave Wilkinson (Vignette), Mark Wood (Eastman Kodak Company), Prasad Yendluri (webMethods Inc.), and Brandon Zhu (NetManage Inc).
УДК 004:006.354 | ОКС 35.100.05 |
Ключевые слова: интероперабельность, базовый профиль |
Электронный текст документа
и сверен по:
официальное издание
М.: Стандартинформ, 2019
