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

Dear colleagues,

In preparation of our TC meeting to be held next Tuesday, June 8^th please read below the proposed handling of received comments on the Requirements document during its public evaluation.

This proposal has been implemented in a draft CD02 (with revision marks), to be discussed and possibly accepted in next Tuesday’s meeting.

See document link: http://www.oasis-open.org/apps/org/workgroup/soa-tel/download.php/38112/t-soa-req-01-cd-02-8june proposal.doc

My proposals are in red inline the text of the original commenter, in the form > ER …

If the group accepts this proposal we can accept proposed document as CD02 and begin the CS voting process. We will discuss on Tuesday each item.

My view is that none of the submitted comments is related to a “substantive change”, so if this as well is accepted by the TC we will not need a second public evaluation round.

Speak to you on Tuesday.

If you can’t make it but want to give your views please send comments via email to the TC list.

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.)
> ER: Done, comment accepted

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/

> ER: Done, comment accepted

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.
> ER: Done, comment accepted

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.
*********
> ER: Done, comment accepted

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)

> ER: Done, comment accepted; my mistake;: I wanted to numerate requirements but as a matter of facts the [ xyz] form is used for quoting references, Now all requirements are numbered as Req. 1, Req. 2. etc.

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?

> ER:,.Issues are in standards pertaining to other TCs, we just point out the issue and require its solution. Then, to aid, we offer our thoughts on possible ways to solve the issue. But the final response must come from TCs who “own the standard”

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

> ER: Done, comment accepted; same handling as of Section 2.

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.

> ER: Done, comment accepted. Conformace rules now have been identified in Section 6 per each requirement.

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