--- In [email protected], "Mike Glendinning" <mi...@...> wrote: > > Michael/Udi, > > I hesitate to get involved when there appears to be several heavy > debates about semantics going on, but why this distinction > between "service" and "UI app(lication)"? I just don't get it!
There is a view on SO design where the UI application is not a service nor considered part of a service. Instead, the UI application is a service consumer. Krafzig, Banke and Slama support this view in "Enterprise SOA: Service Oriented Architecture Best Practices" using the category of "application frontend." They define this as: "Application frontends--although they are not services themselves-- are the active elements of a SOA. They initiate all business processes and ultimately receive their results. Typical examples of application frontends are GUIs or batch processes." > To me, what you call a "UI app" is just a "service" that is > consumed directly by a human rather than a machine. So what? I recall that a couple of folks here promoted the notion that the UI could be managed just like a programmatic interface. That a service has a UI as just another of its interfaces. The issue I have with that is how many UIs will/should a service have? If services are to be used in various contexts, how do we manage the (presumably) different UIs for each context? Will there always be a 1-to-1 between service operation and screen representation? Or will a "real" application sometimes have a single screen supported by multiple services? What is more effective: * Managing the UI as a service interface whereby one keeps the UI elements defined in a manner that they can be used in isolation (on their own screen) while also being easily combined with other UI eliments (shared screen with elements from other services)? Would the "shared screen" case prompt the creation of an aggregate service, the only interface of which is a combined UI screen? * Encompass UI aspects within an application that manages the presentation, using services behind the scenes for the heavy lifting of the business logic? With the talk of a service providing UI(s), multiple contracts, multiple interfaces, etc. it seems like we may try to have a service do too much. At what point does multiple interfaces (UI or otherwise) start to indicate that a service may need to be refactored? -Rob
