Public Comment

[comment-form@oasis-open.org]

Comment from: dandashi@mitre.org

Name: fatma dandashi
Title: lead software systems engineer
Organization: Mitre
Regarding Specification: OASIS SOA Reference Model
Software scope
There is a mention of software scope on lines:
25, 28, 75, and specifically: 
167- 170 
Note that while the concepts and relationships described in this reference model may apply to other "service" environments, the definitions and descriptions contained herein focus on the field of software architecture and make no attempt to completely account for use outside of the software domain. Examples included in this document that are taken from other domains are used strictly for illustrative purposes.
These 4 references are not enough to clarify this scope to the reader. Specifically, the use of terms such as capability and need which are generic to any domain and the accompanying examples that are from everyday life and not necessarily from software domain, re-enforce to the reader the false impression that this reference model and/or SOA principles in general apply to any domain where a service might be used.. I find this adds to the current misconceptions within DoD that view SOA as the answer to all problems, not realizing the principles and techniques set forth in industry and by this body (OASIS) are restricted to the software domain.
Suggestions:
1.	Make the scope clearer by adding stronger language to introduction and to section 2.1
2.	2. remove examples from every day life and make them clearly examples for software solutions
3.	change the use of the terms need and capability to 
Lines 58-60, scope being software only can be reinforced here.
Line 154: again implies services could be those provided by humans for example (confusing)
Line 272: “Thus, the service could carry out its described functionality through one or more automated and/or manual processes that themselves could invoke other available services.”
This is clearly Not a software service if a manual process is involved to perform the service function. The use of a service may involve a human, but the service itself is not a manual process. This again adds to the confusion about the definition of a service.
Line 277: real world effect again implies scope outside software. Usually effect on real world is indirect.
Comment # 2:
Use of the term architecture within document to denote an arch model (see lines 34-37).  A blue print is a (partial) model of the house. One blue print only shows one perspective, and several of those actually model the complete architecture. The house itself has a certain architecture (the concept), but that architecture is not the blueprint itself. Pls see IEEE 1471. Restrict use of term architecture to mean the actual concept of the thing being described. And/or clarify at beginning that use within this document is always to architecture model, but that word the “architecture” is being used for brevity to actually mean architecture model.
•	IEEE1471: “Things” (called systems in the standard), “Architectures,” and “Architecture Descriptions” (AD)
–	Things are systems, enterprises, systems-of-systems, man-machine systems, whatever you are interested in - “System of interest”.
–	“Architecture” is a conceptual property of a Thing.
•	Tied to the structure of the Thing, but not necessarily the physical structure.
•	A Thing (read a system) has one architecture
–	An “Architecture Description” is a document/model of the Architecture of a Thing
Comment #3 (related to 1 above)
Line 262 definition of term service: “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.”
Line 530: “That the service performs a certain function or set of functions;”
Line 543: “3.3.1.2 Service Functionality” 
Line 550: functions
1. There seem to be two different definitions of the term service-capability and function. 
2. Suggest you stay away from using the term capability and use term function instead (more closely associated with software than is the term capability). 
On Line 474: internal actions (use implementation)
Line 510: you use term function to mean HOW the service is provided which is internal to service implementation (same as your term internal action on line 474), but should not be confused with term “function” used on line 530 to mean the service that is actually provided. I would assert that function DOES NOT change.
Line 518, use term function as opposed to capability (for consistency in document), especially sine you end sentence with term functionality
Comment #4
Lines 262 and 530: Contend that a service should provide ONLY one function but multiple interfaces (line 268 implies only one interface), otherwise it is not properly defined and well encapsulated. A function does not necessarily mean one at the level of a C++ method for example.
Comment #5
Line 264: “A service is provided by one entity – the service provider –.” More than one provider could provide same service. Perhaps you mean to just define the term provider. But your words imply there can only be one.
Comment #6
Line 281: the use of the term change in shared state is confusing and may mean state of service itself. The service does not change state as a result of being invoked and then executing.  If it did, others will not be able to use it afterwards.  Suggest: state of object of service is changed.
Line 364: related comment: assumes service provider has authority to effect change in state of some object that consumer needs, this authority is given by whom?  It is more likely that provider provides some computational service, the results of which are passed back to consumer who then stores it in some object (which he owns, or has authority over) to effect a change in state of that object.  My point is to avoid use f term shared state.  If services are truly agnostic of consumers, they will have no knowledge nor authority to effect any changes directly, and will not directly effect a state change.
Line 452- editorial: remove extra and “…between and temporal properties…”