Telecom SOA Requirements Version 1.0

[Patrick Durusau <patrick@durusau.net>]

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)