[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Definition(s) of "service"
Ken: Thank you for owning this! Good luck next week. May I suggest that the Editors use the WIKI page during their meeting? Duane Ken Laskey wrote: > Duane, > > I hate to say this (and my fellow co-editors may disagree) but I think > the task needs to be taken on by the editing team as a whole. My SOA > mailbox has over 2300 messages with many threads having a bearing on > this, and even a cursory scan will be a significant effort. Also, as > the current designated editor for the service section, I don't see a > good way of just dumping it onto someone else. > > I would be willing to be talked out of this position. > > Ken > > At 12:25 PM 8/9/2005, Duane Nickull wrote: > >> I would like to request a volunteer or volunteers to own this issue >> and ensure that none of the depth of this conversation is lost. We >> have passed around heaps of good thoughts. The owner would >> essentially be responsible for capturing the views / opposing views >> and keeping documentation up to date as this gets discussed. The >> owner would not be entitled to simply gloss over with their own point >> of view but would act much like an editor - reflecting the consensus >> or the TC or noting the lack thereof. >> >> Anyone interested in owning this? >> Duane >> >> >> >> Frank McCabe wrote: >> >>> I strongly resist the tendency of equating service with the 'back end >>> capability' (or whatever). This is a dangerous and non-scalable >>> direction to go in: >>> >>> 1. The implementation of a service is none of the service consumer's >>> business. >>> 2. The service consumer should not even be able to figure out how a >>> service is delivered. If it can, then you will get security risks >>> and/ or scalability issues >>> 3. A given capability may not be fully exposed in a given service >>> 4. A given service provider agent may not *have* the capability >>> offered in its service -- it may know someone who knows ... it may >>> not be possible to characterize the capabilities of a service provider. >>> 5. From the point of view of the service consumer, fundamentally, it >>> cannot (normally) distinguish the surface aspects of interacting with >>> a service and the deeper aspects that rely on the service's >>> realization (e.g. this is an Oracle database so be careful with your >>> SQL) >>> >>> On the other hand, the service consumer interacts with a service in >>> order to achieve an effect. In most interesting cases this is a >>> 'real- world effect'. The consumer is interested in the fact that >>> the bank >>> account has been credited. >>> >>> Interestingly, these real world effects can *also* be expressed in >>> public semantic terms -- without relying on representing the internal >>> state of the resource. For example, a bank customer wants to know >>> that his or her account has a certain balance. This is a fact that is >>> warranted by the bank; not simply by the database resource that the >>> bank happened to use to store the account information. I.e., there is >>> a public 'on-the-wire' assertion that the bank attests whenever a >>> authorized request (again, note the on-the-wire nature of this) is >>> made to the appropriate bank service. >>> >>> >>> Frank >>> >>> >>> On Aug 8, 2005, at 3:02 PM, Chiusano Joseph wrote: >>> >>>>> -----Original Message----- >>>>> From: Ken Laskey [mailto:klaskey@mitre.org] >>>>> Sent: Monday, August 08, 2005 5:50 PM >>>>> To: soa-rm@lists.oasis-open.org >>>>> Subject: RE: [soa-rm] Definition(s) of "service" >>>>> >>>>> As appeared earlier in this thread, there are contexts in >>>>> which it is not necessary to discriminate between the >>>>> capability and the service that accesses it, >>>> >>>> >>>> Ken, are you equating capability with resource? I recall a >>>> reference to >>>> resource that fits the above description, but not one to capability. >>>> >>>> Joe >>>> >>>> Joseph Chiusano >>>> Booz Allen Hamilton >>>> O: 703-902-6923 >>>> C: 202-251-0731 >>>> Visit us online@ http://www.boozallen.com >>>> >>>> >>>>> and our >>>>> discussion of service can make this clear. However, I think >>>>> this thread has also shown ample examples of where the >>>>> service and the capability are clearly separate concepts and >>>>> where it may be useful to allow that difference to be >>>>> captured. For example, it is likely for someone to ask if >>>>> two services are the same. While we do not address that >>>>> particular question, it is far simpler to handle if we know >>>>> whether the underlying capability is the same than if we >>>>> obscure that difference at first principles. >>>>> >>>>> Ken >>>>> >>>>> At 05:03 PM 8/8/2005, Chiusano Joseph wrote: >>>>> >>>>>>> -----Original Message----- >>>>>>> From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com] >>>>>>> Sent: Monday, August 08, 2005 12:10 PM >>>>>>> To: Ken Laskey >>>>>>> Cc: soa-rm@lists.oasis-open.org >>>>>>> Subject: Re: [soa-rm] Definition(s) of "service" >>>>>>> >>>>>>> This is going in a weird direction. >>>>>>> I believed that there was significant consensus that the >>>>>> >>>>> notion of >>>>> >>>>>>> service that we are interested in *is* the >>>>>>> interface/boundary/offering. >>>>>>> >>>>>>> The capability behind the service -- that which makes the service >>>>>>> possible -- is private and out of bounds. That capability >>>>>> >>>>> is, by the >>>>> >>>>>>> way, best described using agent terminology. >>>>>> >>>>>> >>>>>> Respectful non-concur. IMHO, the service *is* the >>>>> >>>>> capability, and the >>>>> >>>>>> service *has* an interface through which interaction with that >>>>>> capability may be possible. >>>>>> >>>>>> Joe >>>>>> >>>>>> Joseph Chiusano >>>>>> Booz Allen Hamilton >>>>>> O: 703-902-6923 >>>>>> C: 202-251-0731 >>>>>> Visit us online@ http://www.boozallen.com >>>>>> >>>>>> >>>>>>> Frank >>>>>>> >>>>>>> On Aug 8, 2005, at 8:50 AM, Ken Laskey wrote: >>>>>>> >>>>>>> >>>>>>>> This is good because it highlights the bits of >>>>>>> >>>>> confusion we have >>>>> >>>>>>>> to explain our way around. >>>>>>>> >>>>>>>> The user interface is the facade through which the user >>>>>>> >>>>>>> interacts with >>>>>>> >>>>>>>> a service (i.e. inputting information/requests, viewing >>>>>>>> results) but there may be delivery capabilities that >>>>>>> >>>>> are invoked >>>>> >>>>>>>> through relevant services and the delivery capabilities are the >>>>>>>> mechanisms through which results are packaged and sent to the >>>>>>>> requester/consumer. For example, if I make a request for >>>>>>> >>>>>>> an image and >>>>>>> >>>>>>>> as part of that request, information about my connectivity is >>>>>>>> provided, logic (capability) can be executed (possibly >>>>>>> >>>>>>> invoked through >>>>>>> >>>>>>>> a service) to decide which delivery mechanism is most >>>>>>> >>>>> appropriate >>>>> >>>>>>>> (e.g. high res or low res, what kind of compression, ...). >>>>>>>> >>>>>>>> Ken >>>>>>>> >>>>>>>> At 11:18 AM 8/8/2005, Michael Stiefel wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Actually, I think two things are being confused here. >>>>>>>>> >>>>>>>>> There is one service being used by several different >>>>>>>> >>>>>>> applications. >>>>>>> >>>>>>>>> The user interface (i.e. the actually delivery mechanism) >>>>>>>> >>>>>>> is not part >>>>>>> >>>>>>>>> of the service, or strictly speaking part of the SOA. >>>>>>>>> >>>>>>>>> Michael >>>>>>>>> >>>>>>>>> At 10:43 AM 8/8/2005, Ken Laskey wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> I'd have to think about this further but in general I >>>>>>>>> >>>>>>> would say yes. >>>>>>> >>>>>>>>>> The underlying capability is making pizza and offering >>>>>>>>> >>>>>>> the product >>>>>>> >>>>>>>>>> for sale. The mechanisms for accessing the capability are in >>>>>>>>>> person, by phone, online. Note, the capability existed >>>>>>>>> >>>>>>> before there >>>>>>> >>>>>>>>>> was online ordering and this is just another >>>>>>>>> >>>>> mechanism to access >>>>> >>>>>>>>>> a capability that already existed. >>>>>>>>>> Interestingly from an orchestration/choreography sense, >>>>>>>>> >>>>>>> the delivery >>>>>>> >>>>>>>>>> of the pizza (in person pickup, delivery service from >>>>>>>>> >>>>>>> pizza place, >>>>>>> >>>>>>>>>> third-party delivery (e.g. Takeout Taxi around >>>>>>>>>> here)) constitutes another set of capabilities that can >>>>>>>>> >>>>>>> have service >>>>>>> >>>>>>>>>> interfaces and can be combined in response to invoking >>>>>>>>> >>>>>>> the ordering >>>>>>> >>>>>>>>>> service. All of these can be used for delivery of things >>>>>>>>> >>>>>>> other than >>>>>>> >>>>>>>>>> pizza (even the pizza place might also deliver sandwiches). >>>>>>>>>> >>>>>>>>>> I think part of the confusion is that a *physical* >>>>>>>>> >>>>>>> delivery service >>>>>>> >>>>>>>>>> is a millennia-old, longstanding capability that has >>>>>>>>> >>>>>>> nothing to do >>>>>>> >>>>>>>>>> with SOA and is *not* the service in the SOA sense >>>>>>>>> >>>>> but it uses a >>>>> >>>>>>>>>> different aspect of the S word. >>>>>>>>>> >>>>>>>>>> Ken >>>>>>>>>> >>>>>>>>>> At 07:11 PM 8/7/2005, joe@pantella.net wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Does this imply that if I order a pizza online vs. order a >>>>>>>>>>> pizza over the phone vs. order a pizza by walking into the >>>>>>>>>>> store, that these are all separate services? >>>>>>>>>>> >>>>>>>>>>> --JJP >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Ken Laskey [mailto:klaskey@mitre.org] >>>>>>>>>>> Sent: Thursday, August 04, 2005 12:35 PM >>>>>>>>>>> To: soa-rm@lists.oasis-open.org >>>>>>>>>>> Subject: RE: [soa-rm] Definition(s) of "service" >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This gets back to the previous discussion when we >>>>>>>>>> >>>>> talked about >>>>> >>>>>>>>>>> resources, i.e to what extent the service is the >>>>>>>>>> >>>>> mechanism to >>>>> >>>>>>>>>>> access (possibly coordinate) capability vs. when is it >>>>>>>>>> >>>>>>> considered >>>>>>> >>>>>>>>>>> the capability itself. >>>>>>>>>>> >>>>>>>>>>> I think any consideration of the service as the >>>>>>>>>> >>>>>>> capability/resource >>>>>>> >>>>>>>>>>> should be very limited. >>>>>>>>>>> >>>>>>>>>>> Ken >>>>>>>>>>> >>>>>>>>>>> At 11:07 AM 8/4/2005, Chiusano Joseph wrote: >>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Ken Laskey [mailto:klaskey@mitre.org] >>>>>>>>>>>>> Sent: Thursday, August 04, 2005 11:04 AM >>>>>>>>>>>>> To: Chiusano Joseph; soa-rm@lists.oasis-open.org >>>>>>>>>>>>> Subject: RE: [soa-rm] Definition(s) of "service" >>>>>>>>>>>>> >>>>>>>>>>>>> Somehow saying service *provides* capabilities >>>>>>>>>>>> >>>>>>> misses the SOA >>>>>>> >>>>>>>>>>>>> motivation to provide an effective way to bring together >>>>>>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>> parts I >>>>>>>>>>> >>>>>>>>>>>>> need to solve a problem. Integration is often >>>>>>>>>>>> >>>>> of disparate >>>>> >>>>>>>>>>> parts >>>>>>>>>>> >>>>>>>>>>>>> that exist for their own purposes. Service can help >>>>>>>>>>>> >>>>>>>>>>> coordinate but >>>>>>>>>>> >>>>>>>>>>>>> the challenge is to make use of the tools/resources/ >>>>>>>>>>>> >>>>>>>>>>> capabilities >>>>>>>>>>> >>>>>>>>>>>>> that already exist, not to create new stovepipes. >>>>>>>>>>>> >>>>>>> Saying the >>>>>>> >>>>>>>>>>>>> service provides all this is a tempting >>>>>>>>>>>> >>>>> simplification but >>>>> >>>>>>>>>>>>> I >>>>>>>>>>>> >>>>>>>>>>> fear it >>>>>>>>>>> >>>>>>>>>>>>> will trivialize the concepts most in need of >>>>>>>>>>>> >>>>> clarification. >>>>> >>>>>>>>>>>> >>>>>>>>>>>> Agree - and I should clarify that I was merely saying that a >>>>>>>>>>> >>>>>>>>>>> service >>>>>>>>>>> >>>>>>>>>>>> provides capabilities (in general). Combining a >>>>>>>>>>> >>>>>>> capability here, a >>>>>>> >>>>>>>>>>>> capability there, here a capability, there a capability, >>>>>>>>>>> >>>>>>>>>>> everywhere a >>>>>>>>>>> >>>>>>>>>>>> capability (oops sorry - that's the EIEIO song), we >>>>>>>>>>> >>>>>>> have composite >>>>>>> >>>>>>>>>>>> capabilities. >>>>>>>>>>>> >>>>>>>>>>>> Joe >>>>>>>>>>>> >>>>>>>>>>>> Joseph Chiusano >>>>>>>>>>>> Booz Allen Hamilton >>>>>>>>>>>> O: 703-902-6923 >>>>>>>>>>>> C: 202-251-0731 >>>>>>>>>>>> Visit us online@ http://www.boozallen.com >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Ken >>>>>>>>>>>>> >>>>>>>>>>>>> At 10:35 AM 8/4/2005, Chiusano Joseph wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Ken Laskey [mailto:klaskey@mitre.org] >>>>>>>>>>>>>>> Sent: Thursday, August 04, 2005 10:18 AM >>>>>>>>>>>>>>> To: soa-rm@lists.oasis-open.org >>>>>>>>>>>>>>> Subject: RE: [soa-rm] Definition(s) of "service" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'd still like to emphasize service as the access to >>>>>>>>>>>>>>> capabilities for which there are extra-service >>>>>>>>>>>>>> >>>>>>>>>>> motivations for >>>>>>>>>>> >>>>>>>>>>>>>>> their existence and requirements for use of the >>>>>>>>>>>>>> >>>>>>>>>>> capabilities >>>>>>>>>>> >>>>>>>>>>>>>>> that must be >>>>>>>>>>>>>> >>>>>>>>>>>>> navigated >>>>>>>>>>>>> >>>>>>>>>>>>>>> by the service. Thus, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "A service is a mechanism to enable access >>>>>>>>>>>>>> >>>>> to a set of >>>>> >>>>>>>>>>>>> capabilities, >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I would say that access control mechanisms enable such >>>>>>>>>>>>> >>>>>>>>>>>>> access, and that >>>>>>>>>>>>> >>>>>>>>>>>>>> the service *provides* the capabilities. Note: Use of >>>>>>>>>>>>> >>>>>>>>>>>>> "access control" >>>>>>>>>>>>> >>>>>>>>>>>>>> is too concrete for our RM - I stated it only to >>>>>>>>>>>>>> illustrate >>>>>>>>>>>>> >>>>>>>>>>>>> the point. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Joe >>>>>>>>>>>>>> >>>>>>>>>>>>>> Joseph Chiusano >>>>>>>>>>>>>> Booz Allen Hamilton >>>>>>>>>>>>>> O: 703-902-6923 >>>>>>>>>>>>>> C: 202-251-0731 >>>>>>>>>>>>>> Visit us online@ http://www.boozallen.com >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> where the access is provided using a prescribed >>>>>>>>>>>>>> >>>>>>>>>>> interface and is >>>>>>>>>>> >>>>>>>>>>>>>>> exercised consistent with constraints and policies as >>>>>>>>>>>>>> >>>>>>>>>>>>> specified by >>>>>>>>>>>>> >>>>>>>>>>>>>>> the service description." >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ken >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> At 11:15 PM 8/3/2005, joe@pantella.net wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Just trying to sort through this; some common themes >>>>>>>>>>>>>>> >>>>>>>>>>>>> that seem to >>>>>>>>>>>>> >>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>> acceptable: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> A service provides capabilities. >>>>>>>>>>>>>>>> A service is accessible. (If this is true, then >>>>>>>>>>>>>>>> service >>>>>>>>>>>>>>> >>>>>>>>>>>>> cannot be a >>>>>>>>>>>>> >>>>>>>>>>>>>>>> verb.) A service has an interface. (If this is true, >>>>>>>>>>>>>>> >>>>>>>>>>> then a >>>>>>>>>>> >>>>>>>>>>>>>>> service has >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> a boundary.) A service interface is >>>>>>>>>>>>>>> >>>>> prescribed. (Then >>>>> >>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> service and its >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> interface are distinct, and the interface has >>>>>>>>>>>>>>> >>>>>>>>>>> associated rules. >>>>>>>>>>> >>>>>>>>>>>>>>>> I'm not sure this is true, the interface may >>>>>>>>>>>>>>> >>>>>>> describe the >>>>>>> >>>>>>>>>>>>>>>> rules, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> but Im not >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> sure it has rules. In fact, I'm inclined to >>>>>>>>>>>>>>> >>>>>>> suggest that >>>>>>> >>>>>>>>>>>>>>> the interface >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> defines the rules for accessing the service. Which >>>>>>>>>>>>>>> >>>>>>>>>>>>> would lead me >>>>>>>>>>>>> >>>>>>>>>>>>>>>> to suggest that the service interface is more than a >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> specification of the >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> data model, but also of the policies >>>>>>>>>>>>>>> >>>>> associated with >>>>> >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> >>>>>>>>>>>>> service.) >>>>>>>>>>>>> >>>>>>>>>>>>>>>> A service is a set of behaviors. (Not sure I'm on >>>>>>>>>>>>>>>> board >>>>>>>>>>>>>>> >>>>>>>>>>>>> with this, >>>>>>>>>>>>> >>>>>>>>>>>>>>>> something about behaviors doesn't sit well.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Given this, perhaps something like: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> "A service is a bounded set of capabilities that are >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> accessible through >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> a prescribed interface." >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- JJP >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> P.S. I think this definition might just be >>>>>>>>>>>>>>> >>>>>>> flexible enough >>>>>>> >>>>>>>>>>>>>>> to navigate >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> the service offer/contract discussion also. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com] >>>>>>>>>>>>>>>> Sent: Thursday, July 28, 2005 12:32 PM >>>>>>>>>>>>>>>> To: Frank McCabe; SOA-RM >>>>>>>>>>>>>>>> Subject: RE: [soa-rm] Definition(s) of "service" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Frank, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> While I believe that the previously proposed >>>>>>>>>>>>>>> >>>>>>> definition is >>>>>>> >>>>>>>>>>>>>>> sufficient, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I offer the following as a compromise. >>>>>>>>>>>>>>> >>>>> Hopefully, the >>>>> >>>>>>>>>>> notion of >>>>>>>>>>> >>>>>>>>>>>>>>>> "capabilities" addresses your issue of >>>>>>>>>>>>>>> >>>>> needing to get >>>>> >>>>>>>>>>>>> things done. >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> "A service is a set of behaviors to provide >>>>>>>>>>>>>>>> capabilities >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> accessible via >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> a prescribed interface." >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: Frank McCabe >>>>>>>>>>>>>>>> [mailto:frank.mccabe@us.fujitsu.com] >>>>>>>>>>>>>>>> Sent: Thursday, July 28, 2005 10:10 AM >>>>>>>>>>>>>>>> To: SOA-RM >>>>>>>>>>>>>>>> Subject: Re: [soa-rm] Definition(s) of "service" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I hesitate to spoil this party ... but I'm >>>>>>>>>>>>>>> >>>>> going to :) >>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1. There is a distinction between action and result. >>>>>>>>>>>>>>> >>>>>>>>>>>>> (Just ask any >>>>>>>>>>>>> >>>>>>>>>>>>>>>> roboticist) Behaviour sounds a child >>>>>>>>>>>>>>> >>>>>>> misbehaving with no >>>>>>> >>>>>>>>>>>>>>>> discernible effect. Computer Scientists have a >>>>>>>>>>>>>>>> tendency >>>>>>>>>>>>>>> >>>>>>>>>>>>> to focus on >>>>>>>>>>>>> >>>>>>>>>>>>>>>> the purely technical aspects of their work: bytes >>>>>>>>>>>>>>> >>>>>>>>>>>>> shuffling around >>>>>>>>>>>>> >>>>>>>>>>>>>>>> at random within hopefully enormous memories. >>>>>>>>>>>>>>>> 2. Also, we have to bear in mind that nobody invests >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> millions of $s (or >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> even 100's of them) in systems that >>>>>>>>>>>>>>> >>>>> contemplate their >>>>> >>>>>>>>>>> navels >>>>>>>>>>> >>>>>>>>>>>>>>> or have no >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> business payoff. I think that we have to directly >>>>>>>>>>>>>>> >>>>>>>>>>> address the >>>>>>>>>>> >>>>>>>>>>>>>>>> reason that services are deployed. 3. One of the >>>>>>>>>>>>>>> >>>>>>>>>>> movitating >>>>>>>>>>> >>>>>>>>>>>>>>>> best practice aspects of SOAs is >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> that clarity >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> and 'separation' between the providers of >>>>>>>>>>>>>>> >>>>>>> services and the >>>>>>> >>>>>>>>>>>>>>> consumers of >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> services leads to more scalable and robust >>>>>>>>>>>>>>> >>>>>>> architectures. >>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> All of the above is fuzzy language; but, at the >>>>>>>>>>>>>>> >>>>>>> same time, >>>>>>> >>>>>>>>>>>>>>> "A service >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> is a set of behaviors accessible via a prescribed >>>>>>>>>>>>>>> >>>>>>>>>>> interface." >>>>>>>>>>> >>>>>>>>>>>>>>>> sounds a lot like bureauspeak. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I believe that there is strong consensus on the >>>>>>>>>>>>>>> >>>>>>> following >>>>>>> >>>>>>>>>>>>>>>> characteristics: >>>>>>>>>>>>>>>> a. The concept of service is 'at the >>>>>>>>>>>>>>> >>>>> boundary' between >>>>> >>>>>>>>>>> service >>>>>>>>>>> >>>>>>>>>>>>>>>> providers and consumers. b. The service is >>>>>>>>>>>>>>> >>>>>>> 'there' to get >>>>>>> >>>>>>>>>>>>>>>> things done; but doesn't >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> itself denote >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> the engine that performs the tasks. >>>>>>>>>>>>>>>> c. There is a reason for using a service. >>>>>>>>>>>>>>>> d. There is a lot of extra metalogical information >>>>>>>>>>>>>>>> about >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> services that >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> make it possible for third parties to >>>>>>>>>>>>>>> >>>>> develop partners >>>>> >>>>>>>>>>>>> for services. >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I, for one, would prefer a strongly anglo-saxon >>>>>>>>>>>>>>> >>>>>>>>>>> phrasing of the >>>>>>>>>>> >>>>>>>>>>>>>>>> definition of service that speaks to these points. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Frank >>>>>>>>>>>>>>>> ti >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> >>>>> -------------------------------------------------------------- >>>>> >>>>>>>>>>>>>>> ------------------- >>>>>>>>>>>>>>> / Ken >>>>>>>>>>>>>>> Laskey >>>>>>>>>>>>>>> \ >>>>>>>>>>>>>>> | MITRE Corporation, M/S H305 phone: >>>>>>>>>>>>>> >>>>>>>>>>> 703-983-7934 | >>>>>>>>>>> >>>>>>>>>>>>>>> | 7515 Colshire Drive fax: >>>>>>>>>>>>>>> 703-983-1379 | >>>>>>>>>>>>>>> \ McLean VA 22102-7508 >>>>>>>>>>>>>>> / >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> >>>>> -------------------------------------------------------------- >>>>> >>>>>>>>>>>>>>> -------------------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> -------------------------------------------------------------- >>>>>>> >>>>>>>>>>>>> ------------------- >>>>>>>>>>>>> / Ken >>>>>>>>>>>>> Laskey >>>>>>>>>>>>> \ >>>>>>>>>>>>> | MITRE Corporation, M/S H305 phone: >>>>>>>>>>>> >>>>>>> 703-983-7934 | >>>>>>> >>>>>>>>>>>>> | 7515 Colshire Drive fax: >>>>>>>>>>>>> 703-983-1379 | >>>>>>>>>>>>> \ McLean VA 22102-7508 >>>>>>>>>>>>> / >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> -------------------------------------------------------------- >>>>>>> >>>>>>>>>>>>> -------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>> >>>>> ------------------------------------------------------------------- >>>>> >>>>>>>>>>> -------------- >>>>>>>>>>> / Ken >>>>>>>>>>> Laskey >>>>>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>> \ >>>>>>>>>>> | MITRE Corporation, M/S H305 phone: >>>>>>>>>> >>>>> 703-983-7934 | >>>>> >>>>>>>>>>> | 7515 Colshire Drive fax: >>>>>>>>>>> 703-983-1379 | >>>>>>>>>>> \ McLean VA >>>>>>>>>>> 22102-7508 / >>>>>>>>>>> >>>>>>> >>>>> ------------------------------------------------------------------- >>>>> >>>>>>>>>>> --------------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>> >>>>> -------------------------------------------------------------------- >>>>> >>>>>>>>>> ------------- >>>>>>>>>> / Ken >>>>>>>>>> Laskey >>>>>>>>> >>>>>>> >>>>>>> >>>>>>>>>> \ >>>>>>>>>> | MITRE Corporation, M/S H305 phone: 703-983-7934 | >>>>>>>>>> | 7515 Colshire Drive fax: >>>>>>>>>> 703-983-1379 | >>>>>>>>>> \ McLean VA >>>>>>>>>> 22102-7508 / >>>>>>>>>> >>>>>>> >>>>> -------------------------------------------------------------------- >>>>> >>>>>>>>>> -------------- >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>> >>>>> -------------------------------------------------------------------- >>>>> >>>>>>> -- >>>>>>> >>>>>>>> ----------- >>>>>>>> / Ken >>>>>>>> Laskey >>>>>>> >>>>>>> >>>>>>> >>>>>>>> \ >>>>>>>> | MITRE Corporation, M/S H305 phone: 703-983-7934 | >>>>>>>> | 7515 Colshire Drive fax: >>>>>>>> 703-983-1379 | >>>>>>>> \ McLean VA >>>>>>>> 22102-7508 / >>>>>>>> >>>>>>>> >>>>>>> >>>>> -------------------------------------------------------------------- >>>>> >>>>>>> -- >>>>>>> >>>>>>>> ------------ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> >>>>> -------------------------------------------------------------- >>>>> ------------------- >>>>> / Ken >>>>> Laskey >>>>> \ >>>>> | MITRE Corporation, M/S H305 phone: 703-983-7934 | >>>>> | 7515 Colshire Drive fax: >>>>> 703-983-1379 | >>>>> \ McLean VA 22102-7508 >>>>> / >>>>> >>>>> -------------------------------------------------------------- >>>>> -------------------- >>>>> >>>>> >>>>> > > -- > > --------------------------------------------------------------------------------- > > / Ken > Laskey \ > | MITRE Corporation, M/S H305 phone: 703-983-7934 | > | 7515 Colshire Drive fax: 703-983-1379 | > \ McLean VA 22102-7508 / > > ---------------------------------------------------------------------------------- > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]