OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-tel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Dear colleagues

This mail is to inform you that in our June 8th meeting we have accepted to address the comments received on the Requirements document in public evaluation as proposed by the Reqs document editor.

 

Hereafter you have the details

 

 

 

Group decisions are > SOA-TEL …

 

 

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.)
> SOA-TEL, 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/

> SOA-TEL 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.
> SOA-TEL, 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.
*********
> SOA-TEL, 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)

> SOA-TEL, comment accepted; 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?

 

> SOA-TEL: ,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

> SOA-TEL, 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.

 


> SOA-TEL, 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)

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è necessario.

 

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è necessario.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]