This post originated from an RSS feed registered with Java Buzz by Michael Cote. Original Post: Ajax Middleware from PeopleOverProcess.com Feed Title: Cote's Weblog: Coding, Austin, etc. Feed URL: https://cote.io/feed/ Feed Description: Using Java to get to the ideal state. Latest Java Buzz Posts Latest Java Buzz Posts by Michael Cote Latest Posts From Cote's Weblog: Coding, Austin, etc.

By seeming coincidence I’ve encountered the concept of “Ajax middleware” three times this week, and once back in December when James and I talked with Nexaweb.

?!

The term “Ajax middleware” is really just a working phrase. Essentially, the idea is rolls up all the code and sub-systems from browser to back-end that perform classic middleware functionality:

• Allowing different parts of the system to “physically” talk with each other, for example, by providing a messaging or event’ing bus from the browser all the way to the back-end
• Integrating with 3rd party data (read) and workflow (write) stores
• Transforming said data and workflow as needed (usually with some semantic mapping)
• Data formats and data types that allow different parts of the system to talk to, understand, discover (or use at runtime without further training/configuring by humans), and work with each other
• All the administration, security, and enterprisey things that “back ends” do like administering users, limiting what those users can access, and creating audit trails for what users do.

“Didn’t CICS do that?”

All of these things are “The Same Old Shit” as we’ve seen in systems since the epoch. The point is more that a new island of software — the technological world that runs Web 2.0 — is increasingly coming to these Tried and True systems, if not the problems that lead to them.

Of course, for those of us who relish seeing improvement and evolution, the hope is that this island will bring the core principals of simplicity and coolness to the problem, where the past incumbents (J2EE and other enterprisey heavy-weights) approached the problem set with core principals of stability and reliability. That’s not to say either contender ignores each others principals, but that the guiding ideas that you start with end up influencing your system more than the ones you finish with.

The Glass Bus

This morning while Anne and I were talking with several IBM folks about QEDwiki, one interesting term that came up was “the glass bus.” Here, the idea is that all of the widgets (components, portlets, plugins, modules, or what have you) need some manner of communicating beyond DOM hacking.

While DOM hacking may be fine and dandy if the system is kept simple enough and said hackers are skilled enough, it does require a human, namely, the hacker. Further, the sort of mashing together that you’d like to see users start to do won’t work out so well if DOM hacking is required: hence the term “users.” While I’d like to see the web app users of the world skilled in futzing around with the raw goods of a web page, I don’t think it’ll happen anytime soon.

Thus, instead, you need:

• the data types and semantic standards to allow widgets to work together
• a way for those widgets to communicate with each other in the browser: a glass bus

Glass, of course, because it’s on the “screen” (or client) rather than on the server.

Blowing Glass Buses

So far I’ve seen a glass bus — or something akin to it — in several Ajax middleware stacks: The Frontside’s Freestyle framework, Nexaweb, JackBe’s Presto, and QEDwiki. Other frameworks that I haven’t looked at or am forgetting, no doubt, have a glass bus as well.

To my standard bigot’ed mind, what’s called for here is to standardize on, if not an implementation of, a glass bus. At the very least a specification of some sort is needed. Groups like OpenAjax might be a nice body to take care of that (indeed, they may already be doing so), or at least verify the validity, or lack there of, of the idea.

The benefit of getting a glass bus spec is allowing widget authors to code to that spec rather than any given framework. Certainly, it’s the same old component/JavaBean/J2EE dream. Which isn’t to dismiss the idea at all: open source frameworks and in-house code have done well writing to and using component specs. Even though the JavaBean/EJB marketplace of mid-90’s dreams never emerged, we forget how much “free” value we got from the core ideas of those component-oriented specs.

When it comes to the UI, I’m not sure we’ve been as successful, but why not have a go in Web 2.0 land? Again, the different starting principals of Web 2.0 folks might be a boon for avoiding the unsuccessful attempts of the past.

If successful, we might actually get those widgets that know your time zone without you telling them. That is, software that does the right thing without you rubbing its nose in the steaming pile of righteousness.

Transfers to the Back-end Bus

The glass buses I’ve seen typically can make the jump between glass and the back-end, which is where much of the value in those systems comes from in large part (check out the second half of this podcast for a discussion of how The Frontside does it). Now, I wager that we’ll see people fall into the same “abstracting away the network” traps that coders always fall in to, but once they re-learn those lesson, the benefits will be large.

As a long-term road-map item, I suspect people like Mule Source and other ESBs would do well to keep their eye on integrating with glass buses and helping avoid the usual pitfalls of such endeavors.

Beyond Map Mashups

I’ve complained before that map mashups are all that we see in the Web 2.0 world. To be fair, of late there’s been progress with IM and SMS mashups (like Twitter and mon.itor.us), but maps are the established cliché. Also, as one of the IBM’ers on the QEDwiki call commented, people understand maps so they’re a natural choice for initial applications.

As Anne and I were watching the QEDwiki demo this morning, I got to thinking that this maps cliché is probably a technical side-effect as well: maps are just about the only type of rich data type available on the public web at the moment. That is, whether you’re going with Yahoo! or Google maps, their APIs are open and well defined enough semantically that you can actually do something fun and interesting with them.

There aren’t that many other Ajax-enabled data types waiting out there to be manipulated as easily as maps.

Now, savvy coders have created bridges and adaptors between ERP and behind-the-firewall systems. I’d like to see more vendors going full-bore on these approaches rather than having them in the “research” arms of development. It’s why we get so excited over seemingly boring things like layering Ruby on-top of ABAP.

If I’d have told you that there was something awesome to do with all that geo-location data five years ago you’d probably have told me I was talking boring too. All of those green-screen silos of data have magnificent potential as Ajax middleware datatypes. The hope is that taking previously boring data and workflow into a new context and adding in new data will result in exciting new software.

Microformats

As always, I cheerlead microformats as a large part of that bag of something new. To wit: the just released Dishola.com encodes all of it’s reviews in the hReview microformat.

You can imagine that someone like Jay could arrange taking all of those dishes and mashing them up with Sabre’s piles of “boring” backend data to do something knock-your-socks-off cool with them during the next Sabre hackday.

The Simple “Tool” for SOA Ails

Another interesting aspect of the Ajax middleware stacks I’ve seen is that they treat SOA’s as a back-end source to pull from. JackBe went into the most depth of the people we talked with about doing things like pulling in WSDLs and facing them with (hopefully) simpler interfaces for the Ajax and other light weight models.

For SOA cynics like myself, what’s nice here is getting back to the notion of treating a Web Service/SOAP thingy as simply another data and workflow source to draw from and interact with rather than an ends to itself. In that sense, once again, ESB stacks are somewhat philosophically aligned with Ajax middleware: I am in ur enterprize opning up ur datars.

For the first time in a while I got excited about SOA beyond slide-ware pitches and the resulting code-monkey hassle while looking at these Ajax middleware stacks.

Disclaimer: IBM and Mule Source are clients. Charles Lowell, founder and CEO of The Frontside is a good friend of mine and long time podcasting buddy.

Technorati Tags: ajax, middleware, mulesource, esb, jackbe, qedwiki, ibm, soa, microformats, dishola, sabre, mashups, openajax, thefrontside, nexaweb, j2ee