OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Service definition at nauseum


Jeff,

 

Good stuff! With respect to the ATM example: in my view, the two are fundamentally different services for several reasons.

1.       The access to the service is through different interfaces. I would define service uniqueness as partially specified by the interface for access.

2.       The governance and management of the two are different, i.e.,

3.       The handling of faults, errors, and events associate with the two are different

4.       The preconditions for access are different, i.e., to cash a check at a bank you generally must have an account with the bank, whereas to use an ATM, the card you carry must belong to a network in which the particular ATM participates.

5.       The outcome of certain activities will be different between the two such as submitting checks for deposit. In the ATM case, all checks wait for processing before funds are available and in the teller case, certain checks will be processed and the funds made available immediately.

 

So to me there is a notion that a bank offers capabilities which are realized through services such as teller transactions, ATM transactions, and even bank-to-bank, bank-to-business, business-to-bank transactions. Each realization of a capability constitutes a unique service in my mind.

 

My opinions, though…

 

Dan Hestand

Lead Software Systems Engineer

The MITRE Corp

781.271.3755

phestand@mitre.org

 

From: Estefan, Jeff A (3100) [mailto:jeffrey.a.estefan@jpl.nasa.gov]
Sent: Wednesday, April 21, 2010 4:54 PM
To: soa-rm@lists.oasis-open.org
Subject: [soa-rm] Service definition at nauseum

 

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



-------- Original Message --------

Subject:

Services - again

Date:

Mon, 29 Mar 2010 16:19:10 +0100

From:

Chris Partridge <partridgec@borogroup.co.uk>

Organization:

BORO Group

To:

Dave McDaniel <davem@silverbulletinc.com>

CC:

<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]

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]. 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]. 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]. 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

 

BORO Solutions Limited

Website:                                     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

 

BORO Solutions Limited

Website:                                     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] The OASIS-RM definition is used in DM2 and noted in M3.

[2] 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.

[3] 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] “an act of helpful activity; help; aid: to do someone a service” Random House Dictionary.

 

 

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]