It depends if the service is viewed as the technical service, in which case the UI isn't part of it. Or a business service which is providing capabilities to an end user, in which case the UI is part of it. Effectively the execution context changes between the two scenarios with a UI being one of the few ways for a person to interact with a computer.
Steve 2008/9/4 Gervas Douglas <[EMAIL PROTECTED]>: > --- In [email protected], "Rob Eamon" > > <[EMAIL PROTECTED]> 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. > > On the face of it this would seem logical in that a true human user > (not an engineer scanning code and URLs, for instance) would normally > go through a client via a User Interface as opposed to accessing the service > directly.... > > Gervas > >> >> -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...>> >> > >
