Blogs

In the latest EBA podcast we were lucky enough to have Duane “Cosmic Genius” Nickull with us from Adobe.

Mostly just discussed SOA and jabbed at SOA 2.0 a bit

I am also hacking away at a Flex component for copy and paste functionality between our AJAX Grid and a Flex DataGrid (or Microsoft Excel). I did a quick google and found that someone from Adobe already did a copy/paste to/from Flex and Excel example - just five days ago.

Check it out.

I have been intently following Dion, as you do, over at the good old SOA Blog. One recent post is, as usual, more of the same commentary about Web 2.0 and SOA.

In his latest post Dion suggests that:

“Writing software from scratch will continue going away. It’s just too easy to wire things together now. Witness the growth of truly amazing mash-ups of which things like Retrievr and Meebo are only two tiny examples.”

This is a bit too far off the Web 2.0 global SOA deep end for me. Retrievr is admitedly an interesting mash-up but is it really “truly amazing”? Is it something you need to use everyday - something to write home to Mom about? I suppose it could be considered amazing from the perspective of available mash-ups but in general mash-up quality and usefulness is relatively low. From what I can tell the main reason to provide API’s to your software is to either:
a) get more users and increase your valuation when selling your Web 2.0 company to Yahoo!
b) hope that Google likes your mash-up and hires you
c) gain the support of the increasingly trendy niche of hybrid “programmer / blogger / never the cool kid in school” types to help you achieve goals a) or b)

d) attract attention to attain status of trendy hybrid “programmer / blogger / never the cool kid in school”
(please leave any other ideas in comments below)

Flickr in itself is only marginally amazing, and it was written from scratch - shock horror!

If one even considers what a mash-up really is, one finds that we have always developed software by “wiring things together” have we not? I can imagine with every level of programming language abstraction there is some journalist somewhere who heralds it as evidence of a new golden age of programming productvity. The only difference here is that programming languages - unlike mash-ups - can actually be useful!

The real amazing software that I find myself using is that which actually *enables* the mash-ups; for example, Google or eBay have great technology and are products/services that can not simply be created by mash’ing up a few JSON based JavaScript streams in a browser.

In his latest post, Dion even says:

“Maybe software developers should just go back to sprouting acronyms and delivering software that doesn’t do what people want.”

To me, he is trying to say that Web 2.0 let’s people build good, useable software - this is sort of true and I am a big believer in AJaX of course. However, I would like to know how many social networking, tagging, blogging, sharing //insert buzz word here// Web 2.0 applications we need!

The actually point that I was thinking about when I gave this post a title was that I just don’t understand why creating REST based services is really that open, easy, or robust? At least with Web Services and WSDL one can automatically build a C# or Java proxy for a service and even have JavaScript emitted for use on the client, can you do the same for the del.icio.us REST API so easily? In fact I find it astounding that an API such as that of Flickr, which is actually quite robust, does not even have a standard WSDL based description of the bindings (addmitedly some aspects of the API are not that complicated to warrant SOAP based services but at least a binding description would be nice) - my point being that it seems to me WSDL descriptions (or any kind of machine readable one for that matter) of mash-up enabling APIs are a few and far between despite the fact that they are actually quite useful for generating proxies etc. Also, how will these supposedly simple services work with the Semantic Web? I am not sure the Semantic Web will be that easy in itself so does that mean we should forego it and just settle for Web 2.0 or maybe 1.5? Well yeah maybe we should :S I guess I could be alone in thinking that the Semantic Web is what we should really be talking about rather than mashing-up Google with Craigslist (I know, Google + Craigslist is sooooooo 2005). The whole idea of an API for a service that one has to actually physically read makes me shudder - haven’t people had enough of mapping inputs and outputs to services (whether they are REST or otherwise)??? Maybe I should quit complaining and define a REST service description language (RSDL) that is a simple version of WSDL …

I suspect this drive to simplicity is going lead us down a path we have been on before. As you make things more simple you also, generally, make them less valuable. I know that many take the KISS principle too literally sometimes and apply it to the nth degree. Sure Google is pretty damn complex but they also have billions of dollars in revenue - complex and valuable. On the other hand, look at Retrievr - simple and worthless. Choose your poison.

Paul Kedrosky chimed in on the recent introduction of Structured Blogging (SB). Paul suggests that laziness is going to prevent SB from taking off and I would have to agree. Like many Web 2.0 concepts, it puts too much faith in the hands of the user - and aside from over zealous alpha-geeks, it will likely be too much work for users to actually use.

As time goes on I am certainly finding that just using a search engine is actually faster than using del.icio.us and is less work to boot! Flickr is the one exception where tagging is actually slightly more useful [1,2] - seeing as how search engines have a hard time indexing image content . This is my common conclusion from using many different online services. Sure I sign up for all the great new Web 2.0 / AJAX services … I signed up for Writely and they can use me in their stats of doubling their user base every X weeks but I am never going to use it again; not because it is not cool and slightly useful but because I am simply too lazy.

This subject also came up yesterday as I was reading one of the latest fire stoking, “Five somethings about Web2.0 / AJAX”, post [3] by Dion Hinchcliffe over on the Web 2.0 blog. Dion’s number one reason that Web 2.0 matters is because it “seeks to ensure that we engage ourselves, participate and collaborate together”. Again I can’t help but think about how lazy most people are. Sure people that are actually interested in Web 2.0, tagging and the like make it seem really great but for the most part they cannot be bothered.

For Web 2.0 to get traction beyond the alpha-geeks I think it needs to empower developers and ask less of end-users.

References

[1] More Tags - Dave Johnson, Dec 14, 2005
[2] Tagging Tags - Dave Johnson, Dec 1, 2005
[3] Five Reasons Why Web 2.0 Matters - Dion Hinchcliffe, Dec 7, 2005

I sure am behind the times. I just saw found out about the SOAP and WSDL support in Mozilla / Gecko based browsers. This is very cool and I am not sure why more people are not using this … especially in AJaX circles.

The other interesting thing that I found was that you can extend the DOM in Mozilla to support Microsoft HTML Component files or HTC’s - these are used in Internet Explorer to implement things such as SOAP and WSDL support. So you can in fact have SOAP and WSDL support in Gecko with either the built in objects or using HTC’s.

Ok so why aren’t more AJaX people using this built in support for SOAP + WSDL in Mozilla? If you prefer to generate JSON on the server and pass that up you are just crazy since you could instead pass it up as XML embedded in SOAP and then use XSLT on the client to (very quickly) generate HTML or CSS or whatever from the XML.

As usual, Bill Scott has recently shared with us some of his keen insight into what makes Web 2.0 tick. In his latest post he introduces and defines the three (rich) dimensions of Web 2.0 as visual, interaction and data [1].

Before the arrival of so many AJaXified applications, data was the bottleneck through which the other two dimensions had to be squeezed. Now, developers are free to work in any dimension almost completely disjoint from the others using CSS, DOM and XMLHTTP for visual, interaction and data respectively.

I say almost because the choices you make in any dimension can and do influence the others (AJaX string theory). AJaX developers generally insist on minimalist and tightly coupled data communication methods; the reason for this is simple - if you pass SOAP, or worse, some WS-* compliant messages between the server and client you are going to have lots of extra data passed back and forth and will require more processing which both take time and reduce the usability of an application. Take Google for example, to get the best performance from their AJaX applications they generally return pure JavaScript or JSOR (JavaScript on the rocks). Doing this is great for a one-off customer facing application but when you want to share and open up data it becomes a lot of work to interoperate between Google, MSN and Amazon maps. In short, by making the data dimension more complicated to allow for say SOAP interoperability, we make the job of the DOM / JavaScripr dimension that much more difficult due to the increased overhead. This trade-off in performance has to be considered.

So as Web Services and all the standards that come under that umbrella are currently moving towards implementing Service Oriented Architectures (SOA) and (maybe even more importantly) the Semantic Web, were is AJaX going? What CSS and DOM trade-offs are we willing to make for the sake of rich data? Sure AJaX is young but let’s face it, everyone and their dog was using iFrames or XMLHTTP since the 90’s. AJaX and Web 2.0 developers should think about looking to SOA for guidance if we truly want to see rich data at its best. Let’s not get hung up on a Google map + housing listing “mashup” (not to say that I wasn’t excited to see it ) or worrying so much about back-buttons. We need to be driving development of Internet technologies on the client as well as hacking around and pushing the boundaries of the today’s Web!

Where do we go from here? In my previous post I discussed the synergies between SOA and AJaX [2] and in light of that discussion, I have been thinking about AJaX and how to create a truly data rich Internet application. Most of my thoughts end up at the sad conclusion that we are at the mercy of the web browser vendors that don’t have WS-* or even SOAP processing built-in (which Mozilla actually does have now ). Alternatively, maybe we should be looking at building a 4th dimension into AJaX applications of light weight standards based on the SOA tenets (discoverability, reusability, abstract models, policies)?

[1] Richness: The Web in 3D - Bill Scott, August 30, 2005
[2] SOAJaX: Where does SOA Stop and AJaX Begin- Dave Johnson, September 02, 2005

There has recently been a maelstrom brewing over SOAJaX with some people claiming their is no correlation whatsoever between the two [1], some comparing the software industry to the fashion industry [2], some making nice graphics outlining important implications for SOA designers [3,4] the old “it’s all semantics” argument [5] and some being completely inane [6].

As many before have noted, SOA and AJaX are both just ridiculous acronyms describing architectural paradigms that encompass entire families of web technologies - but let’s try to look beyond that So let’s try to answer the question of what exactly SOA and AJaX have to do with life the universe and everything.

To start with, the “it’s all semantics” argument is correct. If you look around you can find a different definition of SOA depending on the time of day [8]. So, as Dion Hinchcliffe discusses [7], I think a good place to start is looking at what exactly SOA and AJaX are.

To get the definition of SOA I went straight to the horses mouth - OASIS. Since some smart people realized that SOA was completely ambiguous and didn’t mean anything in the real world, a technical committee created specifically to define a SOA reference model (they call this the SOA-RM TC). Hopefully, the result of all the hard work being done by the SOA-RM TC should be some guidelines to help in defining what components are required to actually call something a SOA. The work is not completely done but a recent SOA-RM Technical Committee overview presentation [9] by Duane “cosmic genius” Nickull (I hope that some of the absurd smarts rub off on this Canadian technologist) of Adobe. From this presentation there are at least five things that are required for something to be considered a SOA: a service that can be called through a prescribed interface, a service description declaring all relevant aspects of the service for would be consumers, discoverability, abstract data and behavioural models, and finally a policy which imposes constraints on consumers of the service. Of course loose-coupling is also a SOA hallmark.

Ok. I did not see any mention of Flickr, CSS, XML or the “yellow fade” technique there. Things are looking grim.

Now let’s consider what a RM for AJaX might look like. I am thinking that the important things for AJaX must be some degree of Asynchronicity, JavaScript and XML? Let’s knock of the last two first. Since SOA is quite technology agnostic it cannot really have anything specifically to do with JavaScript or (although most implementations use) XML. However, we may be able to weave a connection around the thin thread that is the capital “A” in AJaX - of course the second “a” is part of the word JavaScript and so should not be capitalized but that is another kettle of fish as they say. Asynchronous. Both SOA and AJaX (for the sake of argument) use either a synchronous or an asynchronous based communication pattern. So in the strictest sense AJaX can be a nice way to consume SOA services and provide a usable interface to them. That being said, if today’s SOAs are defined using the likes of WS-* then AJaX will never rise to God-like status it is striving for because you don’t want the WS-* stack written in JavaScript. So AJaX can consume services based on a SOA if AJaX developers want to play in the same league, but today I doubt it. This is where the commonalities start and end - but hey it’s better than nothing.

Strictly speaking AJaX is simply an important layer above a SOA like any other web application framework today; they are, for the most part, separate and discrete entities. Their paths may cross at some point in an optical fibre in the middle of the Atlantic Ocean but that is as close as they come. Before AJaX rose to super-stardom developers would simply utilize SOA from their Ruby on Rails or .NET or JAVA application running on the server and then convert the returned data to HTML and serve that up to the client. Now that AJaX has landed people have the opportunity to bypass that server layer and go straight to the source - if they want to deal with SOAP, WS-* etc they can do that. In general this is not the case. Since developers are lazy by design (at least the good ones) and AJaX developers (the laziest of the bunch) have shunned XML and, in an effort to reduce the amount of JavaScript coding to be done, have come up with their own data formats (JSON, JavaScript on the rocks or JSOR, amongst other more obscure or proprietary ones). These formats were spawned outside of the standards world in the wild west that is Web 2.0. Sure you can have a system that follows the tenets of SOA and uses JSON as the data format of choice if you are building a Web 2.0 consumer facing photo sharing website but this might not be so helpful when trying to integrate supply chains.

Although SOA has not quite hit the fashion industry status that AJaX has, SOA is the bricks and mortar that our software systems of the near future will be built upon while AJaX is but the decoration nailed to the walls. It just so happens that in Web 2.0 the walls are generally quite thin and AJaX appears to, and does, blend into a bit of an ad hoc, loosely defined, SOA.

So what implications do SOA and AJaX have for each other? Dion mentioned in one of his articles [3] that AJaX would likely push SOA away from WS-* way of doing things but I contend that AJaX will not have as much influence on SOA as he suggests because:
1) the SOA crowd is more established than the Web 2.0 cowboys thus it will take more than a few rogues to completely turn the tables
2) in web browsers today there is no support for discovery and policy binding, which are necessary for SOA particularly in the enterprise
3) people have been developing web applications that consume services for many years - to think that because of the re-introduction of asynchronous requests from the browser developers will suddenly find that they need to access enterprise Web Services directly from the browser seems unfounded (and a security risk to boot)

If nothing else, AJaX is creating a new generation of developers that will at least think about rich clients and how they interact with SOAs - this is good. Also, the visual side of AJaX helps to put a pretty face to the SOA name (guilt by association) - this is also good.

To finish off on a positive note, I think the biggest implication that AJaX has for SOA is that AJaX (and Web 2.0 in general) represents a vast improvement of client applications in terms of usability, which opens up new, uncharted territory for data manipulation and visualization on the client. This new territory will likely increase the amount and variance of data that web application developers will want; thus, developers will increasingly be faced with situations in which the only logical choice will be to access data through a SOA and to buy into the SOA way of doing things. If SOA gets buy in from the vocal and loveable AJaX crowd it could be a real shot in the arm for SOA as well as the implications that SOA has in store for the future. We are already seeing this trend with our AJaX based components on various platforms, which apparently are “ready for prime-time, white collar, Fortune 1000 usage” [3] as can be seen by our customers such as Time Warner, BMW, Bank of America, Goldman Sachs, and Siemens to name a few.

The question is will AJaX stagnate as purely an extension of current web development techniques or will it mature into it’s own “light” SOA for client side development or even better will browser vendors decide to build WS-* into the browsers of the future so that AJaX can play ball with the big boys?

[1] On Atlas/AJaX and SOA - Nick Malik
[2] SOA, AJAX and REST: The Software Industry Devolves into the Fashion Industry - Dare Obasanjo
[3] State of Ajax: Progress, Challenges, and Implications for SOAs - Dion Hinchcliffe
[4] Ajax: User Interface Pattern or SOA Dissemination Engine? - Dion Hinchcliffe
[5] AJAX, SOA, and FWCAR - Mohair Sam
[6] New Specification for SOA using AJAX = JAXASS - Titus
[7] Beating a Dead Horse: What’s a SOA Again? All About Service-Orientation… - Dion Hinchcliffe
[8] Revisiting the definitive SOA definition - SearchWebServices.com
[9] An Introduction to the OASIS Reference Model for Service Oriented Architecture (SOA) - Duane Nickull