--- In [email protected], "Suhayl Masud" <[EMAIL PROTECTED]> wrote: > > [snip] > > I disagree that we should build 2 or 3 versions of the same > service. Bad idea. Keep in mind that data coupling increases when > the intelligence is shifted away from the service and into the > consumer by pushing out massive amounts of data, instead of > information or intelligence.
But they would not be the same service. They would be 2 or 3 new and different services. I think I asked before, but how does a consumer know the difference betweent "massive amounts of data" and "information and intelligence?" The service specifies what data is returned--so who can tell which is "intelligent data" and which is "just data?" > I also disagree that another service be built to provide the extra > information needed. There are lots of things the UI needs (I am > generalizing again), for example, it likes to show things in lists. > You cannot send *all* the information that would show in the list > (say a 1000 records), but you cannot build your service to do > pagination instead (not really a service anymore). This is just an > example I pulled of the top of my head, but you get the idea, the > UI is a different beast. Right. The UI isn't a service (nor a collection of services). It performs all the complex things it needs to do to provide the rich experience users need. Pagination is probably one of those things. > > So the question is a general query...how do you handle the GUI? > > How have I handled it? I have tightened the business service to do > the business function well, to be cohesive, and not tied to any > user interfaces. You can ask it an intelligent question and gives > you an intelligent response (does not push out raw data). Again, how does a client distinguish between these? What do you mean specifically by "intelligent question" and "intelligent response?" > For anything else the UI needs from that domain, and if it is not > related to the business task, it goes about it the traditional > way, getting it from the database via a middle layer (not a > service). Perhaps. But it certainly could use another service to get that data. Again, I must say that if the data is something the user needs to use the application to take the correct action in the UI, then it is part of the business task. > > I believe Anne has pointed out a similar situation in her comment. > > I like this group so far, there is intelligent interaction on it. > That's why I suggest that we examine the SOA and the GUI, and SOA > and reporting intelligently (I feel that reporting is another non- > SOA thing btw, that the needs of reporting cannot be met with SOA). A design guided by archtitectural principles, service-oriented or otherwise, will need to address the role and responsibilities of the UI or reporting tool. I agree that a UI will generally be guided more by other principles rather than by SOA principles. The UI generally will be guided by SOA principles as a service consumer, not as a service provider. A UI is not a "non-SOA thing." -Rob
