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