Why do we do this to ourselves. As my friend Keys said, we go through endless cycles as an industry solving the same problems again and again. Technology X is too complex, create technology Y cause it is much simpler. Then technology Y lacks features, so lets add it. Now technology Y is too complex, let's create technology Z, and so forth. I have gone through distributed technologies like ONC RPC, COM, CORBA, EJB, Web Services, SCA. I am a fan of REST, because it exploited existing HTTP infrastructure.

So, why the rant, cause I see people doing exactly what destroys simple technologies. Most recent is this link TX support for JAXRS and REST and transactions. Adding transactional support for JAXRS? Why would I want distributed transactions for REST. Really, don't we learn anything in this industry. Why on earth would we want to propagate transactions over REST? We already did that with SOAP? Or why would I want to expose a Tx API over multiple HTTP calls? Leaving Tx's open across multiple HTTP calls has already proven to be a bad practice? REST is stateless, and therefore makes middleware scalable.

A Business process or facade itself can be a resource (/MyBusinessProcess), but the implementation of that service can use regular Tx API's and hide those details.

REST is about "Exploitation." Web Services and SCA is about "Abstraction" Let's put a stake in the ground and use the right technologies for the job rather than destroy something as beautiful as REST.[Read More]

In my previous blog, I talked about how API's should be modeled from a Consumer Centric Approach. From an On Premise perspective, a typical logical architecture for supporting this type of deployment is shown in the figure below. A typical application architecture contains an Application Server hosting the interaction services, usually implemented as a set of REST services or Worklight Adapters. Typically, even in a Single Page Architecture, your application server does some type of session management, caching or storing of User Data, and Integration to the back end either by accessing the data or through an ESB or BPM engine. Because this tier was an entry point into your infrastructure from the Internet, it required a large amount of work to scale, maintain, upgrade, and so forth.

This week IBM announced the Open Beta for BlueMix. A Platform as a Service platform for building out next generation solutions out in the cloud. This includes tools for building web apps, mobile apps, and so forth.

As Enterprises look to leverage cloud at different levels, a definite pattern that has emerged is offloading the Mobile/Web Application Server out to the cloud, using Platform as a Service providers.

There are many advantages to this model:

A larger ecosystem of choices are available. For example, I can choose to build out API's using Node.JS, Java, or Ruby. Entry points are no longer products, but services, including development platforms.

A source of services available to your application, directly available. Examples are Local JSON Storage, Session State Caching, Mobile Push API's, and so forth.

Availability of SDK's for different client platforms. For example, making iOS SDK's available for Apple Devices or JavaScript API's for clients.

Ability to scale out web traffic without Infrastructure investment. Bluemix sits on top of a Softlayer as an Infrastructure as a Service stack.

Many Enterprises still will want to maintain their back ends and System of Records "On Premise." It is difficult to move generations of host systems out to the cloud. In addition, there are many security reasons why enterprises wish to hold their data "On Premise." However, the security maturity of Cloud Providers, like Softlayer, As such, the emergence of a Hybrid Cloud Architecture is emerging.

How would a Logical Application Architecture look like in this scenario. Look at the figure below.

The REST/API tier that typically runs on-premise is now built in the cloud. You can built services using technology to meet the interactions patterns, weather it be push services through mobile networks, asynchronous IO with WebSockets and Node.JS, or application logic with Java. From an On-Premise perspective, exposing API's and API Management becomes a key capability as providing Data Services from the Enterprise will be the new name of the game.

Offloading your read transactions, interactions, User Model to the cloud, will free up your own infrastructure to handle the revenue generating transactions and core business. Leveraging the cloud to host your User Model means you can augment your interaction with Social and Mobile Services like location or push services without the infrastructure cost.

The Next generation web and mobile services will be living out as cloud services, it is time think about the next generation reference architecture to support it.

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.

I am recovering from a very busy IBM Impact. It was great to meet with so many customers. By far, Mobile was the topic that I spoke the most about. One area of discussion is how web design is fundamentally different than mobile. Designing modern web 2.0 applications is like designing a mall directory. You show all the possible places and how to get there. Some shoppers go to the directory and plan out their shopping. They find the one or twenty stores they need and look for the directions. However, mobile is about having to run into the mall and be done in 5 minutes. You need to go right to the 1 store you are going to visit without looking at the mall directory as quickly as possible. The mobile web app is like having a personal guide who needs to know when you walk in and show exactly where you want to go.

Today I went out to eat with my wife and kids somewhere about an hour away from my home town. I did not know the area. She asked me to find the closest of a particular department store. I went to their mobile site and tried to use the "Locate Store" Feature on their mobile site. It asked me for an address. Of course I did not know where I was to begin with, so I did not have an address. Their Mobile Application failed them (not me, I did not want to go to the store, my wife did) because they missed the moment to guide me to their store. In turn we ended up driving home instead. We also have no plans to buy the item we needed cause something else came up. Their Mobile Website was designed like a normal website. An address locator makes sense behind my home computer, but not while I was trying to find you on my Blackberry Torch. That store lost revenue today.

A Mobile Web page of a store with locations should have a button that says: "Find Store Near You." Upon clicking, it should return a list of stores (5 max). I can touch the first store and it should use the Geolocation API to give me accurate directions. It can also integrate with my GPS application or integrate with a web based navigation system to provide my navigation.

Mobile applications need to know the road most traveled. It needs to provide me with the fastest route to the 1 item I am going to do. It needs to know where and sometimes when I am going to do it. It is the context of the phone use. That is the key word. If you miss the moment, then you lose. People will pass it up and not use your app.

Many have commented on Oracle buying BEA out there in the blogging community. One thing I am very interested in seeing is which persistence mechanism is supported if they choose one. Most likely, we will see Oracle pushing BEA's App Server. TopLink has had a long history as a persistence provider and supports JPA. But BEA's App Server is based on OpenJPA (more specifically the Kodo product they purchased from SolarMetric.) IBM also built its JPA provider(available via the EJB 3 Feature Pack for WebSphere) on top of OpenJPA. It should be interesting to see which way Oracle/BEA goes with in persistence.

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]