HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
 

The Internet is reshaping both the business and computing worlds, defining new ways in which business is done and how applications are designed and developed. The Web allows businesses to build distributed applications that enable the sharing of information around the world and both customers and employees to interact directly with business operations. Some strengths of the Web and Internet are their ability to provide uniform access to information through a consistent user interface and the capacity to allow applications to work together across multiple platforms. The standard technologies that make heterogeneous computing across a global network possible, including TCP/IP, HTTP and CGI, have fueled the rapid growth of applications on the Internet and intranets. However, as Web application functionality expands beyond static Web sites and basic data querying systems to more complex, mission-critical, enterprise Web applications, the current Web technologies become limiting factors in what can be achieved. To take full advantage of the Internet and the Web, a more robust, distributed-object, connection-based protocol needs to emerge as the standard communication protocol.

The Internet Inter-ORB Protocol (IIOP) promises to do just that unite objects and applications on the Web. IIOP is an inter-ORB protocol and part of the CORBA specifications put forth by the OMG (Object Management Group). IIOP has the potential to become the next standard communication protocol on the Internet, replacing, or coexisting with, HTTP/CGI. It provides an object-based protocol that could greatly enhance the types of applications that are built and placed on the Web. Browsers and Java applications could work together to "surf" distributed objects instead of just content. IIOP has widespread industry support and is becoming a common feature in application server software and middleware. Should IIOP continue to garner support, it will become as common a protocol on the Web as TCP/IP and HTTP are now. This article describes IIOP and how it could turn the Internet into a network of distributed, interoperable objects.

What Is CORBA?
Before diving into IIOP, you need a brief overview of CORBA. CORBA is a distributed technology that supports access to remote objects developed in multiple languages across a variety of platforms, operating systems and networks. The CORBA 1.1 specifications spelled out the core functionality of an ORB (Object Request Broker), and described an IDL (Interface Definition Language) to define objects it interfaces with. The core of the CORBA architecture is the ORB, which is the object bus. The ORB allows client applications to find objects and invoke methods on them locally or across a network. It handles passing requests, responses and exceptions between a client object and a server object. When the client application uses an object, it doesn't need to know the object's location, programming language or type of platform because the ORB masks these details. The ORB handles the location of server objects in a repository that keeps this level of detail from the client. Objects the ORB will manage need to be registered so they are available to client applications.

Objects are the software solution to a business problem. They can be used to better describe and implement business processes. They're pieces of reusable software that encapsulate data and methods. The object class gives the object a name and an interface, and defines what it can do. An object class is used to build object instances in memory at runtime, and is written in a language such as Java. IDL can be used to describe the object class and methods in a language-neutral way. IDL doesn't actually implement any of the functionality an object will provide, but it can be used to create proxies that make distributing an object possible. It's also used to mask the language used to build the object from the client.

The client knows about server objects and functions through the proxy or stub generated by the IDL. A similar proxy or skeleton is generated for the server. These proxies handle marshaling, masking the fact that the object or request is remote. The proxies also manage object references that are used to identify a particular object instance of an object. The stub is a stand-in for the remote object on the client while the skeleton is a stand-in for the remote request on the server. The proxies allow each application to act as if the object or request came from within its own process (see Figure 1).

Figure 1
Figure 1:

Proxies enable static calling of object methods and require the stub to be compiled with the client. In addition to using proxies, CORBA also allows clients to call objects using the Dynamic Invocation Interface (DII), which allows client applications to call objects of which it has no knowledge at compile time.

CORBA 1.1 outlined the workings of this object bus, ensuring that objects written for one ORB could be moved to another. It didn't guarantee that the ORB from one vendor could communicate with one from another vendor. The ORB vendors were free to design their ORB products using any technologies and techniques they desired as long as they were compliant with the specifications. This resulted in several incompatible, proprietary ORB implementations. The CORBA 2.0 specifications addressed this concern, providing interoperability between ORB products through IIOP.

What Is IIOP?
CORBA 2.0 outlined a General Inter-ORB Protocol (GIOP) that specifies how ORB products from different vendors could communicate with each other. GIOP defines a standard data transfer syntax and messaging format over a transport protocol. It doesn't specify a particular communication protocol. It's a simple, protocol-neutral specification that can be mapped to several different network protocols. Since an ORB is concerned with maintaining object and data persistence between requests, GIOP assumes that the transport protocol is connection-oriented.

GIOP messages are made up of requests and replies in the traditional client/server model. To invoke a method, a client sends a request to a server, which waits for requests. On receiving one, the server processes it and sends a reply and any return values to the client.

The GIOP specification outlines the mapping of OMG IDL data types and object references to a common network representation known as CDR (Common Data Representation). CDR is an over-the-wire data format that handles marshaling of data types, byte ordering and other low-level operations to ensure that data is transported in a common standard format so that ORB invocations and information sent between machines on a network mean the same thing to both applications.

IIOP, a specific implementation of GIOP, defines how GIOP messages are mapped to the TCP/IP protocol (see Figure 2). To ensure interoperability between ORBs, CORBA 2.0 specifications dictate that all ORB products must support IIOP, either natively or through a bridge. Figure 3 illustrates how a client application can access an object on a different ORB through IIOP. Without IIOP to bridge the gap between incompatible ORB products, the client application using ORB A wouldn't be able to access the server object hosted by ORB B. IIOP provides a common interface that masks the ORB implementations behind it, making each ORB appear the same to each other.

Figure 2
Figure 2:
Figure 3
Figure 3:

How IIOP and TCP/IP Work
Most network stacks and communication protocols are compared to the OSI reference model when attempting to describe the role it plays in allowing communication between machines and applications. The OSI reference model, shown in Figure 4, has seven layers, each with a different set of responsibilities and its own set of APIs used to communicate with the layers above and below.

Figure 4
Figure 4:

As a network message is received, it moves up the stack, allowing each layer to perform its tasks, such as routing, error checking and data marshaling. Each layer removes any message header information pertinent to its layer and passes the message along to the next layer. When a message is sent out on the network, the opposite occurs. The higher up the stack a protocol rests, the more abstract it is and the more low-level communication details it takes care of. The APIs used to interact with a protocol on higher levels mask the intricate details of network messaging and marshaling handled by lower layers, while the level of abstraction between layers allows protocols in the higher levels to support several different lower-level protocols. Using higher-level protocols makes application development easier and more portable. Leaving communication management to a protocol frees developers to develop application objects.

IIOP
IIOP is a high-level protocol that takes care of many of the services associated with the levels above the transport layer, including data translation, memory buffer management and communication management. It's also responsible for directing requests to the correct object instance within an ORB. An object instance is identified by an Interoperable Object Reference (IOR), which is specified by the GIOP and generated by the ORB. Because actual object references are handled differently by each ORB, an IOR is used to pass object references between different ORB products. The client application can access the object using the IOR, which masks the client application's ORB implementation from the ORB implementation used to host the CORBA object.

TCP
TCP (Transmission Control Protocol) makes up the transport layer of the stack and is responsible for ensuring that the right application on a machine receives the message. It's also charged with dividing messages into smaller packets and reassembling incoming packets. TCP uses a port number to identify a particular server application. Most "well-known" server applications and services have a default port number on which they listen for requests. For example, 80 is the default port number for an HTTP Web server. Using a well-known port number makes it easier for client applications to find servers they are interested in connecting to. Unfortunately, IIOP doesn't have a default port.

IP
IP (Internet Protocol) is a network layer protocol that provides inter-network communications and an addressing scheme: the familiar IP addressing that's used on the Internet and Web. An IP address is a 32-bit number, usually represented in dotted decimal notation, for example, 161.125.23.116.

Each part of the address represents a byte of information ranging in value from 0 to 255. Depending on the class and subnet mask used by the IP address, a portion of the number represents the network ID and the remainder identifies the host or node on the network.

IIOP and HTTP
The Internet is now dominated by HTTP/CGI applications. The Hypertext Transfer Protocol (HTTP) is the standard communication protocol used by browsers and Web servers. It allows for the exchange of content, such as HTML documents, images and spreadsheets, on the Internet. The Common Gateway Interface (CGI) allows Web servers to access application programs. These application programs are capable of providing dynamic content and services over the Web, making data-driven Web-based applications possible. In addition to CGI, many Web server products provide extensions to interact directly with databases and objects. Figure 5 illustrates typical Web application architecture.

Figure 5
Figure 5:

HTTP/CGI is a slow and stateless protocol, however, with several limitations that impact how applications are built. The limitations inherent in HTTP/CGI can be resolved using IIOP. It's designed to support objects and state rather than content, making it a natural protocol on which applications can be built, and works over TCP/IP, helping it fit right into the Internet and intranet environments. IIOP provides a standard, robust protocol and, when coupled with the portability of the Java language, will eventually replace HTTP/CGI as the model on which Web applications are built.

IIOP has the following advantages over HTTP/CGI:

  • It doesn't require spawning a new instance of a program for each request.
  • It supports more robust argument data types than strings.
  • It provides the ability to obtain references to any objects on the Internet defined by OMG IDL.
  • It provides persistence of state between calls.
In addition, CORBA ORB and application server products provide dynamic function invocation, load balancing, transaction services and other robust features not found in most CGI applications. Figure 6 provides an overview of an IIOP-based Internet application.

Figure 6
Figure 6:

IIOP, Java and the Internet
The portability of the Java language and the openness of IIOP can be combined to create new and powerful Web applications. Java applets can communicate with objects via IIOP, allowing clients to access functionality without going through a Web server or using CGI. Java's portability rests on its ability to be compiled as bytecodes, which can be downloaded and run on a variety of platforms and operating systems using a Java Virtual Machine (JVM). JVM technology, available with most browsers, makes running Java applets and applications accessible to every client on the Internet. Java applet technology allows code to be deployed and managed from a central server, downloaded over the Internet and run on a client workstation. This enables changes to be made to Java programs and redeployed easily because each client downloads the code whenever it's needed.

Using a Java-enabled browser, a user can enter a URL to access a company's Web server. The Web server can return an HTML page and a Java applet over HTTP to the browser. The Java applet will contain an interface that allows the user to interact with the application. Using the client-side ORB, the Java applet can send requests to objects on another server using IIOP. These objects will be hosted by an application server or ORB, and can provide access to various data sources and processing. Accessing objects over IIOP instead of HTTP allows the Java applet to take advantage of the distributed object protocol, passing objects, various data types and maintaining state.

Figure 7 illustrates how the browser, Java, HTTP and IIOP can work together to provide a solution to building Web applications, a solution made even easier because of the support and widespread availability of IIOP by several leading software vendors. Netscape, Inprise/Visigenics and other application server vendors want to make CORBA and IIOP as ubiquitous as HTML and HTTP are today. To make this a reality, Netscape and Inprise/Visigenics are making Java and IIOP available on the Web by bundling their technologies. Netscape Navigator 4 ships with a Java Virtual Machine and Visigenic's Visibroker for Java ORB, making Java and IIOP available to every client that uses a Netscape browser.

Figure 7
Figure 7:

In addition to being widely available on the client, application servers and ORBs are also providing support for IIOP. The application server is a new breed of software that combines ORB functionality with that of a TP Monitor and Web server. Application servers host objects while providing scalability, reliability and access to various data sources in the middle tier.

Table 1 lists some of the major companies that support or plan to support IIOP in their Web/Application server products.

Table 1

It's interesting to note that the Visibroker ORB is licensed to SilverStream, Sybase, Oracle and Netscape, and is the basis for the CORBA/IIOP support in their products. Sun has stopped supporting their ORB products, NEO and Joe, and is encouraging customers to migrate to Visibroker. In addition, Sun has announced that Java RMI will support IIOP as well as JRMP as the underlying protocols. This makes Visibroker the leading ORB solution on the Internet.

The one notable company not listed as supporting IIOP is Microsoft, which is promoting DCOM as an alternative protocol. DCOM is not widely supported by non-Windows platforms, however. Microsoft tools and servers, including Internet Explorer, IIS and MTS, aren't likely to support IIOP in the near future. ORB client software, however, and products such as IIOP Engine by Iona, will help client applications without Netscape's browsers interact with objects on the Web. Bridges between DCOM and CORBA/IIOP will also enable MTS and IIS to interoperate with objects over IIOP on the server side.

Conclusion
IIOP provides a solid basis for the development and deployment of enterprise Web applications. The distributed object support and functionality it provides go a long way in overcoming HTTP/CGI limitations. Used in conjunction with the Java programming language, portable distributed applications on the Web are becoming viable solutions to business problems. Despite competition from DCOM, IIOP has both industry support and strong technology, making it the best candidate for becoming the next universal Internet protocol.

About the Author
Michael Barlotta is vice president of business development at MO Systems Solutions, Inc., and a CPD associate. He has a BA in computer science from The University of Albany (SUNY), New York. Mike is a contributing author to PowerBuilder 6: Secrets of the PowerBuilder Masters (SYS-CON Publications, Inc.) and the author of Distributed Application Development with PowerBuilder 6 (Manning Publications) You can contact him at [email protected]

	

Listing 1.
 
CREATE TABLE Customer ( 
CustomerId INTEGER NOT NULL PRIMARY KEY, 
Name VARCHAR(32), 
Address VARCHAR(100) 
) 

CREATE TABLE Orders ( 
OrderId INTEGER NOT NULL PRIMARY KEY, 
CustomerId INTEGER NULL REFERENCES Customer, 
Item VARCHAR(20), 
UnitPrice NUMERIC, 
Quantity INTEGER 
) 

Listing 2.
 
// Customer class 
public class Customer implements PersistenceCapable { 
private int customerid; 
private String name; 
private String address; 
private DCollection ordersForCustomer; 

// Accessor methods 
public int getCustomerid() { 
return customerid; 
} 
public void setCustomerid(int customerid) { 
this.customerid = customerid; 
} 

public String getName() { 
return name; 
} 
public void setName(String name) { 
this.name = name; 
} 

public String getAddress() { 
return address; 
} 
public void setAddress(String address) { 
this.address = address; 
} 

public Iterator getOrdersForCustomer() { 
return ordersForCustomer.iterator(); 
} 
public void addOrdersForCustomer(OrdersordersForCustomer) { 
this.ordersForCustomer.add(ordersForCustomer); 
} 
public void removeOrdersForCustomer(OrdersordersForCustomer) { 
this.ordersForCustomer.remove(ordersForCustomer); 
} 

// Constructors 
public Customer (Database db, int p_customerid) { 
this.customerid = p_customerid; 
} 
} 

// Orders class 
public class Orders implements PersistenceCapable { 
private int orderid; 
private String item; 
private long unitprice; 
private int quantity; 
private Customer customerForOrders; 

// Accessor methods 
public int getOrderid() { 
return orderid; 
} 
public void setOrderid(int orderid) { 
this.orderid = orderid; 
} 

public String getItem() { 
return item; 
} 
public void setItem(String item) { 
this.item = item; 
} 

public long getUnitprice() { 
return unitprice; 
} 
public void setUnitprice(long unitprice) { 
this.unitprice = unitprice; 
} 

public int getQuantity() { 
return quantity; 
} 
public void setQuantity(int quantity) { 
this.quantity = quantity; 
} 

public Customer getCustomerForOrders() { 
return customerForOrders; 
} 
public void setCustomerForOrders(CustomercustomerForOrders) { 
this.customerForOrders = customerForOrders; 
} 

// Constructors 
public Orders (Database db, int p_orderid) { 
this.orderid = p_orderid; 
} 
} 

Listing 3.
 
public void addOrdersForCustomer(Orders ordersForCustomer) { 
// check the credit history before adding the order 
if ( CreditHistory.getCreditHistory(this) == CreditHistory.BAD){ 
System.out.println("Sorry, bad credit history"); 
return; 
} 
// customer has a good credit history 
this.ordersForCustomer.add(ordersForCustomer); 
} 

Listing 4.
 
// open the database 
Database db = Database.open("jdbc:microsoft://thestork:1433/orderentry", 
"scott", "tiger"); 

// start a transaction to create a new Customer 

Transaction t = new Transaction(); 
t.begin(Transaction.OPTIMISTIC); 
Customer c = new Customer(db, 1000); 
c.setName("Foor Bar"); 
c.setAddress("901 San Antonio Road, Palo 
Alto CA-94303"); 
// do some more stuff like create orders for this customer etc.. 
try { 
t.commit(); 
} catch (RetryException re) { 
System.out.println( "The transaction did not go through. Try 
again."); 
} 

// close the database 
db.close();
  
      
 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.