Issue 15322: Capabilities (soaml-rtf) Source: SINTEF (Brian Elvesæter, brian.elvesater(at)sintef.no) Nature: Clarification Severity: Significant Summary: On page 40 it is stated that "Capabilities represent an abstraction of the ability to affect change" and there is a lot of explanation why modelling capabilities makes sense on what I perceive to be the business perspective on an SOA.On page 63 it is stated that "Alternatively, Capabilities may realize ServiceInterfaces using standard UML Realization. This approach is somewhat different in that it says that the Service Interface is a "specification" and the Capability "implements" this specification."In my view here the concept "capability" is used on two different abstraction levels: 1) abstract business view, and 2) IT implementation view. This should be avoided! Resolution: Revised Text: Actions taken: July 1, 2010: received issue Discussion: End of Annotations:===== s is issue # 15322 From: Brian Elvesær Capabilities On page 40 it is stated that "Capabilities represent an abstraction of the ability to affect change" and there is a lot of explanation why modelling capabilities makes sense on what I perceive to be the business perspective on an SOA.On page 63 it is stated that "Alternatively, Capabilities may realize ServiceInterfaces using standard UML Realization. This approach is somewhat different in that it says that the Service Interface is a "specification" and the Capability "implements" this specification."In my view here the concept "capability" is used on two different abstraction levels: 1) abstract business view, and 2) IT implementation view. This should be avoided! To: Brian.Elvesater@sintef.no Cc: soaml-ftf@omg.org Subject: Re: issues 15322 - 15324 -- SoaML issues (RTF not chartered) X-KeepSent: 80E75972:D36A93C6-8525775E:0044D881; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Jim Amsden Date: Mon, 12 Jul 2010 08:42:10 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 07/12/2010 06:42:11, Serialize complete at 07/12/2010 06:42:11 Brian, There were many long discussions about what a Service is during the development of SoaML. One school of thought was that a Service was a kind of Class representing the definition and possibly the implementation of a service. Such a type could declare for example its dependencies on other services it uses. The intention was to provide a simple way to define services and their dependencies. This approach is very similar to traditional OO classes and doesn't really address the decoupling facilities that were intended to be supported by SoaML. However, it was a useful abstraction of 1) the description of a capability some participants might need, and/or 2) the description of a capability some participants have - often to provide implementations of provided services. The compromise we came up with was to use the word "Service" to designate a feature provided by a Participant - something they can perform and "Request" for a feature a Participant might need. These features are Ports designated by the <> and <> stereotypes respectively, and are usually typed by a ServiceInterface. The ServiceInterface is therefore the definition of the service, not the service itself. And A Capability is used to describe something participants might need or have to implement services as was done in UPDM. We realize this is a compromise and that the term "Service" is often used to refer to many things - commingling the type/instance boundary. Jim Amsden, Senior Technical Staff Member Rational EA and ADC Tools 919-461-3689 From: Juergen Boldt To: issues@omg.org, soaml-ftf@omg.org Date: 07/08/2010 11:29 AM Subject: issues 15322 - 15324 -- SoaML issues (RTF not chartered) -------------------------------------------------------------------------------- This is issue # 15322 From: Brian Elvesær Capabilities On page 40 it is stated that "Capabilities represent an abstraction of the ability to affect change" and there is a lot of explanation why modelling capabilities makes sense on what I perceive to be the business perspective on an SOA.On page 63 it is stated that "Alternatively, Capabilities may realize ServiceInterfaces using standard UML Realization. This approach is somewhat different in that it says that the Service Interface is a "specification" and the Capability "implements" this specification."In my view here the concept "capability" is used on two different abstraction levels: 1) abstract business view, and 2) IT implementation view. This should be avoided! ============================================================== This is issue # 15323 From: Brian Elvesær Figure 21: Interfaces The Shipping and ScheduleProcessing interfaces should be stereotyped <>.Also as stated above (issue 7) the concept of Cability as written in the standard is ambiguous as it has two different semantics whether seen from the business perspective or the IT perspective. I would personally only use the concept on the business level, thus a Capability should not be able to realize a ServiceInterface. The standard should clarify the ambiguity of the concept and choose one consistent meaning. I suggest restricting the Capability concept to the business perspective only. Thus, a ServiceInterface (IT perspective) exposes a Capability (business perspective). =============================================================== This is issue # 15324 From: Brian Elvesær Figure 22: Interfaces (same as figure 21) The Shipping and ScheduleProcessing interfaces should be stereotyped <>.Also as stated above (issue 7) the concept of Cability as written in the standard is ambiguous as it has two different semantics whether seen from the business perspective or the IT perspective. I would personally only use the concept on the business level, thus a Capability should not be able to realize a ServiceInterface. The standard should clarify the ambiguity of the concept and choose one consistent meaning. I suggest restricting the Capability concept to the business perspective only. Thus, a ServiceInterface (IT perspective) exposes a Capability (business perspective). Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org