I haven't posted much here lately since I've been having a lot of fun over at my
new Web 2.0 blog. While
Web 2.0 is a hugely important topic in its own right, one of the key elements of Web 2.0 applications is that they offer an open API for anyone to remix or "mash" the services into new applications by aggregating a site's functionality into their own. Think Amazon's REST/SOAP services or search APIs by Yahoo or Google as particularly well known examples. This makes the entire Internet the API for the next generation of web applications.
Not sure about this? Need an example? Take a look at Marc Andreessen's Ning, it's a new remixing service for non-developers. The resulting mash-ups can then be reshared and mixed again. How are the services made available to users? You guessed it, either via an Ajax or HTML interface of some kind but most usefully via web services of one form or another.
This takes us back to the Service Description Language comparison that I've been attempting to complete on and off for a few months now. As web services really get kicked into high gear with emerging techniques like Ajax that voraciously consume them, web service description languages are going to either grow increasingly important or increasingly irrelevant depending on whether they routinely provide added value to developer's daily work. We last left the comparison getting ready to take a look at Savas Parastatidas' and Jim Webber's ambitious and capable Soap Service Description Language (SSDL).
Simplicity and elegance are design approaches strongly in vogue right now with lean/agile development processes, Google-style web interfaces with spare layout, and Web 2.0's doing more with less to increase quality meme, to name just a few. Can SSDL, with its base functionality and four associated and sophisticated protocol frameworks, compete in a nimble world where Ajax clients will be very commonplace and prefer to consume oh-so-simple REST, JSON, and POX/HTTP services? We'll find out as we begin implementing our order service contract in SSDL in my next post. Note: I did recently get an Ajax client to communicate fairly easily with a .NET web service, and there are now SOAP stacks for Ajax frameworks, such as Bindows.
Also note that the SSDL core protocol consists of schemas, messages, and endpoints, which define the information structures going in and coming out of the SOAP web service, what operations on the web service take the aforementioned structures, and where on the Internet or local network the operations can be found, respectively. These can then be combined into protocols that describe the order and other high level aspects of the operations. It's pretty neat stuff and I can see how it would be very useful, especially in formal environments, but it will be interesting to see how consumable it is in the everyday rough and tumble world of Web services with a capital W.
Stay tuned while we figure out how to build an extremely loosely coupled SSDL SOAP service and client...
Technorati: Web Services
, SOAP, Ajax