BS ISO IEC 19500 — CORBA (Common Object Request Broker Architecture) Series

📐 BS ISO/IEC 19500 is the British Standards Institution (BSI) adoption of ISO/IEC 19500, whose content derives from the Object Management Group’s (OMG) Common Object Request Broker Architecture (CORBA) specification, under the general title Information technology — Object Management Group — Common Object Request Broker Architecture (CORBA). The series was developed jointly by ISO/IEC JTC 1/SC 7 (Software and systems engineering) and OMG, with UK participation through Technical Committee IST/15 (Software and systems engineering); all three parts were published on 15 April 2012 under ICS 35.080. CORBA is the most representative neutral middleware standard in the field of distributed object computing. It allows objects running on heterogeneous languages, operating systems, and hardware platforms to invoke one another transparently through an Object Request Broker (ORB), without concern for the other side’s process location, implementation language, or runtime environment — making it a foundational technology for telecom network management, banking core systems, and large enterprise application integration.

💡 The core idea of CORBA: describe object interfaces in a language-neutral way via IDL (Interface Definition Language), with the ORB handling object location, parameter marshalling/unmarshalling, and cross-network transport, so a client invokes a remote object as if it were local — achieving “language-neutral, platform-neutral, location-transparent” invocation.

1. Structure and Scope of the Series 📌

The BS ISO/IEC 19500 series consists of three mutually independent yet interlinked parts, each addressing a key facet of the CORBA architecture:

Part	Standard No.	Subject	Edition	ICS
Part 1	BS ISO/IEC 19500-1:2012	Interfaces	First edition, 2012	35.080
Part 2	BS ISO/IEC 19500-2:2012	Interoperability	Second edition, 2012 (supersedes 2003)	35.080
Part 3	BS ISO/IEC 19500-3:2012	Components	First edition, 2012	35.080

In terms of scope, Part 1 defines the basis of the CORBA programming model — the object model and the syntax and semantics of IDL interfaces. Part 2 answers “how do ORBs from different vendors and platforms interoperate”, specifying the General Inter-ORB Protocol (GIOP) and the Internet Inter-ORB Protocol (IIOP). Part 3 lifts traditional CORBA objects to a higher-level component model (CCM), extending object orientation to component orientation and supporting component-level design, assembly, and deployment. Together the three parts answer three progressive questions of distributed object computing: how to describe interfaces, how to interoperate across networks, and how to assemble systems from components.

⚠️ Version note: Part 2 is the 2012 second edition and explicitly supersedes and withdraws the 2003 edition; Parts 1 and 3 are first editions of 2012. In engineering and procurement practice, always use the current edition and watch for later BSI Amendments and Corrigenda.

2. Part 1: Interfaces and the Object Model 🔧

Part 1 specifies CORBA’s interface requirements and is the logical starting point of the series. It first defines a complete Object Model, including fundamental concepts such as Object, Object Reference, Request, Type, and Interface, and gives object semantics for object creation and destruction, request delivery, and exception propagation. It then defines the full syntax, lexing rules, and semantics of the Interface Definition Language (IDL), explaining how to declare modules, interfaces, operations, attributes, constants, and the various data types (basic, constructed, and parameterized types).

In addition to IDL, Part 1 specifies the ORB core interfaces and a set of supporting interfaces, including:

Object creation and reference resolution: how to create objects and how to convert an object reference into a resolvable form;
Request invocation mechanisms: two paths — static invocation via compiled stubs and the Dynamic Invocation Interface (DII);
Interface Repository: storing IDL definitions as objects to support runtime reflection and dynamic discovery;
Exception handling and the Any type: a standardized exception model plus encoding rules for the Any type that can carry an arbitrary value.

The standard also defines extension mechanisms such as Value Types and Abstract Interfaces, and provides conformance and compliance requirements that distinguish mandatory from optional capabilities, giving a basis for consistency evaluation of different vendors’ ORBs. The keywords used in Part 1 (must, shall, may, etc.) have normative meaning and should be interpreted accordingly when reading clause strength.

✅ Value: Part 1 gives CORBA implementations and client development a unified programming model and language-mapping basis — as long as the same IDL and ORB interface semantics are followed, ORBs from different vendors present a consistent API to application developers.

3. Part 2: Interoperability and the GIOP/IIOP Protocols 🔥

Part 2 specifies CORBA’s interoperability mechanism, whose goal is to let heterogeneous ORBs exchange requests and replies transparently. Its central achievement is a layered interoperability architecture:

General Inter-ORB Protocol (GIOP): defines the general format, message types (Request, Reply, LocateRequest, LocateReply, MessageError, and so on), transport abstraction, and data encoding rules (CDR encoding) for inter-ORB request/reply messages, plus clauses for extensions such as unreliable multicast transport;
Internet Inter-ORB Protocol (IIOP): as GIOP’s concrete mapping over TCP/IP, specifying connection establishment, version negotiation, message flow, and compatibility rules so ORBs from different vendors can interoperate over the Internet/intranet;
Interoperable Object References (IOR): the standardized representation of object references, encoding a tagged profile collection that carries protocol addresses (such as TCP/IP host and port) for clients to resolve and route;
Inter-ORB Bridges: achieving interoperability between different ORB domains or protocols through bridges, including message-routing bridges and reference-conversion bridges.

Part 2 also includes terms and definitions that clarify the meaning of concepts such as interoperability, bridge, GIOP, IIOP, and domain, and explains the relationship between these protocols, the ISO/IEC formal standards, and the OMG specifications. For large distributed systems that must integrate across vendors and platforms, Part 2 is decisive — it unifies the “protocol-private” ORB world onto a public, auditable wire format.

🚨 Implementation note: IIOP uses binary encoding and listens on dynamic ports by default; crossing a NAT/firewall requires explicitly opening ports and planning network access control. If a client cannot reach a remote object, first verify the address information in the IOR and the firewall policy, then check protocol version and encoding compatibility.

4. Part 3: The CORBA Component Model (CCM) 🛠️

Part 3 specifies the CORBA Component Model (CCM), lifting CORBA application development from “bare objects” to “components”. CCM introduces these key concepts:

Components and component levels: a component is a self-contained entity exposing multiple facets for client calls; components can be ranked into levels, from pure interface usage up to full lifecycle, persistence, and transaction semantics;
Ports: a component interacts externally through ports, including facets that others call, publishers that emit events outward, and event sinks that subscribe to external events;
Component identity and component homes: each component has a unique identity, and a home creates, locates, destroys, and discovers components by primary key — acting as the component’s factory and repository;
Component definition and declaration: rules for writing component types, interfaces, attributes, and deployment declarations, and for assembling multiple components into an application;
Lifecycle, assembly, and security management: instantiation, assembly into component groups (assemblies), transaction boundaries, notification, and security policy configuration.

With CCM, CORBA supports a development style closer to modern middleware: integrators encapsulate, reuse, and hot-swap components as units, containers handle cross-cutting concerns (transactions, security, persistence), and business developers focus on component-internal logic. This part also gives conformance-declaration requirements so component products can be consistency-checked under a unified framework.

💡 Deeper understanding: CCM is closely aligned with the later EJB (Enterprise JavaBeans) in concept — the “component + container + home” architecture provided a standard template for enterprise component development in the 2000s, and understanding it still helps interpret modern middleware designs.

5. Engineering Practice Essentials 🔍

Although CORBA peaked in the 1990s to early 2000s, its technical legacy remains widely deployed. Practical points include:

🔍 Legacy system integration and migration: many telecom network management, banking core, and manufacturing execution systems still run on CORBA; new architectures can interoperate transparently through OMG-defined bridges and gateways, or expose CORBA interfaces as REST/message-queue services via adapters.
🔧 Protocol troubleshooting and integration testing: with an understanding of GIOP message structure and CDR encoding, IIOP messages can be parsed directly to quickly locate common faults such as parameter encoding mismatch, version negotiation failure, and IOR resolution errors.
📊 Consistency evaluation: when selecting and procuring an ORB, use the conformance/compliance clauses of Parts 1 and 3 to require suppliers to provide consistency test results and compatibility matrices, lowering heterogeneous interoperability risk.
📋 Security and network planning: secure IIOP transport is usually achieved via SSL/TLS or the CSIv2 (CORBA Security Interoperability) extension; complete port planning, certificate management, and access-control policy design before deployment.
📚 Knowledge retention: concepts such as IDL, the Interface Repository, and dynamic invocation remain visible in modern RPC frameworks (e.g., gRPC, Thrift); studying this series helps understand general patterns of distributed computing.

6. Frequently Asked Questions ❓

❓ Q: How does CORBA differ from Web Services?
A: CORBA uses binary IIOP transport and object references, offering low latency and high performance but poor firewall traversal and a steeper learning curve; Web Services use open protocols such as HTTP/XML(S) and JSON, which cross firewalls more readily and integrate with the Internet ecosystem. Modern new systems usually prefer the latter, with legacy CORBA adapted via gateways.

❓ Q: What is the role of IDL?
A: IDL describes object interfaces (data types, interfaces, operations, attributes) in a language-neutral way; an IDL compiler maps them to specific languages, generating client stubs and server skeletons, ensuring compile-time type safety for cross-language invocation.

❓ Q: What is the relationship between GIOP and IIOP?
A: GIOP defines the general inter-ORB message format, message types, and CDR encoding abstraction, independent of any specific transport; IIOP is GIOP’s concrete implementation over TCP/IP, specifying connection establishment, version negotiation, and the actual wire expression of messages — the online protocol used for heterogeneous interoperation.

🔍 Q: What role does the IOR play in interoperability?
A: The IOR is the standardized encoding of an (interoperable) object reference, internally carrying the target ORB’s protocol and address information (such as IP and port) in a tagged profile. A client needs the IOR to route to the target object; IOR resolution failure is one of the most common causes of failed cross-network calls.

❓ Q: Is this series still relevant today?
A: Yes. CORBA remains the foundation of many deployed telecom and financial systems; understanding its interfaces, interoperability, and component model is essential for maintaining, troubleshooting, and migrating those systems. Its IDL, Interface Repository, and dynamic invocation ideas directly influence modern RPC and middleware design.

🔒

正在加载下载地址，请稍候 10 秒