A slight aside here but it is one of the wonderful things about technology in the way that we insist on re-inventing the wheel all the time.
Back in the late 80s and through the 90s I worked on "traditional" thick client systems and had just those horizontal skills that Udi is talking about (hell I've still got them, but my career has moved on). What is "impressive" is how much of the RIA stuff is just not learning from the work that was done (even using Thick Java clients) only 10 years ago and is baking in the same old mistakes. A couple of my favourites (and certainly a blog post I'll do soon) are the 1 UI per service concept, the fine grained interaction piece for a distributed UI/App and of course the continual work of WILI v KISS in the interface itself. GUIs are a special case of skills to do well, they are not graphic design skills they are HCI skills and the number of people who can do it well is bugger all (IME), but the number of people who can create a GUI is just as large as the number who could create a bad website. >From an SOA perspective I conceptually consider the UI to be a "Facade" (that word again) on the Services being provided to the user, or as a Virtual Service (my term) which provides the user with _their_ correct interaction model. For most non-trivial services the aggregation of information and process and the user interface will be an important part of the usability and can't be simply seen as a "one UI per service" approach. The UI should be based on the interaction model of the user, not on the interaction model of a system. Computers like massive 100% correct data interactions, people like incremental validated data interactions, etc, etc. Considering the UI is essential to the success of a service, or set of services, that is to be used by the user. With a Web client it is more reasonable to take a fragment/page approach with late integration but with a Rich interface that is (IMO) just a criminal wasted opportunity. So I guess what I'm ranting about is that the UIs take different approaches, a Web UI with its traditional page wait is one issue, a Web 2.0 with AJAX is another and a full RIA should be yet another level. Theoretically the AJAX UI could be in the later group but there is (to my mind) a clear break from where it becomes a better to use Web Page and a fulling caching etc RIA (and yes Google Gears could be part of that switch). My main gripe in this world is that as a user of the beloved XmForm Motif Widget it depresses me that in 2008 I don't have the layout managers that I had in 1993. 15 years of "progress" in IT gets me a slightly prettier default skin but less usability. RIA isn't trivial and most RIA of today would have been a crap thick client in the mid-90s. Steve 2009/1/26 Udi Dahan <[email protected]>: > Rich client UI requires a special set of skills. Same for web UI. Same for > working with a rules engine. Same for working with a DB. Etc. > > > > The horizontal technological layers by themselves have no connection to > business in any way. They are not services. > > > > The service is around them providing the business context for each. > > > > -- > > Udi Dahan - The Software Simplist > > > > From: [email protected] > [mailto:[email protected]] On Behalf Of > Michael Poulin > Sent: 25 January 2009 19:53 > To: [email protected] > Subject: Re: [service-orientated-architecture] Re: IBM's Carter on Selling > SOA to the CEO > > > > I totally agree with Mike. > > I can only guess that mentioned separation roots in significant differences > of required skills and programming practice applied for UI and non-UI > development. At the same time, logically, they work for the same consumer, a > human in this case. > > BTW, I have found another 'phenomenon' in RIA. The abbreviation talks about > Application while majority of attention is on Rich Internet user interface. > > - Michael > > > > ________________________________ > > From: Mike Glendinning <[email protected]> > To: [email protected] > Sent: Sunday, January 25, 2009 4:32:00 PM > Subject: [service-orientated-architecture] Re: IBM's Carter on Selling SOA > to the CEO > > Michael/Udi, > > I hesitate to get involved when there appears to be several heavy > debates about semantics going on, but why this distinction > between "service" and "UI app(lication) "? I just don't get it! > > To me, what you call a "UI app" is just a "service" that is consumed > directly by a human rather than a machine. So what? > > Such services still have an "interface", "contract" (what one might > call loosely the functional requirements) , "policy" (an awful term > but what seems to be used to represent non-functional requirements > an "implementation" and oh, a "real world effect". > > Why not manage (or "govern" - another awful term, yech!) these > aspects using the same approach and mechanisms as you use for all of > your other services? > > For me, what we used to call an "application" just becomes a > convenient way of packaging and delivering the infrastructure > required to implement one or more services. > > Whilst the functional requirements of services being consumed by > humans can differ markedly from those intended for machines, there is > considerable overlap and technologies like HTTP give us a reasonable > (although not perfect) way of handling the implementation of this > through the content negotiation mechanism. > > An interesting question remains as to the extent to which the > infrastructure supporting services should be completely aligned with > the services, that is share the same basic architecture. Whilst > there are doubtless cost savings to be achieved from shared > infrastructure, this does introduce the need to manage a separate > architecture and dependency graph which can conflict with those > defined for the services themselves. > > Regards, > > -Mike Glendinning. > > --- In service-orientated- architecture@ yahoogroups. com, Michael > Poulin <m3pou...@.. .> wrote: >> >> This very interesting post, Udi, especially because I take a > slightly opposite approach but get similar result: "In that sense, > the UI app doesn't call a service. Rather, the service has components > deployed in multiple places (including the UI app, the app server, > the DB, etc) that talk to each other, but this communication is > within the service boundary." >> >> My logic is simple: >> 1) user interface by itself does not make sense (like a "smile > without cat") >> 2) user interface is a reflection of one of following cases (or > their combination) : >> a) reflection of the business service's functionality that the > business service has decided to expose through particular UI >> b) reflection of a composition of business service UIs [see a)] >> c) reflection of the business operational process (user > journey), which may have its own UI as well as a combination with > business service UIs (portal) >> 3) user interface contributes only one generic quality - User > Experience Requirements - that may be applied to any business logic > exposed in the UI >> 4) business service/process may have multiple UIs for multiple > audiences and perspectives >> >> The problem with granularity or operations in the UI and business > service certainly calls for an intermediary; I formulated one of > possible solution in http://ajax. sys-con.com/ node/730632? page=0,2 by > representing a UI Collaboration/ Conciliation pattern (similar to > Erl's UI Mediator pattern but with different reasoning, targets and > capabilities, and published 3 months before his book). >> >> - Michael >> >> >> >> >> ____________ _________ _________ __ >> From: Udi Dahan <thesoftwaresimplis t...@...> >> To: service-orientated- architecture@ yahoogroups. com >> Sent: Saturday, January 24, 2009 7:58:32 PM >> Subject: RE: [service-orientated -architecture] Re: IBM's Carter on > Selling SOA to the CEO >> >> >> Re: "The UI app interacting with multiple, independent services to > do the work directed by a user." >> I take a slightly different view (don't I always). >> I consider the UI process to be a generic host able to host code > from services. A composite app, if you will, just without any code of > its own that deals with anything relating to the business. Any > business-related code running in that app belongs to a service, when > you take the development and logical deployment views. >> My definition of service here is that a service is not just > something that runs – rather, more of a "business service" which can > be looked at from multiple perspectives, including the team which > develops it, from an organizational perspective. The decision to run > this set of code in that process is taken by the service. >> In that sense, the UI app doesn't call a service. Rather, the > service has components deployed in multiple places (including the UI > app, the app server, the DB, etc) that talk to each other, but this > communication is within the service boundary. Communication between > services is primarily event-driven where the events represent > business-significan t occurrences like the acceptance of an order, > not a button click (when taken to the extreme). >> One of the reasons I find this model preferable is that there is > often a higher degree of coupling between one view in the UI app and > the mid-tier code it calls, than between one view and another in the > same UI app. It looks like there should be some explicit boundary > there. It looks like there should be some ownership. Enlarging the > definition of service to include the UI code like this decreases > cross-boundary coupling (UI->service) , and can make versioning > simpler now that there is clearer ownership. >> Does that make sense? >> -- >> Udi Dahan - The Software Simplist >> >> From:service- orientated- architecture@ yahoogroups. com > [mailto:service- orientated- architecture@ yahoogroups. com] On > Behalf Of Rob Eamon >> Sent: 14 January 2009 22:25 >> To: service-orientated- architecture@ yahoogroups. com >> Subject: [service-orientated -architecture] Re: IBM's Carter on > Selling SOA to the CEO >> >> --- In service-orientated- architecture@ yahoogroups. com, "Udi > Dahan" >> <thesoftwaresimplis t @...> wrote: >> > >> > In my view of business services, applications are NOT necessarily >> > replaced, but are a part of a business service. >> >> Sure, traditional applications may be used as part of a service >> implementation. >> >> > Some applications are problematic in that they contain >> > functionality under the responsibility of multiple business >> > services. Applications like "the portal", or "the database", >> > or "the ERP" often fall under that category. >> >> Sure. No confusion there. Even after an SO effort, there will >> potentially be "new" applications that aggregate multiple services >> into a cohesive whole to be used by users, would you agree? >> >> > While the refactoring effort may prove to be difficult, the >> > applications still continue to exist afterwards. >> >> We seem to agree here. Some apps will exist as service > implementation >> platforms. Other apps will be the front-ends of services. The UI > app >> interacting with multiple, independent services to do the work >> directed by a user. >> >> > Let's take a closer look at what complexity is. On the one hand, > we >> > have these apps which are likely to be monolithic big piles of > mud >> > with very high internal complexity. After performing the SO >> > approach, we may have more moving parts, yet each is better > defined >> > with much lower internal complexity than before. >> >> Sure. We despise the monoliths. Let's break them up. And reassemble >> things in new ways. And structure components such that reassembling >> in new ways is easier to do. >> >> Lower internal complexity would seem to be an assumption. >> >> > If we were to look at the average complexity of the before and >> > after, we see that it goes down substantially. There are many >> > metrics that can be used to prove that (cyclomatic complexity, > for >> > one), but the KPI we see improving is the time it takes to make a >> > change or add functionality to the ecosystem. >> >> Does anyone have anything other than anecdotal evidence of > complexity >> decreasing "substantially? " >> >> > Yes. That actually means that more people can work on more parts > at >> > the same time rolling out more business functionality faster. In >> > short, that's a good thing. >> >> That's one of the benefits of busting things up--and the pro that >> offsets the con of increased complexity. I see what you're saying-- >> but let's not gloss over the complexity aspect of more people > working >> on more parts at the same time. >> >> IMO, an increase in complexity is a given for an SO environment. > This >> increases the emphasis on the need for architectural discipline and >> good engineering and management practice. For example, instead of >> dealing with the version update of 1 application, we have to > consider >> multiple services. The impact of a change, which may in the past be >> isolated to a single application, now needs to consider all >> consumers, which may not be known (depending on management/tracking >> rigor). Changes to interfaces will now encompass versioning more >> often than as been done in the past. >> >> Keeping complexity and redundancy minimized are definitely > worthwhile >> goals. IMO, SO approaches *tend* to increase complexity so we need > to >> stay on top of it and manage it well. >> >> As always, just my 2 bits. >> >> -Rob >> No virus found in this incoming message. >> Checked by AVG - http://www.avg. com >> Version: 8.0.176 / Virus Database: 270.10.6/1891 - Release Date: > 13/01/2009 08:17 >> > > > > Internal Virus Database is out of date. > Checked by AVG - http://www.avg.com > Version: 8.0.176 / Virus Database: 270.10.7/1895 - Release Date: 15/01/2009 > 19:10 > > ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[email protected] mailto:[email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
