404... your app no longer works

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

A groovy week on grails

So the Ruby on Rails people asked the group that started the "Groovy on Rails" effort to stop using the term "on Rails" (whatever). That is why they have the name Grails now. They didn't ask me and I have to say that this week of building a first end to end app for production use with Grails was quite groovy.

First, I do like the coding by convention approach that allows less code and less configuration to be used. I also like that what configuration is there is in the form of classes not XML. We made an app for the ANDRILL effort and it should see the light of day soon (ie be reviewed and deployed).

During the course of this development I was very impressed with how the various packages in Grails: Hibernate, Quartz, AJAX (via prototype in my case), Spring (obviously) and the GORM objection relation mapping all work. I am very keen to make up a Quartz job and then use the jabber resource to make a job that looks for changes or additions to the database and then IM's me. That is more for me, the real version would likely report via email.

We did run into some issues (Grails is only version .3 after all). An issue with binary uploads in a none scaffolded controller (I assume the generated static code is somehow out of sync with the dynamic scaffold generated code). Also had an issue with using the remotelink tag for AJAX calls vs using the remoteform tag for the same effect. We resolved this by just not using them :) but I need to report this to the Grails people to see if it is a known issue or something I was doing wrong. Getting used to the scope of certain classes and methods took some getting used to as well, but that is more just my ignorance with how the plumbing was working at the start of this effot.

Having full access to the all the wonderful Java classes makes Grails a no brain-er for me over Ruby on Rails. I have to admit I am a bit sad that Sun seems to be in love with Ruby (via jRuby which ironically is also a codehaus effort at http://jruby.codehaus.org) and pays little if any attention to Grails so far (hopefully this will change). Yes, though jRuby the Ruby syntax gets access to the classes as well. We will see how this all works out. I was interested to find that one of the key people in the Apache Geronimo effort is also one of the key Groovy people as well. Ruby has some very cool aspects to it, but I think the JVM is a better host for it than as a stand alone app directly on top of the OS.

In a final experiment (ref: InfoQ Grails + EJB and a Graeme Rocher blog entry) we used entity classes (not entity beans) that we generated via Netbeans for a database and dropped the POJO's into a grails app and were able to get read and write access to the db via the grails app using these entity classes as our domains with simple generated controllers and views. We had some issues with primary key mappings, but nothing too hard for us to work around. This was interesting to me since I could use the entity classes along with Hibernate to do the data access work and then Grails as an lightweight flexible dev layer on top of that. Grails lacks sophisticated buses like Service mix and others, but I am not certain I need or want those at this time (or that I can't do what I really want inside the Grails framework anyway).