However, the developers at CERN in Geneva did certainly not expect the popularity that the WWW achieved meanwhile. With this popularity, more features were added including dynamic pages or to sending data from the client to the server for further processing. In 1995, the Common Gateway Interface (CGI) was introduced for that purpose. With CGI, the client send information via a file transfer mechanism to the server where the data is read and processed. The server side is usually implemented with the language PERL. To implement such a PERL interface is tedious and difficult. And once in operation, performance is poor. Additionally, dynamic dialogues between client and server are impossible due to the block-oriented nature of data transfer.
At this point, the "Internet Inter-ORB Protocol" (IIOP) enters the scene. Early versions (1.x) of CORBA did not specify an ORB-internal communication protocol. That is, every ORB vendor determined how its ORB would communicate internally. For that reason, it was impossible to send messages from one ORB to an object living in another ORB vendor's server process. Consequently, CORBA 2.0 defined IIOP. IIOP as a standardized protocol allows communication between different ORB-products. There was a proof of concept at Object World West in August 1995: object request brokers from more than a dozen ORB vendors communicated as they were a single system! Many different HW and OS platforms were involved and several implementation languages like C, C++ and Smalltalk.
Thanks to Java and ORBs supporting Java, the inter-ORB concept was taken to the Internet. Today, WWW-browsers can act as clients that access objects on the server via IIOP. The traditional WWW-protocol (HTTP) is not used anymore. The following figure depicts the bootstrapping of a IIOP connection between a client browser and the IIOP-server.
The client requests a HTML-page at the HTTP-server. The client loads it and recognizes that it references Java-code.
The client requests the Java classes at the HTTP-server. The downloaded classes in our example are not standard applets but "ORBlets". They enable the browser to communicate with the CORBA server. ORBlets are application level classes, e.g. a customer object proxy.
In case that the browser does not have the IIOP java archive, the server must download the basic IIOP classes, too.
The client establishes not the connection to the CORBA server. If done successfully, the client can send messages to objects living in the CORBA server, avoiding the HTTP/CGI bottleneck.
Advantages:
client and server communicate with much less overhead
server functions can have a return value
real Data Types - and not only strings - can be exchanged
the server side objects can be implemented in any language (where an CORBA 2.0 compliant ORB is available)
We don't want to give the impression here that IIOP is the infamous "Silver Bullet". Especially when used in Wide-Area-Networks, data often needs to be cached on the client and it is useful to do certain processing directly on the client-side, thus ??undermining a clean 3-tier-architecture. Security is another topic, but that's not specific to IIOP. CORBA offers here a great set of mechanisms (see our security page). However, it can be tricky to work around certain Internet security mechanisms that come with the browsers or with firewall products.
Besides these drawbacks, IIOP allows the Internet browser to act as a true application shell. Netscape recognized that and included the necessary ORB components in their client and server products. Microsoft goes a very similar way, but uses its proprietary ActiveX/DCOM technology instead of CORBA.
d-tec Distributed Technologies GmbH, 1998
本文地址：http://com.8s8s.com/it/it18405.htm