Intelligent transport systems — Using web services (machine-machine delivery) for ITS service delivery — Part 1: Realization of interoperable web services

ISO 24097-1:2017 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. ISO 24097-1:2017 is applicable to inter-ITS sector web services as well as ITS web services for non-ITS users.

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

General Information

Status
Published
Publication Date
18-Jul-2017
Current Stage
9060 - Close of review
Start Date
03-Mar-2028
Ref Project

Relations

Buy Standard

Standard
ISO 24097-1:2017 - Intelligent transport systems -- Using web services (machine-machine delivery) for ITS service delivery
English language
40 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

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 24097-1:2017(E)
©
ISO 2017

---------------------- Page: 1 ----------------------
ISO 24097-1:2017(E)

COPYRIGHT PROTECTED DOCUMENT
© 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

---------------------- Page: 2 ----------------------
ISO 24097-1:2017(E)

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
© ISO 2017 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 24097-1:2017(E)

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

---------------------- Page: 4 ----------------------
ISO 24097-1:2017(E)

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.
© ISO 2017 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO 24097-1:2017(E)

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

---------------------- Page: 6 ----------------------
ISO 24097-1:2017(E)

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.
© ISO 2017 – All rights reserved vii

---------------------- Page: 7 ----------------------
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
© ISO 2017 – All rights reserved 1

---------------------- Page: 8 ----------------------
ISO 24097-1:2017(E)

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

---------------------- Page: 9 ----------------------
ISO 24097-1:2017(E)

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.
© ISO 2017 – All rights reserved 3

---------------------- Page: 10 ----------------------
ISO 24097-1:2017(E)

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

---------------------- Page: 11 ----------------------
ISO 24097-1:2017(E)

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]”.
© ISO 2017 – All rights reserved 5

---------------------- Page: 12 ----------------------
ISO 24097-1:2017(E)

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

---------------------- Page: 13 ----------------------
ISO 24097-1:2017(E)

Figure 2 — SOA and its construct standards
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.