This rings very true. In my opinion, IBM does a fairly good job of staying out getting out of the way. In fact, a lot of the internal community tool innovation going on over the last few years is surfacing as Lotus Connections, which will enable enterprises with social tools. However, no amount of money can purchase a culture, which grows organically. Paraphrasing (former IBMer) Don Ferguson, “if you stand in the way of the Internet, it will run you over.” But do follow the link and read these three bullet points in context:

DO NOTHING

GET OUT OF THE WAY

KEEP THE ENERGY LEVELS UP

Via Tim O’Reilly: Link to The 100% guaranteed easiest way to do Enterprise 2.0?

PUT remains one of the most confusing HTTP verbs because it is so frequently misdescribed, even by people who really do know better. The common description is that PUT is for UPDATE and POST is for creating new resources; and this is wrong, wrong, wrong.

Source: PUT is not UPDATE

Elliote is dead on here. I am guilty of comparing REST to SQL CRUD, including PUT == UPDATE. Upon reflection, however, I always thought of a “complete” update…comparable to Eliotte’s DELETE then INSERT with the same primary key. Nevertheless, despite intentions, UPDATE does carry certain connotations.

Elliote references Joe Gregio’s pioneering thoughts on REST from 3 years ago. It doesn’t seem to suggest that PUT == ”partial” UPDATE. I recall a Roy Fielding quote (but couldn’t find the reference) in saying PUT is not a byte for byte replacement of the resource by the exact contents of representation. Rather, the server interprets the representation, but does in fact update the entire resource with information from the representation.

Joe does place a disclaimer in the very article that it is dangerous to begin thinking of REST in terms of SQL tables.

I hesitated to include this table. By presenting it, I wanted to point out the overlap in the four basic methods of HTTP. What I don’t want to happen is that you start thinking of web resources as SQL tables. Don’t do that.

Source: How to Create a REST Protocol

So it seems the lesson (finally) learned by myself is to not describe REST to people in terms of ambiguous SQL idioms. There is some overlap, but no absolutes. If the SQL comparison is necessary, disclaim the caveats upfront.

It’s difficult to avoid thinking interms of SQL. Especially for me, having taking three courses on relational algebra in college. Opposite of my upbringing, however, traditional relational databases will be marginalized over the next decade as more specialize data systems become evident (i.e. BigTable).

It’s kind of fun getting a glimpse of what others are thinking about by subscribing to their del.icio.us bookmarks. Recently Joe Gregorio bookmarked the following…

Python Cheese Shop : zdaemon 2.0a6

monit

plope - supervisor2

Hmmm, whatcha thinking about, Joe?

Everyone is a buzz about Yahoo!’s Pipes. And rightly so. This type of mashup builder might finally rid the word “mashup” from Google Maps. I got about 10 minutes of play time before the Eastern seaboard woke up to give the new service a try.

I need to play with this a bit more to have a better opinion. So would all of you just stop hitting the server? Until then, the only comment I have is Yahoo! missed a great opportunity to get rid of RSS’s bugs by promoting Atom over RSS. I know that Yahoo! doesn’t share my sentiment for Atom, however.

Yahoo! Pipes!

Yahoo! Pipes: Deconstructing a Pipe

Yahoo! Pipes: The Modules for Building Pipes

Pipes

Yahoo’s Pipes Hard to Grok But Snazzy

Yahoo Launches Pipes for Data Mashups

Yahoo! Launches Pipes

Yahoo Launches Pipes, an RSS Remixer

Yahoo! Pipes: Ajax Mashup Builder

Pipes and Filters for the Internet

And that was just by 9:30 AM EST!

Dion Hinchcliffe nails a growing sentiment among many over the last few year(s). There have been enormous unncessary resources spent on the WS-* vs. REST debate. And whether what flavor you side with, the movement REST pundits push, sometimes vehemently, is summarized by Hinchcliffe as…”leveraging the fundamental strengths of the Web to turn applications into platforms.” [1]

I’ve heard some refer to this as using HTTP the way it was intended, if you don’t its like running with scissors. [2] The current state of SOA is not intentional. Rather, it is engineering tendancy to “boil the ocean.” Nobody wanted to bastardize HTTP, nor did anyone set out to produce complex specifications thousands of pages long.

When it comes down to it, WS-* and REST are Service Oriented Architecture. I, personally, argue that REST styles and principles exemplify the spirit of SOA more accurately. But that is subjective. Regardless, the time has come that architects look their work form different perspectives.

So let’s look at what Hingcliffe proposes SOA architects to consider in the coming year.

1. Make services consumable in the browser
2. Consider syndication over “service-ing”
3. Deeply embrace URI addressibility
4. Use Ajax as the face of your SOA
5. Monetizing your SOA
6. Enable users as service consumers
7. Virtualization, fast scaling, and on-demand architectures
8. Offer an SOA as visual services via widgets
9. Consider JSON as a service option
10. Encourage and discover emergent solutions
11. Leverage the Global SOA

Hinchcliffe’s article mirrors my thoughts over late 2005 and through 2006. The article acutely summarizes key movements in SOA. In my role at IBM, I have the opportunity to work on a project that addresses nearly all of these issues and influence IBM’s future strategy in context of “Web 2.0″. Over the coming weeks, I will be exploring each of topics in separate posts.

Sources:

[1] Eleven Emerging Ideas for SOA Architects in 2007

[2] http://bitworking.org/projects/rest/6.html