GWT and AppFuse

Someone recently sent me the following e-mail asking about GWT integration in AppFuse.

I see from your blog that you're spending some time with GWT at the moment. What's your plan, are you going to integrate GWT as another UI Option for AppFuse?

The reason I'm asking is that I actually checked out all of the AppFuse code from the svn repository yesterday, with the intention of starting off adding some GWT stuff in there. My intention was to start by getting a basic Maven archetype together for GWT as an AppFuse UI.

However, if you're planning on doing this yourself in the near future, then there's no point in me starting doing it, I'd have to learn how to write archetype's for a start (not that it looks too difficult) but you'd obviously do it much quicker.

Being a good open-source developer, I moved the discussion to the developer mailing list and replied there:

It's likely I'll create a version of AppFuse Light with GWT, but I doubt I'll do it in the near future. I hope to release AppFuse 2.1 first (which will include "light" archetypes). I wouldn't get your hopes up in waiting for me to do the work. However, I'd be happy to assist you in doing it. AppFuse Light is now modular and uses the AppFuse backend.

http://raibledesigns.com/rd/entry/appfuse_light_converted_to_maven

Here's how I believe GWT should be integrated:

  1. Create an appfuse-ws archetype that serves up RESTful services (http://issues.appfuse.org/browse/APF-897).
  2. Create an appfuse-gwt archetype that consumes those services. This archetype would contain a proxy servlet that allows #1 to be on a separate host/port.

In addition to #1, I hope to convert the Struts 2 and Spring MVC archetypes to use those frameworks' REST support.

For #2, we could use SmartGWT or GXT. SmartGWT might be better since Sanjiv is a committer on this project. ;-)

I know I've been slacking on AppFuse development, but it is ski season and running to work seems to drain my late-night coding ambitions. With that being said, I'm committed to getting AppFuse 2.1 released by JavaOne (hopefully sooner). I figure it's a good week's worth of work and I'll probably have to do it late at night to find the time. That's OK though, I usually really start to enjoy it once I get into it.

Posted in Java at Mar 04 2009, 10:50:26 PM MST 5 Comments

Colorado Software Summit 2008 Wrapup

Snowman in Keystone Last week, I attended the Colorado Software Summit in Keystone and had a great time. Not only was the weather beautiful and the food delicious, the sessions I attended were awesome. If you ever get a chance to go to this conference, I highly recommend it. It's like being on vacation and learning with a bunch of old friends.

Yan Pujante also attended this conference and documents his experience, photography and presentations in Colorado Software Summit 2008.

Below is a list of my entries for all the sessions I attended.

For next year, I think the conference should shorten its sessions (from 90 to 60 minutes), invite more speakers and cut the price in half (to $999 per person). How do you think the Software Summit could be improved?

Posted in Java at Oct 28 2008, 11:03:23 PM MDT 2 Comments

RESTful Web Applications with Subbu Allamaraju

Subbu works at Yahoo! developing standards, patterns and practices for HTTP web languages. In the past, he was a web service and Java developer. He was also a standards contributor at BEA and an author of books on Java EE. His current passion is HTTP and REST. Subbu confesses that he's not a web developer, has no interest in the internals of programming models used for web frameworks and he's only interested in the visible aspects of the architecture.

"The Web is Mostly Restful"

Being RESTful in an abstract sense means:

  • Resources are named by URIs
  • Resources have representations (Atom, HTML, JSON, XML)
  • Resources contain contextual links to allow navigation of state
  • There's a Uniform Interface

In the web today, some resources and URIs are personalized, but most are not. Some depend on sessions, but most do not. The consequence of a personalized UI with a non-unique URI is you cannot rely on browser caching.

The web is full of different representations (HTML, XML, JS, PDF, CSS, Flash). The problem with HTML is you can't tell links that you want a particular representation based of a link. The links are hard-coded to be a particular content-type. However, some media types on responses are ignored. This is often a problem with browsers and whether the user has plugins installed.

The Uniform Interface for the web is HTML and primarily links and forms (GET and POST). There's still some misconceptions (e.g. POST is secure). However, it's not about security, it's about idempotency and safety. You need to make sure you only use POST when you're changing data. POSTs are not repeatable. GET URIs are not always refreshable, which is quite unfortunate. Users shouldn't have to fight the back button.

Caching is a fundamental aspect of the web. Even in a personalized site, most of the content can be cached. The web is read-only for the most part. However, many enterprise web applications don't take advantage of caching. This is fine when there's not that many users, but it's bad when you want to scale to thousands of users. There's several frameworks that use cache-busting and prefer backend caching over HTTP caching. These frameworks are not using the web like they should.

Backend caching (e.g. Memcached) uses a non-uniform interface and you need to explicitly program to it. Frontend/HTTP caching has a uniform interface that's pluggable. Backend caching is generally more expensive to develop and deploy. There are cases where data should be cached on the backend, but you shouldn't focus all on backend caching w/o doing some frontend caching.

With Ajax, you get more opportunities to be RESTful. XMLHttpRequest is another HTTP client that can be programmed to. It has full support for the uniform interface, which allows content negotiation, optimistic concurrency and caching. Cross-domain hacks can be done with <script> and <iframe> to tunnel requests over GET. The W3C has been working for the last two years on how to do cross-domain Ajax w/o using hacks. The problem with current cross-domain implementations is they often use GET for everything, which isn't very RESTful. Subbu recommends using a proxy on the same domain if you do need to talk to other domains. This will allow your Ajax code to remain RESTful.

Web Frameworks
Web development is hard because of all the moving pieces that exist. Because of this, many web frameworks have been created to solve the various problems. In 1997, there were servlets. They provided basic plumbing and closely reflected HTTP/1.1. Servlets provided a poor programming model, but it allowed a lot of frameworks to be built on top of it. We don't use servlets to write applications, only to write application frameworks. The second era came about in 2001 when Action-oriented frameworks became popular. In 2004, JSF and friends came to play. JSF is a component-based framework with known limitations (complex, slow, uses POST for almost everything, Ajax is difficult). These limitations have resulted in a number of third-party patches being developed to solve these issues.

JSF was designed to use the request to create a component tree that maintains state. Unfortunately, the state is not something the developer has control over. It's not the state of the application, it's the state of the components. The client's knowledge of the state is mentioned with a cookie and the server keeps the state in the session. The problem with JSF is you don't have a choice of state in your application - you can't write stateless applications like you can with servlets.

JSF uses overloaded URIs for its resources. When you have one URI with multiple representations, there's no way to tell how a representation was chosen. JSF's compromise is to allow client-side state saving. However, they do this by putting hidden field in the form and requiring POST for navigation.

JSF vs. REST
Basically, these two are at opposite extremes. JSF is focused heavily on a UI component model. The people that developed it misinterpreted how the web works and made some fundamental questionable choices. You can patch it, but you can not fix it.

Web 2.0 Frameworks
GWT is a cross-compilation based framework. You write Java to generate JavaScript (b/c everyone hates writing JavaScript). It mashes client and server code into a single source. These layers communicate using GWT-RPC. Typical RPC concerns do not apply since code generation handles coupling and the client is downloaded from the same application. GWT-PRC does POSTs to the server and uses HTTP like a transport layer. To be fair, GWT does allow you to use a RequestBuilder to use the web like it should be used. This class allows more control over HTTP requests, it supports GET and POST and it allows so-called RESTful layers (GWT-REST and GET-Restlet). GWT is focused heavily on ease-of-use, which is good. It's modeled after RPC and breaks the uniform interface and focuses on backend caching. Unlike JSF, GWT is fixable, but the community tends to use RPC instead of RequestBuilder.

SOFEA has a central promise of SOA. Business logic is a reusable service that changes less often. The presentation application calls those services and changes more often. The nice thing about this type of architecture is it allows a separation of concerns and loose coupling. However, it doesn't embrace REST like it should. Appcelerator is an implementation of SOFEA that has a Ruby on Rails-like usability. However, it uses a SOAP/HTTP style with messaging and POSTs to a single URI. Appcelerator is interesting, but it introduces a different style of coupling. It breaks URI opacity and client deals with POX instead of links.

Conclusion
Don't fight the architecture of the web. Innovate and enhance instead of breaking. If nothing else, break judiciously. As developers, we should demand more from our frameworks and make sure they use the web and HTTP like it should be used.

Posted in Java at Oct 24 2008, 09:52:02 AM MDT 16 Comments

What's Coming in Spring 3.0

This morning, I delivered my What's Coming in Spring 3.0 talk for the 2nd time at Colorado Software Summit. Since there is no Spring 3.0 source code to speak of, I was unable to do the "Choose Your Own Adventure" demo at the end. :(

The good news is I was able to easily upgrade the Spring Kickstart application from Spring 2.0 to Spring 2.5.5 (using annotations). When 3.0 is released, I hope to update this project to use 3.0 as well as show what I needed to change. If I get ambitious, I might even change the UI to use Flex or Ext JS to show a RESTful client. Below is my presentation - hope you enjoy.

Posted in Java at Oct 22 2008, 11:51:12 AM MDT 12 Comments

Presenting Web Frameworks of the Future Tomorrow in Denver

Tomorrow (Thursday) night, I'll be doing an encore presentation of my Web Frameworks of the Future at DeRailed. If you're in Denver and would like to hear me ramble while drinking a beer, join us at Forestroom 5 at 6:30.

After the last few days, I'm happy to report I should be in good enough condition to pull this off. If you're curious to learn more about my experience at OSCON and this presentation, please see my writeup on the LinkedIn Blog.

Posted in Open Source at Jul 30 2008, 09:56:17 PM MDT 2 Comments

[OSCON 2008] Web Frameworks of the Future: Flex, GWT, Grails and Rails

Below is the presentation I'm delivering at OSCON today. Unfortunately, I had to remove slides on GWT and Flex to fit w/in the 45 minute time limit. I hope to expand this presentation in the future, as well as continue to develop the side project I'm working on using these technologies.

Posted in Open Source at Jul 23 2008, 04:25:23 PM MDT 19 Comments

GWT and REST

I've posted two message to the GWT Google Group in the last couple of days. However, new member messages are moderated and neither has shown up yet. I'm reposting my questions here in hopes of getting some answers.

Is there a way to easily use a REST backend with GWT? I tried GWT-REST. It works, but it seems to be centered towards Rails (I'm using Grails) and it suffers from the SOP issue.

JSONRequest looks promising for cross-domain support, but I can't get it to work either. The provided examples work, but not my simple hello world that returns:

{"response":"Hello World!"}

Also, the example implementation only has GET support, not PUT, DELETE or POST. I can post my REST backend on the public internet if anyone is interested in seeing the issues I'm having.

Thanks in advance for any advice.

Posted in Java at Jul 21 2008, 10:31:58 AM MDT 14 Comments

Should we change AppFuse to be Struts 2-specific?

Dusty recently posted an interesting idea to the AppFuse developers mailing list:

After thinking/coding/reading for a while I think the more interesting task is: Retool AppFuse to be one or more Struts2 plugins based on various higher level app patterns. (AppFuse Facebook, AppFuse Employee DB, AppFuse Blog, AppFuse Basic LDAP, AppFuse Basic Crowd).

This all comes from the fact, that I have been wanting to refactor the AppFuse web layer for Struts. One of the interesting aspects of AppFuse is that it works pretty much the same across all its web frameworks. It does so with some lowest common denominator abstractions that can be ported and look and work the same across frameworks. I have picked my tool(s): Struts 2 and Ruby On Rails when I want to pretend I am young again. I know Spring MVC, JSF, etc. but I have no desire to build significant apps on those platforms. It's not because they suck and Struts2 rules, it is because I know Struts 2 the best, I am most efficient there and it provides everything I need to build great webapps (Let's not devolve to a framework debate). So, I would rather have a more Struts 2-specific web stack, that really leverages conventions born and raised there. The nice thing about the Struts 2 web stack is that it is complemented nicely by AppFuse's data/service layer, since unlike Grails or Rails, Struts 2 has no data or service layer. [Read More »]

Seems like a good idea to me. What do you think?

Someday I'd like to come up with a "compatibility test" that allows others to improve upon the ideas in AppFuse and develop their stacks independently. A suite of Selenium tests that require extensionless URLs might be a good start.

Posted in Java at May 29 2008, 08:29:44 AM MDT 11 Comments

REST and Seam Talks at Denver's JUG

After a long hiatus, I decided to attend the Denver JUG meeting this evening. Tonight there's a couple of interesting talks:

I'll do my best to live-blog these sessions, so hopefully you can read along and learn everything I do.

Give It a REST by Brian Sletten
This talk isn't an implementation talk, it's more of a motivational talk. Brian is trying to answer the question "Why do we care?". We care because we have a lot of WS-Dissatisfaction. "Conventional" Web Services are often:

  • too difficult for non-trivial tasks (real complexity)
  • too complex for trivial tasks (artificial complexity)

RPC-based Web Services are mythically interoperable and time/process coupled in painful ways. SOAP has largely become popular because of marketing dollars behind in. REST is more like the "hippy" way that has grass-roots support with no corporate sponsor.

What makes SOAP difficult? It's remote procedure calls and its tunneled using existing application protocols (HTTP). Furthermore, there are no nouns (mappings to business terms), only handlers. There are no semantics, only handlers. When you tie yourself to a contract/WSDL, you can have anything back that you want - so as long as its simple XML. This isn't entirely true because a lot of things can be shoved into XML (Word documents that are Base64 encoded).

The main problem with SOAP is it solves a problem that most people don't have. It solves an edge case, rather than the main problem.

Many people say "SOAP is secure and REST isn't".

Why do people believe this? It's because of the long list of SOAP-related security acronyms: XML Encryption, XML Signature, XKMS, SAML, XACML, WS-Security, WS-Trust, XrML. Even if you're using these in your system, there's no proof that your implementation is secure. REST is what we all use on the web with online shopping, etc. We don't seem to have a problem with the security we use everyday on the web, do we?

SAO is an architectural style promoting loose coupling among software participants. Sompanies have rigid definitions of what constitutes a SOA. Many believe that SOAP is an essential piece, but it's not. SOAP 1.2 and Doc Lit are improvements, but are they necessary? Interestingly, 85% of Amazon's users chose REST over SOAP when given the choice.

What is REST? The acronym stands for REpresentational State Transfer. It's an architectural style based on certain constraints designed to elicit properties of scalability and extensibility. It's an idealized notion of how the early web should work and helped drive the way it eventually did work. It's more than just URLs!

Resource-Oriented Computing focuses on information spaces, not code or objects. It focuses on logical connections and reduces complexity by separating actions from nouns. In the history of the web, we started with URLs that pointed to documents. Eventually, these documents became dynamic and were generated on-the-fly.

URLs are locations on the web that are horrible names because they change so much. URIs are good names that have no way of being resolved. Fundamentally, REST is a separation of the parts of the system: Nouns, Verbs and Representation. A Resource (in a REST architecture) can be a file, a service or a concept. It can also have different representations. Resources are named with Resource Identifiers. It's simply the means of naming a resource. It's a standard syntax that allows various schemes. Often known as URIs (or IRIs). It's orthogonal to satisfying the reference and it's one of the missing pieces of "normal" web services.

Examples of Representation include 1) a particular dereferencing of a Resource Identifier to a Resource at a particular time, 2) a byte-stream tagged with metadata or 3) it could change based on request or processing/display capabilities of the client (Firefox vs. WAP).

REST's verbs are design decisions to minimize the the complexity of implementing a system. GET retrieves a resource and always returns the exact same result. It doesn't change anything in the backend system. Because of this, it allows for easier layering of your system - particularly when you introduce caching for GETs. POST is used to create (or update) a Resource. It does not require a "known URI" and it supports the append operation. PUT creates (or updates) a Resource, but requires a "known URI" and also supports an overwrite operation. Lastly, there is DELETE, which removes a Resource. This is not supported in modern browsers. Just because browsers don't support them doesn't mean you can't implement them in your applications.

REST's concepts were developed by Roy Fielding in his thesis. He was trying to create a system that had the following architectural properties: performance, scalability, generality, simplicity and modifiability. REST allows us to create true client-server applications. To satisfy scalability requirements, REST is stateless. All parameters travel with the request and no session information is maintained on the server. This improves scalability through load-balancing and allows visibility of intermediary processors.

One of the first things that becomes a bottleneck in enterprise systems is the database. This works fine if you like paying Oracle. By using REST and HTTP concepts, it's easy to take advantage of a cache. This allows replication of an external data set where it's too large to copy locally. REST allows you to create Layered Systems that allow you to have managed dependencies between layers. Having a RESTful architecture allows you to swap out the backend without changing the front-end and vise-versa.

Now Brian is going to do some demos using NetKernel. He recommends using HTML documents to describe services. The beauty of developing a RESTful system is there's nothing preventing you from appending ?wsdl to your URLs to return SOAP.

Invoking functionality using web-friendly techniques is a very nice way to build web applications.

What is controversial in REST? When you are not dereferencing you should not look at the contents of the URI string to gain other information.. However, if you structure your URLs in your application in a hierarchical manner, people will be able to use URIs in this way.

What isn't controversial? No one believes you should rely on sessions or other state at the application level. They also believe using nouns, not verbs is an excellent idea.


Seam by Norman Richards
Seam isn't just a web framework, it's an integration technology for building applications for the web. It's a technology that takes your persistence and web technologies and unifies them so you have a simpler view of your system.

First of all, what is Seam?

  • It's a unified component and event model - you access all your components the same way
  • It has a declarative state with a rich context model
  • It provides deep integration with minimal glue code
  • It minimizes configuration, prefers annotations to XML
  • It allows a freedom of architectures and technologies
  • It also allows testing of components in context

With Seam, you have a number of technology choices to make. The first is which business component model you want to use (EJB 3 vs. POJO). You might choose EJB 3 if you want more clustering capabilities. For persistence, you can use Hibernate or any JPA implementation. Norman recommends using JPA if possible. You also have a choice of languages: Java or Groovy (and possibly Scala in the future). Seam gives you a choice of web frameworks. All the examples today will use JSF, but there's also support for GWT and 2.1 will have support for Wicket. Also, there's some non-committers developing support for Flex. Norman believes component-based web frameworks are the best way to develop web applications. While I hear this from a lot of folks component-based framework authors, it seems ironic that the "best" way to develop webapps is not the most popular way (PHP, Struts, Rails).

I think it's ironic that there's a REST (no state) and a Seam (it's all about state) talk in the same night. I'm tempted to ask why a stateful architecture is better than a REST one, but I'm not really that interested in the answer. I think your architecture should be determined by the needs of your application, rather than choosing the architecture and then implementing an application with it.

In addition to choices, Seam gives you a number of tools: CRUD generation, Eclipse and NetBeans support and full IDE support in JBoss Tools / JBoss Developer Studio.

Now Norman is doing a demo - starting by creating a new Seam Web Project in Eclipse. He mentions that he's skipped a number of steps: downloading and installing Seam, downloading and installing JBoss and configuring your Seam installation and database in Eclipse. He has two projects in Eclipse - apparently the New Project wizard creates two - one for the application and one for testing. It's strange that the tests don't go in the actual project. The directory structure has src/action and src/model for your Seam components. After doing some simple CRUD, Norman starts JBoss and looks at the master/detail screens it generates.

To make a Java class a Seam component, you usually only have to add a @Name annotation to the class. While trying to show us how the Authenticator/login works, Norman tried to open components.xml. Unfortunately, this crashed Eclipse and 30 seconds later - following a bevy of "file does not exist" errors, we're back in action. To inject dependencies in a Seam environment, you use the @In annotation. In the example class, here's what the code looks like:

try {
  currentUser = (Person) entityManager.createQuery("select p from Person p where" + 
       " p.email = #{identity.username} and p.password=#{identity.password}").getSingleResult();
} catch (NoSuchEntityException e) {
  currentUser = null;
}

This example appears to encourage title coupling with the data layer, rather than loose coupling (i.e. a DAO layer). I'm sure Seam doesn't prevent you from developing a more loosely coupled application.

Bug Alert: The <h:messages> tag looks like it always has an <li> - even when there's only one message. Struts 2 has the same issue with its <s:errors> tag. It's disappointing that so many Java framework developers don't have more attention to HTML details.

Probably the coolest part of Norman's demo is how Eclipse auto-synchronizes with JBoss so he never has to start/stop anything when he changes Facelets pages or Java classes. Of course, hot deploy should be possible with any web application if you're using Eclipse Web Tools effectively.

I do believe all-in-one starter frameworks like Seam, Rails, Grails and AppFuse are excellent. However, I also believe they're solving a problem that only 10% of companies have. Most companies don't have the ability to start applications from scratch - unless they're a startup. Most companies have an existing infrastructure in place for the backend and they simply need a better web framework to slap a pretty face on it. I don't know the best solution for this, but it seems like a logical choice to RESTify the backend (possibly with a web framework) and then use a modern web framework for the front-end. IMHO, the best web frameworks for a RESTified backend are Flex, GWT and Appcelerator. If nothing else, these appear to be the most hyped for 2008.

Many of the enhancements that Seam has added to the Java web programming model are being pushed back into the Web Beans JSR. With Seam, injection is bi-directional (input and output), is continuous during application invocation and dis-injected after action is done. The whole purpose of this is to let Seam handle the state of your application. By not worrying about storing/maintaining state, you as a developer can concentrate on business logic more and get your applications done faster.

At this point, Norman started talking about Seam's events and how you can use them. Unfortunately, my battery ran out and I drifted off to do some other stuff. I'm sure Seam's Event Model is pretty cool, I just missed it.

Posted in Java at Jan 09 2008, 08:59:45 PM MST 5 Comments

Go Light with Apache Struts 2 and REST by Don Brown

After attending Dan's talk on REST, I stayed in the same room and listened to Don Brown talk about Struts 2's support for building RESTful applications. Below are my notes from the event.

What is wrong with today's web applications? You're using a modern web framework and you've cleanly separated your presentation and business logic. The biggest problem in modern web applications is Confusing URLs.

A URL should be a resource indicator - not a method invocation. Often, web applications have little or no caching. People use GET to perform data manipulation and POST may or may not change state (especially with JSF). Another big issue with modern web frameworks is there's too many abstraction layers that hide HTTP headers and it's difficult to manipulate them.

Today's applications are "information silos". There's a lot of information in your applications, but it's all buried in HTML, JavaScript and CSS. There's no way to get this information out of your application unless you explicitly expose it.

The answer to many of these problem is REST. It's the Way of the Web. To solve the information silo problem, you can create a single interface that has multiple representation of the same resource. There's one URI for all types of resources - be it XML, JSON or HTML. How does this work w/o modifying the URL? You modify the URL's extension.

Struts 2 has a couple of plugins that make developing RESTful services easier. The first is the Codebehind plugin and the 2nd is the REST plugin. Don is doing a demo with the REST plugin and shows that there's no Struts configuration files needed (no struts.xml and no struts.properties). The only thing that's necessary is to specify an "actionPackages" init-param on the DispatcherFilter in web.xml. This activates the Codebehind plugin that uses conventions to determine the view template's path.

In Don's demo, he's creating an "OrdersController" that implements ModelDriven. After implementing a setId() method (to set the id from the request parameters), a getModel() method (to return the Order object) and implementing a show() method that returns HttpHeaders, Don starts up his server and shows that http://localhost:8080/order/5 returns an HTML page. Changing the URL to end in /5.json returns JSON, /5.xml returns XML.

public HttpHeaders create() {
    service.save(order);
    return new DefaultHttpHeaders("success").setLocationId(order.getId());
}

The Poster Plugin for Firefox is great when you're working with REST services. Don used this plugin to show us that it's possible to post to JSON and get back JSON results. His demo was impressive, especially the fact that there was no XML configuration required for Struts. I also like how the DefaultHttpHeaders class allows you to manipulate headers in a type-safe manner.

To use the REST plugin, you'll want to use Struts 2.1. If you're using Maven, all you need to depend on is struts-rest-plugin. The struts-codebehind-plugin (as well as struts-core) will be pulled in by transitive dependencies.

One disadvantage of REST vs. WS-* is you can't generate client code from a WSDL. You'll have to write your client by hand. However, one advantage of REST is there's already lots of clients - your browser, curl, etc.

The Struts REST Plugin hasn't been officially released, but hopefully will be in Struts 2.1.1. You can checkout the code from SVN using the URL below. The documentation is located here.

http://svn.apache.org/repos/asf/struts/struts2/trunk/plugins/rest

Great talk Don - and excellent work on the REST plugin for Struts. I can't wait to try it out.

Posted in Java at Nov 15 2007, 06:12:58 PM MST 18 Comments