ISO 24097-1:2017

INTERNATIONAL ISO
STANDARD 24097-1
Second edition
2017-07
Intelligent transport systems — Using
web services (machine-machine
delivery) for ITS service delivery —
Part 1:
Realization of interoperable web
services
Utilisation des services du Web (livraison de machine à machine) pour
la livraison de services ITS —
Partie 1: Réalisation des services du Web interopérables
Reference number
©
ISO 2017
© ISO 2017, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2017 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 2
3 Terms, definitions and abbreviated terms . 2
3.1 Terms and definitions . 2
3.2 Abbreviated terms . 3
4 Conformance . 3
5 Notation . 4
5.1 Prefixes and namespace URI used in core specification . 4
5.2 Web service syntax notation: BNF pseudo-schemas . 4
5.3 XPath 1.0 notation . 5
5.4 Notation of service provider, service consumer combination . 5
5.5 SOA stack name notation . 5
5.6 Set notation . 5
5.7 Tentative IRI expression . 5
5.8 Rnnnn (nnnn: digits integer) . 5
6 Requirements . 6
6.1 Basic concept of web services standardization . 6
6.1.1 Web services architecture . 6
6.1.2 International standard web service standardization . 7
6.2 Web service metadata . 8
6.2.1 Common requirements and recommendations for metadata . 9
7 Service description layer .11
7.1 Service description layer structure .11
7.2 Service description layer: Requirement and recommendation for interface
description sublayer .11
7.2.1 Role of WSDL .11
7.2.2 Multiple WSDL specifications .11
7.2.3 WSDL and SOAP relationship . .13
7.2.4 ITS web service interface metadata (WSDL) versioning rule .13
7.2.5 Requirement and recommendation for applying WSDL 2.0 .13
7.3 Service description layer: Requirement and recommendation for policy
description sublayer .14
7.3.1 WS-Policy role and syntax .14
7.3.2 Requirement and recommendation for policy description.17
7.4 Service description layer: Requirement and recommendation for addressing sublayer .18
8 Quality of service layer .18
8.1 Quality of service layer: Requirement and recommendation for reliable
messaging sublayer .18
8.1.1 Requirement and recommendation for reliable messaging policy description .18
8.2 Quality of service layer: Requirement and recommendation for security sublayer .20
8.3 Quality of service layer: Requirement and recommendation for transaction sublayer .20
9 Messaging layer.20
9.1 Messaging layer: Requirement and recommendation for XML messaging .20
9.1.1 Role of SOAP.20
9.1.2 SOAP Structure .21
9.1.3 SOAP 1.2 relationship to WSDL 1.2 .21
9.1.4 SOAP message transmission optimization (MTOM) policy.21
10 Service publication/discovery layer .21
10.1 Service publication/discovery layer: requirement and recommendation for
universal description, discovery, and integration .21
10.1.1 Role of UDDI .21
10.1.2 UDDI components .22
10.1.3 Public UDDI .22
10.1.4 Requirement and recommendation for service registration stack .24
Annex A (normative) Principles and evolution of WSDL from version 1.1 to 2.0 .25
Annex B (informative) WSDL syntax .36
Bibliography .39
iv © ISO 2017 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO’s adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following
URL: w w w . i s o .org/ iso/ foreword .html.
This document was prepared by ISO/TC 204, Intelligent transport systems.
This second edition cancels and replaces the first edition (ISO 24097-1:2009), which has been technically
revised.
A list of all the parts in the ISO 24097- series, can be found on the ISO website.
Introduction
ITS services have been evolving from single functional and limited area specific services, to a broad
range of services in which many systems co-operate to provide effective and efficient service provision
across a wide area. Today, ITS services are required to communicate not just with other parts of
the same ITS service, but between different ITS services, and even with non-ITS services or a user’s
system directly, e.g. traffic management systems, route guidance systems, homeland security systems,
environment protection systems, private freight management systems, etc.
These systems (even those limited to ITS services) are usually deployed in a heterogeneous environment
that may use different hardware, operating systems (OS), middleware, and/or development languages.
This creates a challenge to realize system coordination across the organizations in a way that is flexible
and quick, at a reasonable cost. Web services (WS) are a recent methodology that overcomes these
difficulties. Using web service technology for ITS services can significantly simplify and reduce the cost
of internet based service provision, which may well affect the speed at which ITS services are deployed.
The World Wide Web Consortium (W3C) defines web services as follows:
“A web service is a software system designed to support interoperable machine-to-machine interaction
over a network. It has an interface described in a machine-processable format (specifically WSDL (Web
Services Description Language)). Other systems interact with the web service in a manner prescribed
by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in
conjunction with other web-related standards.”
Web services require significant functionality, and as a result, an architecture is indispensable. Web
service standardization organizations construct standards by SOA. SOA is the evolutional form of
distributed computing and object orientation.
By applying SOA-based standards to the ITS services, the following benefits are expected.
From a business viewpoint:
— Increased service value;
— Internationalization; and
— Expansion towards business automation.
From a system development viewpoint:
— Easy and quick development of ITS service coordination and service area expansion;
— More efficient service development (web services enable system developers to focus on the “what”
rather than the “how.” “How” is covered by a set of standard base tools. This enables quick and easy
system software development;
— More reusable software because web service standards have a composable structure, and
— Easier connections to legacy systems.
In the ITS sector, a significant number of messages have been or are being developed (and in some cases
standardized). Message standardization is intended to improve system coordination, interoperability
and re-use, so the conditions for web services are already considered mature. In addition, the use of
web services will increase the flexibility of ITS services to interoperate and communicate beyond the
ITS sector and in areas where the delineation between ITS services and general commercial services
converge.
From the perspective of web services standards evolution, 2007 was an epoch-making year. WSDL
2.0 became the W3C recommendation. Correspondingly, relevant web service specifications were
standardized by open standards bodies (W3C and OASIS). These standards cover all functional layers.
By using these standards, the ITS sector has a rigid base for interoperable web services.
vi © ISO 2017 – All rights reserved

ITS service collaboration with other sectors is expected to increase mutual effectiveness. Economic
globalization also requires communication across the country, often across the world. All of these
collaborations rely on interoperability of services. Interoperability is only achieved based on open
international standards.
Web services were developed to use distributed network resources in an interoperable way. However,
to realize interoperable web services various capabilities are required.
Using web services (machine-machine delivery) for ITS service delivery has been developed considering
these circumstances. ISO 24097 consists of two parts: ISO 24097-1 and ISO/TR 24097-2.
This document focuses on a way to realize interoperable ITS web services. ISO/TR 24097-2 will be an
example-based document which will show how to realize interoperable web services.
INTERNATIONAL STANDARD ISO 24097-1:2017(E)
Intelligent transport systems — Using web services
(machine-machine delivery) for ITS service delivery —
Part 1:
Realization of interoperable web services
1 Scope
This document establishes a Service Oriented Architecture (SOA) for the realization of interoperable
web services for Intelligent Transport Systems (ITS).
Web service behaviour is described at the metadata level, i.e. a higher level of abstraction, to enable
auto-generation of both a ‘service requester’ program as well as a ‘service provider’ program. Figure 1
presents the principal entities involved in a web service scenario. They are service provider, service
requester, and ‘registry’. The registry includes business information and technical information such as
interface and policy. Figure 1 also depicts the actions of the service provider and the service requester.
A service provider interacts with the registry to enable it to “publish” the provided service. The service
is characterized in the form of a web service interface describer in the form of a standardized web
service description language (WSDL) and policy (WS-Policy). A service requester interacts with the
registry to “discover” a provider for the service he is seeking. That interaction takes place through
“Universal Description Discovery, and Integration” (UDDI) dialogue and endpoint reference (EPR).
Once the service requester identifies a service provider, he “binds” to the service provider via an SOA
protocol.
This document is applicable to inter-ITS sector web services as well as ITS web services for non-ITS users.
Figure 1 — Web service entities and their relationships
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 14817 (all parts), Intelligent transport systems — ITS central data dictionaries
NOTE See Bibliography for general W3C references.
3 Terms, definitions and abbreviated terms
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
—  IEC Electropedia: available at http:// www .electropedia .org/
—  ISO Online browsing platform: available at http:// www .iso .org/ obp
General terms of W3C web service definitions can be obtained from the website w w w .w3 .org/ tr/ ws
-arch/ and terms defined in a specific web service standard are also referable.
3.1 Terms and definitions
3.1.1
composability
facility enabling web services to add new features incrementally
3.1.2
domain
functional area in a policy assertion
EXAMPLE Security, reliability, transaction, messaging optimization.
3.1.3
ITS WS
web service that is designed specifically to support ITS services via the internet
3.1.4
international standard web service
web service conformant to this document
3.1.5
platform
hardware, operating system, middleware, and application development language which provide a
system environment
3.1.6
policy assertion
element of service metadata which identifies a domain (such as messaging, security, reliability and
transaction) specific behaviour
3.1.7
skeleton
elements of service-side code used for receiving remote method calls, invoking them and returning the
result to the sender
3.1.8
stub
client code required to talk to a remote service
2 © ISO 2017 – All rights reserved

3.1.9
WS metadata
service metadata
metadata
high-level service description of a web service that controls provision of that service
3.2 Abbreviated terms
BNF Backus-Naur Form
BP basic profile (of Web Services Interoperability Organization)
BPEL business process execution language
DD data dictionary
DR data registry
EPR endpoint reference
HTTP hypertext transfer protocol
HTTPS hypertext transfer protocol security
IRI internationalized resource identifier
MIME multipurpose internet mail extension
MOF meta object facility
MTOM (SOAP) Message Transmission Optimization Mechanism
OID Object Identifier
OMG object management group
OSI open system interconnection
QoS quality of service
REC recommendation
RM reliable messaging
RMI/IIOP remote method invocation/internet inter-ORB protocol
RPC remote procedure call
SMTP simple mail transfer protocol
SOA service-oriented architecture
TCP/IP transmission control protocol/internet protocol
tModel technical model
UDDI universal description, discovery, and integration
URI uniform resource identifier
UTF-8(/16) 8(/16)-bit universal character set transformation format
W3C world wide web consortium
WS web service
WS-I web services interoperability (organization)
WSDL web services description language
XML eXtensible markup language
XSD XML schema definition
4 Conformance
There are no explicit conformance tests within this document. Conformance is achieved by conforming
to the provisions of the requirements clauses of ISO 24097-1. Specific conformance tests may be added
at a subsequent date as an additional part to the ISO 24097- series.
5 Notation
5.1 Prefixes and namespace URI used in core specification
This document uses predefined namespace prefixes throughout; as provided in Table 1. Other prefixes
and namespaces (e.g.’ Web Services Policy’ and ‘Web Services Addressing’ etc.) are shown in specific
clauses of this document.
NOTE 1 The choice of any namespace prefix is arbitrary and not semantically significant (see [Namespaces in
XML]). However, the prefix must be unique in any single document.
NOTE 2 For reasons of brevity, not all examples are shown as full schemas. In this case, it is assumed that the
namespace has been declared in a parent element.
Table 1 — Namespace prefix and namespace URI
Category Prefix Namespace URI
wsi
WS-I namespace http:// ws -i .org/ profiles/ basic/ 1 .1
WSDL 2.0 namespace for WSDL framework. wsdl http:// schemas .xmlsoap .org/ wsdl/
WSDL 1.1 namespace wsdl11 http:// schemas .xmlsoap .org/ wsdl
WSDL namespace for WSDL SOAP binding. soapbind http:// schemas .xmlsoap .org/ wsdl/ soap/
WSDL namespace for WSDL HTTP GET & POST
http http:// schemas .xmlsoap .org/ wsdl/ http/
binding.
soapenc
Encoding namespace as defined by SOAP 1.1 http:// schemas .xmlsoap .org/ soap/ encoding/
soapenv
Envelope namespace as defined by SOAP 1.1 http:// schemas .xmlsoap .org/ soap/ envelope/
Instance namespace as defined by XSD xsi ht t p://www .w 3. org/2 000/1 0/X MLSchema- instance/
Schema namespace as defined by XSD xsd http:// www .w3 .org/ 2000/ 10/ XMLSchema/
The “this namespace” (tns) prefix as a convention
tns
(various)
to refer to the current document.
All other namespace prefixes are samples only.
In particular, IRIs starting with “http://e xample
(other) (various)
.com” represents application-dependent or
context-dependent IRI.
5.2 Web service syntax notation: BNF pseudo-schemas
BNF pseudo-schemas are used to represent web service syntax.
— The syntax appears as an XML instance, but values in italics indicate data types instead of literal
values.
— Characters are appended to elements and attributes to indicate cardinality:
o “?” (0 or 1)
o “*” (0 or more)
o “+” (1 or more)
— The character “|” is used to indicate a choice between alternatives.
— The characters “(“ and “)” are used to indicate that contained items are to be treated as a group with
respect to cardinality or choice.
— The characters “[“ and “]” are used to call out references and property names.
— Ellipses (i.e., “…”) indicate points of extensibility. Additional children and/or attributes MAY be
added at the indicated extension points but MUST NOT contradict the semantics of the parent and/or
4 © ISO 2017 – All rights reserved

owner, respectively. By default, if a receiver does not recognize an extension, the receiver SHOULD
ignore the extension; exceptions to this processing rule, if any, are clearly indicated below.
5.3 XPath 1.0 notation
XPath 1.0 notation is used to specify an XML element and/or attribute.
5.4 Notation of service provider, service consumer combination
There are four combinations of service provider and service consumer. In this document the combination
is represented using the “service provider”, “service consumer” notation.
EXAMPLE Traffic service provider, freight industry.
5.5 SOA stack name notation
SOA stack name is represented by bold italics.
EXAMPLE messaging
5.6 Set notation
Set is represented by being embraced in curly brackets (“{ “and”}”).
EXAMPLE Integer set of 1 to 9
{1, 2, 3, 4, 5, 6, 7, 8, 9}
5.7 Tentative IRI expression
Some constructs cannot determine their value when creating standards. In this case, a tentative value
is expressed by /tentative in bold italics. The final value will be given using real IRI.
EXAMPLE WSDL soapbi nd: address (real web service address)
xmlns="http:// schemas .xmlsoap .org/ wsdl"… >
…





In this case, location is real service IRI and cannot determine the standardization point but it is
necessary to be expressed to provide a valid WSDL document.
5.8 Rnnnn (nnnn: digits integer)
Rnnnn is used to display the WS-I Basic Profile requirement identifier number. The expression is shown
as “[Rnnnn]”.
6 Requirements
6.1 Basic concept of web services standardization
6.1.1 Web services architecture
Given that web services require significant functionality, an architectural context is essential. Web
[4] [5]
service standardization organizations construct standards within the framework of an SOA. , An
SOA is an evolutionary form of distributed computing and object-orientation.
The fundamental SOA philosophy (architecture) is:
— Systems shall be coupled loosely with messages;
— Systems shall be linked dynamically; and
— Systems shall be composable by functional stacks.
In a web service SOA, functional stacks are as follows:
— Service composition stack: the stack that describes the coordination of business processes. This
stack is used to automate real business;
— Service description stack: the stack that describes the service interface and its related service
policy. This stack is used for metadata description;
— Quality of service (QoS) stack: the stack that ensures message quality, security, and transaction
quality;
— Messaging stack: the stack that describes message behaviour;
— Transport stack: the stack that transports the message; and
— Service publication and discovery stack: the stack that publishes a web service and supports its
discovery.
Web services are constructed upon an SOA-based open body of standards (see Figure 2 below). Each
standard is constructed in a platform independent manner. As a result, a web service (service and
client) can communicate with each other independent of their platform. In this case, interoperability is
realized when both sides conform to the same standard.
6 © ISO 2017 – All rights reserved

Figure 2 — SOA and its construct standards
NOTE 1 Currently, many software vendors provide a variety of development tools from integrated web
service development tools to component level tools. Using these tools enables the developer to make rapid and
comparatively easy enhancements.
NOTE 2 Some architects depict QoS layer as being higher than the upper layer of Service description layer.
Other architects depict the reverse. This document describes the Service description layer as the higher of the
two layers. The reason for this is that Service description layer uses the QoS layer and it controls the behaviour
of the QoS layer.
6.1.2 International standard web service standardization
Figure 3 depicts an MOF-like view of web services. The dashed arrow shows reference relationships.
M3 Layer (XML + XML Schema and Namespace) provides the syntax of the web service standards.
ISO 24531 is the standard schema used within the ITS sector.
M2 Layer (Web service standards, WS-I BP, and this document) provide the rules and guidance for web
service development.
M1 Layer (ITS Web service standards) provides rules and guidance for web service development that is
particular to ITS. If M1 Layer instances of specific web service (ITS web service) follow this document,
basic interoperability should be achieved.
Figure 3 — ITS web service standard structure
6.2 Web service metadata
Web service standards are based on an SOA. This means that web services are constructed using a
collection of layered functions. The fundamental layers are depicted in Figure 2. The topmost layer is
the “Service composition” layer. This layer covers, as the name indicates, the composition of multiple
services. As this document covers only a single web service applications, this layer description is not
included in this document.
The second highest layer is the “Service description” layer. This layer is a metadata layer in general
terms. The “Service description” layer consists of three sub-components, namely interface description,
policy description and addressing. These sub-components are standardized as WSDL, WS-Policy, and
WS-Addressing, respectively.
The WSDL standard provides interface information description. The WS-Policy standard covers web
services capabilities and constraints. The WS-Addressing standard presents the basis of metadata
end point reference (EPR) and some message addressing functionality. Using these standards, ITS
web services can respond to real world requirements. WS-Policy and WS-Addressing can be used
independently of the particular WSDL version being used.
8 © ISO 2017 – All rights reserved

Figure 4 — WSDL, WS-Policy, and WS-Addressing relationship
A single service document is required for an easy understanding of the service by the service consumer
and automated tool support. W3C provides two mechanisms: WSDL extensible points and WS-Policy
attachment specification. Extensible points are the logical points where other standard functionality
(in this case WS-Policy) can be attached to the WSDL description. The WS-Policy defines the attaching
mechanism to WSDL. Using these mechanisms, web service behaviour is described in a single document.
Web services provide enriched functionality in a modular manner.
6.2.1 Common requirements and recommendations for metadata
6.2.1.1 International standard web service metadata description
International standard web service metadata shall be declared in a formalised format.
NOTE A metadata formal expression is a contract between a service provider and a service requester
(usually different parties). In addition, formal metadata supports automatic creation of requester and provider
programs.
6.2.1.2 Use of utf-8 or utf-16
UTF-8 or UTF-16 shall be used for a metadata declaration.
NOTE Using UTF-8 or UTF-16 is standard for international XML applications.
6.2.1.3 Version upgrade scenario
When metadata changes, support shall be provided for all previous versions to the extent possible.
REASON   There are multiple scenarios for upgrading web services (see Figure 5). If the service is for
an anonymous user, and/or requires assured response, continued support for the old version should be
provided as depicted in the Type 2 scenario (see Figure 5).
Figure 5 — Version upgrade scenario
6.2.1.4 Interface or policy change
When changing the interface or policy definitions, the analyst shall analyse the impact that the change
has on the other (policy or interface) definition.
REASON   Web services work only with a consistent interface and policy pair. For example, if a new
binding is added in the interface description, it could impact WS-Policy. The reverse is also true. The
cross check ensures that the interface is consistent with the policy. Any change should be made within
the constraints defined in 6.2.1.3. If the change cannot meet the requirements of 6.2.1.3 it becomes a
new service, and the old service is retained.
NOTE There are many ways to manage physical files so that they continue to correspond with a change to
the WSDL or WS-Policy. One method is to change the same file (Type 1 of Figure 6); an alternative is to create new
physical files (Type 2). Type 1 in Figure 6 minimises change but the method selected is a service provider’s choice.
Figure 6 — WSDL WS-Policy change
6.2.1.5 Metadata versioning
Metadata versioning is not required but is highly recommended. Where used, the version number shall
be attached to WSDL and WS-Policy independently.
REASON   Version numbering facilitates detecting changes in the metadata. Independent version
numbering for both WSDL and WS-Policy is necessary because each can change independently.
NOTE For WSDL versioning rule see 7.2.4. For WS-Policy versioning rule see 7.3.2.5.
10 © ISO 2017 – All rights reserved

7 Service description layer
7.1 Service description layer structure
Since web service standards are based on an SOA, a set of standards shall be identified to address all
required functions. The Service description layer shall consist of the following sub-layers: Interface
description, Policy description, and Addressing. The layer shall explicitly identify the standards for:
WSDL, WS-Policy, and WS-Addressing. The following subclauses describe how to realize interoperable
ITS web services using these standards.
7.2 Service description layer: Requirement and recommendation for interface
description sublayer
7.2.1 Role of WSDL
‘Web Service Description Language’ is the formal service description language of a web service
interface. It becomes a contract condition between a service provider and service consumers.
“Contract” also implies that the service provider and a service consumer can create a program from
WSDL without ambiguity.
The following describes the role of WSDL in ITS:
— Description of technical conditions agreed between service provider and service consumer, and
— Can provide automatic generation of stub and skeleton using web service development tools. This
reduces the software development load for both the provider and consumer.
7.2.2 Multiple WSDL specifications
The current version of WSDL is WSDL 2.0 and this version of this document is focused towards
WSDL 2.0. However, this is a recent evolution. Figure 7 shows the evolution of WSDL and SOAP. The
current versions (at the time of developing this document) of WSDL and SOAP are WSDL 2.0 and
SOAP 1.2, respectively.
Adoption of WSDL 2.0 has been slow; therefore, support for WSDL 1.1 is expected to be employed for
some time and has to be accommodated where encountered.
This is important because WSDL 2.0 and SOAP 1.2 are not backwards-compatible. Therefore only
(WSDL 1.1, SOAP 1.1), (WSDL 2.0, SOAP 1.2) and (WSDL 2.0, SOAP 1.1) are acceptable combinations. As
a result, the user must select the version of the specification.
Figure 7 — WSDL and SOAP version correct combination
WSDL 2.0 rules are defined in the body of this document. The corresponding WSDL 1.1 rules are
presented in Annex A (normative). Detailed WSDL syntax for both version 1.1 and 2.0 is shown in
Annex B (informative).
Figure 8 — WSDL migration
12 © ISO 2017 – All rights reserved

7.2.3 WSDL and SOAP relationship
SOAP is a messaging protocol. Both WSDL 1.1 and WSDL 2.0 can select the SOAP protocol (as well as
other protocols like direct HTTP or MIME).
WSDL 2.0 can designate SOAP 1.1 and /or SOAP 1.2 (default). SOAP is considered as the communication
infrastructure. Therefore, WSDL 2.0 supports the use of SOAP 1.1 (backward compatibility).
In the case of WSDL 1.1, selecting SOAP binding requires the use of SOAP 1.1.
7.2.4 ITS web service interface metadata (WSDL) versioning rule
a) An ITS web service interface metadata version is represented by the following form:
m.n.a
— m: major version number (xsd: positiveInteger),
— n: minor version number (xsd: nonNegativeInteger), and
— a: draft version letter (xsd: NCName)
b) Version change rule:
— m: the major version number shall be changed to m+1 when the change from the previous version of
the service WSDL will cause existing documents to fail to validate;
— n: the minor version number shall be changed to n+1 when the change to the service WSDL will
result in all existing documents continuing to validate. However, some new documents which
validate against the new version will fail against the old version; and
— a: the draft version letter shall be changed every time when a new draft is issued. If “a” is null, it
means the version is official (not draft).
NOTE 1 The XML version is explicitly declared in the XML declaration. Others are specified by namespace
attribute.
NOTE 2 The version number can explicitly be declared in WSDL 1.1; wsdl11/definition/@name
7.2.5 Requirement and recommendation for applying WSDL 2.0
This clause determines the requirement for applying WSDL 2.0.
7.2.5.1 WSDL 2.0
WSDL 2.0 offers the following benefits over WSDL 1.1:
a) It provides a more modular structure for easy WSDL development and reuse,
b) It supports an object-oriented style (e.g. inheritance), and
c) It provides a clear definition of an extension point (e.g. ‘Web Service Policy’ is described using this
extension point). This enables enriching functionality of web services.
NOTE At the time of this documentation, tool support for WSDL 2.0 is still poor. By comparison, the older
WSDL 1.1 has rich tool support. Considering this fact, it is important to select the most appropriate WSDL version
in any deployment effort.
7.2.5.2 WSDL 2.0 conformance test
In order to promote interoperability, ITS WS shall use validation via W3C’s WSDL 2.0 web site.
REASON   WSDL 2.0 validation to W3C’s WSDL website is a minimum condition for interoperable web
services.
NOTE This website supports online checking of files.
7.2.5.3 Import message and fault
It is strongly recommended to construct a message as an independent XML document to WSDL and
import them to WSDL (but not required).
REASON   Separating service description layer from messaging layer enables a modular style of
development which simplifies maintenance or evolution of systems. Most fault messages are common
to various applications and therefore reusable. This helps rapid development of ITS web services. Many
countries have already completed message standardization which also supports interoperability and
rapid development of web services.
7.2.5.4 WSDL 2.0 name (wsdl: description/@ name)
Wherever possible, ISO 14813-1 based service classification should be used in WSDL 2.0 name attribute
(strongly recommended but not required).
NOTE This will promote more consistent names and the meaning will be more understandable.
7.3 Service description layer: Requirement and recommendation for policy description
sublayer
WSDL allows the formal description of an interface. As previously described, WS-Policy complements
other facets of web services facilities and requirements (see Figure 4). Describing security, reliable
messaging, and/or transaction in a formal manner is indispensable for real world web services. A
formal description also supports automation. In this clause, the basics of WS-Policy and requirements
and recommendations for ITS web services is described.
Table 2 depicts the WS-Policy related prefixes and XML Namespace.
Table 2 — Prefixes and XML Namespaces
Prefix XML Namespace Specifications
h t t p : // s c h e m a s .xm l s o a p . o r g / w s/ 20 0 4/ 0 9/ p ol i c y/
mtom [WS-MTOMPolicy]
optimizedmimeserialization
[SOAP 1.2 Messaging Framework (Sec-
soap http:// www .w3 .org/ 2003/ 05/ soap -envelope
ond Edition)]
sp
ht t p:// do c s .oasis -open .org/ ws -sx/ ws -securitypolicy/ 200702 [WS-SecurityPolicy]
wsa http:// www .w3 .org/ 2005/ 08/ addressing [WS-Addressing Core]
wsam http:// www .w3 .org/ 2007/ 05/ addressing/ metadata [WS-Addressing Metadata]
wsdl http:// schemas .xmlsoap .org/ wsdl/ [WSDL 1.1]
[Web Services Policy Framework, Web
wsp http:// www .w3 .org/ ns/ ws -policy
Services Policy Attachment]
h t t p :// d o c s . oa s i s -open .org/ wss/ 2004/ 01/ oasis -200401 -wss
wss [WS-Security 2004]
-wssecurity -secext -1 .0 .xsd
wst
ht t p:// do c s .oasis -open .org/ ws -sx/ ws -trust/ 200512 [WS-Trust]
h t t p :// d o c s . oa s i s -open .org/ wss/ 2004/ 01/ oasis -200401 -wss
wsu
[WS-Security 2004]
-wssecurity -utility -1 .0 .xsd
7.3.1 WS-Policy role and syntax
This sub-clause describes WS-Policy basics (role and syntax) and ITS web services requirements and
recommendations.
14 © ISO 2017 – All rights reserved

7.3.1.1 WS-Policy ― Framework
As previously described, web service requirements and constraints relate to topics like security,
reliability, transaction, and messaging. It is desirable to pull together all these topics into one document
because it facilitates understanding and simplifies software development. These topics (security,
reliability, etc.) are organized into a single policy document using the W3C standard, “Web Services
Policy 1.5 - Framework”. It provides a mechanism to define policy topics in a consistent fashion (see
Figure 9).
NOTE Before Web Services-Policy 1.5, WS-Policy had been developed by vendor groups. The final specification
version was version 1.4. It moved to W3C and its versi
...