SCEA1.5 - Protocols

HTTP Properties:
Client-Server Architecture 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 the HTTP/1.0 protocol 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. There is no "memory" between client connections. The pure HTTP server implementation treats every request as if it was brand-new, i.e. without
context.
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.


HTTPS(Secure Hypertext Transfer Protocol) :
HTTPS (Secure Hypertext Transfer Protocol) is a 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 layer. (HTTPS uses port 443 instead of HTTP port 80 in its interactions with the lower layer, TCP/IP.) SSL uses a 40 or 128-bit key
size for the RC4 stream encryption algorithm, which is considered an adequate degree of encryption for commercial exchange.
Suppose you use a Netscape browser to visit a Web site such as NetPlaza (http://www.netplaza.com/) and view their catalog. When you're ready to order, you
will be given a Web page order form with a URL that starts with https://. When you click "Send," to send the page back to the catalog retailer, your
browser's HTTPS layer will encrypt it. The acknowledgement you receive from the server will also travel in encrypted form, arrive with an https:// URL, and
be decrypted for you by your browser's HTTPS sublayer.
HTTPS and SSL support the use of X.509 digital certificates from the server so that, if necessary, a user can authenticate the sender. SSL is an open,
nonproprietary protocol that Netscape has proposed as a standard to the World Wide Consortium (W3C). HTTPS is not to be confused with SHTTP, a security-
enhanced version of HTTP developed and proposed as a standard by EIT.
Resource:Whatis.com/https.htm


IIOP:
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 Internet Protocol (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.
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.
reference: http://www.blackmagic.com/people/gabe/iiop.html


JRMP :
The Transport layer employs JRMP, also known as the RMI Wire Protocol, 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.
All JRMP sessions consist of a header followed by one or more messages. The header contains just the ASCII codes for the characters JRMI , the protocol
version, and the "subprotocol" to be used. There are three subprotocols: SingleOpProtocol, StreamProtocol, and MultiplexProtocol. SingleOpProtocol signifies
that only one message follows a header before the end of a session (i.e., the connection closes). StreamProtocol and MultiplexProtocol can transfer one or
more messages. The latter is used when multiplexing calls from both client and server on a single socket, as described below.
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). The figure shows a hypothetical
StreamProtocol situation. The client sends the Call message to invoke a server object's method; the server then invokes this method and replies with a Return
containing any results. Assuming that a remote object is returned, the client then sends a DgcAck message to let the server's garbage collector know that it
has received the remote object. On another socket, the server sends a Ping to find out whether the client is alive, which replies with a PingAck.
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. This being the case, how do clients listen for server connections?
Enter the MultiplexProtocol and its group of five messages: Open , Close , CloseAck , Request, and Transmit. They allow client and server to simulate the
StreamProtocol's 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.
Unfortunately, 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.
This workaround is a smart solution, since HTTP is a firewall-trusted protocol. Still, performance takes a hit due to the time needed to convert messages to
HTTP requests. In addition, no multiplexing of invocations can be accomplished, because keeping the connection open between client and server is not part of
HTTP 1.0. The primary reason for SingleOpProtocol's existence is to encapsulate RMI through HTTP.
Reference: http://www.byte.com/art/9802/sec4/art3.htm

RMI:
RMI This is a possible if the objects in the user interface and the business layers are all Java objects. The persistence layer is mostly
accessed through JDBC. Other relational object mapping of the data layer is also possible. Advantage of RMI Object are passed by value. The server/ client
can reconstitute the objects easily. Data type can be any Java objects. Any Java objects can be passed as arguments. Arguments has to implement the
serializable interface Disadvantage of RMI Heterogeneous objects are not supported. Corba If the objects in the client layer and the business layer are
heterogeneous, i.e. the objects are implemented in C, C++ Java, Smalltalk then Corba is most suitable. Advantage of Corba Heterogeneous objects are
supported. Disadvantage of Corba Objects are not passed by value, only the argument data is passed. The server/ client has to reconstitute the objects with
the data. Only commonly accepted data types can be passed as arguments. Dcom This works best in windows environment. Distributed Object Communication Advantages Disadvantages HTTP Simple, Established Has to communicate to a Servlet, Java Server pages Cannot communicate to a Java class directly RMI Object are passed by value. The server/ client can reconstitute the objects easily. Object are passed by reference Data type can be any Java objects. Any
Java objects can be passed as arguments. Arguments has to implement the Serializable interface Heterogeneous objects are not supported. Corba Heterogeneous objects are supported. Objects are not passed by value, only the argument data is passed. The server/ client has to reconstitute the
objects with the data. Only commonly accepted data types can be passed as arguments Dcom If windows is the deployment platform suits well with the operating system This works in windows environment at best Distributed Object Frameworks Distributed Object Frameworks are RMI, Corba, Dcom, EJB. Basic Three-Tier Java Technology Architecture The three-Tier Java
Technology Architectureis achieved by HTML, Applet, Java Application on the client. Servlet, Java Server Pages on the Middle Tier. JDBC communication to the
persistence or Database layer Client C to M comm. Middle M to P comm. Persistence HTML HTML with applet HTTP Servlet Java Server Pages JDBC RDBMS Legacy File Java Application JRMP RMI Server JDBC RDBMS Legacy File Java Application RMI- II0P EJB JDBC RDBMS Legacy File Java Application ( Not a Java 3 tier) IIOP Corba JDBC RDBMS Legacy File

Conclusions: HTTP and HTTPS are very similar protocols with only the fact that HTTPS provides a layer of security(the SSL). They are both capable of passing a variety of
data types but there is no logic, objects may only be executed if there's another protocol to handle them. 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 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.

Default Portnumbers for the above protocols:
Http : 80, 8080
HTTPS,SSL: 443, 8443
JRMP: 1099
LDAP: 389
LDAP Over SSL - IIOP: 636