ГОСТ ISO/IEC 24824-2—2013
П римечание — «XSD схема» в данном случае является не «документом-схемой», а абстрактной схе
мой (набор компонентов схемы — см. W3C XML схема), чьи XML представления состоят из одного или нескольких
«xsd:schema» членов информации элемента. Как правило, схема встроена в описание сервиса с помощью добав
ления ее XML представления.
12.2.3 Набор всех XSD схем, импортированных или встроенных в описание сервиса, называется
исходным набором схем.
12.2.4 Каждый тип данных содержимого в исходном наборе схем может быть описан либо вы
сокоуровневым компонентом схемы element declaration, либо высокоуровневым компонентом схемы
complex typo definition или simple type definition
12.3Абстрактные интерфейсы и абстрактные операции
12.3.1 Абстрактный интерфейс описывается путем предоставления информации для набора аб
страктных операций и неявно содержит следующую информацию о схеме (вытекающую из другой ин
формации в описании сервиса):
a) RPC схема (см. 12.3.2), а также
b) ASN.1 набор схем (см. 12.3.3).
12.3.2 RPC схема представляет собой специально созданную XSD схему, поддерживающую кон
кретные интерфейсы RPC-вида. и должна быть получена, как указано в 12.5. Исходный набор схем с
добавленной RPC схемой называется полным набором схем абстрактного интерфейса.
12.3.3 ASN.1 набор схем является ASN.1 отображением полного набора схем абстрактного ин
терфейса. Каждая XSD схема в полном наборе схем должна быть отображена независимо вASN.1, как
указано в МСЭ-Т Х.694 | ISO/1EC 8825-5. ASN.1 модули, сформированные Х.694 отображением, форми
руют ASN.1 набор схем абстрактного интерфейса.
12.3.4 Абстрактная операция определяется с помощью следующей информации:
a) названия операции (квалифицированное название):
b
) (опционально) определения входного сообщения:
c) (опционально) определения выходного сообщения и
d)
набора из нуля или более определений сообщений об ошибке.
12.3.5 Если присутствуют оба определения входного и выходного сообщения, то порядок, в кото
ром они появлялись (например, запрос и ответ), не смотря на то что он не рассматривается в настоя
щем стандарте, должен быть указан описанием сервиса.
12.3.6 Определение входного сообщения и определение выходного сообщения должны иметь
одну из следующих форм:
a) ноль или одно высокоуровневое element declaration, которое принадлежит к одной из схем в
исходном наборе схем (см. 12.2.4), или
b
) список из нуля или более различных неквалифицированных имен, каждое из которых связано
с высокоуровневым complex type definition или simple typo definition, которое принадлежит одной из
схем в исходном наборе схем (см. 12.2.4).
П римечание — В некоторых языках описания сервисов (например WSDL 1.1 [2)) форма описания
входного или выходного сообщения будет указана операционной привязкой, как ограничения на информацию (не
описано в настоящем стандарте), которая предоставляется абстрактной операцией.
12.3.7 Каждое определение сообщения об ошибке должно указывать высокоуровневое element
declaration, которое принадлежит одной из схем в исходном наборе схем (см. 12.2.4).
12.3.8 Интерфейс называется документо-ориентированным, если для каждой операции опреде
ление входного сообщения (если имеется) и определение выходного сообщения (если имеется) имеют
вид согласно 12.3.6, а).
12.3.9 Интерфейс называется RPC-ориентированным, если для каждой операции определение
входного сообщения (имеется) и определение выходного сообщения (если имеется) имеют вид соглас но
12.3.6. Ь).
12.3.10 В противном случае интерфейс не является ни документо-ориентированным, ни RPC-
ориентированным и описание сервиса, содержащее такие абстрактные интерфейсы, не является
SOAP-ориентированным описанием сервиса, как описано в настоящем стандарте.
12.4Интерфейсные и операционные привязки
12.4.1Интерфейсная привязка связывает абстрактный интерфейс с дополнительной информа
цией. результатом чего является полная спецификация конкретного интерфейса.
19