I have been using the Dojo Store, Dojo Grid> and Dojox Wires a lot recently to build RIA applications that consume RESTful Services that I create in Project Zero. Since REST focuses on exposing resources, it puts some burden on maintaining flow on the clients. Model View Controller in my mind is crucial in Ajax applications. To reduce some chattiness, Ajax applications deal with data locally, and certain UI events trigger saving local data to the server. In essence, the Ajax applications that deal with local data now need to manage 2 resources, a local one inside the browser and a set of remote resources, and has to do so without the benefit of a transaction manager.

Applications have to worry about keeping the state of the local data clean, as well as deal with server data. This makes the role of a Controller in Ajax applications very important. An Ajax controller needs to: ** Respond to UI events* Synchronize Data between Local Model and Remote Model (RESTful Services represented as URL's)* Respond to Server events (Ajax responses or COMEt patterns)* Update View (or at least trigger the updating of a widget, or trigger a refresh of a smart widget). * Error Handling for all the scenarios above.

It seems that the Controller logic is where I use JavaScript the heaviest. Lately I have found the Dojox Wires really helps reduce the amount of JS that I write, so I am using it more and more inside my controller logic. It does not completely eliminate JS, but it gives my controller some structure. I previously blogged about Dojox Wires. I find myself repeating the same patterns again and again. The architecture looks like the figure below.

I may be looking to use JET Transformations to generate these type of clients from existing RESTful Resources.

I have had some interesting experiences with the Dojo Grid and the Dojo ItemWriteStore. A Dojo Grid can be populated from a Store. For a while, when I updated the data in the grid, the Dojo Store was not being updated. I had populated the Grid programmatically with code like this:

I was doing it programmaticly because I had to first wrap the RESTful Data into Store format (I recently discovered wires helps here too). My friend and coworker Jared Jurkiewicz then told me that the DojoData Object for the Grid needed to receive the Store at construction time, or else it would think the Store was read only. So if you want changes to the Grid to propagate to the Dojo Store, you need to create the Grid Model by passing the Store in its constructor as shown below.

With the EJB 3 and Ajax Patterns, I am finding it much easier to code Service Endpoints in Servlets, rather than using frameworks sometimes. Traditionally, the use of MVC abstractions was favored because a lot of view logic was handled in the Container. But for Ajax apps coded in something like Dojo, I find myself just writing RESTful Services for Java EE apps in Servlets. The fact that I can inject Session Beans right into them makes it easy to hook up Ajax endpoints to business logic. Below is an example of a Servlet using the JSON4J API that is part of the WebSphere Web 2.0 Feature Pack.

Of course, writing logic to move between POJO's and JSON is not as fun. Forwarding to a JSP template to do this could be easier. Or using a higher level API like that in the RPC package may be preferred as well.[Read More]

I have just finished 5 straight weeks of conferences starting with IBM Impact and finishing last week at the WebSphere Services Technical Conference which is an internal conference. I am glad it finished. Last week, my book, Persistence in the Enterprise was released.

Besides myself, my coauthors are Geoff Hambrick, Kyle Brown, Robert Peterson, and Kulvir Bhogal. The book focuses on the persistence layer of an application. The first half of the book is primarily focused on things like requirements (persistence focused), design, best practices, and criteria for selecting a persistence layer. The second half of the book focuses on implementing those using 5 different technologies: JDBC, IBatis, Hibernate, OpenJPA, and pureQuery.[Read More]

Certain entities within an Enterprise make a lot of sense to RESTtify. For example an account. It does not take much of a mental leap to create a RESTful service out of an account.

POST to /Account creates an account.GET to /Account/233 retrieves details of account.PUT to /Account/233 updates and accountDELETE to /Account/233 deletes an account.

So then there are actions that do not easily translate. People then drop to some HTTP-RPC thing. An example is when I transfer money from one account to another. A conversation with one of my collegues Brad Bouldin got me thinking about how one might go about RESTfully creating such a service. In an RPC SOA style, I would most likely have something like:

This would be ok if this was a programmatic BPEL process that can propagate transactions, but not in a browser or client tier.

So the transferFund method would have to be a service which in itself is hosted on a server platform, usually on the same App Server that is exposing the account entities. So this would involve a local update.

Now, there is no transferFund verb in REST. Only HTTP methods. So you could use something like JSON-RPC, SOAP, or XML-RPC.

Or you can make a mental switch and consider a Transfer as a noun (or Resource itself). Most likely, besides transferFunds(), you have operations like viewTransfers(), getTransferDetail(), etc...

So fundamentally, the way to create this Facade for Transfer in a RESTful fashion is to make Transfer itself a resource.

POST to /Transfer executes a new Transfer.

You may have a payload with{ accountFrom: '/Account/223',accountTo:'/Account/333',amount:100.00}

a GET to /Transfer/someGeneratedId would return a history of the Transfer record.

PUT could update a Transfer that has not completed, and a DELETE could concel one that has not completed.

REST actually can force a more complete facade which makes you think of 'Auditing' right up front. Specifically for REST services that are resources that map really to some event in the back end.

This does lead to having you to think about navigation between Transfer and Account and forming relationships you might not have thought of. Like an Account Object may have a link to Transfer.

Usually, there is some fundamental namespace that they are under. For example, Customer. You may really have the following:

GET /Customer/custId/Account returns list of accounts for CustomerGET /Customer/custId/Transfer returns list of Transfers for customerGET /Customer/custId/Account/accountId/Transfer returns a list of transfers involving this account

But the semantics can get tricky. What if I want the transfer only involving fromAccount.

I have not written a blog entry in a couple months. To tell you the truth, I struggle with blogging. I consider myself a private person in many aspects of my life. It is funny that my role at work is forcing me to be more 'social' than I would normally be. I like people, don't get me wrong, but the social web takes social skills.

Anyone who knows me knows I can talk one on one. Once I get started, it is hard to shut me up. But in crowds I tend to like to move to the back and observe.

It is funny, when I go to my parents house with my wife and kids, my wife and parents dominate the conversation. I do try to get a word in edge wise, but I find myself out quickly. Part of that is because my Father and Wife just interrupt me. So I have become used to it. I actually leave the room and play with my kids and my sister's kids like a big kid myself.

I started to think about the reason, and I found that the conversation actually does not interest me. They talk about 'so and so' over here, and that person over there, typically called gossiping, which I do not like to do (and the Bible, since I am a Christian, actually discourages it).

So relating that to the 'social web', one can very quickly find that if you are in the wrong community, you may not have much to say. Now, I have a lot to say about Web 2.0, Middleware, etc... so there are other things.

I look at social websites like Facebook. I have an account, with friends. They all post a lot of pictures, send virtual gifts, and other types of applications. I do not like these things too much. First off, I would much rather receive a real gift. Also, I don't like posting pictures of my family. I seem to think the web has a lot of security problems and the pictures wind up in some sick-o site. The status feature is interesting, except, do I want the world to know what I am doing. Though I enjoy reading what others are doing. I have found the scrabble app as cool, and I play a lot with my wife, so that is fun.

I like to share, I try to teach my kids this all the time. But do I want to share what I am doing, or where I am flying?

I think it comes down to is I like to interact with people face to face, I like being around people and listening to them more than talking, and I like to contribute what I know, but not every single thing I am doing. I also like to work in smaller groups of people.

But what about more 'private' people. Maybe they are read only members of the social web.

This is a rant I know, and I am going to post next on a technical topic. But isn't this what blogging is suppose to be about?

Anyway, it takes 'social' skills to be on the social web. This is something I have to work on I guess.

A Beta Driver of the new Google Browser has been released for Windows (which leaves us MAC users waiting to try it.) There has been a lot of blogs and comments on the new browser so I am not going to discuss a laundry list of features, but focus in on the application centric approach.

I love that each tab is it's own process, and that application isolation can be achieved on the client. One thing I love about Web 2.0 and Ajax is the focus on applications. Having your desktop run different apps rather than one monolithic browser process obviously solves a lot of issues.

By the way, this is exactly the model that WebSphere sMash (Project Zero) has for applications on the server. Every application runs in its own process, and you do not deploy an app to a server, you just run the app, which is the server.

Today, I just released a new article (with Steve Ims as a co-author) on WebSphere sMash (this is actually a rewrite of last years article we did on P0, but with the latest driver and tools). We discuss application centric design of sMash in the article.

The google browser model matches what we have been doing with WebSphere sMash and Project Zero on the server. I can definitely see an architecture where applications running on the desktop call applications in the cloud that service them (or are bound to them as shown in the figure below).

But I have been spending a lot of time helping some of my customers with REST Architecture. I figured I would post some here. I will give some bullet points and will be publishing papers soon. Note, these are not in any order of importance. All are important. Note, I am just putting pointers in rough format here, and I will publish some more articles on the topics later.

1.) Understand REST. Here are the top 2 misconceptions about REST:

a.) REST is just any XML over HTTP not using SOAP? NO !!! REST is a Pattern of exchanging Resources. RPC is Not REST

b.) REST is only useful for CRUD(Create, Read,Update, and Delete) semantics.

2.) Define a strategy for defining resource/services:

* What are the resource identifiers?* Is there a hierarchy of resources?E.g. a list of employees may be one resource, each employee is another /employees vs. /employee/empid1* What HTTP Request/Response Headers SupportedAccept, Content-Type, Range, etc….What is the representation of the data exchanged?JSON? XML? PDF?

* What are the methods supported at each resource?Do you support POST, GET, PUT, DELETE?

10.) Think about API Versioning from the start:

* Follow a Close Spec (slow moving)/Open Extension (Popular Extensions become the next wave of standards) Closed/Open* How do I represent Versions? a.) Use URI? /v/3/myResource (better for Bookmarking, expressive)

14.) Sometimes you need to Relax.

15.)Documentation As a Service.

Atom can be a great way to document since you can link to the service URI Patterns.

What should REST Documentation have?

Documentation as a Service/resource/formatsCatalog, Registry What are my URI PatternsWhat Headers do I support?What Verbs are valid for my resource?What Response codes do I support?What do they mean for my service?What formats do I support? (JSON, and ATOM)Which header do I use? Accept, query param?What schema describe it?

16.) Write your Unit Tests first using something like HttpUnit.

Hi guys and gals, hope all is well. IBM Impact 2009 is on its way. I will be there. Somehow, I managed to end up presenting 7 lectures and 4 labs. I am not sure why I do this to myself. I don't even plan out to do this many sessions. Last year, I took great pleasure in delegating. This year, the delegation just did not happen. Though I do have great co-presenters and lab advocates, so I may be able to escape here and there to see some other great sessions. Even though I am quite busy, I plan to take a REST!!!

I am the track lead for Application Development and Web 2.0. One of the major themes for this track is REST. We have great sessions in the technical track around REST. Here is the list of sessions (Lectures only, will Blog on Labs soon), their speakers, and their time slots: