Udi, in my model, each service includes those "horizontal technological layers" (as well as operational manual activities if needed).
Does this mean that "The service is around them providing the business context for each" or we can represent more transparent and structural view if we say that "horizontal technological layers" comprise corresponding "horizontal technological layers" of the services/processes, plus, the data persistent layer? Otherwise, does it make sense having a "horizontal technological layer" without a "business context"? - Michael ________________________________ From: Udi Dahan <[email protected]> To: [email protected] Sent: Monday, January 26, 2009 7:36:19 AM Subject: RE: [service-orientated-architecture] Re: IBM's Carter on Selling SOA to the CEO 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:service-orientated- architecture@ yahoogroups. com [mailto:service- orientated- architecture@ yahoogroups. com] On Behalf Of Michael Poulin Sent: 25 January 2009 19:53 To: service-orientated- architecture@ yahoogroups. com 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 <mi...@dulciana. com> To: service-orientated- architecture@ yahoogroups. com 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
