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. > > > > > > >
