Protocols

Port overview

Scenarios:

·         HTTP/HTTPS – internet sites

·         RMI-IIOP – intranet environment; interoperability requirements (EJB-EJB, EJB-CORBA, etc.)

·         RMI-JRMP – intranet with an all Java environment

Firewalls:  Firewalls provide protection by:

·         packet filtering

o        IP blocking – source or destination IP

o        Port blocking – e.g. only allow well-known ports such as 80, 443, 25, etc.

·         protocol filtering – e.g. no FTP

·         HTTP/HTTPS aren’t generally affected by firewalls as ports 80 and 443 are normally allowed through. However, HTTP clients cannot generally accept asynchronous updates (push model) as more than likely the client will be prevented from running a socket server.

·         Most of the time, IIOP and JRMP are affected by firewalls as they use dynamic port allocation for object servers and use less well-known ports.

·         Although IIOP and JRMP can be tunneled through HTTP this isn’t ideal – the main benefit of being connection-based protocols is then lost.

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 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.
HTTPS(Secure Hypertext Transfer Protocol)

·         HTTP1.0 uses tear-down

o        Client opens/closes socket connection to the web server every time

·         HTTP1.1 uses keep-alive (a persistent connection).

o        Client holds socket connection open over multiple requests.

o        Still regarded as connection-less as it’s acceptable for the client or server to drop the connection at any time (e.g. Apache uses a 15 sec timeout on keep-alive sockets), client will re-establish the connection.

o        Client/server can use pipelining – i.e. sends multiple requests/responses down the socket at once.

·         Pros:

o        simple request/response mechanism

o        allowed through firewalls (most of the time)

o        widely supported / deployed

o        extensible - supports tunneling of arbitrary data;

o        custom request types/response content

·         Cons:

o        stateless - hence non-transactional

o        insecure - hence HTTPS

o        inefficient - e.g. MIME encoding can make files bigger

o        doesn’t support “push” model

HTTPS

·         Stateful / 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 layer.

·         HTTPS uses default 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.

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

·         Pros:

o        secure – only “in-the-clear” at client / server

o        allowed through firewalls (most of the time)

o        widely supported / deployed

·         Cons:

o        computationally expensive – excluding dedicated hardware, HTTPS can only process 10% of the traffic HTTP can

o        low performance compared to HTTP

o        Admin overhead – renewing certs, etc.

·         Each party (client/server) may hold multiple SSL sessions.

·         Each session may include multiple secure connections.

·         SSL handshake Process :

o        The client and server exchange capabilities (e.g. SSL version, ciphers available, etc.). The server includes it’s certificate in the response

o        client verifies the CA’s digital signature in the server certificate using the CA’s public key

o        if OK, the client generates a pre-master secret, encrypts it using the server’s public key and sends it to the server [if using client certificates, the client response includes the pre-master secret and the client certificate. The server verifies the CA’s digital signature in the client certificate using the CA’s public key]

o        the server decrypts the pre-master secret using it’s private key

o        using the pre-master secret, the client and server use an agreed algorithm to independently generate the master secret

o        the master secret is then used to generate a set of session keys (symmetric keys for speed)

o        the client and server exchange messages confirming that the encrypted session has started. Subsequent SSL records are compressed and encrypted / signed using the session keys

Note on Dashed line in the above figure: An RMI-IIOP client cannot necessarily access all existing CORBA objects. The semantics of CORBA objects defined in IDL are a superset of those of RMI-IIOP objects, which is why an existing CORBA object's IDL cannot always be mapped into an RMI-IIOP Java interface. It is only when a specific CORBA object's semantics happen to correspond with those of RMI-IIOP that an RMI-IIOP client can call a CORBA object. The dotted arrow indicates a connection that is sometimes -- but not always -- possible.

IIOP / RMI-IIOP

·         Stateful / connection-based.

·         no default port – the GIOP/IIOP implementation will dynamically assign ports when an object server instance binds to a name

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

·         GIOP  à CDR formatting rules + Message formats + message-transport assumptions.

·          IIOP (InterObject Internet protocol)  à General Inter-ORB Protocol (GIOP) + TCP.

·         Interoperable Object Reference (IOR) à address for the program ( part of the address is based on the server's port number and Internet Protocol (IP) address ). The IOR contains a set of profiles (details of host, port, object instance, etc.) so that a client knows where to connect / send messages back and forth.

·         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

·         CORBA is an integration technology, not a programming technology. It is specifically designed to be the glue that binds disparate programming technologies together

·         RMI-IIOP à RMI+CORBA à combines RMI's easy programming features + CORBA's interoperability

·         Pros:

o        supports propagation of security/transactional context

o        an open standard from the OMG

o        Mostly used for intranets / extranets – i.e. clients behind corporate firewalls or VPN connections Clients communicate with servers via an IOR (Interoperable Object Reference).

o        Interoperability – Java clients can call C++ servers; Cobol client can call Java server, etc.

o        Legacy integration

o        Designed for generic remote object invocation - type safe, extensible

o        Inbuilt support for security and transactions

o        CORBA and IIOP also guarantee that objects can describe their interfaces at run-time. The ability to do this in object and component models is often called "introspection." This capability allows users much more powerful browsing capabilities. Rather than just downloading documents, users can interactively discover and inquire about a wider range of more sophisticated object services.

·         Cons:

o        Firewalls – servers bound to arbitrary ports so firewall can’t be configured with an IIOP port; can use HTTP Tunneling. Can be supported with an IIOP proxy but “push” model is still problematic

o        Performance – all method invocations are remote (possibly over the internet)

o        Pass-by-reference – only supports remote references, can’t use pass-by-value (until CORBA 2.3)

·         The two major changes CORBA accepted were the Objects by Value and the Java-to-IDL Mapping specifications. The former, already available to RMI users in the form of Java object serialization, is a CORBA specification intended to make other languages implement a similar capability. The latter is the mapping used to convert RMI Java interfaces into CORBA IDL definitions, and must not be confused with the IDL-to-Java mapping already defined in CORBA 2.2.

·         RMI-IIOP client cannot necessarily access an existing CORBA object. If you do want to use Java to access CORBA objects that have already been written, Java IDL is an alternative to RMI-IIOP. Using Java IDL (a core part of the Java 2 Platform), you can access any CORBA object from Java.

·          Sun's recommendation for usage of RMI-IIOP and Java IDL.

·         If you want to use Java to access existing CORBA resources, Java IDL is recommended.

·         If, conversely, you want to export Java RMI resources to CORBA users, you should  use RMI-IIOP.

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 the default protocol for RMI – stateful / connection-based.

·         JRMP is a simple protocol consisting of five messages, plus an extra five for multiplexing flow control.

·         The default port for the RMI registry / JNDI name server is 1099, object servers will be dynamically assigned ports by the RMI runtime.

·         Pros:

§         Richer feature set than IIOP

§         pass by reference or by value;

§         distributed GC;

§         stub download ,

§         Single multiplexed connection

§         allows to move code ( behaviour)  in addition to data (state)

§         Data type can be any Java objects. Any Java objects can be passed as arguments. Arguments has to implement the serializable interface

§         carries Java's security model to ensure that the code downloaded is safe to run

§         allows pass by value references

§         uses Java as both an interface definition and an implementation language

§         uses a URL-based naming scheme

·         Cons:

o        Firewalls – servers bound to arbitrary ports; TTP tunneling limited

o        Performance – all method invocations are remote (possibly over the internet)

o        RMI lacks followings with respect to IIOP

§         Interoperability - only works in a Java environment In other words, RMI objects can talk only to other RMI objects. With RMI, you cannot invoke objects written in other languages or vice versa.

§         Dynamic invocations and interface repositories.

§         Wire protocol for security and transactions. RMI is both proprietary and lightweight. It was not designed to interoperate with other ORBs or languages. Unlike CORBA's IIOP, RMI is not a suitable backbone for the Internet or intranets; it lacks services IIOP provides.

§         Unlike CORBA, RMI offers no concept of services

§         RMI also does not include any object activation policies, such as those used by CORBA ORBs.

§         server objects written in Java using RMI suffer from poor performance due to limitations inherent in the Java virtual machine

§         While RMI is a viable option for smaller-scale applications to be written entirely in Java, CORBA provides the foundation for integration of existing objects with new code and also the ability to scale for the future

§         Lacks IIOP’s support for transaction/security context propagation ( RMI has only the naing service. CORBA has support for Naming, Security, Transactions, Events and Concurrency control )