Comments on Public Review of SOA-EERP specifications

[William Cox <wtcox@CoxSoftwareArchitects.com>]

1. The terminology appears to be inconsiteent with that in the SOA Reference Model. Terminology alignment with that specification. This applies to the White Paper, and the explanatory sections of all three specification.  In particular, at least the use of "Service" should be made consistent in all SOA-EERP specifications.

2. Editorial: Many sections start on a left hand (verso) page. They should start on a right hand (recto) page.

3. All issues identified as "Deferred" in the TC issues list dated 2009-10-24 Revision 18 should be opened and considered.

4. The TC should consider whether the details of how services and service providers are identified is consistent with good parctices in defingin information exchanges. In other words, these specifications may need to change due to design considerations for the protocol, which is not being reviewed at this time. A review with a future version of these specifications and the protocol should undergo a unified public review in the future.

5. bqOs lines 5ff: a service is not defined in this specification, yet "service discovery" is applied. All uses of service must be examined for consistency with the "service" in Service Oriented Architecture. "Business Service" is a new definition in these specs and should be carefully and clearly defined. This comment applies to all of the specifications -- service is used frequently but not defined and without reference to SOA-RM.

6. The tiles of the specs and the TC strongly suggest that the Soa meaning is implied, but is never stated.

7. Likewise, "Business Service Level Agreement" suggests a relatoinship to SOA-and SOA RM, but the relationship is never stated.

8. A non-normative section should be included in each specification showing additional samples, and demonstrating that empty or nearly empty artifacts do not conform.

9. The White paper does not carefully define a model or architecture for interaction; those aspects of EERP should be spelled out in the forthcoming protocol specification. Some may be better in these specifications, e.g., could it be stated that only a rating service returns a rating list? and only a business service (still undefined) returns credentials?

10. The use of "third party" (e.g., in Rating lines 100) is problematic. Does the specification assert that only "third parties", which is taken to mean "parties unaffiliated with either the requester or the target of the rating request" will respond? The conformance clauses on this issue are extremely weak. This is another area where the overall architecture, in a normative form rather than a white paper, is essential to understanding.

11.  Again in Rating, line 624 (and similar locations in the other specs): OASIS specifies that the normative schema is that in the identified separate file. This should be noted in all of the schemas in the specifications. In (e.g.) bQoS, Appendix B "Non-Normative Text" says "none" but is followed by non-normative Appendix C which is not identified as non-normative.

12.  In Rating, not enough is done to connect "Credentials" to the common uses of the term, including in security and business. This is essential.

13. In BSLA Non-Normative text is Appendix C, preceded by the SML Schema. This should be identified per OASIS rules as non-normative and that the separate XSD file is normative.

14. BSLA lines 1-12. This is not sufficient to connect the notion of a BUSINESS Service Level Agreement to an SLA as understood in the software/IT world. An explanation connecting, contrasting, and comparing the notoins should be included. There is some defition in 2.3 (line 108-110) which partially satisfies this. In conjunction with comment 15 this needs to be more clear and more prominently placed at the beginning of the document in Section 1.

15. All three specifications use common words (e.g. Service, SLA, Quality of Service, Rating, Credentials) but do not define them or reference the relevant definitions. All the specifications should carefully compare and conrast, and where a specific technical meaning or meaning may be understood, indicate whether that meaning is intended.  Otherwise the documents are hard to comprehend. The missing comparison and contast beteween "SLA" and "BSLA" is one case in point (see item 14). The connections all need to be explicit, not implicit or suggested (but never confirmed).  The documents read as if there were a detailed architectural and interaction model that is understood by the authors but never explained to the readers. This is a barrier to implementation, understanding, and conformance.

16. BSLA table 1, udt - why does this referenc both UBL and CEFAACT when it's a urn to CEFACT?

17. the reference to services and other things are all URIs. How can an implementation determine which kind of service or entity is at the URI used? This is in all three specifications.

bill cox

--
William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax