Is there an alternative to RMIfor getting access to remote Model from Controller?
Ekaterina Galkina
Greenhorn
Posts: 25
posted 1 week ago
I've been reading Head First Servlets and JSP and here is a fragment about RMI:
As the book says RMI is needed here to get access to the remote been.
On the other hand I read that RMI is obsolete.
So should I really use RMI in this case?
So, we have to move some of our model components off of the web server hardware and
on to the business tier servers. You know this won’t be the last time...
As the book says RMI is needed here to get access to the remote been.
On the other hand I read that RMI is obsolete.
So should I really use RMI in this case?
posted 1 week ago
-
1
-
-
-
-
I think they are being sloppy. RMI stands for Remote Method Interface. The closest to getting access directly to a Model object would be EJB Entity Beans.
RMI is primarily "obsolete" because the original RMI required that both sides of the conversation be done in compatible versions of Java and because it's not firewall-friendly. However, a web-friendly version - RMIOIP which stands for something like RMI Over Internet Protocols addressed some of that.
RMI is still quite useful, since it has about the lowest overhead of any standard Java client/server protocol, but in most cases, something more flexible and/or web-friendly is desired. The first attempt at that was SOAP - which is regrettably verbose and complicated. The second was AJAX, which, when paired with JSON or YAML is fairly low overhead and easy to work with.
The primary use for RMI is when you want high-performance communication between different JVMs on the same local network.
RMI is primarily "obsolete" because the original RMI required that both sides of the conversation be done in compatible versions of Java and because it's not firewall-friendly. However, a web-friendly version - RMIOIP which stands for something like RMI Over Internet Protocols addressed some of that.
RMI is still quite useful, since it has about the lowest overhead of any standard Java client/server protocol, but in most cases, something more flexible and/or web-friendly is desired. The first attempt at that was SOAP - which is regrettably verbose and complicated. The second was AJAX, which, when paired with JSON or YAML is fairly low overhead and easy to work with.
The primary use for RMI is when you want high-performance communication between different JVMs on the same local network.
An IDE is no substitute for an Intelligent Developer.
Ekaterina Galkina
Greenhorn
Posts: 25
posted 1 week ago
Thank you.
A silly question, but can REST services (http or not) be an alternative here?
Tim Holloway wrote:I think they are being sloppy. RMI stands for Remote Method Interface. The closest to getting access directly to a Model object would be EJB Entity Beans.
RMI is primarily "obsolete" because the original RMI required that both sides of the conversation be done in compatible versions of Java and because it's not firewall-friendly. However, a web-friendly version - RMIOIP which stands for something like RMI Over Internet Protocols addressed some of that.
RMI is still quite useful, since it has about the lowest overhead of any standard Java client/server protocol, but in most cases, something more flexible and/or web-friendly is desired. The first attempt at that was SOAP - which is regrettably verbose and complicated. The second was AJAX, which, when paired with JSON or YAML is fairly low overhead and easy to work with.
The primary use for RMI is when you want high-performance communication between different JVMs on the same local network.
Thank you.
A silly question, but can REST services (http or not) be an alternative here?
Ekaterina Galkina
Greenhorn
Posts: 25
posted 1 week ago
-
1
-
-
-
-
It's kind of hard to say about "business tier", since that's a term that can be used in many ways. For me, it would be something behind the web application and in your context that would normally put it on the LAN and thus RMI-friendly. Or, often, the business tier is simply a layer of a specific webapp. You'd normally only use a separate business VM if it had more than one client.
One of the popular ways to connect in a shared business processor is to link the web frontends with the business processor via a messaging agent. Something like JMS, maybe RabbitMQ. That gives an additional advantage when the load gets heavy, since the messaging agent provides queueing capabilities.
ReST is simply a web protocol that avoids keeping a Java HttpSession on the webapp server. Its advantage is that because HttpSessions consume server resources, that's fewer resources needed for the app to work. Another, bigger advantage is that since an HttpSession is bound to a single server or server cluster, you cannot effectively scale up and have, say, a thousand servers where incoming requests are load-balanced according to which server has the lowest current load.
From a data point of view, ReST communications are typically simple URL requests with JSON or YAML responses. Since they're being using like remote procedure calls from machine to machine, this is more convenient and less work than sending and receiving HTML content.
Incidentally, the original RPC idea expected a smart client calling procedures/methods over the network. This doesn't work too well over the Internet, since the delays can be considerable. These days, remote apps prefer to limit their requests. More work being done per request and lower frequency of requests.
One of the popular ways to connect in a shared business processor is to link the web frontends with the business processor via a messaging agent. Something like JMS, maybe RabbitMQ. That gives an additional advantage when the load gets heavy, since the messaging agent provides queueing capabilities.
ReST is simply a web protocol that avoids keeping a Java HttpSession on the webapp server. Its advantage is that because HttpSessions consume server resources, that's fewer resources needed for the app to work. Another, bigger advantage is that since an HttpSession is bound to a single server or server cluster, you cannot effectively scale up and have, say, a thousand servers where incoming requests are load-balanced according to which server has the lowest current load.
From a data point of view, ReST communications are typically simple URL requests with JSON or YAML responses. Since they're being using like remote procedure calls from machine to machine, this is more convenient and less work than sending and receiving HTML content.
Incidentally, the original RPC idea expected a smart client calling procedures/methods over the network. This doesn't work too well over the Internet, since the delays can be considerable. These days, remote apps prefer to limit their requests. More work being done per request and lower frequency of requests.
An IDE is no substitute for an Intelligent Developer.
Ekaterina Galkina
Greenhorn
Posts: 25
posted 1 week ago
I should have attach a picture from the book. It illistrates RMI.
Coud you also clear two point...
I'm a bit confused with mentioning AJAX in the previous message.
I thought Ajax was used to make javascript calls from browser to update a page partially, but here on the pic there are calls from Servlet (Controller).
Does it mean using ReST with EJB?
Coud you also clear two point...
I'm a bit confused with mentioning AJAX in the previous message.
Tim Holloway wrote:The second was AJAX, which, when paired with JSON or YAML is fairly low overhead and easy to work with.
I thought Ajax was used to make javascript calls from browser to update a page partially, but here on the pic there are calls from Servlet (Controller).
Tim Holloway wrote:ReST is simply a web protocol that avoids keeping a Java HttpSession on the webapp server.
Does it mean using ReST with EJB?
Ekaterina Galkina
Greenhorn
Posts: 25
posted 1 week ago
I ve posted a queetion about rest web services into a separate thread https://coderanch.com/t/683298/java/REST-web-services-Spring-Hibernate
posted 1 week ago
-
1
-
-
-
-
AJAX stands for something like "Asynchronous JavaScript Data Exchange". It is normally used when an "intelligent" web page wants to do partial form data submission and/or partial page updating. In that respect, it acts like a remote procedure call from the page, but unlike RMI, it's entirely over http/https protocols, so it's Internet-friendly. The AJAX server-side code can be simple servlet code or it can be handled by a framework dispatcher, such as the AJAX support (action processor) that's part of JavaServer Faces.
ReST is a session-less protocol. So an AJAX request can be ReST-less or ReST-ful, depending on your design.
A server-side processor, such as a servlet, that wishes to invoke business functions on a third-party server is allowed to do so, as long as the J2EE restrictions are observed. In the case of servlets, that means that the invoking request is not permitted to spawn child threads or wait for long intervals (more than 1 second or so). The third-party server can be RMI, JMS, web services, or anything else that a normal Java application could employ.
Enterprise JavaBeans were originally intended to provide services similar to what ordinary JavaBeans do, except that they can operate between JVMs. The first 2 attempts at EJB architecture, however, proved to be too much overhead and not Internet-friendly. EJB3 introduced the Java Persistence Architecture (JPA), which has become the standard for Entity Object Relational Model (ORM). JPA beans are POJOs, so they can be used much more efficiently than remote EJBs can be and can operate in almost any environment.
One of my favorite architectural models involves using JSF with AJAX on the front-end, a tier of business logic beans between the JSF GUI model objects and the persistence objects, and 3 tiers of persistence.
The top tier is invoked by the business tier, and is fully transactional. It deals with detached working sets of persistence model objects (Entity objects). This tier understands not only object relationships, but business contstraints on the objects.
The second persistence tier handles per-table functions, mostly. It is the tier that handles the bean finders and CRUD functions. Each class in this tier is usually a DAO handling just one table (or somethings a table plus direct children for tight parent-child relations). The top persistence tier uses these DAOs to find, assemble, and maintain the more complex table relationships.
The bottom persistence tier is simply the ORM model objects themselves. These can be simple JPA entities or actual remote or local EJBs, depending on requirements.
Here's a case where I solved a problem using RMI and probably would do so again even today when other options exist. I had the need to process millions of related records against a fuzzy scoring system and the entire set needed to be checked daily. Even with optimal change detection, this would typically spin off a full scan that took about 10 hours, running once or twice a week.
If I had put that function directly in my webapp, it would have held the entire webapp server hostage for the duration of the run. Not only the controlling webapp, but other unrelated business apps would be held up unless I forcibly terminated this very-long-running process. So I moved that part of the app function to an RMI server and used the webapp to monitor and control it via RMI. That left me free to start or stop the webapp server without interfering with the batch process.
ReST is a session-less protocol. So an AJAX request can be ReST-less or ReST-ful, depending on your design.
A server-side processor, such as a servlet, that wishes to invoke business functions on a third-party server is allowed to do so, as long as the J2EE restrictions are observed. In the case of servlets, that means that the invoking request is not permitted to spawn child threads or wait for long intervals (more than 1 second or so). The third-party server can be RMI, JMS, web services, or anything else that a normal Java application could employ.
Enterprise JavaBeans were originally intended to provide services similar to what ordinary JavaBeans do, except that they can operate between JVMs. The first 2 attempts at EJB architecture, however, proved to be too much overhead and not Internet-friendly. EJB3 introduced the Java Persistence Architecture (JPA), which has become the standard for Entity Object Relational Model (ORM). JPA beans are POJOs, so they can be used much more efficiently than remote EJBs can be and can operate in almost any environment.
One of my favorite architectural models involves using JSF with AJAX on the front-end, a tier of business logic beans between the JSF GUI model objects and the persistence objects, and 3 tiers of persistence.
The top tier is invoked by the business tier, and is fully transactional. It deals with detached working sets of persistence model objects (Entity objects). This tier understands not only object relationships, but business contstraints on the objects.
The second persistence tier handles per-table functions, mostly. It is the tier that handles the bean finders and CRUD functions. Each class in this tier is usually a DAO handling just one table (or somethings a table plus direct children for tight parent-child relations). The top persistence tier uses these DAOs to find, assemble, and maintain the more complex table relationships.
The bottom persistence tier is simply the ORM model objects themselves. These can be simple JPA entities or actual remote or local EJBs, depending on requirements.
Here's a case where I solved a problem using RMI and probably would do so again even today when other options exist. I had the need to process millions of related records against a fuzzy scoring system and the entire set needed to be checked daily. Even with optimal change detection, this would typically spin off a full scan that took about 10 hours, running once or twice a week.
If I had put that function directly in my webapp, it would have held the entire webapp server hostage for the duration of the run. Not only the controlling webapp, but other unrelated business apps would be held up unless I forcibly terminated this very-long-running process. So I moved that part of the app function to an RMI server and used the webapp to monitor and control it via RMI. That left me free to start or stop the webapp server without interfering with the batch process.
An IDE is no substitute for an Intelligent Developer.
Ekaterina Galkina
Greenhorn
Posts: 25
posted 6 days ago
I saw 3 tiers of persistence in some projects.
The names of top tire classes are usually end with "Service"/
The second persistence objects are DAOs.
Is the same in your project?
Ekaterina Galkina wrote: 3 tiers of persistence.
The top tier is invoked by....
The second persistence....
The bottom persistence tier is simply the ORM model objects themselves.
I saw 3 tiers of persistence in some projects.
The names of top tire classes are usually end with "Service"/
The second persistence objects are DAOs.
Is the same in your project?
