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: OASIS SOA-EERP Whitepaper


I agree with Ken, here, and I did not specifically address this in my 
review of the specifications which will momentarily appear in the SOA-RM 
TC and RA SC lists.

Cheers,
Rex

Laskey, Ken wrote:
>
> Chris,
>
> There is a distinction made in the EERP work that we realized too 
> late: the distinction between a business service and a SOA service. 
> The business service is the functionality brought to bear in order to 
> realize a set of desired real world effects. The capability is an 
> entity that implements the required functionality and is accessed in a 
> SOA ecosystem via a SOA service.
>
> If I preface their initial use of */Services/* with “Business”, then 
> the point is not only clarified but consistent with their second 
> sentence. I think it also has all the clarifying properties you propose.
>
> Ken
>
> ---------------------------------------------------------------------------
>
> Dr. Kenneth Laskey
>
> MITRE Corporation, M/S H305 phone: 703-983-7934
>
> 7515 Colshire Drive fax: 703-983-1379
>
> McLean VA 22102-7508
>
> *From:* Bashioum, Christopher D [mailto:cbashioum@mitre.org]
> *Sent:* Thursday, April 01, 2010 5:09 PM
> *To:* Peter F Brown (Pensive); soa-rm@lists.oasis-open.org
> *Cc:* Laskey, Ken
> *Subject:* [soa-rm] RE: OASIS SOA-EERP Whitepaper
>
> I sort of agree, except that the RM doesn’t state what you just did. 
> The service is “the mechanism by which needs and capabilities are 
> brought together”. It explicitly distinguishes the mechanism for 
> access from the capability itself – it does not state that using the 
> capability makes it a service. It’s a fine distinctinction, but an 
> important one.
>
> So ... back to my original concern. I think the reason there has not 
> been more adoption of the RM is that folks don’t know how to tie it to 
> the capability, and many folks have been using the term “service” to 
> apply to the underlying capability vs. the ability to bring that 
> capability to bear for “anyone’s” need. I.e., the business service as 
> distinct from the SOA service.
>
> *From:* Peter F Brown (Pensive) [mailto:Peter@pensive.eu]
> *Sent:* Thursday, April 01, 2010 4:45 PM
> *To:* Bashioum, Christopher D; soa-rm@lists.oasis-open.org
> *Cc:* Laskey, Ken
> *Subject:* RE: OASIS SOA-EERP Whitepaper
>
> I don’t think that is correct.
>
> A capability addresses a need – it is a **potential** to perform a 
> service - the need is satisfied by using the capability: the service.
>
> Capabilities don’t “perform” anything, they just “are”. The 
> performance of a service – delivering a real world effect – depends on 
> there being a capability but is not the same thing.
>
> Cheers,
>
> Peter
>
> *From:* Bashioum, Christopher D [mailto:cbashioum@mitre.org]
> *Sent:* Thu, 01 April 2010 11:09
> *To:* soa-rm@lists.oasis-open.org
> *Cc:* Laskey, Ken
> *Subject:* [soa-rm] OASIS SOA-EERP Whitepaper
>
> Has anyone else from the SOA RM TC reviewed the OASIS SOA-EERP whitepaper
>
> http://docs.oasis-open.org/soa-eerp/whitepaper/EERP-Model-UseCase-WhitePaper-cd03.pdf
>
> They reference the RM, however, there is one paragraph that caught my 
> attention:
>
> */Services /*are performed by people, machines, and hardware/software 
> applications, and represented by SOA services. The qualities of a 
> business service are expressed by means of the Business Quality of 
> Service (bQoS) specification. The nature of bQoS varies across 
> industries and services.
>
> The RM would change this to
>
> */Capabilities /*are performed by people, machines, and 
> hardware/software applications, and represented by SOA services. The 
> qualities of a business service are expressed by means of the Business 
> Quality of Service (bQoS) specification. The nature of bQoS varies 
> across industries and services.
>
> I think we may need to do something about addressing the idea of a 
> capability that is intended for “others”, i.e., a business service – 
> which is enabled in Software by a SOA service in front of a 
> capability. We’ve talked about it, but I think a whitepaper on this 
> will be useful.
>
> Note that such a whitepaper would also go a long way towards helping 
> to navigate the SOA Standards landscape, as I think the main issue 
> between the various SDOs on SOA is about using the term “service” to 
> mean “functionality intended for others” vs. as an IT artifact that 
> enables access to such funtionality (which is the RM view).
>
> Thoughts?
>

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