REST and WebSphere in 2009 Trends and Directions

Jerry Cuomo recently mentioned in an InfoQ article the WebSphere trends and directions for 2009

One of those topics was a comment on the support the WebSphere was doing in the area of REST (and the need for a common REST API), and how we are working to allow our own products as well as customer applications to be developed quicker and easier (promoting an ability to react faster and be more Agile).

Anne Manes made a comment about why we need a REST API - isn't HTTP GET,PUT,POST, DELETE enough?

I've provided an update with respect to where I think Jerry was headed via his comments (and what we are doing in WebSphere to provide value to customers)..

However - I find it interesting that folks think that REST is so much easier that you don't need any more information that 4 interfaces. You still need to know what the resources identifiers are and what is the resource state actually represents in order to use them (irrespective of the actual encoding/formatting of that data). That need isn't any different than any other distributed communication mechanisms that I've worked on in the past. I've worked w/SNA, TCP/IP, DSOM (Distributed System Object Model), CORBA/IIOP, Web Services, and now REST - as I'm focusing on REST within WebSphere. Irrespective of the technologies around (and I've seen all the comments about problems w/the technologies, tight coupling between technologies, lack of interoperability, etc...) - at the end-of-the day - you have a "client" making a request for information to some "service/resource" and it needs to understand the format of that data to accurately process the data. If you change the format, you potentially break the client. In a web-presentation world and HTML, the data can change the data, but our human minds can easily understood if the data format changes. For example, ESPN.com recently changed their web site around - however, I can still manage to deal w/it - since human minds can easily comprehend it. However - I know that if I wrote a script looking for the scores of yesterday's games (thereby automating it)- that it would fail since the location/context of that information is now in a different spot and presented differently.

In the end - I think we need to take our focus off the technologies themselves, and place the focus more on the value obtained in using the technologies to achieve a business goal. Defining patterns and best practices to use technologies are as critical to making our customers succeed as the technology itself. Anti-patterns are also valuable as the prevent customers from following practices known to be error prone. WebSphere focuses on producing middleware so that it can provide to customers an ability to expose data, services, whatever is needed for customers so that they can more easily provide value to their customers. I think all Jerry was alluding to is that by trying to be consistent with how we expose data/interfaces amongst our products, we can use those as best practices and patterns for others to do the same. That is what we are doing in WebSphere. As we can, we will publish best practices and use cases for using our technologies. In addition, in cases that we know we can do better - we are learning from those efforts and will be listing those as anti-patterns. Every time I have a discussion w/our services organization that use our technologies - that's the first question they ask - please give me reference patterns and anti-patterns.

Those who cannot remember the past are condemned to repeat it.

IBM again leads Oracle (and everyone else) on SPECjAppServer2004 performance and cost

I recently had someone email me on a performance topic and they referenced WebSphere Application Server's SPECjAppServer leadership. They actually didn't know that IBM regained total leadership in this benchmark late last year. Maybe the fun of the holidays didn't allow folks to notice? I wanted to post this update, so if other folks missed it they would notice.

In these times of tough economic conditions, it's really important to focus on total cost of ownership and ways to improve efficiency. IBM's continuous leadership in performance proves we care about performance as it relates to end to end J2EE enterprise computing scenarios. This increased performance means you can host more workload and applications on the same resources that you used before. Our performance engineers are continuously improving performance of your applications and we use SPECjAppServer to demonstrate those improvements.

Sometimes people ask me how SPECjAppServer matters to them. It's this continuously increasing performance that matters to them. Originally SPECjAppServer helped the J2EE programming model transition from a programming model to a capable enterprise ready programming model (stressing basic performance and scalability). Now, SPECjAppServer leadership helps customers know the middleware they are buying from IBM is helping them improve their efficiency.

This view is a technology view (leadership at 22634.13 JOPS), however it has business impacts as well. That result was achieved at roughly one half of the cost of our closest competitor. That just acquisition cost. If you consider the power savings on top of that you're not only being more green, but saving green.

Again, great work by the WebSphere Application Server performance team!

Disclaimer: SPEC is a non-profit organization that establishes, maintains and endorses standardized benchmarks to measure the performance of the newest generation of high-performance computers. Its membership comprises leading computer hardware and software vendors, universities, and research organizations worldwide. For complete details on benchmark results and the Standard Performance Evaluation Corporation, please see www.spec.org. Competitive claims reflect results published on www.spec.org as of January 23, 2009 when comparing SPECjAppServer2004 Total JOPS on all published results.