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: [soa-rm] RE: Service definition at nauseum


I don't see it as SOA vs non SOA, but Service AND SOA Service.

Cheers
Rex

Lublinsky, Boris wrote:
> The notion of SOA vs non SOA services bothers me.
> Building an SOA implementation through exposing a stovepipe functionality using service interface is a very valid approach to building services.
> And I do agree that we were doing functional decomposition for 40 years now. There is one important difference although (http://www.ibm.com/developerworks/architecture/library/ar-soastyle/). Prior to SOA this was done on the application level, while SOA is doing this based on the enterprise architecture. And yes there are distributed computing roots in SOA, but SOA is not distributed computing or component-based development, or OO. It is a different thing
>
> -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com]
> Sent: Thursday, April 22, 2010 1:54 PM
> To: Bashioum, Christopher D
> Cc: Lublinsky, Boris; Estefan, Jeff A (3100); soa-rm@lists.oasis-open.org
> Subject: Re: [soa-rm] RE: Service definition at nauseum
>
> I wouldn't contend that we don't need a definition for SOA-specific
> viewpoints. What Jeff and many others have found problematic is the
> foundational notion of "Service" that is different across different
> organizations and is, therefore, different when that definition gets
> applied to to more SOA-specific concerns. While I agree with a lot of
> what you say, I disagree with "Whatever definition we come up with
> should fail if applied to a non-SOA service." Our SOA definition must
> build from the root, not contradict it. However, if you mean that our
> definition of a SOA-service doesn't strictly apply to a non-SOA service,
> I would agree.
>
> Getting services out of stovepipes is difficult in times like this
> because stovepipes are reassuring environments. That'll change.
>
> Cheers,
> Rex
>
> Bashioum, Christopher D wrote:
>   
>> Rex,
>>
>> my only problem with the way you've defined a service is that the normal stovepipes with individual interfaces optimized for each consumer will satisfy that definition.  We have to look at what makes a "SOA Service" different from what is not a "SOA service".  Whatever definition we come up with should fail if applied to a "non-SOA service".
>>
>> If you say that it is just decomposition of enterprise service model, that just sounds like the normal functional decomposition that we've been doing for 40 years also.
>>
>> In our SOA class, we looked at the history of SOA, and it comes out of the distributed software world:
>>
>> 1) 1991: the term "services" from Burton Group's Network Services Model,
>> 2) 1996: Gartner analysts Schulte and Natis use the term "Service Oriented" Architecture,
>> 3) 1998 Network Applications Consortium position paper "Business Services Architecture: Integration of software components and common services infrastructure"  has the following quote:
>>
>> "A service-oriented architecture takes the concept of modularity and separation of data
>> and business rules further still. Gartner Group defines a service-oriented architecture
>> as "a particular style of multi-tier computing that helps enterprises share logic and
>> data. It assumes multiple software tiers ... and leverages the principle that many
>> aspects of processing logic are common to many users of some particular data set
>> rather than being uniquely associated with one particular application... A service is a
>> black box that hides code and data from the developer of the client application... A
>> service-oriented architecture maximizes code reuse and minimizes the redundancy of
>> logic and data by organizing functions into shareable, encapsulated modules that can
>> be accessed from multiple requestors.""
>>
>> The above quote embeds another quote from  "Architecture and Planning for Modern Application Styles." GartnerGroup Systems Software Architectures (SSA) Strategic Analysis Report. R. Schulte. 4/28/97.
>>
>> I can forward the last paper referenced if anyone is interested.  During this time, CORBA and DCOM were dominant, and the failings of those two to cross organizational boundaries (which the RM identifies as an important issue) led to the development of the standards for web services (WSDL, SOAP, etc.).
>>
>> The point is that the term SOA grew up out of the distributed programming world, and was a way to help get the IT more directly aligned with what businesses need - and not so much in terms of functionality but in terms of re-wickering functionality to meet the changing competitive landscape.
>>
>> So ... the definition we use must be one that helps guide development of distributed systems, and not just business organization.
>>
>> Note also that the SOA evolution has been tracking well with the object oriented evolution.  Many of the OO concepts apply to business, but in the end it is a paradigm that influences how you go about analyzing, organizing, and decomposing your requirements into things that get built.
>>
>> -----Original Message-----
>> From: Rex Brooks [mailto:rexb@starbourne.com]
>> Sent: Thursday, April 22, 2010 10:15 AM
>> To: Lublinsky, Boris
>> Cc: Estefan, Jeff A (3100); soa-rm@lists.oasis-open.org
>> Subject: Re: [soa-rm] RE: Service definition at nauseum
>>
>> I think we're getting closer incrementally. Boris makes some important
>> points, but, for me, what I take away from his comments is the notion
>> that we need to be careful about the perspective or viewpoint from which
>> a service is defined. At the Reference Model level, where the idea of
>> means or mechanism is problematic, I think we can say that a service is
>> a capability that is offered either explicitly to the public or
>> privately between participants. That is at the simplest and most
>> fundamental level of abstraction.
>>
>> Moving from there to the perspective or viewpoint of the SOA-RAF,
>> Services are further explained in the specific contexts of Service
>> Ecosystem, Realizing SOAs, Owning SOAs, and Governing and Managing SOAs.
>> Each of these viewpoints has specific concerns that we elaborate.
>>
>> Cheers,
>> Rex
>>
>> Lublinsky, Boris wrote:
>>
>>     
>>> Jeff,
>>>
>>> This is a great summary, here is where I am starting to be very uneasy:
>>>
>>> With a rush for SOA we seem to somewhat equate SOA with distributed
>>> computing and as a result service orientation with distribution. As a
>>> result we are starting to invent business services, infrastructure
>>> services, IT services and all other kinds of services. The question
>>> goes back to what an SOA is what is it all about and what it is
>>> supposed to do. Services should be a result of decomposition of an
>>> enterprise business model and a results are not just functional block
>>> (capability), but capability within a frame of a given enterprise
>>> business model. An access point and such is a service implementation
>>> concern, more than a service definition concern. Based on this, here
>>> is my assessment of your statements
>>>
>>> 1. 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. What is
>>> weird here is that a service is a verb, not a noun. Cardinality (in
>>> english) refers to a noun not a verb. The whole cardinality debate is
>>> coming from an attempt to bring services to OO, which is not the right
>>> thing to do. In services methods are independent and grouped together
>>> only for better manageability - compare to namespaces.
>>>
>>> 2. 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). I would
>>> guess capability is a service, while performance is a policy. You can
>>> expose the same capability (service) with different policies through
>>> different endpoints. What's the problem?
>>>
>>> 3. 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. I would say they are different contracts for the
>>> same functionality with different policies (see above)
>>>
>>> *From:* Estefan, Jeff A (3100) [mailto:jeffrey.a.estefan@jpl.nasa.gov]
>>> *Sent:* Wednesday, April 21, 2010 3: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.
>>>
>>> 4. 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.
>>>
>>> 5. 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.
>>>
>>> 6. 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).
>>>
>>> 7. 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.
>>>
>>> 8. 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.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>> The information contained in this communication may be CONFIDENTIAL
>>> and is intended only for the use of the recipient(s) named above. If
>>> you are not the intended recipient, you are hereby notified that any
>>> dissemination, distribution, or copying of this communication, or any
>>> of its contents, is strictly prohibited. If you have received this
>>> communication in error, please notify the sender and delete/destroy
>>> the original message and any copy of it from your computer or paper
>>> files.
>>>
>>>       
>> --
>> Rex Brooks
>> President, CEO
>> Starbourne Communications Design
>> GeoAddress: 1361-A Addison
>> Berkeley, CA 94702
>> Tel: 510-898-0670
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
> The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above.  If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited.  If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.
>
>
>   

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