Michael Yuan

We all know that dynamic web pages consume CPU and memory resources on the server. So, how can mass web hosting companies provide PHP *and* MySQL support on a $3/mo account? Well, as I found out the hard way (my blog was down for the most of last week since it cannot handle even modest amount of traffic), you get what you pay for …

To be fair, I do understand the need to constrain the number of PHP threads for each shared account to make sure that no one is hogging is resources. The hosting company does not state this limitation when you sign up for their account — all you see is the number of MySQL DBs, mailboxes etc. The number limit on PHP threads is NOT mentioned! However, when your web site hits 25 concurrent PHP threads, all of the sudden, it stops working. And it does not just refuse requests beyond the 25 thread limit. It stops working altogether for 4-5 hours!

Now, 25 concurrent PHP threads should be enough for most sites. I mean, assuming the load is evenly distributed, even if a request takes a long 25 seconds to process, the site is still capable of 60 page views per minute (that is 3600 page views per hour and 86k page views per day). The throughput would be much higher if the processing time is shorter. Considerring that traffic is not evenly distributed, I’d still expect 1000+ page views per hour. So, why did my site crashes when the page view is merely 150 per hour? Oh well, that is because I am running a blog site. A lot of RSS readers would automatically poll my site every a couple of minutes and that is not included in the “page view” stat. So, in reality, my RSS feed PHP script is executed more than 10x of my regular HTML page rendering PHP script.

In any case, I am done with “shared” hosting. I will only use my account for static files (e.g., images). I am now moving my blog to a VPS solution where I have guaranteed server resources.

If TheServerSide is Slashdot for Java developers, dzone is Digg for developers. My blog entry “Is JSF really that bad?” was “dzoned” a couple of days ago and it crashed under the added traffic (or comment spam that associated with the traffic, see below).

Here is the hourly traffic diagram of my site on that day. The site crashed briefly (1-2 hours) in the morning shortly after the story was picked up by news sites. Then it recovers, cannot handled the traffic and crashed soon after dzone referenced it.

Here is the dzone story that started it. My apologies to dzone readers who clicked on the story but only saw the server error!!

Actually, before that, I have never paid much attention to dzone. I know it is a social bookmarking site started by guys at JavaLobby. But that’s pretty much it. Now that I know it better, I start to use and enjoy it.

BTW, the reason my site crashed was that my cheap hosting company only allows 25 concurrent PHP threads. (Yeah, the $5 for 20G storage deal does not look very good now!) Since I route all comments to Akismet to check for spam, the comment submitting PHP thread could potentially be long running. So, it could reach the 25 thread limit very soon if there are a couple comment spam robots working against me. I had to block some IP addresses to recover my site!

JBoss AS 4.0.5 was officially released last week. You need to use the JEMS installer to install the EJB3 profile in order to run EJB3 / Seam applications on it.

I have just updated the EJB3 Trailblazer learning application for AS 4.0.5 release (download the source code here). The only places I need to change are to add select statements in all database queries. Appearantly Hibernate allowed the omission of the select clause while JPA standard does not.

Gavin has released a BETA for Seam 1.1. Get it here. It has some nifty new features. I will update the book very soon! Here are some of the major 1.1 features I especially liked. I will probably write separate blogs explaining them.

* The Seam Application Framework for data-oriented applications

MY: Think “Spring templates” … Those are standard DAO wrappers for entity beans. They reduce the amount code you have to write for common data access features in session beans.

* Integration of Ajax4JSF for partial page refresh

MY: It is great to see those two great frameworks work together! I have been using Ajax4jsf in my Seam + Facelets applications for sometime now. Works great.

* Support for atomic conversations

MY: Greatly reduce database round trips by flushing the persistence context only at the end of the multi-page conversation (as opposed to at the end of each transaction in standard setup). This further makes Seam a superior web framework for ORM (also see here).

* Exception handling via annotations of exceptions.xml

MY: Very nice feature! It allows you to redirect to any page upon any Exception! No more hacking around the FacesServlet

* Efficient clustering of Seam-managed extended persistence contexts and JavaBean components

MY: Seam is a stateful framework that IS highly scalable.

* Page fragment caching via <s:cache/>

MY: You can cache static page segements to improve performance when you have mixed static and dynamic content on frequently accessed pages.

* “Decoration” of invalid input via <s:decorate/>

MY: Another improvement on the already very nice input mechanism that ties JSF input directly to Hibernate validation annotations.

* Page parameters for RESTful applications

MY: Seam already provides strong support for RESTful applications. With this new feature, you can further integrate RESTful pages into your stateful page flow (a.k.a Seam “business process” like page flow).

* New concurrency model for Ajax-based applications

MY: There are several easy ways to integrate AJAX functionalities into Seam apps. This new feature improves Seam’s internal support for AJAX — it now allows multiple concurrent AJAX requests to the same Seam backend component / context.

In addition, other useful enhancements include:

* Asynchronous methods and events
* Enhanced configuration via components.xml
* Themes
* Support for the Sun JSF 1.2 reference implementation

Seam 1.1.BETA1 is compatible with JBoss 4.0.5.GA and JBoss Embeddable EJB3 alpha 8. It is also compatible with GlassFish, the Java EE 5 reference implementation.

One of biggest selling points of JSF is that it is “Java EE standard” technology. However, as developers are starting to discover, the power JSF can be greatly enhanced by “non-standard” technologies that complement JSF: Facelets, Seam, Ajax4jsf, Spring-JSF are just some examples. So, shall we use those “non-standard” technology with JSF? Would they defeat the whole purpose of leveraging a standard-based solution? Well, I think the short answer is: yes, you should use “non-standard” technologies whenever it helps you …

First of all, let’s be clear that the Java EE standard is evolving. Today’s “non-standard” technology, if proven useful, may well be tomorrow’s standard. Hibernate and JPA is a perfect example. In the JSF space, Facelets is written by a Sun employee and Seam already had a JSR approved. They may well become standard technologies in the not too distant future.

But even that aside, I think it is important to understand that the real strength of JSF is that it is a standard component technology. It allows third party vendors to create components based on a standard set of APIs and lifecycle. It also allows tool builders to develop visual UI editors based on the standard interface. That is different from previous attempts of component-based web frameworks in Java, such as Tapestry and WebObjects. The standard-based approach has created a vibrant components and tools market place around JSF like no other Java web framework has seen. And that kind of “standard” is NOT affected by your choice of JSF add-on frameworks such as Facelets and Seam.

So, relax and choose the best tool you need to enhance your JSF development experience. The standard component framework of JSF will continue to be leveraged by 3rd party vendors to give you a rich choice of JSF components and tools. That, is the true power of the JSF standard.

Ignacio Coloma posted a long article detailing his unpleasant experience with JSF, and the MyFaces implementation in particular. First off, I agree with him on many of the points he raised. But, I think some of Ignacio's major complaints can be easily resolved if one is willing to look slightly outside of the "standard JSF". Well, you probably guessed it by now. I am talking about Seam.

1. Ignacio mentioned that ORM (e.g., Hibernate) is difficult when an ORM backend is accessible by the stateful JSF presentation layer. I could not help but notice that he is using the stateless Spring framework to connect JSF and Hibernate. IMO, that is the problem. As we know, ORM lazy loading is a messy problem with any stateless architecture due to limited lifecycle of the persistence context. What you really need is a stateful framework that truly understands how to leverage the state information in the JSF tier and in the ORM tier, and then make them work together. JBoss Seam is such stateful framework for JSF and Hibenrate (or EJB3 JPA, which Hibbernate implements). Believe me, Seam and Hibernate work so well together, you'd think that they are made for each other (actually, they are both brain children of Gavin King). See more on this issue here.

2. Ignacio's second big complaint is that JSF is not friendly to HTTP GET (or REST) URLs as everything is instaniated from a postback. I agree that in plain JSF, it is a hassle to setup RESTful URLs. But with Seam, the HTTP GET parameter is simply injected into the backend component when the component initializes itself for every request. There is no manual pulling of request parameters. You can also start Seam conversations (a state management facility finer than HTTP session) from an HTTP GET operation. I have recently been working on a Seam-based web site that primarily uses GET URLs (and a ton of AJAX). It has been a breeze to write those RESTful pages in Seam!

3. It is somewhat trival, but MyFaces' use of JavaScript in hyperlinks can get very annoying when you want the link to behave like a regular web link (e.g., to right-click it etc.) Seam provides an easy solution via its own UI components like the <s:link> component. The Seam link / button components have the added benefit of support Seam conversation states out-of-the-box.

Example:

To illustrate the above points, let's look at a simple RESTful page with Seam. Suppose that you want to use a URL like product.seam?prodId=8 to retrieve and display a product from a database. The Product entity object might need to further lazy load some of its properties during rendering. Do we need complicated XML or data transfer objects? Not with Seam! Here is the Java component (JSF backing bean):

Then, on the product.xhtml page, you just display the product info.

That's it! All the lazy loading of product properties, if any, are automatically taken care of at the rendering time of the JSF page.

Of course, Seam is not yet a Java EE standard. Does that eliminates JSF's advantage of being a standard? Well, I think the answer is no. But that is for another post tomorrow.

Photos from our last trip to Colorado. Enjoy! (Click on the image below to go to the album)

Third approach: use the Seam Remoting JavaScript library to access backend Seam components directly when a page event happens.

[plug]
This is part of my blog series on Ajax with Seam+JSF+Facelets. Sample code and detailed explanations are also covered in my book on Seam.
[/plug]

Advantage: You can access the backend components via JSF EL in the JavaScript calls. This approach works with any third party JavaScript library, and gives us the most flexibility. Plus, the Seam remoting library itself automatically handles the XML call and asynchronous callback.

Disadvantage: Some JavaScript coding is needed.

The following example shows how to use Seam remoting to implement the username check (check if the input username already exists in the database). The JavaScript obtains a stub reference to the manager component from the backend Seam context. The checkName() JavaScript method invokes the manager.checkName() backing bean method via AJAX to check whether the username is already in the database when the input field loses focus. When the backing bean method finishes, it makes a callback to the JavaScript method checkNameCallback(), which decides what message to render.

The JSF component here is just a regular component with an ID that can be referenced from JavaScript methods, and UI event handler (e.g., onblur) associated with the above JavaScript methods.

In order to access the backing bean method via Seam remoting, we have to tag it with the @WebRemote annotation in the EJB3 session bean interface.

Of course, the example here is very simple and it can be easily accomplished by the Ajax4jsf approach as we have seen. But the real power of Seam remoting is that it exposes an API to JavaScript and hence allows us to work with any JavaScript library, such as Dojo and Rico, to integrate UI with server side components.

This concludes our blog series on Ajax and Seam+JSF+Facelets.

Second approach: use a generic AJAX component library for JSF. The library we talk about here is the open source Ajax4jsf library.

[plug]
This is part of my blog series on Ajax with Seam+JSF+Facelets. Sample code and detailed explanations are also covered in my book on Seam.
[/plug]

Advantage: The benefit is that it allows us to add AJAX functionality to any existing JSF component. Again, it does not require any JavaScript or AJAX servlet code. Since all the Ajax requests happen within the JSF component lifecycle, the backend value binding just works without any additional code.

Disadvantage: It cannot render visual effects beyond re-rendering certain JSF components. It would be hard to implement the auto-completion text popup box using this approach. In addition, it bandwidth intensive to wrap JSF requests in AJAX calls, especially if you use client side state saving.

In the following example, we show how to use AJAX to check whether a user input username already exists in the database. The a4j:support tags adds AJAX support to the existing h:inputText component. Every time the user blurs (de-focuses) the input field, the Ajax4jsf framework submits the value of the input field into the backing bean property via an AJAX call. Once the AJAX call returns, the framework re-renders the "usernameCheck" component.

When the #{manager.tryUsername} backing bean property is set, the backing bean checks the database for existing usernames. Depending on the name availability, the bean sets the usernameCheck property to be re-rendered on the web page.

Ajax4jsf is a very cool library. It works out of the box with Seam and Facelets. Learn to use it!

Courtesy of Todd Smart, here is an Ajax4jsf port of the Seam Hotel Booking demo application. We will have an official Ajax4jsf example for the Seam Hotel Booking demo in the next Seam release!

First approach: reuse AJAX-enabled JSF UI components

[plug]
This is part of my blog series on Ajax with Seam+JSF+Facelets. Sample code and detailed explanations are also covered in my book on Seam.
[/plug]

Advantage: The benefits of this approach are simplicity and power: you do not need to write a single line of JavaScript or AJAX servlet code. Yet, the component itself knows how to render just about any JavaScript and AJAX visual effects -- the JavaScript and backend communication mechanism is encapsulated in the component itself. AJAX services are implemented in Seam backend components bound to the UI component. Due to the high level of encapsulation, you can buy or download such components from market place and just drop them into your application to have Ajax within minutes.

Disadvantage: There is a steep learning curve for implementing your own JSF components. So, you are probably limited to what component vendors sell on the market place. Also, the component license fee can be pretty expensive.

To show how this approach works, let's look at some sample code. The following is an example JSF UI component for an auto-completion text box. With each keystroke, the web page sends the partial input text to the backing bean method #{manager.suggestName} via AJAX, which returns a list of autocompletion suggestions to be rendered on the page. All the JavaScript and communication code are encapsulated in the JSF component.

The backing bean method for AJAX service is as follows.

It is important to point out that when using those component libraries in Seam, you will need to re-package the *.tld files in a seperate JAR in your WAR file's WEB-INF/lib directory, and then place the main component library JAR file in the EAR application's class path (get the book for more on this! :)).

There are several component vendors selling a variety of Ajax-enabled JSF components. Exadel and IceSoft are two well-known commercial vendors. The Sun Blueprints provides some good open source component examples. Interested readers should check out this TSS article and the JSf Matrix site for a comparison of AJAX JSF components libraries.

Still implementing Ajax using brute force JavaScript and XML? That is sooooo 2005! To make Ajax really useful in enterprise applications, we have to integrate it with state-of-the-art server-side web frameworks. In this 4-part blog series, I will attempt to give you a short tutorial on 3 ways to add Ajax functionalities into your Seam + JSF + Facelets applications. They range from very easy (zero JavaScript or XML code) to very powerful (works with any JavaScript Ajax library). So, stay tuned. All the approaches with full sample applications are also covered in my book on Seam. In this first part, I will explain why it is a challenge to integrate Ajax into server side Java application.

So, what is the issue to use AJAX with JSF and Seam web applications? After all, JSF and Seam, especially with Facelets, allow you to use arbitrary HTML tags and JavaScripts on the web page. You can certainly use any JavaScript library to build whatever web UI you want. Well, the real challenge is how to integrate those JavaScript-rendered UI with backend business components. For instance, you might be able to use off-the-shelf JavaScript library to render a rich text editor on the web page, but how do you bind the user input text in the editor box to a backend component (e.g., a string property on a Seam EJB3 entity bean)? The JavaScript rendered dynamic UI is not a JSF component and it does not interpret the JSF EL (i.e, the #{obj.property} notation) for backing bean references.

A naive approach is to write a special HTTP servlet to handle AJAX requests from the JavaScripts. The servlet can then interact with objects in the FacesContext or HttpSession to save the user input or generate AJAX response to the JavaScript. However, the problem with this approach is that it includes a lot of manual coding on both the client-side JavaScript and the server-side Java Servlet. The AJAX servlet developer must be very careful with the states of the server-side objects. It is obviously not the ideal solution. Is there an easier, simpler way to support AJAX in JSF and Seam applications?

Fortunately, as a cutting edge web framework, JSF and Seam provide several elegant ways to integrate AJAX support in your web applications. In the next 3 blog posts, I will cover the following three approaches.

1. Use Ajax-enabled JSF components

3. Use specialized JavaScript for backend access (Seam remoting)

Diego Parrilla recently wrote in his blog: "Yes, we still need Transfer Objects with EJB3 JPA". I think he raised a lot of interesting and valid pionts on the issues we face using EJB3 entity bean POJOs in the web tier. However, I think the answer is also simple: Use a web framework that is designed for the ORM backend! I understand that it is not entirely feasible since many developers have no control over what web framework they choose. But if you do, using a stateful framework like JBoss Seam would completely eliminate the need of DTOs and save you A LOT of trouble.

One of the biggest complaints Diego had was that the web tier cannot lazy load associated objects once the transaction is finished in the business tier. And that forces him to eager load everything and causes a lot of management / performance problems. In fact, this is also one of the most common complaints we heard from Spring / Hibernate users. The problem is that business tier is "stateless" and it closes the database transaction after it passes the object off to the web tier -- hence preventing lazy loading in the web tier.

The extended persistence context in EJB3 is designed to solve this problem (yes, the "experts" did think of this :)). With the extended persistence context, the ORM POJO's lifecycle is extended beyond the business layer transaction. So, you can lazy load anything as long as you do not destroy the context. But it is only useful when used in a EJB3 stateful session bean, which holds the context. JBoss Seam supports EJB3 stateful session bean as one of its basic constructs, and therefore supports lazy loading in web tier out-of-the-box.

Wow, American scientists have a clean sweep on this year's Nobel science prizes. This year's medicine / physics / chemistry Laureates are all scientists working in American research universities. Of course, it is not news that American universities dominate the world when it comes to scientific research. But what's intriguing is that those Nobel Laureates are also graduates from the supposely "failing" American high schools.

As anyone who has attended graduate school in a major American university knows, the research and teaching staff in those universities are disproportionally immigrants (w.r.t to the immigrants population in the US population). In fact, quite a few past American Nobel Laureates are first-generation immigrants coming here on F-1 / H-1 visas. Many people say that illustrates US high schools' inability to produce top quality students for world-class research programs. But what do this year's Nobel awards tell us? Well, I think it tells us that science education in US high schools is both successful and failing -- on different fronts. US high schools are successful in turning out star scientists but fail to educate the mass about science ...

Research has suggested (sorry forgot the link) that American high school kids score lower in tests compared with, say Japanese and Chinese kids, primarily because they spend less time on "studying". Instead they spend more time developing their personal interests (or, just partying :)). Few students in other parts of the world have this luxury -- they are buried in homeworks and academic assignments designed to improve test scores but not to promote personal interests. As we see from this year's Nobel Laureates, once an American student figures out that science is his / her passion, he / she has no problem reaching the top.

In fact, I think that abundance of foreign talents in US universities and tech industry simply means that America is very good at attracting and retaining top talent from all over the world. That is a very good thing for America. (Note to immigration / H-1 opponents: immigrants created much more jobs than they "took away". Think about how many jobs Sergey Brin and Linus Torvalds created?)

Having said that, I still think there are big problems with American high schools. While the high schools can produce seeds for top scientists, they lack the capability to mass-produce workers with basic math / science skills, which is really what the economy needs. I do not think the problem here is the lack of testing or academic assigments. Rather, it is the lack of the "culture" to respect and promote science in schools. The challenge is how do we make science "cool" and how to get kids interested in it before it is too late (that is, after the kid graduates and found himself / herself unable to find a job due to the lack of science / math skills).

Ajax4jsf 1.0.2 now works out-of-the-box with JBoss Seam and Facelets running inside JBoss AS (Ajax4jsf + Seam + plain JSP still has some issues though!). There is no more shared JAR files or ugly hacks. You just need to package the Ajax4jsf library JARs in the same JAR as your EJB3 beans:

myapp.ear
| + myapp.war
| + myapp.jar
     | + ajax4jsf.jar
     | + oscache-xxx.jar
     | + mybean.class

Congratulations to the Ajax4jsf team! So, why do we no long need the separate *-war.jar files in myapp.war? As it turns out, more recent JSF implementations (i.e., JBoss AS 4.0.4 and above) search files by

So, it sees all configuration files in classpath including those in myapp.jar.

I finally put up a web page for the "JBoss Seam: Simplicity and Power Beyond Java EE 5.0" book. The page has the source code download link for the example applications in the book. Have fun!

Please use this thread to report problems / bugs with the code. Thanks. We can still make changes to the book!