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).

coding by convention vs prior convention

Been a while since I posted. I have still be doing some work with Grails and Java EE5. I completed out my test for UI's via AJAX as well but I thought I would put down some thoughts on coding by convention.

I am new to the Rails approach and I have to say I quite like it. The idea that the file system, file names and such carry meaning and that the framework uses these to look for things that might otherwise be designated in XML configuration files is quite nice.

Until of course you create a domain image. I created the domain image in Grails. This has the effect of telling Grails that any URL with /app/image in it should be processed by the controllers, services and such associated with that domain. Unfortunately this also means that img tags with src attributes that use /app/image in their path don't load images from a directory in that path, but that pass the request on to the domain controller.

It's a small point perhaps, but it does make me wonder what else I might run into. Domains with names like image, pdf or I am sure many other (conventional names) just might interfere with the convention of the framework.

Working on contrasting EE5 and Grails (Rails)

It has been a while since I did a post. I have been busy at work on some new architecture designs and intend to make a good entry contrasting Grails and Java EE5 efforts soon. However it has been a while and thought I would post up some errata thoughts I have had. It has been very interesting to see how the two efforts (Grails and EE5) deal with similar goals compared and contrasted to each other. Trying to do the same thing in two different frameworks has definitely made it easier to see how each is addressing needs. Of particular interest is comparing how grails deals with call backs from ajax widgets to server side logic compared to the Java Jmaki effort. I've got a longer post with my lessons from this that I am working on for a later date.

I must say I have come to really like closures. A programming concept I have not used much to this point. Groovy (which Grails is based on) does closures and I also found an interesting page on closures for Javascript. Ruby also obviously does this well.

I selected Grails over Ruby on Rails mostly due to the access I would have to the JVM combined with the Rails approach. Also since I was wanting to contrast against a pure EE5 approach this made more sense. By pure EE5 I mean an entity bean approach combined with JSF. With the hiring of Nutter and Enebo by Sun Microsystems, Jruby (another codehaus.org effort) could becoming an interesting option too since then "Ruby" will have access to the Java API's. It has that access now I believe, however I don't believe the Ruby and Rails aspect of Ruby is fully over to the JVM yet. I do like the coding by convention vs. the XML configuration approach however. I love XML, but think we have done too much with it in places where we could just use the coding language we have available. I definately will be looking at Ruby in general and the Ruby on Rails community more.

A very interesting interview is given by Tim Bray on InfoQ. It's a great listen for anyone interested in dynamic languages, RAILs concepts, ReST vs WS and some of the issues surrounding them.

AJAX and server side scripting

I ran across this page at the sun developer site. It has a very nice run down of various AJAX design strategies. (Ref: http://java.sun.com/developer/technicalArticles/J2EE/AJAX/DesignStrategies/?feed=JSC). This is a good read not just for Java developers but anyone. The principles in it apply toward the development of any architecture in any language implementing AJAX.

In reviewing this document I came across a project again that interested me and spent some time playing with it on our app server (glassfish this time). This is the Phobos project (Ref: https://phobos.dev.java.net/). It basically allows for the use of javascript (and later other scripting languages like hopefully Groovy) to be used on the server side. JSP and JSF use tags to embed Java code into pages that are rendered server side. Phobos extends this to javascript with the concept of "ejs" files which embed javascript into the page for server side rendering. The benefits to an AJAX implementation of javascript on both side are obvious. I do not know yet how well the server side javascript has access to the Java classes. Future integration with JMaki might also make future use of JMaki widgets in Phobos apps easy. How might one instance this into a remote domain though?

I am still curious if one could simply make a GET call to an app server that would render custom javascript in JSONP manner and return it to a script call of a page. In truth couldn't this be a servlet. A servlet responds to a GET call and can return just about anything. So one would seem to be able to make a servlet that returns JSONP. If the Phobos server could return JSON or JSONP as well as EJS rendered HTML that might open some interesting possibilities for remote access to widgets. This may be worth some investigation and comparison to some of our early GWT application experiments.

Why Portals Must Die

A few days back I read a couple articles on some efforts by Google. These were an article on Googles Gadet effort and Google /BEA mash up talks.

While interesting in their own right and likely the kind of thing being done by Yahoo, Microsoft and others it got me to thinking about a mantra I have had going for some time:

Portals must DIE.

This is not to say portals themselves in concept are bad things. Only that they are often used or implemented poorly. I oversee a JSR-168 based portal myself and direct development of applications under that. The intent of portals is obvious. It provides a development group a unified display and authentication API set, among others, to work with. This helps to focus development skill and look and feel issues. A great thing compared to developing against a myriad of API's. Of course portal API's themselves don't talk to each other so little was gained for efforts outside the local enterprise (or enterprise group). In the Java camp the JSR-168 helps to focus efforts around a common portlet spec and that is great. Web services for remote portlets (WSRP) might have been a wonderful thing had I ever seen one example of it in the wild.

It is just that portals don't allow for dynamic mixing of content from various sites into my own space. I can't easily (yet) pull maps from Google, stock tickers from Yahoo, search interfaces from 3rd party databases sites and simply drop them into my page and have them work with authentication and styles (CSS) resident there. I want to be able to do this, so portals must die.

I believe that the common HTML DOM or a CDF derived instance is the common glue (as I spoke about in my OpenDoc posting). Combine this with remote AJAX applications that have some capacity for awareness of secure federated identity and we begin to see the a portlet concept in this environment. Secure "inter-AJAX portlet" communication could be done via a messaging middle-ware though I want to explore what Javascript allows in terms of intercommunication between various functions in a web page to see if that is possible. Look and feel issues could be addressed through systematic CSS utilization. In a manner similar to GWT.

To me the future portal is a simple DOM with portable code that can be pulled across the net to create its UI through local DOM object manipulation. Combine this with federated identity and CSS based styling for logging in and look and feel issues respectively. Let the whole thing talk to a services oriented architecture for logic execution. Hopefully the efforts of the W3C Rich Web Clients efforts will go well.

.NET 3.0 an attack on standards?

So I read my first article on .Net 3.0 this morning over at informit.com. I then headed out to the Netfx3 site and did a little reading on the Communication, Presentation, Workflow and Cardspace foundation that are part of .Net 3.0.

Microsoft has obviously turned their back on standards like Web services, SVG, efforts like SAML, WS-Federation and the Liberty Alliance. I am sure they have done in this in the name of "user experience". However, this will be user experience only on Microsoft Windows.

Do I trust that things like WPF/E (the "Everywhere" cross platform version of WPF) will be coded to, made easy to code to, be used at all by many developers? Of course not, Microsoft has no interest in doing that. As a company they have fostered a culture based around ignoring standards and ignoring where the network is going. Even as powerful as they are, I have no doubt they will fail, but they have the potential to cause huge amounts of damage to peoples data along the way.

The core interconnecting standards of the net are under attack. Microsoft will use its influence, FUD and any other tactics to encourage this. Then they will wrap themselves in the flag of "competition is the cornerstone of capitalism" implying that they are the moral high ground holders.

It is obvious that Vista and .NET 3.0 will bring the most concerted effort yet by Microsoft to undermine Internet standards and cross platform environments.

CDF + Google gadgets = OpenDoc ?

So recently Google was noted for putting out "gadgets" that could be syndicated across the network (ref: Cnet ). The direct link to this being at: http://www.google.com/ig/directory?synd=open/.

This is basically javascript that you can instance in your own web page. There is nothing spectacular about this. However, Google has done a nice job of making it easy (easier) to do this. I am a big supporter of this syndication concept even though there are likely several issues still with this idea especially around security. (One Ref at Greg Murrays Blog)

Now combine this with something like the W3C CDF efforts. CDF allows a developer to place multiple XML formats into a common document.

The collision of all this reminds me of something from Apple from way back. Those that know me know I still haven't gotten over OpenDoc. systems could begin to However, CDF + remote web apps like AJAX Esqdevelop the kind of application that currently is still restricted to the true rich client applications. I don't know where web based applications will stop in terms of being reasonable approaches. Email, RSS aggregation, content management and many other types of communication based efforts have done very well on the browser platform. Lately word processing, spreadsheets and other attempts have started to crop up. I doubt we will see an AJAX based GIMP (or ever want one). For the most part, if I am working on data or creating data local like in a GIMP image there is no need to send that over a network. However, Writely has shown that even word processing can benefit from network aware ability, in its case in the form of real time collaborative editing of documents. (Apple Knowledge Navigator)

Imagine though a document with a SVG canvas being written to by an embedded ajax application communicating over XmlHttpProxy and then locally updating the SVG canvas through inter DOM communication. How about an OpenGL canvas? (Java 3d and applets is perhaps a bit of a digression for this posting, but not much).

I am encouraged and interested by where an open format, open standards based approach will go that mixes interactive applications with the DOM and graphics languages like SVG and perhaps even OpenGL.

It's about the data

I have been trying to figure out what would make me happy. I don't like the net as it is today, it feels to ethereal. Like anything I make, a blog post, a OPML file anything is just going to end up like some old 9 track tape I find some day and can't read or use.

Yea, I could download this stuff and store it somewhere (I do) but must I? Should I? I find that while I have my dug articles from Digg, how many of these links will be there in a year? I'd rather just cut and past them into a personal store. Like the scrapbook firefox extension which I love.

I some ways I would like to see it combined with something like the Simile Piggy / Semantic bank efforts. Perhaps those are what I like and I am just not using them enough yet. At least they are using standards I philosophically agree with like RDF and XHTML and such.

Lately I have been listening about Jini on the Javapossee podcasts and been wondering about how it could be used in data grids vs. the compute grids it seems focused on now.

Now if I could just figure out a portal/dashboard approach I like I would be set. Wonder if KDE's plasma effort will have an easily extensible UI apsect to it ala kramaba (sp) that will make it the wonder desktop. I like the concept of the containers I see so far in it. What I need is a tag based files systems (who needs folders?) and a tagged based UI to go with it. :)

Firefox Application Framework

For some time I have watched the XUL effort at Mozilla. It is interesting as more and more people talk about the creation of "rich apps" (network centric apps.. whatever) to watch various approaches rise to the top. The strong efforts by the eclipse and netbeans camps to form their solutions about their respective architectures is great. There is also the efforts by M$ and their XAML goals eventually. I don't really think XAML is all that "Internet" when you have to run it on a windows machine though.

However, I have been interested to see that XUL, which I felt was only going to be a solution for Mozilla's own apps like firefox, thunderbird and sunbird, gain some traction in the community. The Songbird (http://www.songbird.org) effort is likely the one with the highest visibility, but Democracy TV (http://www.getdemocracy.com/) is also popular. I recently saw on a on-line episide of Command N where they talked about Cletx (http://www.celtx.com) which I guess is also based on XUL. They say it's a firefox app, but I assume the meant XUL.

It would be nice if we had a true XML UI language (yes, perhaps XML is a bad method to represent UI's ... that is another topic) that was a standard. Not that M$ would bother to support it but XUL can't claim to be a standard yet for anything but Mozilla apps.

There are tons of XML UI languages for the Java VM true, but I am not sure they leverage well of the developer community till they get some kinda of buy in from Sun itself. Perhaps with AJAX there is no need. Javascript + DOM + XHTML and go from there, but you loose some of the spiffyness of a true UI (widgets and all). I haven't seen SVG care much for doing it and I refuse to go the flash route.

So I don't know.. if you want to make a true Internet application I guess there is not set of standards to work with other than AJAX approaches.

Web 2.0 semita (footprint)

So I am trying to figure out what my "Web 2.0" footprint looks like and how this compares to my personal computer footprint. The core elements of my web footprint are: (beyond this blog):
Del.icio.us (http://del.icio.us/fils), Odeo (http://odeo.com/profile/Fils), Tag cloud and Blog lines (don't much care for Blog lines for RSS reading)

I have found I don't care for any on-line RSS tools. Prefering instead my Liferea on Linux, though obviously it is my OPML file that is the most important to me.

For news I see I use: Slashdot, Digg, Newsvine, Last.fm for music and Boxxet (the later more interesting in concept than useful in execution) . For all I have accounts and I should resolve out the URL's for them and get them posted here.

I find tools like Writely and box.net to be rather nice and I have started to use them some.

Why do this

So I am not sure why I just did this. I am not really much of a blogger (at least I don't think I am). However, I have started to try and figure out what it is about web 2.0 that bugs me... so I have to do it to resolve why.