What's Chrome Got to Do with SOA?


Sometimes, I feel a little bit sorry for myself, writing about integration.


I mean, integration is a kick in the pants, as we all know, but it's not exactly all new and shiny. So, I figured I wouldn't be able to write about Chrome -- Google's browser, which is brand spanking new. Ken-Hardin, a VP at IT Business Edge, got to review Chrome, and Lora Bentley dished about the Chrome open source buzz on her blog, Open for Business.


And of course, our Headline Watch bloggers gave a Chrome news roundup (they're always nabbing the cool stuff, darn them!). Even security blogger Carl Weinschenk joined the geek-out with a piece on Chrome's shiny new security problems.


I admit it. I was feeling pretty sorry for myself, trudging through, when I stumbled across this headline:

"Chrome Will Enhance SOA in the Enterprise."

Huh? How could something designed for online reading help with SOA?

David Linthicum started this discussion with his post on Chrome. He pointed out that the industry has long had a bigger dream for the browser. The dream is that one day, the browser would be used as a single user interface for delivering applications and, well, services.

Google's already tapped some of that potential with things like Google Documents. If I really wanted to, I could do everything I do on a daily basis through my browser without ever opening another application. I just don't want to ... yet.

From inception, Chrome was created to accommodate delivery of applications and Web services. But how does this translate into supporting SOA?

This is where it gets a bit fuzzy for the average reader, because there's no one article from the mainstream tech that's delved into the technology details. I asked Linthicum by e-mail, and he said it had to do with the memory protection features and AJAX enhancements for service utilization.

I'm not a techie, so I can't be sure, but I suspect the key here is Chrome's process manager. The process manager is what accounts for the better memory management, according to the blog, JK on the Run, and after reviewing the Google Chrome comic book's explanation of the process manager, I can see how that would make a huge difference in how Chrome would handle services, as opposed to, say, Firefox, which freezes up and crashes completely whenever one tab is hung up.

In fact, one ZDNet reader did cite the multi-threaded JavaScript and independent processing for the tabs as key supports for service deployment.

Linthicum felt it was a bit complicated for a blog post, but, judging from his InfoWorld blog on it and ZDNet's Joe McKendrick's take on the topic, the reasoning seems to go like this:

  • Chrome is built for the use of services, and Linthicum believes it's much better at this than your ordinary, evolved-from-content-delivery browsers.
  • Chrome is a better for delivering services than a traditional OS-based interface.
  • Therefore, Chrome is a better platform for mixing and matching applications, services and processes.
  • Thus, Chrome will make it easier for businesses to see services in action, whether they're internal or delivered via the Web.

In effect, he writes, "Services can be seen, thus understood, and 'sex on the screen' SOA-driven applications will wow 'em in the board room."


In a followup post, he clarified it this way:

"Chrome is not a savior for SOA/WOA. Its value is that it considers the use of Web delivered applications, and Web-delivered services, within the architecture of the browser. It's not an afterthought. This is a huge shift in thinking, and something that is desperately needed as we drive toward the use of services for applications and composites where the browser plays a key role. In essence, Chrome will become a valuable piece of the architectural puzzle, perhaps a missing piece."

Joe McKendrick added this explanation:

"But to look at it from an enterprise perspective, Chrome may help lay the groundwork for a smoother path to service oriented architecture as well. Dave Linthicum observes that Chrome is a great leap toward finally abstracting computing away from native operating systems. This is a good thing, and when it comes to both service orientation and Enterprise 2.0 computing -- which both rely on services delivered and consumed from the network -- the client operating system is now only something that gets in the way."

Of course, I probably don't have to tell you that this is not a universally shared view. All you have to do is dig into the comment sections of either post to see this.


Rob Eamon, one of my favorite readers and posters here at IT Business Edge, countered on ZDNet with this remark


"The tenuous tie between SOA and a specific browser would seem to muddy the waters as far as what SOA really is. Alas, the ship seems to have sailed and the days of treating SOA as a way of structuring an architecture instead of as being about specific technologies are long gone."

There are other questions, as well. Charles King, principal analyst at Pund-IT, questioned whether Chrome would even be relevant, given the fact that Google's effectively shut out of enterprises. King told NewsFactor Network that Chrome's "application capabilities means that it's an intriguing platform for the SOA service-delivery model," but theorized that SOA deployments may be too "enterprise-centric."


Another key factor in enterprise adoption will be how developers respond, King said.

"Chrome's success as a platform will come from grabbing developers' attention to create applications that require Chrome's application capabilities. If there are really compelling applications, that will drive adoption."

Could Chrome be the one UI to bring together services and on the browser bind them? I don't know. It'll be interesting to see what role, if any, it plays in SOA adoption.


Oh, and, by the way, happy 10th birthday, Google -- thanks for all the free tools.