How many more buzz words could I get into to the title? Been a while with Christmas this month, but there is something I have been meaning to think/write about. Google says it will do no evil. So why then am I some what concerned when I see things like the news at: http://code.google.com/apis/soapsearch/. While I might not be surprised to see the SOAP end point go away, replaced by a ReST end point, I am a bit shocked to see an AJAX replacement.
This Google search box is definitely exactly what I have been working with myself (and many others). The ability to place a software component directly into a remote DOM. It is also very analogous to the OpenDoc approach I have been advocating for sometime.
However, an AJAX component is not a service. It is not something that I can invoke like a SOAP or ReST end point. Obviously (I think) that a dissection of what is occurring with Google Search AJAX component would reveal a ReST based response system, likely returning XML or most likely JSON(P). However that doesn't mean that the average user will be able to use it or even access that ReST end point (if it is there).
This whole issue with services is interesting. A development group might say they are going to create all their service components as open ReST or SOAP end points. For them to then eat their own dog food is important. That is they should use what they offer others. However, this can have issues like performance and scaling factors. These are issues that might be avoided in a group just used native environment services like (for Java) RMI, Jini, beans, EJB, etc. The lure of SOAP and ReST is that others can use them regardless of platform. However, we don't have an environment right now where many service consumers rely on or trust remote data services to build web apps on. Aggregated RSS/ATOM feeds don't count as a service.
In fact, most groups create and use their own services to build their final value added result, not for others. In that case however, the argument for SOAP or ReST is even harder to make. Indeed that very argument favors the use of components in the primary language(s) of the development group.
Yes, the argument can be made that in the case of Google, driving or presenting the brand is more important from a business POV than "doing good" by giving out a SOAP (or ReST) end point for people to use with potentially no reference to Google at all. However, I am not going to dwell on the business model aspect of this action in this post (perhaps tangentially I will).
No the real wonder I have is since there is no real market for services, will the SOAP and ReST efforts just wither and die for now? Until a need (a want) for the ability for sites like Slashdot and Digg, or TV listing sites or Mac rumors sites or whatever to actually work together for the benefit of each other (and as a result the users) we wont see much need for services. This is unlikely to occur in our current environment where the business model for sites is to get readership and eye balls across adds or to the fewer "pay for premium access" sites. It may occure in other groups less driven by economics and more by altruistic endeavours like science, social good, etc. Even then though, how many groups are willing to risk the operations of their web app on the existence and reliability of services provided by completely autonomous groups?
Had UDDI or any other directory service actually succeeded in gaining use perhaps some of this might have been avoided (perhaps... not likely though). However, that didn't happen. I am curious about an approach that involves more server side logic where an "agent" like application downloads logic and data into a local cache. From there execution of local code can produce results based on the remote logic and data. This has many issues though since many disciplines have so much data that transferring the all the data is not feasible (or logical).
Don't get me wrong. Services are not dead and things like SOAP and ReST may find more affection from things like mobile devices, web aware game consoles (for things like Wii weather) or the recent Google / NASA efforts that might show up in Google Earth than they might from server farm based efforts.
Additionally, ReST based service end point information embedded into a page perhaps via some microformat syntax might be interesting if more value added browsers (rich internet apps (RIA)) like Songbird become more popular. In that example a web site devoted to music might inform a browser like Songbird about its local offering via ReST end points rather than Songbird scrapping the sites content and page DOMs.
Perhaps services are just waiting for that killer app (RIA or agent) to come along and actually make people want all this.
Ref:
http://developers.slashdot.org/developers/06/12/20/0155238.shtml
No comments:
Post a Comment