This process creates an IDL equivalent of the remote interface. The client obtains a reference to the remote object and forwards method calls through the stub.
The Objects-by-Value specification allows complex data types to be passed between the two programming languages involved. The required stub classes will be generated when you compile the IDL file. Generate factory methods for value types. This is useful if your client ORB does not support the factory value type. The compiler generates the IDL file within sub-directories of the idlDirectoy according to the package of the implementation class.
For example, the preceding command generates a Hello. If the idlDirectory option is not used, the IDL file is generated relative to the location of the generated stub and skeleton classes. CORBA is often described as a "software bus" because it is a software-based communications interface through which objects are located and accessed.
Data communication from client to server is accomplished through a well-defined object-oriented interface. The Object Request Broker ORB determines the location of the target object, sends a request to that object, and returns any response back to the caller. Through this object-oriented technology, developers can take advantage of features such as inheritance, encapsulation, polymorphism, and runtime dynamic binding.
These features allow applications to be changed, modified and re-used with minimal changes to the parent interface. The illustration below identifies how a client sends a request to a server through the ORB:.
IDL defines the modules, interfaces and operations for the applications and is not considered a programming language. The IDL specifies a description of any services a server component exposes to the client. Translate the IDL An IDL translator typically generates two cooperative parts for the client and server implementation, stub code and skeleton code.
There are very few other middleware technologies that are available on such a wide range of computers. Some small organizations might use a single programming language for all their projects, but as an organization increases in size, it becomes increasingly likely that the organization will make use of several programming languages.
For these organizational reasons, it is important for a middleware system to support many programming languages; unfortunately, not all middleware systems do so. One extreme case of this is J2EE , which supports only Java.
Another extreme case is the SOAP middleware standard. SOAP applications can be built with a variety of programming languages but, at the time of writing, the SOAP standard defines only one language mapping for Java. This means that there is no source-code portability of non-Java SOAP applications across different vendor products. The on-the-wire protocol infrastructure of CORBA discussed in Chapter 11 ensures that messages between clients and servers are transmitted in a compact representation.
Also, most CORBA implementations marshal data that is, convert data from programming-language types into a binary buffer that can be transmitted efficiently. Many other middleware technologies also use a similarly compact format for transmitting data and have efficient marshaling infrastructure.
0コメント