Java, The Client to Server Shift

By ServerWatch Staff (Send Email)
Posted Aug 7, 2001


Olivier Perron

Java has undergone a great shift from the Client side to the Server side over the last few years. This article explores how and why the shift has occurred.

Java has undergone a great shift from the Client side to the Server side over the last few years. This article explores how and why the shift has occurred.

 

Java before the shift

Java was born as a portable programming language that was very modern and truly well designed. At first, everyone saw Java as a good web tool for applets and client-server programs over the web. A great effort was put in AWT and later on in Swing, both GUI libraries.

People soon realized that portability on the client side was a good thing but that some problems were getting in the way. The first problem was speed and the solution was to go back to Html for user interfaces and have Java on the server. The second problem was firewalls, system administrators don't want to open other ports than the HTTP, HTTPS and FTP ports for security reasons. Of course, that meant applications needed to converse in new ways. The solution was to converse in HTTP or HTTPS (with SSL) because the port is already open, programmers know about HTTP and it's simple enough. That meant Java would move even more to the Server side.

 

The Shift

When? When J2EE appeared.

Why? Because there was a need for RAD on the server side and because hardware was not ready for Java on the client side.

What happened? Application Servers were introduced and J2EE was introduced. Development started and succeeded. Message got out that J2EE it worked well.

 

Java after the shift

Today Java is, more than anything else, a Server Side language. Some people still use it on the Client Side with Swing or AWT, and some people still write applets, but the biggest use for Java today is EJBs and Servlets -- Server side technologies.

 

The main reason for Java's strength on the server side is J2EE's apparition. J2EE has normalized the way java works on the server side and has defined specifications for the Application Server's manufacturers. More than a dozen Application Servers are now J2EE compliant and J2EE compliance has became the only way to stay in business for Application Servers.

 

J2EE compliant Application Servers allow developers to change from one Application Server to another without rewriting the Java program (write once, run anywhere). It also forces Application Server providers to implement many technologies that make the developers-- life easier. That means faster development times, less defects, more standardized programs and easier deployment. Those are very important concepts for Server side programs.

 

I expect J2EE to include specifications for load balancing and fail over, concept that are implement in most AS but are not standardized yet. Sun is adding many new specifications in J2EE and that makes J2EE compliant AS better tools.

 

Java's next shift

Java is not going to shift from the Server per say but we can see a trend to move Java to mobile devices. Java will run on various cell phones and PDAs with J2ME. At this point, J2ME is ready but only a handful of hardware has enough memory to support a programming language other than WML and WML Script. Java databases will also be a big thing, databases like PointBase (www.pointbase.com) are 100% Java with small footprint and sophisticated replication mechanisms.

 

Java will stay the Server language for the next years to come and should have more applications in mobile devices and on the client side, as hardware improves.

 

Page 1 of 1


Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.