Java Web Sockets

Written by Larry Gray on . Posted in Java WebSockets

Java Web Sockets

Java web sockets is Java's alternative to Ajax. It is actually not specifically Java but an open standard called Web Sockets which is the HTTP alternative to Ajax. Java Web Sockets is Java's implementation of Web Sockets. Basically in HTTP and Common Gateway Interface (CGI) protocols there is much text based overhead in each server request and response messaging. Prior a hack was made to servers that was unofficial to get around this problem. They called it Ajax. It was made official with Web Sockets. The jest of it is that now once the web socket is made your web page and Javascript code can make very concise request with as few characters as possible of the server and get back a very concise response. This reduces bandwidth and speeds communications and reduces lag considerably. Which makes many things possible that otherwise would be impractical. Javascript using the HTML DOM can update pieces of a web page in the browser vs having to reload the entire web page from the server. Surely you can see the advantages for yourself.

Java Facelets and Java Server Faces

Written by Larry Gray on . Posted in Facelets / JavaServerFaces

Java Facelets and Java Server Faces

So Java JSP is awesome and we need no more right? Wrong, JSP is great, but it is a very cryptic way to describe things. Also routine work on web type applications developed into repetitive design and coding task. This was turned into what is called web frameworks. Jakarta Struts is a 3rd party api for such a framework. Sun felt it was time to create a framework for distribution with the standard and extended api's. Facelets and Java Server Faces was born.

Faclets and JSF is built on top of the existing servlet technology. A facelet page is based on specialized facelet codes which are "interpreted" by a Java Facelet servlet. Java Server Faces is the framework that uses this facelet language. This gives the developer quick and easy access to common task using good ole MVC design patterns. And as you might guess Facelet source is a whole lot nicer to read than JSP tag source. Why all this ease of reading? Difficult to read source creates bugs, and slows debugging activities.

Java Servlets, JSP, Facelets and JSF may all be used happily together though Facelets and JSF side step JSP. JSP is left out in the cold by JSF. Not a bad thing really. I believe here this skipped uglier JSP and the compilation process. I would still have no problems using JSP if I wanted, so go ahead and use it all. Matter of fact for now this entire web site is JSP based.


I'll mention JavaFX here. This is some api that uses I think cryptic code for doing things similar to Macromedia Flash effects. It is hardly used at all and gained no real support from the Java community. If I learn more i'll put up a special article about this when I get time.

Java Servlets and Java Server Pages

Written by Larry Gray on . Posted in Servlets / JavaServerPages

Java Servlets and Java Server Pages

Well first maybe I should explain a bit about the first actual web applications called CGI's. CGI(Common Gateway Interface) is a protocol or language for formatting request and responses from an http server to and http client. On this web site the server is the Java web server Apache Tomcat 5.5. A client would be any web browser typically. Initially a web server would send a request in CGI format to standard output on the server, at the same time calling a program on the server to startup. This program can be written in any programming language which can get standard input and output to standard output (practically any language, and even shell scripts). So the server sends the request to standard output which is read as standard input by the program. It then processes the request and prepares a response which is again posted to standard output, the server then reads this back in as standard input. The server then sends this information back to the client as a response.

This was a pretty good thing in the dawn of the internet. However staring up a system process for each request used a lot of system overhead, ram, processor and such. This was especially true when the request begin to come in in large numbers at a time. A server could easily be bogged down with request it couldn't answer. It could even crash. However we have a savior, you might recall from the article on Desktop Applications and GUI 'multi threading'. Developers were already writing these servers on machines that could handle this multi threading. So they worked on a way to send this client request to a thread within the same process(the server itself) to be handled. In Java we call this thread a Servlet. This is far more efficient on system resources than starting up a whole system process (multitasking) for each client request. And threads may be pooled, meaning reused without shutting them down and restarting them each time saving even more precious ram and processor time. Since a servlet runs within the server process it is a mini-application. It is to the server what an "applet" is to the desktop application. The server is made in such a way that you merely drop your servlets into, this is even easier than plugging something in. I mean you simply build your Java sources for your Servlet classes, compile them and then locate them in a given folder structure. The Server automatically knows where to look for them based on good ole standards.

Also the Java Servlet API has some nice classes which encapsulate all that CGI messaging complexity. This api handles request data with one object and response data with another. It handles your http request types such as POST, GET, DELETE, etc. with a single method call. The API simplifies the whole mess so that you the programmer are free to work on your web apps logic.

As an example of running servlets look at the comment submission form on the arksoft home page. This is a servlet I wrote which displays the last 10 comments submitted. It also logs the comments in a text file on the server. And it sends me an email notifying me that a reader has submitted a comment, with the comment content and reply email address. A second servlet processes the captcha image spammer filter. Also the comment submission servlet rejects any comment with image links, or urls or html. I may eventually get this form at the bottom of each article but for now its just one form for the entire site.


Servlets are enough right? We can do anything we want with them now! Well yes but the ugliness of this was that source code becomes very ugly when its full of System.out.println(" ..........HTML.........HTML........"); We have mixed logic with content. It works. It works fairly well actually. Its just ugly. What is a JSP page? Its a text file named somename.jsp that contains (text only)(html)(text and or html and jsp tags)(jsp tags may contain Java source)

They came up with Java Server Pages to resolve this problem of ugliness and separate HTML from Java source. A jsp page is a text file that has a mix of HTML and JSP tags. This page is compiled by the server at runtime into you guested it, a Servlet and in this servlet the compiler builds all those System.out.println("...html..."); lines for you. When is it compiled? The first time a jsp page is accessed from a browser. This can take seconds to even a minute and may confound a visitor who thinks the page is not loading. Developers usually access the jsp pages themselves to compile them to save the visitor from having to wait. Speaking of the compiled servlet source, good news is that most of the time you never have to look at that ugliness. You can if you want too but there is usually no need unless a debugging problem arises. Java source code can also be included on the jsp page as well if needed though this is probably not best practice. Instead you try to focus on keeping your content in the jps pages and your application logic in supporting Servlets.

And can we somehow work JavaBeans into this scene? Yup, but I won't talk about it on this web site at this time except to say its called EJB Enterprise Java Beans and that requires an additional Server to run with Tomcat called JBoss. There are other 3rd party EJB containers as well. And in fact you could probably use the JavaBean design without an EJB container if you tried with some benefit.

That's not the end of the story with JSP, JSP has what is called Tag Libraries. To be honest I have yet to mess with them. JSP and Servlets and servers for that matter have one very important feature called 'Server Side Includes'. This means the output of one serlvet can be the input of another. It also means that multiple jsp pages and html pages can be combined into one html page for a single response. How is this helpful? Web page headers and footers are prime examples. Let say I have 100 web pages on a web site. Instead of editing 100 pages to update a header or footer I now only edit two files, one for the header and one for the footer. The index.jsp page for each one will look something like the following psuedo example.

JSP Include header.html tag Page content JSP Include footer.html tag

I use this technique on ever page on this web site for header, footer, bread crumb trail, horizontal menu, vertical menu, related links and recommended books. I sometimes use the same related links for sets of pages for example. Mastering the use of server side includes is a must for any web developer that will save countless hours of work or at least make work possible that otherwise would be put off or never done.

Java Applets and Webstart

Written by Larry Gray on . Posted in Applets / Webstart

Java Applets and Webstart

Java Applets

Java applets are mini-applications which run within another application. Applets actually could be run as a desktop application with Java's appletviewer.exe program. And actually, that may be the only way to make an applet run at the current day and time. Well, a better way to run an applet is to convert it to Web Start application which I talk about later on in this article.

Java applets were quit the rage when Java first appeared on the scene. Applets are primarily run on a web page. However over time they lost popularity. Reasons for this might include applets being to startup. Another was applets not starting up at all which usually had a fix but was frustrating enough from the end user point of view to cause a loss in popularity. Applets may have enjoyed their greatest success in the case of in house programming within corporations. One very well used applet to date might be the RPG game called Runescape. Other popular alternatives to the use of Applets were Javascript and Macromedia Flash. At any rate this gave rise to Java Web Start technology.

Applets are inserted into a web page with a single html applet tag. Later the standard changed on this and an html object tag was used instead. The tag gave the applet space on the page as a rectangular area of given dimensions in pixels. An applet might inhabit for example 400x400 on an 800x600 page.

Applet and Web start applications run in what is known as a Security Sandbox. This means that applets do not have access to ram, to hard drive space or any storage space. Well thy can store and read Java cookies. Cookies might be a whole other article. Javascript , Web Start, Java Servlets and JSP can also access cookies. Briefly a cook is 4096 byets of storage on your hard drive in text files where each cookies is a name=value pair. Don't worry, cookies can't have viruses or malware, though they can be read and written by any application on your computer that has not been controlled by security features, such as viruses and malware. This doesn't mean you should disable them however, it simply means you should be more careful about protecting your computer from viruses and malware.

Applets may also not make network connections to other computers. They can only connect back to the computer they were loaded from. These security restrictions can be relaxed in a number of ways. Applets can be signed and have security certificates. Or a user may install a Java security policy file which grants the applets permission to do potentially dangerous things. Or if the applet is loaded locally from the local hard drive it will have a different security policy and has access to the local system and networking. Applets do have usefulness which is why we now have the Java Web Start technology.

Java Web Start

Java Web Start technology is almost the same thing as the Java Applet technology except that it is a normal java application which runs in a Sandbox on your computer as a desktop GUI application with its own Frame. Security is the same for web start apps as it is for Applets. I do not have much to say about Java Web Start except to say that a special file type called .jnlp is needed to launch the web start app in a single mouse click on a web page link. It is then downloaded and started up in the sandbox. Applets and Web Start applications are both cached on the local hard drive in your browsers cache. Applets, Web Start Apps and cookies are all wiped off the hard drive with system cleanup task.