The main application protocols relevant to the Java ecosystem, and how they can be setup to maximise interoperability:
The network stack is organized in layers (as defined in the OSI model), with each layer reusing the services of the layer immediately below.
From bottom to top, the main layers and protocols associated:
– Network protocol layer (#3 in the OSI model): IP
– Transport protocol layer (#4 in the OSI model): TCP, UDP. The tradeoff here is performance (UDP) vs relability (TCP).
Due to its inherent unreliability UDP is mostly used for video, gaming, chats, etc…
Note that it is possible to introduce some reliability on top of UDP, e.g. RUDP. TIBCO RV works on that principle.
– Application protocol layer (#7, topmost, in the OSI model): HTTP, HTTPS, FTP, SMTP, JDBC, RMI, SOAP…
(all on TCP due to the aforementioned reliability requirements)
Note that JMS being a pure API doesnt quite fit anywhere in the above representation…
Where it gets interesting is how these protocols can be combined to deliver enhanced functionalities:
– Pretty much everything can be tunnelled onto HTTP: RMI/HTTP, JDBC/HTTP, SOAP/HTTP…
The idea here is to piggyback on HTTP to take advantage of its ubiquity and firewall-friendly properties.
– If Http not available, it is still possible to tunnel through SMTP (although that would only suit asynchronous communications)
– JDBC/RMI: access JDBC databases via RMI (and/or ODBC databases via the JDBC/ODBC bridge, via RMI). See http://rmijdbc.ow2.org/
– JDBC/SOAP: In theory Java clients could use a SOAP<->JDBC bridge to access databases via SOAP/HTTP. Not sure if any such bridge exists.
– SOAP/JMS: improved reliability, guaranteed delivery of SOAP messages.
– RMI / JMS: reuse RMI programming model but with added benefits provided by JMS (reliability, asynchronousity)
– SOAP/RMI: using an existing RMI infrastructure to transport SOAP messages (will negatively affect bandwidth).