ISO TR 24532-2006 Intelligent transport systems - Systems architecture taxonomy and terminology - Using CORBA (Common Object Request Broker Architecture) in ITS.pdf

《ISO TR 24532-2006 Intelligent transport systems - Systems architecture taxonomy and terminology - Using CORBA (Common Object Request Broker Architecture) in ITS.pdf》由会员分享，可在线阅读，更多相关《ISO TR 24532-2006 Intelligent transport systems - Systems architecture taxonomy and terminology - Using CORBA (Common Object Request Broker Architecture) in ITS.pdf（14页珍藏版）》请在麦多课文档分享上搜索。

1、 Reference number ISO/TR 24532:2006(E) ISO 2006TECHNICAL REPORT ISO/TR 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 Systmes i

2、ntelligents de transport Architecture, taxinomie et terminologie des systmes Emploi de CORBA (Common Object Request Broker Architecture) dans les normes, registres de donnes et dictionnaires de donnes ITS ISO/TR 24532:2006(E) PDF disclaimer This PDF file may contain embedded typefaces. In accordance

3、 with Adobes 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 Adobes licensi

4、ng 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.

5、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 public

6、ation 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 ISOs member body in the country of the requester. ISO copyright office Case postale 56 CH-1211 Geneva

7、 20 Tel. + 41 22 749 01 11 Fax + 41 22 749 09 47 E-mail copyrightiso.org Web www.iso.org Published in Switzerland ii ISO 2006 All rights reservedISO/TR 24532:2006(E) ISO 2006 All rights reserved iii Foreword ISO (the International Organization for Standardization) is a worldwide federation of nation

8、al 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. Internatio

9、nal 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 rule

10、s 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 l

11、east 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 particip

12、ating 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 su

13、bject 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/TR 24532:2006(E) iv ISO 2006 All rights reservedIntroduction CORBA is one of many software technolo

14、gies 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, eve

15、n 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. TECHNICAL REPORT ISO/TR 24532:2006(E) ISO 2006 All rights reserved 1 Intelligent transport systems Systems architect

16、ure, 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 I

17、SO 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 Lang

18、uage 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

19、 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 (

20、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 Pl

21、atform-Independent Model model of a software system that is independent of the specific technological platform used to implement it ISO/TR 24532:2006(E) 2 ISO 2006 All rights reserved2.7 Platform-Specific Model model of a software system that is linked specifically to a technological platform 2.8 Se

22、cure 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 ag

23、reed 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 Ad

24、vanced 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 Moto

25、rway 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 ISO/TR 24532:2006(E) ISO 2006 All rights reserved 3 4 Requirements 4.1 CORBA Background CORBA

26、 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- ba

27、sed 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. Client

28、s use an objects 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 explanatio

29、n 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 C

30、ORBA 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 tha

31、n 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 beh

32、aviour 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 wil

33、l 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 m

34、ode 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 consider

35、ed 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. 4.3.2 Data/message transfer 1)In a limited

36、 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 subclau

37、se describes message transfer in the sense widely used in ITS, where the messages are considered to be data. ISO/TR 24532:2006(E) 4 ISO 2006 All rights reservedtheir data is valuable, and that it could be used to provide further services, but they may not yet know exactly what services could be prov

38、ided. 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

39、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 a

40、pplication. 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.

41、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

42、. 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 bas

43、ic 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 applicatio

44、ns (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 Notifi

45、cation Service can be employed. 4.3.3 Specialized CORBA versions For embedded or other low-footprint systems, “Embedded CORBA” or “Minimum CORBA” shall be used. For hard real-time systems “Realtime CORBA” shall be used. 4.3.4 CORBA Security Like any distributed technology, CORBA has points at which

46、security threats should be considered. For each threat-point there are countermeasures, and many countermeasures have been standardized in OMG security specifications. Possibly the most widely implemented aspect of CORBA security is the use of the IIOP protocol over the secure SSL protocol. However,

47、 any deployment of CORBA (or indeed any information technology) should consider the threats, define a security policy, and (in the case of CORBA) investigate available countermeasures in CORBA security specifications and implementations. 4.3.5 CORBA Access Through Firewalls CORBA has acquired a repu

48、tation for being awkward to use through firewalls. This is due to a combination of non-technical factors, which can be overcome. A fundamental firewall function is to prevent any outgoing access except to specific ports with specific protocols, for example a firewall may explicitly allow the web pro

49、tocol HTTP to pass through the well-known TCP port 80. CORBA IIOP also has established well-known ports (one for regular IIOP and one for IIOP over SSL). However, firewall administrators have been reluctant to open up ports other than the well-known HTTP ports. The argument is sometimes given that since HTTP is the protocol for retrieving static HTML information, while IIOP could be used to invoke any arbitrary behaviour, then the latter is less secure. However, this argument is refuted by the ability to “tunnel” to layer virtually any pr