Intelligent transport systems — Systems architecture, taxonomy and terminology — Using CORBA (Common Object Request Broker Architecture) in ITS standards, data registries and data dictionaries

ISO TR 24532:2006 clarifies the purpose of CORBA and its role in ITS. It provides some broad guidance on usage, and prepares the way for further ISO deliverables on the use of CORBA in ITS.

Systèmes intelligents de transport — Architecture, taxinomie et terminologie des systèmes — Emploi de CORBA ("Common Object Request Broker Architecture") dans les normes, registres de données et dictionnaires de données ITS

General Information

Status
Withdrawn
Publication Date
08-Jun-2006
Withdrawal Date
08-Jun-2006
Current Stage
9599 - Withdrawal of International Standard
Completion Date
24-Jun-2019
Ref Project

Buy Standard

Technical report
ISO/TR 24532:2006 - Intelligent transport systems -- Systems architecture, taxonomy and terminology -- Using CORBA (Common Object Request Broker Architecture) in ITS standards, data registries and data dictionaries
English language
8 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

TECHNICAL ISO/TR
REPORT 24532
First edition
2006-06-01

Intelligent transport systems — Systems
architecture, taxonomy and
terminology — Using CORBA (Common
Object Request Broker Architecture) in
ITS standards, data registries and data
dictionaries
Systèmes intelligents de transport — Architecture, taxinomie et
terminologie des systèmes — Emploi de CORBA (Common Object
Request Broker Architecture) dans les normes, registres de données et
dictionnaires de données ITS




Reference number
ISO/TR 24532:2006(E)
©
ISO 2006

---------------------- Page: 1 ----------------------
ISO/TR 24532:2006(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.


©  ISO 2006
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland

ii © ISO 2006 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/TR 24532:2006(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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
In exceptional circumstances, when a technical committee has collected data of a different kind from that
which is normally published as an International Standard (“state of the art”, for example), it may decide by a
simple majority vote of its participating members to publish a Technical Report. A Technical Report is entirely
informative in nature and does not have to be reviewed until the data it provides are considered to be no
longer valid or useful.
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.
ISO/TR 24532 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
© ISO 2006 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/TR 24532:2006(E)
Introduction
CORBA is one of many software technologies involved in distributed systems and system integration. There is
a significant number of existing CORBA deployments in ITS, and discussions on best practice and
standardization have naturally emerged, and discussion can often lead to comparisons between different
technologies and confusion, even apparent “competition” between different software technologies.
The objective of this Technical Report is to identify the role of and provide guidelines for the use of CORBA in
ITS.

iv © ISO 2006 – All rights reserved

---------------------- Page: 4 ----------------------
TECHNICAL REPORT ISO/TR 24532:2006(E)

Intelligent transport systems — Systems architecture,
taxonomy and terminology — Using CORBA (Common Object
Request Broker Architecture) in ITS standards, data registries
and data dictionaries
1 Scope
This Technical Report clarifies the purpose of CORBA and its role in ITS. It provides some broad guidance on
usage, and prepares the way for further ISO deliverables on the use of CORBA in ITS.
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
2.1
General Inter ORB Protocol
inter ORB protocol that defines the message formats between ORBs in a distributed environment
2.2
Interface Definition Language
language for defining interfaces to CORBA objects which is independent of platform, operating system and
programming language
2.3
Internet Inter ORB Protocol
inter ORB protocol that allows ORBs to use the Internet as a communications bus by mapping inter ORB
messages onto TCP/IP
NOTE This is an implementation of GIOP.
2.4
Model-Driven Architecture
method of writing specifications and developing applications, based on a platform-independent model (PIM)
NOTE A complete MDA specification consists of a definitive platform-independent base UML model, plus one or
more platform-specific models (PSM) and interface definition sets, each describing how the base model is implemented on
a different middleware platform.
2.5
Object Request Broker
function within the CORBA architecture that acts as a broker in fulfilling client requests for services from
objects in a distributed environment
2.6
Platform-Independent Model
model of a software system that is independent of the specific technological platform used to implement it
© ISO 2006 – All rights reserved 1

---------------------- Page: 5 ----------------------
ISO/TR 24532:2006(E)
2.7
Platform-Specific Model
model of a software system that is linked specifically to a technological platform
2.8
Secure Sockets Layer
protocol for transmitting private information via the Internet by using public and private keys to encrypt data
2.9
Travel Information Highway
open and independent association of information publishers and receivers who have an interest in exchanging
travel information using an agreed set of principles
3 Abbreviated terms
C2C Centre to Centre
CORBA Common Object Request Broker Architecture
GIOP General Inter ORB Protocol
IDL Interface Definition Language
IIOP Internet Inter ORB Protocol
IOR Interoperable Object Reference
ITS Intelligent Transport Systems
MATTISSE Midlands Advanced Transport Telematics Information Services and Strategies in Europe
MDA Model-Driven Architecture
NTCIP National Transportation Communications for ITS Protocol
OMG Object Management Group
ORB Object Request Broker
PIM Platform-Independent Model
PSM Platform-Specific Model
QMISS Quantified Motorway Information Supply System
SSL Secure Sockets Layer
TCP Transmission Control Protocol
TCP/IP Transmission Control Protocol/Internet Protocol
TIH Travel Information Highway
UML Unified Modelling Language
2 © ISO 2006 – All rights reserved

---------------------- Page: 6 ----------------------
ISO/TR 24532:2006(E)
4 Requirements
4.1 CORBA Background
CORBA is a vendor-independent architecture and infrastructure that computer applications use to work
together over networks. Using the standard protocol IIOP, a CORBA-based program from any vendor, on
almost any computer, operating system, programming language or network can interoperate with a CORBA-
based program from the same or another vendor, on almost any other computer, operating system,
programming language and network.
CORBA applies object-oriented principles to distributed programming. A “CORBA object” offers services
through well-defined interfaces specified using the OMG/ISO IDL. Clients use an object’s services by issuing
requests to the object. The implementation details are kept hidden from clients. Language mappings from IDL
to various programming languages make CORBA constructs available to invoke in programs.
This Technical Report does not attempt to provide a full explanation of CORBA. Key parts of CORBA are
already International Standards, including ISO/IEC 14750 and ISO/IEC 19500-2.
CORBA is created and developed at the Object Management Group (OMG), a not-for-profit industry
consortium. The best reference for further CORBA background is www.omg.org/corba.
4.2 When CORBA is appropriate
CORBA is a direct and productive way of implementing systems with distributed behaviour. Due to the wide
range of language and operating system bindings available, CORBA is often a suitable choice when
integrating existing systems. CORBA can provide a richer range of services than those available in many
other middleware technologies.
4.3 Applying CORBA in ITS
For the purpose of this Technical Report, usage of CORBA will be split into distinct paradigms: “objects with
behaviour” and “data/message transfer”. Both are legitimate usage paradigms for ITS.
4.3.1 Objects with behaviour
Distributed ITS systems have traditionally relied on messaging, but CORBA offers a richer programming
model than just messaging. In this model, objects communicate and collaborate with one another to achieve
the purpose of an overall system. Designers, rather than thinking about what data will be exchanged, consider
what services will be offered by each component. The components are given CORBA interfaces with
operations that denote some real behaviour.
Compared to messaging, this approach is more tightly coupled. Although asynchronous messaging is well
supported in CORBA, the classic mode of use is for clients to make synchronous invocations of the operations
of the service-providing CORBA objects. In many applications, this tight coupling is likely to be the best
approach. Where the desired behaviour of components is known, creation of corresponding object interfaces
is considered to be the most direct and productive way of designing and programming. The objects will tend to
be domain-specific. A good example context in ITS would be integration of control systems, where
components must interact to achieve overall system behaviour.
1)
4.3.2 Data/message transfer
In a limited set of application contexts, data transfer is the best model. The reasons are partly non-technical,
but nonetheless valid. Data owners, such as transportation authorities or operators, may have an idea that

1) While it is also possible to implement object invocations through messaging, this subclause describes message
transfer in the sense widely used in ITS, where the messages are considered to be data.
© ISO 2006 – All rights reserved 3

---------------------- Page: 7 ----------------------
ISO/TR 24532:2006(E)
their data is valuable, and that it could be used to provide further services, but they may not yet know exactly
what services could be provided. Rather than waiting to define services, the data owner may actually achieve
quicker uptake by making their data available, to encourage service providers to participate.
In travel information applications, both information service providers and network operators need to know the
current state of the travel network. Because significant travel incidents are irregular and yet require timely
response and information dissemination, there is often a requirement for asynchronous event-based data
exchange. There is also a requirement for discovery of current state on initialization of a client application.
These two distinct requirements are the key forces on the design of CORBA interfaces for travel information
systems. While OMG has already standardized particular CORBA interfaces for common computing patterns
(“CORBA Services”), none of the current OMG set provides a complete solution. For example, the OMG
Notification Service has been used in ITS, but with an additional layer added to handle client initialization.
CORBA interfaces for data distribution will tend to be general, with operations phrased in terms of general
software and data concepts rather than ITS-specific concepts. The ITS-specific content will be passed as
parameters. An interesting design issue is whether specific ITS data models should be encoded into the IDL
(e.g. as ITS-specific structs or value types) or whether the IDL should use general mechanisms (such as IDL
“Any” type or IDL unions of possible basic types). Specific types have slightly better performance when
marshalling. General types avoid recompilation of IDL after data model changes. While the great majority of
applications would require re-coding anyway to reflect data model changes, general types are very useful to
those few applications (typically graphical user interfaces or protocol bridges) that can adapt to new models at
runtime using metadata.
Message transfer can be a useful technique where loose coupling is desired, perhaps to match underlying
legacy system behaviour. In this case, existing OMG services such as the
...

Questions, Comments and Discussion

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