JCEA Part 1: Protocols

 

Contents

  1. General
  2. References
  3. Syllabus
    1. Concepts
    2. Common architectures
    3. Legacy connectivity
    4. EJB
    5. EJB Container model
    6. Protocols
    7. Applicability of J2EE
    8. Patterns
    9. Messaging
    10. Internationalisation
    11. Security
  4. Reference
    1. UML
  5. Resources
  6. Further Tips
 
 

Syllabus

  • Given a list of some of its features, identify a protocol that is one of the following: HTTP, HTTPS, IIOP, or JRMP
  • Given a scenario description, distinguish appropriate from inappropriate protocols to implement that scenario
  • Select common firewall features that might interfere with the normal operation of a given protocol
 

Information

Protocols

Port Overview

Standard port Protocol/Service Comment
21 FTP File transfer protocol
23 telnet Remote login
25 SMTP Simple mail transfer protocol
80 HTTP WWW transmission protocol
110 POP3 Post office protocol
161 SNMP Simple network management protocol
443 SSL Secure sockets layer
389 LDAP Lightweight directory access protocol
636 LDAPS LDAP over SSL - IIOP Internet Inter-Orb Protocol
1099 JRMP Java remote method protocol

HTTP

The HTTP protocol is based on a request/response paradigm. The communication generally takes place over a TCP/IP connection on the Internet. The default port is 80, but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, so long as reliability can be guaranteed.

The HTTP protocol is connectionless and stateless After the server has responded to the client's request, the connection between client and server is dropped and forgotten. To mainstain state the following techniques may be used:

Cookies
A variable or name-value pair created and used by the webserver but stored on teh client by the browser
URL rewriting
By changing each link to contain soem extra state information it is possible to maintain state between connections. This solution poses a security risk as otehrs may be able to break into the connection
HTTPS
As HTTPS is connection based (see later) it can be used instead of HTTP to maintain state in a secure way.
Applets
An Applet can hold state or keep a dedicated connection open continously

An extensible and open representation for data types HTTP uses Internet Media Types (formerly referred to as MIME Content-Types) to provide open and extensible data typing and type negotiation. When the HTTP Server transmits information back to the client, it includes a MIME-like (Multipart Internet Mail Extension) header to inform the client what kind of data follows the header. Translation then depends on the client possessing the appropriate utility (image viewer, movie player, etc.) corresponding to that data type.

HTTP has three request formats:

GET
Simplest request. Carries only a URL which may have small amounts of extra information appended to it using seven-bit ASCII characters, typically of the form http://server/page?extra%20information
POST
Used to send significant amounts of information from the client to the server. Data sent using multiple lines.
HEAD
Used to find basic information about a page without looking at it, typically used to check whether a page has changed from the last cached version.

HTTPS (Secure Hypertext Transfer Protocol)

HTTPS (Hypertext Transfer Protocol over Secure Socket Layer, or HTTP over SSL) is a connection-based Web protocol developed by Netscape and built into its browser that encrypts and decrypts user page requests as well as the pages that are returned by the Web server.

HTTPS is really just the use of Netscape's Secure Socket Layer (SSL) as a sublayer under its regular HTTP application layering. (typically using port 443). SSL gives encryption, authentication, and an identifiable session for maintaining state, however it has high startup overhead.

The level of encryption and authentication depends on the capaibility of both parties and so security is only as strong as taht negotiatied.

IIOP

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).

IIOP moves state for arguments and return values for method calls, but not behaviour (objects). It may be tunnelled over TCP/IP port 80. CORBAS services can be made available to IIOP. These include security, transactions and naming.

CORBA is not the only architecture that uses IIOP. Because a TCP/IP-based proxy is usable on almost any machine that runs today, more parties now use IIOP. When another architecture is IIOP-compliant, it not only establishes a well-proven communication transport for its use, but it also can communicate with any ORB implementation that is IIOP-compliant. The possibilities are endless.

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.

JRMP

JRMP is a proprietary wire-level protocol designed by Sun Microsystems to transport Java RMI. JRMP serves the same function as IIOP, but also supports object passing. Also known as the RMI Wire Protocol, is used to send method invocations and associated parameters and to return values and exceptions from one Java virtual machine (JVM) to another. JRMP is a simple protocol consisting of five messages, plus an extra five for multiplexing flow control.

JRMP moves state and behaviour (whole Objects) including arguments, return values and exceptions for method calls. As it is native Java technology there is less overhead in converting data to Java types. It can use SSL and JAAS security services.

Communicating clients and servers typically each open a socket to the other (i.e., both systems connect and listen for connections). The client's socket typically invokes methods on server-side objects, and the server's socket calls client-side objects (e.g., callbacks).

Default applet security restrictions deny applets the right to open sockets back to any server other than their originating host; they also block any attempt to listen for socket connections. To get around this JRML allows a client and server to simulate two-way communication using a single socket. In the current implementation, up to 256 virtual connections can be opened, each identified by a unique ID.

Connecting via a socket back to the server is not always possible for applets running behind firewalls (e.g., on a corporate intranet), which typically block any attempt to open a socket back to the Internet. Should it fail to open a connection, an RMI client wraps its method invocation inside the body of an HTTP request (which is the protocol browsers use to communicate with Web servers), and the RMI server sends any results as an HTTP response.

When to Use

  • HTTP and HTTPS are very similar protocols with only the fact that HTTPS provides a layer of security (using SSL). They are both capable of passing a variety of data types without anyunderstanding of the data being carried.
  • HTTP is the lowest layer of logic and can only be used as a delivery mechanism for other protocols.
  • JRMP is a robust object server that communicates well when working with JAVA based objects. It is capable of passing objects refrences rather than just values that have to be reconstituted so that the object may be executed by the client rather than the server. In the even that the server is secure or cannot communicate in the most efficient manner JRMP falls back to HTTP. JRMP is only capable of passing JAVA objects.
  • IIOP is the most flexible of the transport mechanisms, it can communicate objects created in many langauges including C, C++, JAVA, and smalltalk but only passes data by value requiring the server to do all the work and requiring that only common data types be passed as arguments making it more restrictive than JRMP which allows any JAVA data type.
 

Links

  1. Comparing IIOP, RMI and HTTP
  2. HTTP from whatis.com
  3. HTTPS from whatis.com
  4. IIOP from whatis.com
  5. IIOP from blackmagic.com
  6. JRMP from byte.com
 

Observations

HTTPS (HTTP+SSL) runs on 443. Two questions expected you to know this.

Page created by Leo Crawford
last updated in June 2002