Suhayl, I think you missed the point.I think you're mixing "service" with "web service".
It's not the just the matter with GUI. If we create a service that can be used by other applications (e.g. GUI, HRM, payroll), does a service need an interface that satisfies all these other applications? Let's reword your question. A service is defined based on a model of a particular domain. How can we used it in a different domain? Can we used it in a different context? I don't want to put words in your mouth, but I don't think these are the questions you really want to ask. The question I think you're really more interested is, how we can model domains and defined services that can be used in multiple domains. H.Ozawa Suhayl Masud wrote: > Michael and Anne, > > Thanks for your input as well. Also I agree with most of what > Michael has written. I must agree that the "example" I put up is > vague. > > In my crude example, we have a service for a particular domain, it > satisfies the business process needs of that domain perfectly. > However, different GUIs access this service and have valid needs to > show more information than the service should rightfully provide. > What type of information you ask? All types of information that is > not the realm of the business service. > > 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. > > 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. > > 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). 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). > > 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). > > Disclosure: well I am an independent consultant and really biased > towards any products. My architectural bias is a bit more towards > standardized partner to partner interactions as I have worked > extensively with RosettaNet and ebXML in the past. > > --cheers > Suhayl > > > > --- In [email protected], "Anne Thomas > Manes" <[EMAIL PROTECTED]> wrote: > >> For the most part I agree with Michael, here, but I wanted to add >> > one more > >> thought to the discussion, and that is the distinction between >> > application > >> and service. >> >> Why is it that Suhayl is working on the assumption that a UI (an >> application) can retrieve data from one and only one service? Or >> > that all > >> information displayed in the UI must in fact come from a service? >> > A common > >> feature of an application is that it pulls information from >> > multiple > >> services or multiple data sources. If a service supports the needs >> > of a > >> number of applications, it seems inappropriate to bloat the >> > service with > >> additional information just to support a single application. >> > Either build a > >> composite service to support the individual application's >> > requirements, or > >> simply implement the appropriate code in the application to >> > retrieve the > >> additional data required. >> >> Here's an important point that many folks often miss in their >> > exuberance to > >> adopt SOA: not everything needs to be a service. Things that are >> application-specific should be implemented in the application. >> >> Anne >> >> On 7/1/07, Michael Poulin <[EMAIL PROTECTED]> wrote: >> >>> Hey guys! >>> I know I am late to this stream but still would like to add my >>> > 1p. to it. > >>> I have not read all messages but guessed there are two major >>> > flows in the > >>> discussion (based on what I read): 1) how to design a solution >>> > for exact > >>> task set by Suhayl Masud; 2) concerns that there is not >>> > everything OK with > >>> the task itself (Gregg Wonderly) >>> >>> So, instead of 'how' I usually start with the question 'why'. 1) >>> > Why UI > >>> got disconnected from the service in given example? 2) Why >>> > particular UI > >>> asks for more data than service provides? 3) Why the service >>> > dare to hate > >>> "to modify the perfectly good business service" for this domain? >>> >>> I have several answers: >>> 1) the business analysis of the case is absent. Also, technical >>> > solution > >>> design is absent. The task is formulated in silo, w/o business >>> > and > >>> executable context. As usual, one tries to set the cart before >>> > the horse - > >>> SOA service is client-centric methodology: if the service cannot >>> > meet the > >>> requirements, it is fired. Period. >>> >>> 2) I see a possibility of mistaken UI design for given domain. >>> > Since UI > >>> must reflect not a user wishes but the business service >>> > interface, the data > >>> in the interface has to be adequate to the business service. A >>> > necessity > >>> for more data may mean that the UI tries to a) cross the business >>> domain/function/service; b) user experience (embedded into the >>> > UI) extends > >>> (but rather narrows) business interface which might not be >>> > acceptable from > >>> the overall business model perspective >>> >>> 3) perfect business service, even in the same domain, may not >>> > necessary > >>> cover all customer needs. That is, this service is not enough >>> > and new > >>> service is needed. Another case, the "perfect business service" >>> > is not that > >>> perfect after all: since the case of just data set variation in >>> > the service > >>> return, a document/literal service style can accommodate such >>> > change > >>> extremly easy. So, the problem here is not in technology but in >>> > the human > >>> factor (that One who does not want to modify the service). That >>> > is, you have > >>> to look for managerial means to 'convince' that One to do the >>> > job. If the > >>> service is perfect RPC style - this is the very case to >>> > demonstrate the > >>> service has to be retired right away because it is perfectly bad >>> > service, > >>> especially as a business service. >>> >>> I also deal a lot with 'presentational services'. They reflect >>> > business > >>> interfaces of the business services and never crosses the >>> > business service > >>> boundaries. The 'presentational services' usually represent sub- >>> > sets of the > >>> business service data model. If the UI requires extended set of >>> > data (wider > >>> than the business service data model defines), it is a clear >>> > signal for a > >>> service composition of several services. Otherwise, the service >>> > must handle > >>> any data combinations based on its business service data model >>> > with minimal > >>> data format (Schema) modifications (represented as service >>> > versions). > >>> - Michael >>> >>> >>> >>> *Suhayl Masud <[EMAIL PROTECTED]>* wrote: >>> >>> I am curious to find out how fellow SOA practitioners are >>> > handling > >>> the GUI in the SOA world. >>> >>> The GUI is an interesting beast in SOA (and so is "reporting" for >>> that matter). GUIs require customized information, tailored to >>> particular screens. Now you can format information for the >>> > screen on > >>> the presentation layer in the GUI, but what if the UI needs >>> more/different information than the service provides? >>> >>> To offer a crude hypothetical: consider a service that requires >>> > 10 > >>> items in an order to process that order in a specific domain, but >>> the user interface requires 15 information items from the same >>> domain. Now, one hates to modify the perfectly good business >>> > service > >>> specifically to satisfy the needs of one UI. I have seen the >>> solutions of "presentation services", and have built a few >>> myself....frankly; they don't really look much like services >>> > [they > >>> resemble pure old application APIs over SOAP http). >>> >>> So, fellow practitioners, how have you handled the requirements >>> > of > >>> an information rich user interface in your environments? >>> >>> -Regards >>> Suhayl Masud >>> http://www.linkedin.com/in/smasud >>> >>> >>> ------------------------------ >>> Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s >>> > user > > panel<http://us.rd.yahoo.com/evt=48516/*http://surveylink.yahoo.com/g > mrs/yahoo_panel_invite.asp?a=7+>and lay it on us. > >>> >>> >>> > > > >
