Good points you've made. Just want to ask a question to help me clarify. Should a service always have "textual description" as well as the "code". For example, should a service always send employee name and product name as well as an employee number or a product code. Or should a presentation layer fetch the names based on the code. The second question is suppose if there was a M&A and one of the backend system is to be phased out. Let say services offered by both companies are similar but not completely the same. Furthermore, let say they both customized some applications. How should we combine the services and modify the UIs. What would be the benefit of using "services" in this circumstance.
H.Ozawa Michael Poulin 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 > and lay it on us. >
