I would agree with you, Jafar. However, I am looking at the business service as at full end-to-end multi-layered entity which can/may have its own UI (among other interfaces for different communication channels) reflecting its business functionality. Such view on business service breaks traditional overall layered *picture* while preserves the same layered structure inside the service. I think, this is the style of MDA.
As of relationship between UI and SOA, I described my view on this topic in the article "Resolving RIA-SOA Conflict" that to be published in AJAXWorld Magazine this month. About "We need a user friendly UI that can't abstract a separated as Services at the backend": how do you think where the UI comes from? Yes, UI is not a business service but it is the business service face, made by the same business service model but only with a make-up based on the User Experience requirements. The major differences of UI, as a service interface, from other interfaces are: 1) granularity 2) consumers that work with the service via this type of interface are outside of technical environment/system. This allows intensive and deliberate interface changes with not consequences to the rest of the technical environment/system. I need some additional information to understand your question about management of the business process changes with relationship to UI. - Michael ----- Original Message ---- From: jmortazavian <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, September 11, 2008 1:16:19 PM Subject: [service-orientated-architecture] SOA and User Interface layer Hi, I am very interested to speak about the dependencies between UI and Services in SOA view. How can we abstract UI portions like service functionality boundaries? I think that these are not depending together and we can't satisfy SOA principals at the UI layer. We need a user friendly UI that can't abstract a separated as Services at the backend. If so, then how can we mange business process changes? Jafar
