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/gmrs/yahoo_panel_invite.asp?a=7+>and lay it on us.
