Interesting timing of your question Rob. I pose the blog entry Gervas
posted from me as a partial response to your question. However, I
would be careful about the statement "Services do not have UIs" as all
services have interfaces. I'll go so far as to say that a service
could have a human interface in addition to a UI. That said, I would
be careful to differentiate platform from architecture. To me Chrome
is the platform and SOA is the architecture that something running on
that platform might access. I will say David is very good selling to
the management audience who will eat up this type of messaging. We in
this group (I don't believe I've seen too many management types here)
can dispose of the rhetoric, but it seems to be digestible by the
community at large, as I stated in my blog entry.
JP
On Sep 4, 2008, at 12:55 PM, Rob Eamon wrote:
The following article is at:
http://weblog.infoworld.com/realworldsoa/archives/2008/09/google_chrom
e_a.html
I'm quite interested in the views of others on the role of a browser
in SOA. From my viewpoint, Linthicum is making quite a stretch in
terms of what matters in SOA. A browser isn't a service provider nor
a service client. It may be the client-side,run-time environment of a
web app, but it is the app that is the service client, not the
browser. Thus, how can a browser be "built for the use of services?"
I'm also interested in reactions to this statement (not from
Linthicum): Services do not have UIs.
-Rob
<<Google Chrome and SOA
The presence of Chrome will drive much SOA in the short term
There is so much coverage around Google Chrome by the mainstream
technology press that I typically don't pay much attention to these
kinds of "hype-y" things until there is a reason to pay attention. I
did download Chrome, installing it on the test machine in my office
to see what the fuss was about and how this would affect the world of
SOA/WOA. Folks, there is something to pay attention to here.
The reality is that traditional browsers, such as IE, were built from
the ground up for content surfing and not application deployment and
service utilization. IE put in several mechanisms to support more
rich features, however the architecture of that browser meant that
developers work around, not with IE.
I view the browser as really the next platform, something that will
allow you to access a multitude of rich Internet applications,
services, and have them work and play well together, no matter if
you're on a traditional desktop, phone, PDA, or a screen in your car.
Chrome seems to be a much larger leap in that direction, built from
the ground up to deal with Internet-delivered applications and Web
services, abstracting you away from the native operating system. At
least it seems that way from my initial testing.
So, what does this have to do with SOA? Everything. SOA, at its
essence, is the use of services as a way to deal with architecture.
We expose services that we have been dealing with for years (legacy),
we create new services, and we leverage services in the cloud that we
neither own nor host. Then, we're able to create business solutions
by mixing and matching services into processes and/or applications,
simply put.
Thus, having a browser that is built for the use of services,
Internet delivered or internal, using better operating and security
mechanisms, could revolutionize the way we look at SOA. Services can
be seen, thus understood, and "sex on the screen" SOA-driven
applications will wow 'em in the board room.
I've always said that most SOA going on out there is through the
mixing and matching of external Web-delivered services externalized
through mashups, really as a way to prove the concept and to sell SOA
internally. Now we have a better platform (browser) to do that.
In other words, the presence of Chrome will drive much SOA in the
short term; it looks like a much better tool for the job.
More details as I continue testing...>>
