← Prev in month
← Prev in thread
Fwd: [soa-rm] Definition(s) of "service"
So,how do we respond to this? The wiki may help on this but I think one of the topics at the editors' mtg may be how to glean key thoughts from an overactive email list, using the service definition as a first challenge. Ken Begin forwarded message: From: Duane Nickull <> Date: August 10, 2005 3:50:32 PM EDT To: Ken Laskey <> Cc: 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:] Sent: Monday, August 08, 2005 5:50 PM To: 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:] Sent: Monday, August 08, 2005 12:10 PM To: Ken Laskey Cc: 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, 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:] Sent: Thursday, August 04, 2005 12:35 PM To: 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:] Sent: Thursday, August 04, 2005 11:04 AM To: Chiusano Joseph; 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:] Sent: Thursday, August 04, 2005 10:18 AM To: 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, 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:] 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:] 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 / ---------------------------------------------------------------------------------- Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508
← Prev in month
← Prev in thread