[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: suggested responses to PR2 comments
Assuming we can discuss ringtones and various medications under a different agenda items, I suggest the following responses to the issues noted by Duane.
Comment from: Sean.firstname.lastname@example.org
Regarding Specification:Reference Model for Service Oriented Architecture 1.0
Re Section 220.127.116.11.2 Semantics, line 457, 458. The claim that "The formal descriptions of terms and the relationships between them (e.g., an ontology) provides a firm basis for selecting correct interpretations for elements of information exchanged" is incomplete, in that for applications that have an effect on the real world, the formal description must be based on the behaviour of the organizations - that is, at least some form of process model - and not simply on the descriptions of the terms themselves. A clarification of what constitutes a formal description in this context would be helpful.
The next section of the RM discusses behavior models and the role these play. It is beyond the scope of the RM to expand on the specifics of “formal description”.
Comment from: email@example.com
Name: Dr. Frank Zhu
Title: Sr. System Engineer
Regarding Specification: SOA-RM (policy and contracts) --- policy is going to play very important role in SOA. SOA service first has to be policy oriented, which means that policy has to be involved from the full life cycle of SOA service development from development to runtime. Therefore it should be beneficial to develop SOA policy reference model in which it could define capabilities, policy information model, policy language/computing, etc. The current version of SOA rm on policy is little vague. If Users can derive concerete product from SOA policy refence model, it would be great.
The TC agrees regarding the importance of policy and the RM includes numerous mentions of policy and an in depth discussion in section 3.3.2. While an SOA policy reference model may be of value, it is beyond the scope of the current effort.
Comment from: firstname.lastname@example.org
Regarding Specification: Second Draft Reference Model for Service Oriented Architecture v1.0
Dear TC participants:
I have attempted to review the draft from the viewpoint of a layman. My comments reflect that viewpoint.
Lines 246-247. This new material presumes too much knowledge by laymen on the topic of Object Oriented Programming. SOA has been well explained earlier in the draft, complete with examples. However, fundamental relevant concepts of OOP are not explained, and the explanation of an "object" and its role is far too cursory; e.g., "packaging data with operations" and "melding of methods to a given data object."
The distinction drawn between the OOP and SOA paradigms is sufficiently explained for a developer to understand. But for a document that is intended to be understandable to laymen as well, a better explanation of OOP and easily recognizable examples of an "object" would be helpful. It should not be assumed that a layman is familiar with those terms.
Lines 344-345 contains a clause that likewise assumes too much knowledge on the part of the lay reader. "without the proper libraries being present the function call cannot complete." Laymen rarely know what a "library" is in the sense the term is used by programmers; a "function call" is another term of art not known to laymen.
I could provide more examples if it would be helpful. But I think it would be far more helpful if the TC could arrange to have a layman with good editing skills but no programming experience whatsoever supervise a complete rewrite. I support the TC's goal of making the document informative for both software developers and laymen. But the document has not succeeded in delivering a product that is useful to laymen.
But I still appreciated reading it very much. It did help me understand more of the relevant concepts.
As noted in section 1.3, the RM is intended to assist a wide audience, and that also implies a wide range of background. In some of the introductory sections, the TC tries to not only provide perspective but to answer recurring questions about SOA and its relationship to well known paradigms. The discussion of OO is one example of such a relationship. Unfortunately, it is impossible to include sufficient background material for every referenced technology without, in effect, writing reference models for those too. Section 3 of the RM provides the main body of the description of SOA and does not require an in depth knowledge of other paradigms discussed in the preceding sections.