Michael Yuan

Today’s big news is Google’s announcement for Java support on the App Engine. At Ringful, our hardware strategy is two words: cloud computing. We have multiple apps on both Amazon EC3/S3 and GAE.

EC2 is obviously more flexible since it provides a virtualized Linux environment, where you can do anything you want. GAE, on the other hand, feels much more restrictive since it is basically an app server in a scalable infrastructure. For instance, up until today, Python on Django is the only application model supported on GAE. However, as we use both services, I have grown to like GAE a lot more than EC2:

• GAE provides automatic scaling that would just add in more resources based on the real time load of your app; EC2 requires you to actually monitor the load and bring up additional servers yourself.
• GAE’s restrictive programming model also forces you to write apps that are horizontally scalable; With EC2, you could well write apps that cannot scale at all no matter how many server instances you start. In another word, with EC2, there could be well a false sense of scalability — until you really hit a traffic spike …
• GAE is truly usage based — it only charges for CPU cycles that are actually used, as opposed to EC2 which charges CPU time as long as your virtual machine is up, even if it is idle. That makes GAE potentially a lot more cost effective for small apps.

So, in short, I am very excited that Java finally comes to GAE. I immediately applied for Java support in GAE accounts and wrote a couple of small apps to try it out. Overall, it feels great. I am definitely porting my Python apps to GAE Java as soon as I get around to do it. Here is a short summary of my first impression.

The good

* It is based on the standard JDK — not the mutilated Android Java stuff as once rumored.

* Standard servlet + JSP + JSTL stack for web apps. The same kind of setup Tomcat ships out of the box, and should be sufficient for a lot of apps.

* GWT integration if you want an advenced web framework to use with your app.

* JPA support for data persistence in Google’s BigTable.

* Standard WAR deployment. That allows developers to use any tool of their choice — ANT, Maven, Eclipse, NetBeans — as long as it can build standard WAR files.

* Most JVM languages, such as JRuby, Jython, Groovy, and Scala, are already working since the runtime is standard JDK-based.

* A lot of frameworks are already working — or can be made to work with some tweak.

* Cron and scheduler support out of the box. It is a lot better than EJB Timer.

* Direct integration with Google’s data APIs for user authentication, email sending, image manipulation and much more!

The bad

* Most of the Java EE stuff is not supported. Noticeably missing are RMI, JDNI, and JDBC. That means commonly used frameworks such as session beans and Hibernate are not supported. I have heard that JSF 1.2 does not work out of box. I do not expect Seam to work out of the box either. Bummer.

* The persistence store is not a SQL database. I understand that a non-relational data store is needed to support the kind of scalability Google needs. But, BigTable does not even provide full text search! This is Google we are talking about! The lack of SQL supports means that you probably need to re-write significant amount of code if you are porting an app to/from GAE.

* The lack of access to file system would break a lot frameworks that uses XML configuration files — think Struts! But I expect this can be fixed with tweaks in the frameworks.

* The lack of the ability to create and manage threads is probably not a big deal, since technically you should not create threads yourself in a Java EE container anyway. But still, it would be nice to create threads that processes data in the background.

* The HTTP session support in the Java runtime uses BigTable to store session data as opposed to in-memory cache. There got to be a performance for this … But I guess they have to do it this way. In a truly load balanced environment, replicating in-memory sessions is a very complicated task.

* What is the deal with JDO? They really should focus the effort on getting better JPA support.

* No JMS support is a bummer.

The ugly

There is really none I can think of! Despite my numerous mis-givings, Google did a great job bringing Java into a scalable infrastructure and provide very low hosting options for the masses. I look forward to developing more apps on this platform!

Jacob and I are promoting our “Seam Framework” book at JavaRanch this week. Stop by and ask a question in the JBoss Forum to win a free copy of the book. See you there!

I just received a hard copy of my book “Seam Framework” from my publisher today. That means you should be able to get it from Amazon and Barnes and Noble very soon.

The book is the “second edition” of the original JBoss Seam book I wrote back in 2006, which was a JavaOne and Amazon best seller. But, it is much more than a “sequel” of the original book, my co-author Jacob Orshalick has made many major contributions to the book to address the latest and greatest features in Seam and WebBeans. Check it out!

The picture shows both the original “JBoss Seam” book and the “Seam Framework” book side by side — the photo on the cover of the original book was taken by Ju during our trip to the Death Valley in 2005.

In a related story, my friend Norman Richards (also a core developer on the Seam team) spotted the Chinese translation of the original Seam book while he was in vacation in China last month. Now, anyone in China wants to buy one and send to me?

If you are among the 6000+ technologists / entrepreneurs / designers attending this year’s SXSW conference (or are just interested in following what’s going on in the conference), check this out: The SXSW 2008 Mobile Companion (http://webclip2go.com/sxsw08) is a free mobile web application that lets you access everything about the South by Southwest conference right there on your mobile phone. Try it in a web-based iphone simulator (Safari and Firefox only). It works on iphone, Blackberry, Palm, Windows Mobile, Nokia, and just about any smartphone out there. The way it works is that it takes live content about the conferences from all over the web, and make the content suitable for display on small mobile phone browsers. Through the companion, you can check:

* Panel / presentation schedules by day
* Session abstracts
* Film / music performance schedules by day
* Official and unofficial conference news, blogs and wikis
* Blogs of conference speakers (full posts w/ comments)
* SXSW parties!
* Austin local news
* Music and film listings by venue in the Austin area
* and much more …

All you need is to load the following URL in your mobile phone browser. Or, if you do not want to type the URL, simply text the word sxsw08 to phone number 41411 to get a link returned in an SMS message (the SMS works in the US only!).

http://webclip2go.com/sxsw08 (Try web-based iphone simulator in your Safari or Firefox browser)

Why did I create it? Well, as a veteran technology conference speaker / attendee, I can tell you that conference WIFI is flaky at best in most big conferences. In fact, WIFI was the #1 problem in SXSW 2007. It is quite frustrating to take out your 8 lbs laptop just to find out that the WIFI is down or has no coverage in the Hall. Well, with the mobile companion, you can check out just about anything about the conference / speakers in real time on your phone. I personally would use it a lot. And I encourage you to try it out if you have an iphone / blackberry or other connected device. I plan to do the same for most other conferences I attend this year as well.

The technology behind the SXSW Mobile Companion is WebClip2Go. The goal was to let people clip live content from any existing web site / blog, so that those content can be viewed from mobile phones. It has become a hit among my friends — especially those with iphones, since the web content loads much faster and requires simpler navigation in WebClip2Go, compared with directly loading the original web site in iphone. Much still needs to be done to make WebClip2Go ready for the general Internet audience (e.g., we need a Firefox plugin that lets people “clip” web content via drag and drop). In any case, I will blog about WebClip2Go in a separate blog entry later this week. Stay tuned!

BTW, for my Seam readers, it might be comforting to know that the application is built on top of JBoss Seam technology.

One of the most interesting concepts in Seam is “conversation” — it allows your web application to have separate internal states for each browser tab, or for each logical multi-page web operation. Conversations can even be nested to manage multi-level wizards. Conversations let you break away from the monolithic session-based web application state management. However, while the concept is easy to grasp, conversations are not as widely understood as sessions. Many web developers are intimidated by the powerful conversation management APIs in Seam.

Well, no more! Jacob Orshalick just released three draft chapters from our 2nd edition of the JBoss Seam book. Those chapters provide very good explanations on conversations should be used in Seam applications. Thanks Jacob! Go check them out!

Cool! Out of 4 sessions I submitted to JavaOne 2008, 2.5 are accepted! Given that JavaOne accepts less than 5% of all session proposals, this sounds like pretty good success rate. So, what exactly will I talk about in JavaOne?

First off, I will be giving a technical session on Building Interactive Mobile Messaging Applications. I will discuss how to build a SMS service like the Google SMS on a Java EE server. I think the information presented in the session will be useful for a large number of developers — for instance, for web application developers, it is often nice to have a “send to phone” button on your pages to send small pieces of information (e.g., alerts / reminders / links) to the user’s mobile phone. In the session, you will also learn how to make your application respond to requests from SMS (e.g., the user sends in a SMS to reschedule an appointment etc.). The session covers technologies used in such a solution, common design patterns / pitfalls, and third party players involved.

I will also run a BoF session on JBoss Seam: The Deep Integration Framework for Web Applications. I will try to dispel the notion that Seam is somehow a mere “web framework”. Yes, Seam is used in many web applications, but you can just use PHP or Ruby for a simple web site. The real value of Seam is to bring real Java enterprise infrastructure (e.g., business process engine, rules engine, asynchronous messaging infrastructure, advanced transaction services, scheduling service etc.) to the web application. That saves you from hard coding business workflow or rolling your own middleware frameworks in the web application. Come to the session and join the discussion!

Finally, they accepted my proposal on Developing Compelling Mobile Web Applications as a backup session — that is the 0.5 session here. This session covers mobile browser detection, multi-template based web site design, and special UI tricks for the iphone. From what I was told, there is a pretty good chance for backup sessions to be presented in the conference since some session presenters drop out at last minute for various reasons. We will see.

Hope to see y’all in JavaOne again this year!

As a service to my readers, I have updated all examples in my JBoss Seam book to Seam 2.0.0.GA.

Go download the zip file here

The example applications are fully tested against JBoss AS 4.2.0 GA.

NOTE: To build the examples, you now need to download and unzip Seam 2.0.0.GA first, and then set the build.properties file to point to the Seam installation directory.

UPDATE: Several people commented that Seam works just fine with the TopLink JPA provider. I stand corrected. Thanks guys.

Here is what I posted to TSS today …

First, we try very hard to make Seam as generic as possible — so it would not require JBoss AS to run. The proof of this effort is that Seam runs on plain Tomcat (using RESOURCE_LOCAL transactions). So, in theory, it should run on all application servers out there. However, since all Seam developers use JBoss AS on a daily basis (we happen to believe that JBoss AS is the best AS out there :)), it is natural that Seam is tested most extensively on JBoss AS. Also, as an open source project, we do not have access to commercial WLS, WAS, ORA licenses, and do not have access to their support. So, our testing on those servers is not very comprehensive. I have personally installed the trial versions of those servers multiple times since they expire all the time. It is extremely time consuming …

So, the testing on commercial app servers is not very good at this moment. If you encounter issues with non-JBoss servers, raising them on the Seam forum is your best bet. Now here is a breakdown of what works and what not (to the best of my knowledge).

* Tomcat 5.5 and 6: Seam applications work out of the box on those servers if you use the RESOURCE_LOCAL transaction (see examples/jpa). You can use EJB3 features if you install JBoss Embeddable on top of Tomcat.

* Glassfish: Glassfish v2 is known to work with Seam (see examples/jee5 for an example). But we strongly recommend you use Hibernate as the JPA provider — not the default TopLink.

* Oracle: Oracle 10 is known to work with Seam (see examples/jee5 and examples/jpa). Again, choose Hibernate as the JPA provider.

* WebLogic: WebLogic 9.2 and 10 can be made to work with JPA + JTA transaction (see examples/jpa). However, EJB3 on WLS 10 does not yet work. There is a reflection error from the EJB proxy the last time I checked.

* WebSphere: I think the examples/jpa can work against WAS 6.1.0.9. You do need to tweak stuff a lot to make JSF 1.2 and Facelets work on that server. We have not tried WebSphere EJB3. However, anything beyond a simple CRUD app might have problems on WAS. One of the reasons is that the IBM JVM5 has a bug that complains about unknown annotations (the correct way is to ignore unknown annotations as the Sun JVM does). Unless IBM fixes this, you will have problems running Seam on WAS.

So, that’s it. If any of you can help us testing this stuff, please let us know!

I gave a 2-hour talk on JBoss Seam in the New England Java User’s Group last Thursday. Although the talk was at the same night as a crucial game for Red Sox, it still managed to attract 250+ people — making it one of largest JUG meetings I have ever attended! I had a great time there, and learned first hand about how Java developers in the Boston area are using JBoss Seam to solve real world problems. For those who are interested, the presentation itself can be found here:

Slides for the JBoss Seam presentation in NEJUG, Oct 18th 2007

I enjoyed a “re-union” with my Red Hat colleagues in the Boston area: Shelly McGowan, Chantal Yang, Bill Burke, Kurt Stam, and Rajesh Rajasekaran. Thank you guys for making the meeting a success! In addition, I’d also like to thank Mark Johnson (the president of the NEJUG), Heather Fox (publicist at Prentice Hall), and Shaun Connolly (my sponsor at Red Hat) for organizing everything!

Finally, a couple of references to things I mentioned in the meeting:

• My Seam book
• Seam web site (download, docs, forums etc.)
• The Red Hat Developer Studio is the premier Eclipse-based IDE tool for Seam development. Its free / open source cousin is the JBoss Tools project.
• There will be a lot Seam coverage in the upcoming JBoss World conference. Register early!

In a previous post, I discussed how to setup a Maven project for your Seam WAR application. However, most Seam developers are probably working on applications with EJB3 components to fully take advantage of the service infrastructure of the JBoss AS container. So, to complete this series, I setup a maven project for Seam EAR deployment. The project structure is as follows. The ejb module builds the JAR for EJB3 components; the war project build the web application; and the ear module builds the EAR application with necessary library JARs.

The main pom.xml file defines the shared libraries required by all modules. It optionally uses the Seam parent POM to set the version numbers for the dependency JARs. Here is how it might look like:

The ejb/pom.xml file defines the dependencies for the EJB3 module. Everything here is in the provided scope -- unless testing-specific libraries, which are in the test scope.

The war/pom.xml file defines the dependencies for the WAR module. It depends on the ejb module.

The ear/pom.xml file defines how the EAR application is assembled. You need to declare any JARs you want to include in the EAR as dependencies. I also used a JBoss-specific element to setup the class loader repository for the application. It is often needed in JPA applications. Yes, it is verbose -- if you have a better idea, let me know.

Pete Muir recently posted that Seam 2.0 will support Maven integration. It is perfect timing for me since I have just started to use Maven in my new projects. So, I went through the exercise to setup simple Seam web projects in Maven. It is really quite easy. The project builds a single WAR for deployment (you can only use Seam POJO in the WAR -- no EJBs). You can configure it to generate WAR for JBoss AS or Tomcat 6. The beauty of using Maven is that you do not need to worry about things like finding the right version of JARs, setting up the project structure, managing build script etc. In fact, there is no build script to write. So, here is the structure of the source project.

As you can see, you put your application code and configuration in the following directories.

• All the Java source code (e.g., entity beans, Seam POJOs) go into src/main/java.
• All Seam and web-related configuration files go into src/main/webapp/WEB-INF.
• The JPA configuration goes into resources/META-INF/persistence.xml.
• All web content goes into src/main/webapp.
• The resources/seam.properties file is an empty file. It is require for Seam to scan annotations in this WAR

The dependency JARs are declared in the pom.xml file. Below is the pom.xml I used to generate a WAR for JBoss AS deployment. A couple of things to notice here:

• I set the Seam official POM as my "parent" so that I can let Seam figure out the correct versions of the dependency JARs. Notice that I do not need to specify the Facelets JAR version in my POM. Seam will choose a compatible version for me.
• The compiler setting must be "1.5" so that it can handle annotations.
• The javax.el.el-api jar needs to be in the provided scope as it conflicts with the one already in JBoss and Tomcat 6.

That's it. Here is the pom.xml.

Now, what if I want the WAR to be deployed in plain Tomcat 6? No problem, just add the JSF and Hibernate dependencies as follows. There is no need to meddle with commons jars and other 3rd party JARs since JSF and Hibernate dependencies automatically resolve them! Of course, plain Tomcat 6 does not provide a JTA transaction manager, so you will need to provide your own or use RESOURCE_LOCAL transaction -- but you should already knew that if you choose Tomcat ...

So, go and have fun with Maven now! Let me know if there is any issues!

I am in Atlanta for our internal JBoss ESB / SOA training this week. Burr Sutter and his team are doing a great job conveying our SOA vision -- to mesh and reuse services you already built in your "single silo" applications (e.g., a web store and a warehouse management app can share an "order" object when the user confirms an order. Each application then process and save the order in their own ways.).

I have been thinking how Seam fits into this picture. With the support for web services in Seam 2.0, it is actually quite easy to fit a Seam application into a SOA environment. In this post, I'd like to discuss some work I did with the seambay example (a spoof auction site) to make it share its listings with other services, and receive listings from other services.

@Out

To make the seambay application share its auction listings with other services in the SOA environment, we need to serialize the Auction object and push it to the ESB, while it is being saved into the database by the Seam application. The least intrusive way to do this is to use an EJB3 interceptor to "steal" the Auction object when the confirm() method is called. This way, we do not need to make any change to the Seam application code.

When the user enters a new auction listing on the site, the server console prints the following message.

@In

To make the Seam application as a SOA service end-point requires external applications to invoke its business logic through web services. The challenge here is that most business logic in Seam are managed in "conversations", which holds finer grained application state than Http sessions. How do you keep the conversation state across multiple SOAP calls? Well, here is where the Seam Web Service comes into play.

To expose business logic methods in Seam components as Web Service methods, you need to write a facade SLSB to wrap around the methods you want to expose. You can use the Seam.getComponent() method to get any Seam component by its name and then proceed to invoke any method on the component.

Notice that the createAuction(), setAuctionDuration(), setAuctionPrice() and confirmAuction() methods all need to happen in the same conversation so that they can access the same "auctionAction" component. But we do not explicitly pass the conversation id to the web service calls. Instead, when the createAuction() method returns, it inserts a conversation id in the SOAP header, and expect the client to use the same conversation id in the header until the caller reaches confirmAuction(), which ends the conversation. The SOAP request inside a conversation looks like the following:

As a proof of concept to demonstrate that Seam web service is well supported by existing SOAP tools, I build a SoapUI script to demonstrate how to add an auction to the Seam app via web services. Notice the "transfer" elements in the script. They are used to maintain the conversation id header across SOAP requests in a conversation.

Finally, I'd like to make the SOA version of the seambay example available for download. You can find the ready built EAR file in the dist directory, as well as the SoapUI script in the root directory.

TheServerSide is running my article this week:

I like the artwork visualizing "Seam" in an origami bird. Elegant, balanced, and lightweight. Perfect for Seam. The article is based on presentations I recently did on Seam. It targets experienced Java EE developers (i.e., the JUG, NFJS crowd), and goes into depth on some of ideas behind Seam (instead of just a CRUD demo). I hope you enjoy it and let me know your comments. Thanks. Here are some slides from my presentations that are relevant to the article.

Darryl Smith pointed out that we can actually use non-JTA transactions with JPA in Tomcat now. So, I just added tomcat 5.5 and 6.0 build targets for the jpa example in CVS based on his suggestions.

In JBoss Seam 2.0, we made some changes to the way Tomcat is supported as a Seam runtime. It has caused some confusion. So, let me try to clarify here ...

As you recall, in Seam 1.0 to 1.2, we can run Seam applications on Tomcat by bundling the JBoss Embeddable EJB3 library or the JBoss micro-container inside the WAR application. The application will need to bootstrap the EJB3 container or micro-container upon startup. However, the EJB3 library Jars is more than 20 MB. The idea of bootstraping the entire thing for each application is not very efficient. In Seam 2, we leverage the "Embeddable JBoss" library to provide shared EJB3 service to all WAR applications deployed in the Tomcat instance. You have two ways to run Seam 2 applications in Tomcat:

1. If you need to use EJB3 beans, you will need to install the "Embeddable JBoss" libraries as shared library in Tomcat. It is an easy process. You can find instructions for Tomcat 5.5 and 6.0 respectively. Once you do that, you can deploy Seam applications without any restrictions. You will be able to use full EJB3 features including session beans, entity beans, message driven beans, and web services etc.

Of course, you still cannot deploy EAR files on Tomcat. But you can bundle EJB3 JARs in the WEB-INF/lib directory of your WAR application -- essentially re-creating the EAR structure in a WAR. Just run the tomcat.war ANT target on any of the official Seam examples to see how this is done.

2. If you absolutely cannot install any shared library or shared configuration on Tomcat, you can still run Seam applications. However, you will not be able to use EJB3 features -- you must use Seam POJOs instead. You can, however, use JPA in local transaction mode. Seam manages the transaction manager and entity manager for you in this case.

Checkout the jpa and hibernate2 examples in Seam distribution and build for the tomcat55 or tomcat6 targets to see how this works. The jpa shows how to use JPA EntityManager with Seam POJOs and the hibernate2 example shows how to use Hibernate sessions with Seam POJOs. You will need to copy hsqldb.jar into Tomcat's shared lib directory since the example app assumed that we will use a HSQL DB from JNDI (see META-INF/context.xml). Obviously, you do not have to do that in your own apps.

Okay, so much for Tomcat support. What about Seam 2 support for J2EE 1.4 application servers and non-JBoss Java EE 5 application servers? Here are the status:

• J2EE 1.4 application servers: Try the jpa example in Seam distribution. It uses Seam POJOs to replace EJB3 session beans in other examples. The jpa example builds for JBoss 4.0.5/4.2.x, WebSphere 6.1.0.9, and WebLogic 9.2.
• Java EE 5 application servers: Try the jee5 example in Seam distribution. It builds for JBoss AS 5.x, Glassfish V1/V2, and Oracle OC4J 11. We are currently working on WebLogic 10, which has some weird reflection issues.

Hope that helps!

Kito Mann of JSFCentral just posted the PDF slides for our JavaOne talk on Seam and JSF. The slides cover what is hot about JSF and what is not, and more importantly, how Seam enhances and improves JSF in 14 important ways. Just to wet your appetite, here are the 14 key points elaborated in the slides:

1. Reduces Boilerplate code
2. Dependency bijection
3. No XML hell
4. Integrated ORM support (a.k.a, use Hibernate as Gavin intended! ;))
5. RESTful URLs and page actions (for GET requests)
6. Extensive and expanded use of JSF Expression Language (EL)
7. Fine-grained stateful conversations (web transaction, multi-tab support etc.)
8. Direct JavaScript integration for Ajax (use Dojo with your JSF apps)
9. Elegant input validation
10. Graceful exception handling
11. Easy-to-use and rule-based security
12. Business process and rules integration
13. Very easy to test (both unit test and integration test)
14. Tools support (Seam Gen for RoR-like experience for CURD apps)

Go check it out!