What is CORBA

Object interoperability specifications developed by the OMG are often referred to as "Object Management Systems" (Objectmanagement architecture,oma). OMA defines two components: "Core object Model" and "OMA Reference System" (OMA Reference model). OMA Reference System defines a set of basic service structure and mechanism, which realizes the ability of object to operate among each other. The OMA reference system includes the object Request Agent (Broker,orb), Object Services, also known as corbaservices, and some common mechanisms.
Orb is a communication bus that requests each other between objects. When making a request, you need not care where the other person's physical location is. This means that the process in customer code that looks like a scenario call is actually a very complex operation. First, there must be a connection path to the server object. And in order to create a connection, the Orb must know where the code to implement the server is stored. After the connection has been built, the method must be "pooled" for its own variables. For example, they are converted to a binary stream for transmission over the network. Other information that must be passed includes the server's machine name, the server process, and information that identifies the server objects within that process, and so on. Finally, the information is passed through a low-level line protocol, the message is decoded at the end of the server, and the call is formally executed. The Orb hides all these complex operations from the eyes of the programmer and makes the programmer's work almost as simple as the method of invoking the local object.
There is no hard rule on how to achieve the orb core, but in order to achieve a basic compatibility between the orb of different developers, the OMG defines a range of services that can be accessed through standard interfaces.

1. CORBA Interface Definition language (IDL)
CORBA is designed for language-oriented transparency: a client object can invoke a server object method that belongs to different classes, regardless of the language in which the other is implemented. Of course, the client must know the name of the method and the signature that was revealed by the server object beforehand. IDL will be used at this time. CORBA IDL is a language-independent design method that can be used to specify data types, attributes, operations, interfaces, and more. IDL's syntax is similar to C + + or Java syntax. The following table summarizes some common concepts in three languages and shows their corresponding relationships.

CORBA IDL Java C + +

Modular (module) package (Package) namespace (Namespace)
Interface (Interface) interface (Interface) pure abstract classes (Pure abstract class)
Methods (method) methods member functions (members function)

The concept of inheritance is also supported-just like C + +, the colon operator is also used. For properties, methods, and interfaces that need to be implemented and used by servers and customers, programmers write an IDL description. Subsequently, IDL is compiled by a vendor-supplied Idl/java compiler, which reads the IDL source code and generates the corresponding Java codes.
The IDL compiler is a useful tool: it generates not only the Java source that is equivalent to IDL, but also the code that collects the method's arguments and makes remote calls. We call this code "root-Dry" (Stub and Skeleton) code, which is organized into multiple Java source files and is usually part of the same Java package.

2. Naming Service
The naming service belongs to one of the CORBA basic services. A CORBA object is accessed through a reference. Although referencing information is meaningless with our eyes, you can assign a programmer-defined string name to a reference. This operation is called "the string of references." An OMA component called the Naming service is specifically designed to perform "string to Object" and "object to string" transformations and mappings. Because the naming service plays the role of a phone book that both the server and the client can query and manipulate, it runs as a separate process. The process of creating an object to string mapping is called "binding an object"; The process of deleting a mapping relationship is called "Unbind," and the process of letting an object reference pass a string is called "resolution name."
For example, when starting, the server application can create a server object, bind the object to the naming service, and wait for the customer to make a request. The customer first obtains a server reference, resolves the string name, and then makes a call to the server by reference.
Similarly, the Naming Service specification is part of CORBA, but the application that implements it is provided by the Orb vendor (the developer). Depending on the vendor, the way we access the naming service may vary.