A wide accepted epistemological thesis is the theoretical simplicity. Of the two theories equally well to the same domain, the simpler one is to be preferred not only for the beauty and convenience but also for the argument of having larger predictive power. Simplicity principle has to be complemented with fragmentation principle. The central problem of philosophical method is not so much the categorization of any domain but the categorization of maximal domain of observation. Fragmentation helps us in judging the maximal domain where simplicity principle is applied and informs us what observation is relevant and what is not for theory selection. Given the maximal domain of observation from fragmentation, simplicity suggests what theory is relevant and what is not. If an observation derived from fragmentation for theory formation is too complex and cannot be simplified by systematization, the complicating observation will have to be deleted and classified as irrelevant since we would not be able to apply the simplicity principle. If a theory selected from simplicity can be expanded in economical manner, we would have to expand the domain of observation to its maximal while the simplicity principle is maintained.
I think that seeing everything as services violates fragmentation principle and complicates observation. A service encapulates a business/IT function that serves a purpose of the consumer. Only organisms, not machines, are purposeful. Security is a facility and is not purpose related hence is not a service. It only casts constraints to the delivery of the service. Security is one of many facilities managed by the service container. Another violating fragmentation principle is treating messaging hub as a service. To be qualified as a service it must have an architecture consistent to all services, or arcthiecture standards that include a service container, invocation and management framework, service descriptions (end point), mapping (endpoint interface), and service implementation. A service container provides a variety of facilities that a service implementation may have at its disposal: service invocation, development configuration, iterary management, thread management, asynch dispatch, QoS, Life cycle management, Correlation, Security, Connenction, Transaction, and Auditing/tracking. A messaging hub is not a service because, services communicate to other services through messaging hub that is a bus. Jerry --- Todd Biske <[EMAIL PROTECTED]> wrote: > Great point Michael. One of the things I usually > point out is that > you have to consider things from a consumer's > perspective. Security > is a great example. From the point of view of a > business service > consumer, for example, an ordering service, security > is an implied > capability. It's not a service that the business > consumer is > explicitly requesting. From the perspective of a > web service > intermediary or an application server, security may > very well be a > service. How many products integrate with a > security management > solution like SiteMinder where the products acts as > the enforcement > point and makes a call to the security management > solution saying, "I > see a request for this item from this identity. > Should I let it > through?" This is an explicit call, and arguably a > service, but only > from the perspective of the app server or > intermediary, not from the > business service consumer. > > Services do need to be designed with consumers in > mind. Some > services may have a broad set of consumers, others > may be quite > narrow. Designing with no consumers in mind- > taking a build it and > they will come attitude- is not a good practice. I > just listened to > an IT Conversations Technometria podcast with John > Wait from Pearson > Technology Group, and Phil Windley asked him for > advice to new > authors. He said that one thing he always sees is > that the authors > don't target a particular audience. They try to > cover too broad of a > range, and usually go through several editing > sessions to nail down a > particular target. I think the same thing holds > true with service > design. I'd rather see a service that does one > thing very well for a > well-defined set of consumers than a service that > does things in a so- > so fashion for a broad set of consumers. > > -tb > > On Apr 3, 2007, at 6:03 AM, Michael Poulin wrote: > > > I would say that "security infrastructure" is a > "utility " service. > > Security is very much the service in spite of the > question it > > answers. BTW, before getting into discussion at > this level, we have > > to define the subjects: service, utility, etc. > > > > For example, can you say looking at an interface > if its a service, > > or an utility, or a function (C/Fortran, etc.) > sits behind it? > > > > Plus, security includes such things like > confidentiality, > > integrity, non-repudiation that do not relate to > the concerns > > mentioned in the Bill's message. > > > > - Michael > > > > Bill Barr <[EMAIL PROTECTED]> wrote: > > Now we get to the hard part, which is addressing > the differences > > between secure software and security > infrastructure. I believe your > > question is referring only to the latter. Security > infrastructure > > is a utility and not really a service. All the > service is concerned > > about are answers to the questions: does this > requester have valid > > credentials and if so, how do those credentials > translate into a > > role I understand so can fulfill the request? > Getting the request > > to the service in the first place is a job for > "facilities". > > > > -- > > email: [EMAIL PROTECTED] > > > > > > From: > [email protected] > > > [mailto:[EMAIL PROTECTED] > On Behalf > > Of Steve Jones > > Sent: Friday, March 30, 2007 9:34 AM > > To: > [email protected] > > Subject: Re: [service-orientated-architecture] ESB > Standard > > Definition - SOA capabilities and its > categorization > > > > How would you see security being done between > various 3rd party > > services? > > > > > > On 30 Mar 2007 08:34:25 -0700, Bill Barr < > [EMAIL PROTECTED]> wrote: > > Security is best left as an aspect embedded into > the design of any > > specific SOA. Security is really a thought > process, not a capability. > > > > -- > > email: [EMAIL PROTECTED] > > > > > > From: > [email protected] > > > [mailto:[EMAIL PROTECTED] > On Behalf > > Of Steve Jones > > Sent: Friday, March 30, 2007 1:14 AM > > To: > [email protected] > > Subject: Re: [service-orientated-architecture] ESB > Standard > > Definition - SOA capabilities and its > categorization > > > > I'd be a bit worried if security wasn't considered > to be an SOA > > capability, trust, privacy, authentication etc are > all key business > > concepts that need to be handled within a > delivered SOA. > > > > > > On 30 Mar 2007 00:59:23 -0700, Jerry Zhu < > [EMAIL PROTECTED]> wrote: > > I agree with policy enforcement being mediation > > concept to be a category. > > > > So network & security is left out and is > considered as > > non SOA capablity > > > > The issue is Service Registry (SR). I think that > SR is > > used by all Service Platforms, Service Mediation, > and > > Service Managmeent, not just Service management. > So SR > > is considered as common factor of all three > categories > > and extracted out and defined as a separate > capablity > > category. > > > > Also SR is used by business services in > implementing > > business logic in either early or late binding. > The > > fact that SR has its owns APIs and standards makes > it > > well into a category. Also we can buy service > > registry as a standalone product in the market. So > it > > is a good separation of concerns to extract > registry > > out as a category. Metadata will be stored in > > Repostory. > > > > So four SOA capability categories? > > > > Service Platforms > > Service Mediation > > Service Management > > Service Registry/Repository > > > > Ideas from anyone? If no objections we agree that > > this is the SOA capability categorization. Once we > > have this done we can insert capability items in > the > > categories. > > > === message truncated === ____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097
