FW: [soa-tel-comment] Telecom SOA Requirements Version 1.0

Dear colleagues

The evaluation period of our reqs document ended last week, May 20^th.

We received some comments, from Patrick Dursau, attached hereafter,

I will process them and make a proposal (new version of the document) to the TC before our next TC meeting, planned for June 8^th, so that by this meeting we can take a decision on them and possibly start the CS approval process.

In the meantime should any of the TC members have some ideas or suggestions on their handling please do not hesitate to let me know. As a first cut they do not seem “substantive changes”, but I will check thoroughly in the next days.

Regards

Enrico

From: Patrick Durusau [mailto:patrick@durusau.net]
Sent: martedė 18 maggio 2010 2.22
To: soa-tel-comment@lists.oasis-open.org
Cc: tab-internal@lists.oasis-open.org
Subject: [soa-tel-comment] Telecom SOA Requirements Version 1.0

Interesting work but by its own admission, not a standard. Hence, no conformance clause.

Broken link:

In normative references:

http://www.w3.org/TR/2007/REC-wsdl20-primer-20070626/Recommendation

should read:

http://www.w3.org/TR/2007/REC-wsdl20-primer-20070626/

(Note, delete "Recommendation" from the link and it will be fine.)

Redirect:

Add trailing slash to:

http://www.w3.org/TR/2006/REC-ws-addr-core-20060509

Thus:

http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/

2 Requirements on Intermediaries Handling

This section gathers a collection of requirements related to the same typology of issue. Some existing specifications upon which Service Oriented Architectures are currently based on and implemented (such as W3C’s WS-Addressing, W3C’s SOAP, OASIS’s WS-Notification) do not consider the presence of intermediaries in the specified message exchange patterns (in the transactions between the actors that implement the services), or they don’t consider the possible situations in which such intermediaries can be involved.

For this reason, intermediaries handling within SOA implementations is currently achieved via workarounds or proprietary solutions.

Suggest recasting the section header -> Requirements on Intermediaries

The first sentence/paragraph is very awkward. Suggest:

Some existing specifications used by Service Oriented Architectures do not allow for the presence of intermediaries in message exchanges. The lack of standards for intermediaries has led to workarounds and proprietary solutions. This section develops the requirements for intermediaries in message exchanges.

2.1.1 Indentification of Use Case Text

Now reads:

Refer to rows 189 – 192 of [SOA-TEL 1.0], in which the technical issue is documented.

At the moment, a standard way to specify in a message (involved in a process/transaction) the endpoint to which the final result of a “process/transaction" should be sent, does not exist.

Very awkward.

First, I assume that 2.1.1 is supposed to either recite the use case (best choice) or is supposed to be a pointer to where the use case is stated in full? Perhaps both?

BTW, the "rows 189-192" reference isn't how one specifies a location in a document with section numbers.

Suggest:

********
2.1.1 Summary of Transaction Endpoints Use Case

There is no standard way to specify in a message that is subject to a process or transaction, the end point to which the message should be sent at the end of the process or transaction.

The lack of endpoint specification in messages is more fully documented in [SOA-TEL 1.0], 3.1 Transaction Endpoints Specification.
*********

I am not real sure what to make of 2.1.2 Requirement(s) where it appears to quote [SOA-TEL Req. 1].

Is that a quotation? I notice this happens throughout the document.

If it is the TC's intent to cite SOA-TEL 1.0 as the source of the requirements, that's fine but at least do so in a way that makes sense.

For example, in the introduction, say: "The requirements for SOA were developed in SOA-TEL 1.0. Those requirements form the basis for the analysis in this document."

Then, when you get to 2.1.2 (and elsewhere), you say:

The requirements established in SOA-TEL 1.0 for specifying endpoints following transactions are:

(here quote as a block quote the requirements and do a proper citation)

2.1.3 Description (Is this a repetition of that is in 2.1.1?)

2.1.4 It isn't at all clear why the TC wishes to "specify" its musing on possible solutions.

If this is supposed to be a standards document, then here specify *a* solution and in conformance, meeting this "solution" is conformance to this document. Yes?

The same structure and shortfalls are repeated in:

2.2 Requirements on WS-Notification

2.3 Requirements on SOAP

3.1 Requirements on Security Token Correlation

3.2 SAML Name Identifier Request

3.3 SAML Attribute Management Request

3.4 User ID Forwarding

4.1 Cardinality of a Service Interface

4.2 Requirements on Metadata

5 Requirements on SOA collective standards usage

Do note that *must* is a term you define in 1.1 Terminology and in the absence of conformance clauses you are using it *improperly*.

6 - No conformance clause = no OASIS specification or standard.

It is possible to write specific use cases and then define requirements to meet those use cases. Then define conformance clauses for those requirements. That is to say it is possible to accomplish the goal set for this document, just not the way this document attempts to do it.

Hope everyone is having a great day!

Patrick

--

Patrick Durusau

patrick@durusau.net

Chair, V1 - US TAG to JTC 1/SC 34

Convener, JTC 1/SC 34/WG 3 (Topic Maps)

Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300

Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

soa-tel message