Hitoshi- thanks for the input, but I did not miss the point.
I have never compared services with web services. As a matter of fact, if you read my interactions, you will notice that I am saying that "presentation services" that are recommended for gathering information are usually web services and do not really qualify as services. My question was really for fellow practitioners. Once you are in the midst of projects, you will find that you need to address some of these questions or else the overall "system" does not work. In my last post, I gave my method of dealing with this issue, and I have simply been asking others of how they handle similar situations. btw, I agree with your web services vs. services thing. As a matter of fact, 4 or 5 years ago, when "SOA" the term was not popular, I had suggested that web services are a great way for us to start thinking about business "services" (see "Webservices: an Elephant in the dark" http://searchwebservices.techtarget.com/originalContent/ 0,289142,sid26_gci861248,00.html) and even back in 2001 I was suggesting that we not use web services as APIs. --cheers Suhayl --- In [email protected], Hitoshi Ozawa <[EMAIL PROTECTED]> wrote: > > 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" <atmanes@> 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 <m3poulin@> 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 <suhayl.masud@>* 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. > > > >>> > >>> > >>> > > > > > > > > >
