Java IDL--CORBA technology and Java Technology

1. What is Java IDL?
---- Java IDL (Interface Definition Language) can realize the interaction between objects on different platforms on the network. This technology is based on the description of the Common Object Request proxy architecture (CORBA) specification. IDL is an interface definition language that does not depend on a language. All languages that support CORBA have the IDL ing of IDL to this language. As its name indicates, Java IDL supports Java ing to the Java language. The description of the CORBA specification and the IDL ing are defined by OMG (Object Management Group. OMG is composed of more than 700 members. Sun is one of its members and plays a major role in defining IDL-to-Java ing.
---- JDK 100% provides Java developers with the function of developing Java-only distributed applications, that is, remotely calling Java RMI. Java IDL provided by the Java2 Platform can use non-Java languages in distributed applications. That is to say, the orb (Object Request Broker) provided by the Java2 Platform Can interoperate with any orb complying with the CORBA specifications, including orbix of ionat echnologies, Visi Broker of Visigenic software, and component broker of IBM. Currently, the main web browsers (microsoftie4.0 and netscapenavigator4.0) are mainly implemented in JDK. However, the use of Sun's Java Plug-in (plug-in) allows the browser to have all the features of the Java2 Platform.
---- It should be noted that the Java2 Platform provides two different methods to construct a distributed application system, namely, Java RMI and Java IDL, which have similar features and functions, java RMI supports distributed objects written in the Java language. Java IDL can interact with distributed objects written in any programming languages such as C, C ++, and COBOL that support CORBA. These two methods have different characteristics:
---- (1) 100% pure Java and support for legacy application systems (legacy system. Java RMI is a 100% pure Java solution for distributed application systems and has the advantages of "write once, run anywhere" in Java. Application systems developed using Java RMI can be deployed on any platform that supports the Java Runtime Environment.
---- On the contrary, Java IDL is a technology based on the CORBA standard and can remotely call objects written in non-Java languages, therefore, Java IDL provides support for legacy application systems developed in non-Java languages.
---- (2) use different communication protocols. Java RMI and Java IDL currently use different communication protocols, Java IDL uses the CORBA/IIOP protocol, and IIOP (Internet Inter-orbprotocol) the Protocol enables communication between objects on different platforms and written in different languages in a standard way. Java RMI currently uses Java remote message exchange protocol jrmp (Java remote messaging protocol) for communication, jrmp is a protocol designed for remote objects in Java, but sun and IBM have announced that they will support the IIOP protocol in RMI in the future to communicate with remote objects that comply with the CORBA specifications.
---- (3) call an object by referencing a call object or by using a value. In Java IDL, the client interacts with a remote object through reference, that is, the client uses a pile (stub) to operate on objects on the remote server, but does not copy objects on the server.
---- On the contrary, RMI allows the client to interact with remote objects through reference, or download remote objects to the client runtime environment for operations. Because the objects used in RMI are Java objects, therefore, RMI uses the object serialization function in Java to transmit objects between the server and the client. However, later versions of the CORBA specification will include the function of calling objects by value.
---- Java RMI and Java IDL have their own advantages and disadvantages. In a sense, RMI can be seen as an object-oriented version of RPC (Remote Procedure cballs. The biggest advantage of RMI is that it can be used to provide a 100% pure Java solution, which means the construction of RMI application systems will be relatively simple, but this is also a disadvantage of RMI-based application systems, that is, it can only run in the Java environment and cannot make full use of the legacy application system.
---- Both Java RMI and Java IDL can meet a certain range of user needs and are applicable to a certain range of applications. There is an overlap between the two. Some applications can be developed using either of the two technologies, however, for some applications, it is more appropriate to use one of them than to use the other.
Ii. use CORBA and Java IDL
---- Since 1989, OMG has been committed to the definition of standardized description of the open software BUS architecture, and the components developed by different vendors and running on different platforms can interoperate with each other using CORBA, no matter where the object is located, it is implemented in any language. Java IDL allows Java to also support the description of the CORBA specification. As part of Java Enterprise computing APIs, Java IDL can ensure seamless interoperability and connectivity in Enterprise Heterogeneous Computing.
---- The difference between a CORBA object and an object in a general programming language is:
The CORBA object can be located anywhere in the network;
The CORBA object can interact with objects on other platforms;
The CORBA object can be written in any programming language, you only need to map IDL to this language (currently, ing to Java, C ++, C, smalltalk, COBOL, Ada, and other languages is included ).
---- The Interface Definition Language (IDL) is used to define the interface of the CORBA object. All the CORBA objects support the IDL Interface. The IDL syntax is very similar to the C ++ syntax. Using Java IDL, you can define, implement, and access the CORBA object in Java. For each IDL, IDL to Java generates a Java interface and other necessary. java files, including a client pile (stub) and a server skeleton (skeleton ).
---- To use Java IDL, an IDL to Java compiler is required. IDL to Java generates client piles and server skeleton that work with any orb that complies with the CORBA specifications, the Java2 Platform includes corbaapi and ORB, so that the Java application system can call remote CORBA objects through the IIOP protocol. javaorb supports transient (transient) CORBA objects, the transient name server organizes objects into a tree directory structure, and the name server complies with the Naming Service specification described in the COs specification in CORBA ).
---- Figure 1 illustrates the process of sending a message request from the client to the server. The client can also be a CORBA object:
---- The client does not need to know the location and implementation details of the CORBA object or the orb used to access the object.
---- On the client side, the application system includes remote object references. Object references use the pile method as the proxy for remote methods. This method is actually in ORB, therefore, calling the pile method calls the orb connection function, and Orb will pass the call to the pile method to the server.
---- On the server side, ORB uses the skeleton code to call the method of the Remote Call to convert the local object. The skeleton needs to convert the format of the call and parameter. At the same time, when the method returns, the skeleton transforms the result and returns the result to the client through orb.
---- Different ORBs communicate with each other through the IIOP protocol. IIOP is a protocol established on TCP/IP.
---- At present, CORBA is still in the development stage and some standards are still being defined. However, most of the basic structures in CORBA have been defined, and many software vendors have made a lot of development work according to the definition of CORBA, java IDL is an implementation of this specification. However, in the Java2 Platform, all features in the description of the CORBA specification are not implemented, such:
Interface library: Generally, Java IDL operations do not require an interface library. Java clients can access other interface libraries, such as the interface library provided by C ++ orb;
RMI/IIOP protocol;
Call objects by value;
Some types in IDL, such as wchar, wstring, and longdouble.
Iii. IDL ing from IDL to Java
---- To enable Java to support the description of the CORBA specification, Sun has formulated the ing rules between the two to map elements in IDL to elements in Java, the compiler IDL to Java is provided to get the corresponding pile and skeleton from IDL.
---- The following table lists the mappings between elements in IDL and elements in Java.
---- Similar to interfaces in Java, the IDL Interface does not contain the specific implementation of methods. Java developers must provide specific implementation of these methods in Java classes.
4. Use Java IDL to develop applications and Examples
---- Using Java IDL to develop a distributed application system can be divided into five steps:
---- 1. Define remote interfaces
---- Use IDL to define remote object interfaces, and use IDL instead of the Java language because the IDL to Java compiler can automatically generate the pile and skeleton source files of the Java language from IDL, and some code required to connect to orb. With IDL, developers can use other languages to implement clients and servers. If you want to implement a client for an existing CORBA service or an existing client, you must first provide the IDL Interface and then run the IDL to Java compiler to generate a pile and a skeleton, and then implement it.
---- 2. Compile remote interfaces
---- Run the IDL to Java compiler in The IDL file to generate interfaces of the Java version, as well as the pile and skeleton code files. These code files allow the application to be connected to orb.
---- 3. Implement Server
---- Integrate the framework generated by the IDL to Java compiler with the server application, in addition to implementing methods in remote interfaces, the server code also includes starting orb and waiting for remote client calls.
---- 4. Implement the client
---- Similarly, the client is built on the pile based on the client application. It queries the server through the name service provided by Java IDL to obtain remote object references, then, call the method in the remote object.
---- 5. Start the application
---- Once the server and client are implemented, you can start the name service, start the server, and then run the client.
---- The following describes the development process using a classic helloworld program. Helloworld contains an operation that returns a string and prints it out. The communication process between the client and server is as follows:
---- (1) client applications or small applications call the sayhello operation of helloserver;
---- (2) orb passes the call to the registered service object;
---- (3) the service object runs the sayhello method and returns a Java string;
---- (4) orb returns the string to the client;
---- (5) the client prints the value of this string.
---- Although the helloworld program is relatively simple, it involves the same tasks as almost any distributed application system that uses the static call of CORBA, figure 2 illustrates how to use CORBA to implement a classic "helloworld" program between the client and the server.
---- The first step is to define hello. IDL. The following is the hello. IDL described in IDL. There is only one operation (method). This operation returns a string.
Module Hello app
{
Interface hello
{
Stringsay Hello ();
};
};
---- Map the hello. IDL file to the Java source code file and compile the hello. IDL file with the following command:
---- IDL to javahello. IDL
---- According to different options in the command line, the IDL to Java compiler generates different files. The preceding command creates a subdirectory helloapp and generates five files in it: _ helloimplbase. java, _ hellostub. java, hello. java, hellohelper. java, helloholder. java.
---- To complete the application, you must provide server-side and client-side implementations based on these five files.
---- The structure of the CORBA server program is the same as that of most Java applications, that is, to import the required package, declare the server class, define the main method, and handle exceptions. In addition, the CORBA server must have an orb object. Each server instantiates an orb instance and registers a service object with it. Therefore, when Orb receives a call request, it can find the server. Finally, it is the management of service objects. The server is a process that instantiates one or more service objects. The service objects implement the operations described in the interface. Helloserver and the naming service work together to make the service object available to the client. The server needs to reference the name service object and can register with the name service, and ensure that the call to the hello interface is routed to its service object, and finally waits for the client to call.
---- The structure of the CORBA client is basically similar to that of most Java applications, that is, the package required for importing, declaring the application class, defining the main method, and handling exceptions. In addition, just like a server program, a client with a local orb is required to perform all the configuration work. Each client instantiates an org. OMG. CORBA. orb object, then pass some necessary information to the object for initialization, and finally use orb to get the required service. Once an application has orb, you can use orb to determine the location of the service required by the application. In this example, helloserver is used. In order to call operations in a CORBA object, the client application must reference this object. There are many methods to obtain this reference, such as calling orb. resolve_initial_references or use other CORBA objects (such as the Naming Service). When no Naming Service is available in a distributed environment, the CORBA client uses a stringized object reference (stringifiedobjectreference) to obtain the first object.