REST/SOAP - 85% plays 15% on Amazon

[Via Tim O'Reilly]

"I was recently talking with Jeff Barr, creator of syndic8 and now Amazon's chief web services evangelist. He let drop an interesting tidbit. Amazon has both SOAP and REST interfaces to their web services, and 85% of their usage is of the REST interface. Despite all of the corporate hype over the SOAP stack, this is pretty compelling evidence that developers like the simpler REST approach. (I know there are many more complex applications where SOAP is better, but I've always liked technologies that have low barriers to entry and grassroots adoption, and simple XML over HTTP approach seems to have that winning combination.)"

Very interesting but I would argue that it is not the case that for more complex apps, SOAP is better. Sure, there comes a point where you cannot encode parameters into a URI but I don't see why it follows that these more complex web services need to throw out the huge advantages of having a GETable URI.

Here is a URI that will invoke a webservice MYWS that requires a whole bunch of parameters. The params are stored in MyParams:

<a href="/InvokeWS?ARGSURI=MyParams&ForwardURI=MYWS">click me</a>

InvokeWS is retrieved via GET (in other words, its a hypertext link). It picks up the argument payload from the URI "MyParams" which is then POSTed into MyWS. Voila, a "clickable" full payload webservice.

Multibloggers and rss aggregators

Mike Champion has a blog on java.net. He has/had a blog on xegesis too.
Simon Phipps is here and also here. Looks like we are headed towards an era when individuals have multiple blogs - like credit cards - or airline loyalty cards. This trend will intensify the demand for RSS aggregators to create a single "view" of interesting stuff and interesting people.

Jython at Java One

Yes Simon, I'm very pleased. Very pleased indeed!

Scripting with Jython instead of XML

From Scripting with Jython instead of XML

My bias is that XML is a great tool that is misapplied when it is used as a programming language.

Amen.

RFID's

If these are, what I think they are...yikes!

Taking XML processing out of the dark ages

There is a lot of XML out there. There are also lots of developers who, day in, day out, craft programs in Java SAX, DOM or XSLT. All these technologies are useful but incredibly low level tools.
As well as being low level, the exhibit that classic sign of costly development - low to non-existent re-use of processing components.
What if you took a platform like the Java Virtual Machine on which you can run a variety of languages, each suitable for certain types of XML processing task. Java itself of course but also XSLT and Jython.
What if you had a way (using XML of course) of parcelling up a program into a reusable XML processing component?
What if you had a studio that allowed you to grab existing components and chain them together - regardless of their implementation langauge - into an XML processing pipeline?
What if you had a scaleable, J2EE based engine for execting these pipelines?
That's what PropelX is.
The ideas underlying PropelX have been developing in my head for well over a decade at this stage. Back to waaay before XML existed and I did my markup work with SGML. The hope is that the ideas inherent in PropelX catch on, the XPipe project for example, is an open source project aimed at creating open source implementations. Propylon will be donating some code to this effort.
An analogy : Not too far fetched. Think of an XML document as a number. Currently, we do all our calculations by hand. Its terribly laborious and re-use is non-existent. Then the concept of a spreadsheet comes along. Bing! All of a sudden, number processing changes utterly and for the better.
The same thing will happen with XML processing. It has to. PropelX, I believe, is headed in the right direction.

PropelX 2.02 now available

PropelX 2.02 now available for download. Propylon's implementation of the XPipe approach to XML transformation. J2EE based. Use XSLT, Java, Jython to build XML processing components or re-use those supplied in the library. I'll be writing some pieces about PropelX here in the weeks ahead.