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.
The Good:
This is the perfect book to learn the basics of Grails quickly. At 133 pages, I was able to read this entire book in one sitting. The first couple chapters are very introductory, but likely necessary for beginners. The good news is you start writing your first Grails application on page 7 (Chapter 3).
The Good:
This was an interesting book for me because it uses AppFuse for many of its Java-based examples. Unfortunately, it uses the Struts 1.x version which is cumbersome and verbose as far as Java web frameworks go. The most impressive part of this book is how Justin and Stu do an excellent job of walking the line and not insulting Java nor developers using it. They provide an easy to understand view of Rails from a Java Developer's perspective. There's detailed chapters on ActiveRecord (as it compares to Hibernate), ActiveController (compared to Struts) and ActiveView (compared to JSP). This book has excellent chapters on Testing, Automating the Development Process and Security.
The Good:
I really like the style of this book and that it shows you how to get things done quickly with code samples. It's very no-nonsense in the fact that it contains a lot of code and howtos. I really like Scott's writing style and found this book the easiest to read of the three. This may have something to do with my eagerness to learn Groovy more than anything. The most refreshing part about this book is how up-to-date it is. Because it's a Beta, it seems to contain the most up-to-date information on Groovy and Grails. After reading Getting Started with Grails and working with it for a couple weeks, the first Grails chapter seemed a little basic - but that's likely because I've figured out how to mix all those recipes already. The Grails and Web Services chapter definitely has some interesting content, but I've rarely had a need to implement these recipes in a real-world environment. I'd rather see recipes on testing the UI (with the WebTest plugin) and how to use GWT and Flex with Grails. If SOUIs are the way of the feature, this is a must.
. Below is an example Hello World application.
