[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Service definition at nauseum
Thanks Jeff, I really appreciate the effort and I think you're close to nailing it. Cheers, Rex Estefan, Jeff A (3100) wrote: > > Folks, > > I brought this issue up today on the RM call because there have been > numerous dual threads of discussion recently around the core concept > of “services” and “capabilities” both from the response to the > SOA-EERP spec review and from the DM2 side (see attached e-mail note > below and attached slides). > > Let’s first look at the myriad of definition of services from the > various industry rags both from the notional definition of service and > the more IT-oriented definition of service. > > *Notional Definition of “Service”:* > > OASIS SOA-RM makes reference to the dictionary definition of a > [notional] service as “The performance of work (a function) by one for > another” as well as related ideas such as “The capability to perform > work for another,” “The specification of the work offered for > another,” and “The offer to perform work for another.” > > The CBDI SAE Metamodel for SOA formally defines a notional service as > “a capability offered by a provider to a consumer according to a > contract.” A contract is usually a Service Level Agreement, and this > may reference a Service Specification. > > Comments: > > * Contrast “performance of work” with “capability to perform work”. > Certainly the former is the act of the service in execution and the > latter is to potential to act. How does this affect our idea of what a > service is? Is it the act or is it the capability to act or both? > > * Contrast “capability to perform work” from the RM with “capability > offered” from the SAE metamodel. Notions are similar but not exactly > the same. How do we resolve the difference? > > *IT-Oriented Definition of Service:* > > OASIS SOA-RM: > > A mechanism to enable access to one or more capabilities, where the > access is provided using a prescribed interface and is exercised > consistent with constraints and policies as specified by the service > description. > > Comments: > > * It is implied we’re talking about a SOA service here, not the more > general notional service defined earlier. > > * With the exception of “mechanism,” this is an excellent definition > for an IT-type of service (application, data, infrastructure service) > and, again, what we sometimes indirectly refer to as “SOA service.” > > * Have a problem with “mechanism.” Somewhat clearer when viewed as > “means” but still very vague (at least to me). > > OMG SoaML: > > A resource that enables access to one or more capabilities. Here, the > access is provided using a prescribed interface and is exercised > consistent with constraints and policies as specified by the service > description. > > Comments: > > * Essentially the SOA-RM definition of service verbatim, which they > acknowledge, with the exception of their dropping “mechanism.” > Clearly, the SoaML team had similar issues regarding use of the word > mechanism. > > * I personally like this definition although in the RM, we did not > formally define what a “resource” was. We left that to the SOA-RAF. I > would further specialize the definition to read “A service (in the > context of SOA) is…” to be clear we are defining a specialization of > the more general notional service. > > The Open Group SOA Ontology: > > A logical representation of a repeatable business activity that has a > specified outcome (e.g., check customer credit; provide weather data, > consolidate drilling reports). > > * Don’t like this definition for a number of reasons but mostly > because it introduces a whole new set of issues surrounding clarifying > what we mean by a “repeatable business activity.” > > W3C WSA: > > An abstract resource that represents a capability of performing tasks > that represents a coherent functionality from the point of view of > provider entities [p.35] and requester entities [p.36] . To be used, a > service must be realized by a concrete provider agent [p.34] . > > Comments: > > * Once again, viewed as a “resource” and more specifically, an > “abstract resource.” Doesn’t include the RM notion of interface, > contracts & policies, and service description all of which are > critically important. > > Burton Group: > > * Abstracts a capability and makes it available via open, > platform-neutral interfaces. > > Comments: > > * Again, a similar thread in other definitions about abstracting > capabilities or logical representations but misses the key points of > the RM definition about contracts & policies and service description. > > CBDI SAE Metamodel: > > Software Service: A service that is accessed through a digital Service > Interface. > > Comments: > > * I do like that they specialize from the more general notional > service; however, lacks notion of policies (contracts are embedded in > defn of notional service). (Note that they refer to service > description as “service specification”.) > > Bloomberg & Schmelzer – ZapThink (from “Service Orient or Be Doomed!): > > A contracted interface to software functionality. > > Comments: > > * Clearly, an IT-oriented definition of service as the authors clearly > acknowledge. They make the distinction that services in this context > are “interfaces” to software, not the software itself. In other words, > a service is an abstraction of some piece of software. > > * There is no real sense of capabilities in the general sense but > rather functionality and more specifically, software functionality. > > Now to the discussion. Frank brings up an interesting point about the > ATM-mediated service. It is a different service than the bank teller > (human)-mediated service because even though the business functions on > the back end are the same (deposit, withdraw, transfer, get balance, > etc.) the capability of the two offerings is different, i.e., one is > only available during banking hours while the other is available 24-7 > (assuming a functioning ATM). How do we clearly articulate differences > such as these? Are they indeed different services (or service > offerings) from the same service provider since even though their > availability is different the available business functions are the > same? I think they are and not just different service interfaces to > the same business functions because their contracts and policies could > be different as would their service descriptions. Agree or disagree? > > I am forwarding the note from Chris Partridge on the DM2/MoDAF > dissection below (also see attached PPT summary and Ken’s response) > that provides yet another thread on the topic of clarifying the > service definition, although from reading his passages, I think he > does not realize that we separate the notion of a SOA or IT service > from the general notion of a service, i.e., the fact that our > definition of service includes prescribed interface and is exercised > consistent under the constraints & policies as specified in the SD is > really closer to an IT-oriented view of service. If the effort on DM2 > is to use the notion of service in a non-IT-oriented manner, then DM2 > should not adopt our definition (or SoaML’s definition) of service. > They need to start with the more general notional service and then > further specialize from this more abstract notion of service and use > those specializations in development of their metamodel. The CBDI SAE > metamodel does a very good job at this, even if we may not agree on > their definition of core concepts. > > In summary, I think there are three key areas of ambiguity that need > to be clarified, not only for us, but—to David Ellis’ point—for the > general practitioners out there trying to make this stuff work. > > 1. Clearly distinguishing the IT-oriented sense of service from a > notional service without a baseline concept for what a service is in > the abstract is not something we have done a good job at doing. There > is some attempt at this in the RM but most folks focus just on the > straight definition in the RM text or go straight to the glossary > provided description so it’s largely taken out of context. > > 2. Cardinality of capability, i.e., does a service offer of a > (singular) capability or one or more capabilities? Both cardinality > cases are evident in the industry rag definitions but they are not > consistent. Would be helpful to articulate a few examples. > > 3. That there are two sides of the same coin when we refer to > “service.” There is the capability to perform work for another and > there is the actual performance of work for another. This distinction > often gets muddled and it is not particularly clear how to unmuddle it > in our various definitions of service (pardon the slang). > > 4. Multiple services from the same provider with the same back end > functions or are these really multiple interfaces to the same service? > Cite ATM example above. A very important distinction that needs > further refinement. > > 5. Separation of the notion of “capabilities” from “services” is key, > particularly when we’re talking about IT-oriented services. While at > the notional level, these are very closely related concepts, i.e., > services offer or ‘expose’ capabilities; however, it is important to > note that not all capabilities are service oriented. Remember, service > orientation is an organizational principle that drives businesses to > be customer-oriented and governments to be citizen-centered, and, at > its core, it is a contract- and policies-based paradigm. Not all > capabilities are offered that way. One might argue not even close. > When we extend that paradigm to IT architecture, we introduce the > notion of implementation-neutral interfaces, however, contracts and > policies are still core to the paradigm in this domain as well > because, again, we’re talking about the organizational principle of > service orientation. I think this is what is missing in a lot of SOA > work. It’s not just exposing some software functionality provided by > software components via a Web services interface or API in the absence > of contracts and policies. Contractual obligation is absolutely > essential to the essence of this paradigm. > > Suggest we keep this as a separate RM thread distinct from our RAF work. > > Regards… > > - Jeff > > - - - - - - - - - - - - - - > > *From:* Ellis, David [mailto:dellis@sandia.gov] > *Sent:* Monday, April 05, 2010 6:57 AM > *To:* Estefan, Jeff A (3100) > *Subject:* FW: [Fwd: Services - again] > > Jeff > > Here are some more issues. Please treat these as draft and do not > distribute. > > Dave > > *From:* Dave McDaniel [mailto:David.McDaniel@SilverBulletInc.com] > *Sent:* Friday, April 02, 2010 2:10 PM > *To:* Ellis, David; Brooks, Rex; Laskey, Ken > *Subject:* [Fwd: Services - again] > > Dave, Rex, Ken, > > As per today's discussion, follows some work notes between MODAF > workers and myself. Please treat them with discretion. > > -- > Regards/Dave McDaniel > Silver Bullet Solutions, Inc. > (703) 892-6062 x2# (DC) > (619) 237-9220 (San Diego) > (619) 253-9040 (mobile) > www.silverbulletinc.com <http://www.silverbulletinc.com> > > > > -------- Original Message -------- > > *Subject: *** > > > > Services - again > > *Date: *** > > > > Mon, 29 Mar 2010 16:19:10 +0100 > > *From: *** > > > > Chris Partridge <partridgec@borogroup.co.uk> > <mailto:partridgec@borogroup.co.uk> > > *Organization: *** > > > > BORO Group > > *To: *** > > > > Dave McDaniel <davem@silverbulletinc.com> > <mailto:davem@silverbulletinc.com> > > *CC: *** > > > > <ian@modelfutures.com> <mailto:ian@modelfutures.com> > > > > Hi Dave, > > As you know one of the topics that is exercising me is the definition > of Service. > > When I was looking into the definitions of service I came across > something that surprised me. > > OASIS-RM (and then subsequently SoaML) adopt a definition of a Service > as the **access** to a capability – so excluding the capability. > > M3 notes this definition (A type of delivered functionality, specified > independently of the resources that provide it. Note: A service may or > may not have a physical effect on its environment OASIS Definition: A > service is a mechanism to enable access to a set of one or more > capabilities, where the access is provided using a prescribed > interface and is exercised consistent with constraints and policies as > specified by the service description.) > > And DM2 explicitly adopts it, though mentions multiple capabilities. > (A mechanism to enable access to a set of one or more capabilities, > where the access is provided using a prescribed interface and is > exercised consistent with constraints and policies as specified by the > service description. The mechanism is a Performer. The "capabilities" > accessed are Resources -- Information, Data, Materiel, Performers, and > Geo-political Extents.). > > This seems to imply there is an orchestration of capabilities, rather > than just one. > > What is odd is that SoaML then adds a ServicePoint to the service > access – as shown below.(DM2 seems to do the same thing by having a > ServicePort – though I need to check this with Dave.) > > cid:image005.png@01CACF32.1E03A430 > > Are you aware of this – and do you have a view? If you know of any > motivation (apart from that in the document) for this, we would be > interested. > > Your Service picture seems to follow this route, where the capability > is NOT part of the service. > > What seems a little odd is that it shows more than one capability. Is > this right? > > Also, should ALL the Service Provider be included in the Service? > > > > > > cid:part2.09060904.00040707@SilverBulletInc.com > > > I copy my notes below, as these might help explain. > > Notes > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ > > The core notion is Service, and the definitions are copied below. > > OASIS-RM[1] <#_ftn1> > > > > TOG-SO > > > > SoaML > > a mechanism to enable access to one or more capabilities, where the > access is provided using a prescribed interface and is exercised > consistent with constraints and policies as specified by the service > description. > > > > A logical representation of a repeatable business activity that has a > specified outcome (e.g., check customer credit; provide weather data, > consolidate drilling reports). It is self-contained, may be composed > of other services, and is a “black box” to its consumers. > > > > Service is defined as a resource that enables access to one or more > capabilities. Here, the access is provided using a prescribed > interface and is exercised consistent with constraints and policies as > specified by the service description. This access is provided using a > prescribed interface and is exercised consistent with all constraints > and policies as specified by the service description. A service is > provided by an entity - called the provider - for use by others. The > eventual consumers of the service may not be known to the service > provider and may demonstrate uses of the service beyond the scope > originally conceived by the provider. > > Identifies or specifies a cohesive set of functions or capabilities > that a service provides. > > TOG-SSB also includes a second (different) definition: “A service is a > repeatable activity that has a specified outcome”[2] <#_ftn2>. This > effectively moves the definition down a level of representation. > > OASIS-RAF has no direct definition of a Service. > > The core of the OASIS-RM and SoaML definitions are broadly similar. > These talk about a Service as a mechanism / resource that enables > access to a capability, where this is (according to SoaML) “The > ability to act and produce an outcome that achieves a result”. This > would seem to clearly block any identification of the service with the > capability or even an overlap between them. One can picture the > mechanism / resource as an access point to the capability – see the > figure below. (We look at how one can have an access point to > capability (which is an ability) later.) > > What is odd in SoaML’s case, is that it appears to have two layers of > access. There is a ServicePoint (see below) that provides access to > the service and then the service that provides access to the resource > – see the figure below.. It is not clear what the motivation for this > is (apart from conforming to the UML MetaModel). Until a good > motivation is provided. > > *SoaML* > > > > 7.3.11 > > ServicePoint > > > > A ServicePoint is the offer of a service by one participant to others > using well defined terms, conditions and interfaces. A ServicePoint > defines the connection point through which a Participant offers its > capabilities and provides a service to clients. > > Description > > A ServicePoint is a mechanism by which a provider Participant makes > available services that meet the needs of consumer requests as defined > by ServiceInterfaces, Interfaces, and ServiceContracts. A ServicePoint > is represented by a UML Port on a Participant stereotyped as a > “ServicePoint.” > > There is a clear difference between OASIS-RM and SoaML definitions and > TOG-SO definition. The TOG-SO refers to a ‘logical representation’ > whereas OASIS-RM and SoaML refer to, variously, a mechanism and a > resource[3] <#_ftn3>. The TOG-SO definition is clearly at a higher > level of representation than the OASIS-RM and SoaML definitions. > > The TOG-SO “repeatable business activity” is not the same things as > the OASIS-RM / SoaML mechanism / resource. But it is similar to the > manifestation of the capabilities that the mechanism / resource enable. > > Another concern is that none of the definitions match up well with the > normal ordinary language sense of service[4] <#_ftn4>. The TOG-SO > definition is the wrong level of representation, if we revise it down > a level we can make a connection to the ordinary language sense. > However the OASIS-RM and SoaML definitions seem to be referring to > something quite different. The man on the Clapham Omnibus, when > talking of a taxi service would regard the provision of the taxi (the > “repeatable business activity” – but not its representation) as the > service. He would find a sense that excluded this and only focussed on > the related “enabling access” – which in this case might be a > telephone call booking the taxi - as unusual. OASIS-RM explain their > motivation for choosing this unorthodox sense as follows: > > “The service concept above emphasizes a distinction between a > capability that represents some functionality created to address a > need and the point of access where that capability is brought to bear > in the context of SOA. It is assumed that capabilities exist outside > of SOA. In actual use, maintaining this distinction may not be > critical (i.e. the service may be talked about in terms of being the > capability) but the separation is pertinent in terms of a clear > expression of the nature of SOA and the value it provides.” > > So one point we need to clarify is what we want the extent of the > Service to be - the access point, what is accessed or both (as shown > in the figure)? Or, more relevantly; which of these extents is useful > – and which are not? > > cid:image006.png@01CACF32.1E03A430 > > A further issue is that both the OASIS-RM and SoaML definitions also > include significant constraints upon the mechanism / resource. One can > see the influence of IT Services here. However, it is unlikely that > all (non-IT) business services (such as a Taxi service) will be > regimented to the extent that they have a clearly prescribed interface > or a service description that specifies many, if any, constraints and > policies. This suggests that this is a description of an ideal > situation even though it is phrased as a necessary condition. > > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ > > Regards, > > Chris Partridge > > Chief Ontologist > > Mobile: +44 790 5167263 > > Phone: +44 20 81331891 > > Fax: +44 20 7855 0268 > > E-Mail: partridgec@borogroup.co.uk <mailto:partridgec@borogroup.co.uk> > > BORO Solutions Limited > > Website: www.BOROSolutions.co.uk <http://www.BOROSolutions.co.uk> > > Registered in England No: 06025010 > > Registered Office: 25 Hart Street, Henley on Thames, Oxfordshire RG9 2AR > > This email message is intended for the named recipient(s) only. It may > be privileged and/or confidential. If you are not an intended named > recipient of this email then you should not copy it or use it for any > purpose, nor disclose its contents to any other person. You should > contact BORO Solutions Limited as shown above so that we can take > appropriate action at no cost to yourself. All BORO Solutions Limited > outgoing E-mails are checked using Anti Virus software. > > > ------------------------------------------------------------------------ > > Regards, > > Chris Partridge > > Chief Ontologist > > Mobile: +44 790 5167263 > > Phone: +44 20 81331891 > > Fax: +44 20 7855 0268 > > E-Mail: partridgec@borogroup.co.uk <mailto:partridgec@borogroup.co.uk> > > BORO Solutions Limited > > Website: www.BOROSolutions.co.uk <http://www.BOROSolutions.co.uk> > > Registered in England No: 06025010 > > Registered Office: 25 Hart Street, Henley on Thames, Oxfordshire RG9 2AR > > This email message is intended for the named recipient(s) only. It may > be privileged and/or confidential. If you are not an intended named > recipient of this email then you should not copy it or use it for any > purpose, nor disclose its contents to any other person. You should > contact BORO Solutions Limited as shown above so that we can take > appropriate action at no cost to yourself. All BORO Solutions Limited > outgoing E-mails are checked using Anti Virus software. > > > ------------------------------------------------------------------------ > > [1] <#_ftnref1> The OASIS-RM definition is used in DM2 and noted in M3. > > [2] <#_ftnref2> > http://www.opengroup.org/projects/soa-book/page.tpl?CALLER=page.tpl&ggid=1317 > <http://www.opengroup.org/projects/soa-book/page.tpl?CALLER=page.tpl&ggid=1317>. > Compare this with > http://www.opengroup.org/projects/soa-book/page.tpl?CALLER=page.tpl&ggid=1314 > <http://www.opengroup.org/projects/soa-book/page.tpl?CALLER=page.tpl&ggid=1314>. > > [3] <#_ftnref3> OASIS-RM does not define a ‘mechanism’ and SoaML does > not define a ‘resource’. For our purposes, I propose to consider them > as similar or effectively the same. > > [4] <#_ftnref4> “an act of helpful activity; help; aid: to do someone > a service” Random House Dictionary. > > > > ------------------------------------------------------------------------ > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-898-0670
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]