Java RMI over IIOP

Java RMI over IIOP

Object request broker (ORB)

An object request broker (ORB) is a middleware technology that manages communication and data exchange between objects. ORBs promote interoperability of distributed object systems because they enable users to build systems by piecing together objects- from different vendors- that communicate with each other via the ORB [Wade 94]. The implementation details of the ORB are generally not important to developers building distributed systems. The developers are only concerned with the object interface details. This form of information hiding enhances system maintainability since the object communication details are hidden from the developers and isolated in the ORB [Cobb 95].

Dynamic Host Configuration Protocol

The Dynamic Host Configuration Protocol (DHCP) is a set of rules used by communications devices such as a computer, router or network adapter to allow the device to request and obtain an IP address from a server which has a list of addresses available for assignment.
DHCP is a protocol used by networked computers (clients) to obtain IP addresses and other parameters such as the default gateway, subnet mask, and IP addresses of DNS servers from a DHCP server. The DHCP server ensures that all IP addresses are unique, e.g., no IP address is assigned to a second client while the first client's assignment is valid (its lease has not expired). Thus IP address pool management is done by the server and not by a human network administrator.
DHCP emerged as a standard protocol in October 1993. DHCP is a successor to the older BOOTP protocol, whose leases were given for infinite time and did not support options. Due to the backward-compatibility of DHCP, very few networks continue to use pure BOOTP. As of 2006, RFC 2131 (dated March 1997) provides the latest DHCP definition. As of 2004, the latest non-standard of the protocol is RFC 3315 (dated July 2003), which describes DHCPv6 (DHCP in an IPv6 environment).
The Dynamic Host Configuration Protocol (DHCP) automates the assignment of IP addresses, subnet masks, default gateway, and other IP parameters.[1] When a DHCP-configured machine boots up or regains connectivity after a network outage, its DHCP client sends a query requesting necessary information from a DHCP server. The DHCP server manages a pool of IP addresses and also has information about client configuration parameters such as the default gateway, the domain name, the DNS servers, other servers such as time servers, and so forth. The query is typically initiated immediately after booting up and must be completed before the client can initiate IP-based communication with other hosts. The DHCP server replies to the client with an IP address, subnet mask, default gateway, and other requested information such as DNS server, etc.
DHCP provides three modes for allocating IP addresses. The best-known mode is dynamic, in which the client is provided a "lease" on an IP address for a period of time. Depending on the stability of the network, this could range from hours (a wireless network at an airport) to months (for desktops in a wireline lab). At any time before the lease expires, the DHCP client can request renewal of the lease on the current IP address. A properly-functioning client will use the renewal mechanism to maintain the same IP address throughout its connection to a single network. Maintaining the same IP address is important to correct functioning of higher-layer protocols. However, if the lease actually expires, the client must initiate a new negotiation of an IP address from the server's pool of addresses. As part of the negotiation, it can request its expired IP address, but there is no guarantee that it will get it.
The two other modes for allocation of IP addresses are automatic (also known as DHCP Reservation), in which the address is permanently assigned to a client, and manual, in which the address is selected at the client (manually by the user or any other means) and the DHCP protocol messages are used to inform the server that the address has been allocated.
Configuring firewall rules to accommodate access from machines who receive their IP addresses via dynamic DHCP is problematic because the IP address can vary over time. If fine-grained control of access to an IP address is required, the automatic or manual mode should be used for allocating the address.
The negotiation for an address is initiated by a client broadcast. If the DHCP server is not on the local area network and the router is not specially configured, the DHCP server will not receive the broadcast message because routers do not forward broadcasts. However, most routers can be configured as relay agents to forward messages to the DHCP server and to return the server replies to the client. This mode of operation occurs in large organizations using a single DHCP server to supply client configuration to many different networks. Home users should never need this functionality.

The SNMP Management Information Base (MIB) [SNMP]

A Management Information Base (MIB) describes a set of managed objects. An SNMP management console application can manipulate the objects on a specific computer if the SNMP service has an extension agent DLL that supports the MIB.
Each managed object in a MIB has a unique identifier. The identifier includes the object's type (such as counter, string, gauge, or address), the object's access level (such as read or read/write), size restrictions, and range information.

SNMP and UDP

SNMP and UDP
SNMP uses the User Datagram Protocol (UDP) as the transport protocol for passing data between managers and agents. UDP, defined in RFC 768, was chosen over the Transmission Control Protocol (TCP) because it is connectionless; that is, no end-to-end connection is made between the agent and the NMS when datagrams (packets) are sent back and forth. This aspect of UDP makes it unreliable, since there is no acknowledgment of lost datagrams at the protocol level. It's up to the SNMP application to determine if datagrams are lost and retransmit them if it so desires. This is typically accomplished with a simple timeout. The NMS sends a UDP request to an agent and waits for a response. The length of time the NMS waits depends on how it's configured. If the timeout is reached and the NMS has not heard back from the agent, it assumes the packet was lost and retransmits the request. The number of times the NMS retransmits packets is also configurable.
At least as far as regular information requests are concerned, the unreliable nature of UDP isn't a real problem. At worst, the management station issues a request and never receives a response. For traps, the situation is somewhat different. If an agent sends a trap and the trap never arrives, the NMS has no way of knowing that it was ever sent. The agent doesn't even know that it needs to resend the trap, because the NMS is not required to send a response back to the agent acknowledging receipt of the trap.
SNMP uses the UDP port 161 for sending and receiving requests, and port 162 for receiving traps from managed devices.

IIOP protocol for RMI and CORBA

IIOP (Internet Inter-ORB Protocol) is a protocol that makes it possible for distributed programs written in different programming languages to communicate over the Internet. IIOP is a critical part of a strategic industry standard, the Common Object Request Broker Architecture (CORBA). Using CORBA's IIOP and related protocols, a company can write programs that will be able to communicate with their own or other company's existing or future programs wherever they are located and without having to understand anything about the program other than its service and a name. CORBA and IIOP are competing with a similar strategy from Microsoft called the Distributed Component Object Model (DCOM). (Microsoft and the Object Management Group, sponsors of CORBA, have agreed to develop software bridges between the two models so that programs designed for CORBA can communicate with programs designed for DCOM.)
CORBA and IIOP assume the client/server model of computing in which a client program always makes requests and a server program waits to receive requests from clients. When writing a program, you use an interface called the General Inter-ORB Protocol (GIOP). The GIOP is implemented in specialized mappings for one or more network transport layers. Undoubtedly, the most important specialized mapping of GIOP is IIOP, which passes requests or receives replies through the Internet's transport layer using the Transmission Control Protocol (TCP). Other possible transport layers would include IBM's Systems Network Architecture (SNA) and Novell's IPX.
For a client to make a request of a program somewhere in a network, it must have an address for the program. This address is known as the Interoperable Object Reference (IOR). Using IIOP, part of the address is based on the server's port number and IP address. In the client's computer, a table can be created to map IORs to proxy names that are easier to use. The GIOP lets the program make a connection with an IOR and then send requests to it (and lets servers send replies). A Common Data Representation (CDR) provides a way to encode and decode data so that it can be exchanged in a standard way.
A somewhat similar protocol, the Remote Method Invocation (RMI), was developed by Sun Microsystems to serve its cross-platform framework for the Java programming language. Sun has provided a way so that programming that uses the RMI can be mapped to IIOP.