what is the difference between socket programming, rmi and Servlets. When to use what?
RMI is remote method invocation which means methods are invoked remotely or accessing remote sites in client-server communication. Sockets are like gateways which provide access points for programs through some specific port numbers.
No, RMI is not deprecated. Not only is it not deprecated, it is a foundation building block for every J2EE application on the planet.
(1) Socket-based communication (java.net) Sockets are the endpoints of two-way connections between two distributed components that communicate with each other. (2) Remote method invocation (RMI) (java. rmi) RMI allows distributed components to be manipulated (almost) as if they were all on the same host.
Java provides three different types of sockets. Connection-oriented (TCP) sockets are implemented with the Socket class. Connectionless (UDP) sockets use the Datagramsocket class. A third type is the Multicastsocket class, which is a subclass of the DatagramSocket class.
The Socket APIs are the low-level (transport level) abstraction by which a Java application interacts with the network, and by extension with remote clients and services. Socket and related APIs support reliable byte stream and unreliable messaging services. They are typically used for TCP/IP and UDP/IP, though other networking protocol stacks can (at least in theory) be supported.
RMI is a framework and protocol family for implementing application-level networking between Java applications. It models network interactions as Java method calls made against objects that live in other applications. This model requires a mechanism (typically a name server) that allows one application to "publish" objects so that another application can refer to them. This (and the fact that RMI ports are typically blocked by default) means that there is a non-trivial amount of configuration effort in setting up RMI-based applications.
Servlets are a collection of APIs that are primarily designed for implementing the server side of HTTP communications; i.e. for building webservers in Java. They (or more accurately the web container in which they run) take care of the details of the HTTP protocol, so that the programmer (in theory) only needs to deal with "application" concerns.
In practice, the servlet developer and/or deployer has to deal with other things such as mapping URLs to servlets to objects, security and authentication. In addition, Servlets only deal with the server side of an HTTP interaction ... the client side must be handled by different APIs. (You could also argue that Servlets by themselves do not do enough, as evidenced by the proliferation of web application frameworks that are built on top of Servlets.)
In brief:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With