PR comments on SOA-Te Telecom SOA Use Cases and Issues v1.0

["Martin Chapman" <martin.chapman@oracle.com>]

Here are my review comments on http://docs.oasis-open.org/soa-tel/t-soa-uci/v1.0/cd01-pr01/t-soa-uc-pr-01.pdf
Note that these comments are made by me as an individual TAB member, and do not represent the collective views of the TAB.


General: This is a classic example of why OASIS needs a new class of document, currently being proposed by the Board, as this is not
a specification. This recognized in the document under Section 8. Conformance, which correctly states that no conformance clauses
apply.

Abstract:  ".has the objective of collecting potential technical issues and gaps of SOA standards."
	and ".and a rationalization of the possible gap within the standard..."

I am uncomfortable with such vague language as "potential" and "possible"; either these are issues in the view of the TC or they are
not. I suggest deleting these two words here and in other places throughout the document where similarly used.

1. Introduction: Paragraph at line 37: delete "possible" but more importantly I am missing the why? Please elaborate what the
expected next step are after identifying and defining the issues and gaps. Do you want to work with the external bodies to fix the
issues, who is expected to fill the gaps etc? The next paragraph doesn't really help in this regard.


2. Context Setting, para at line 97 and figure 1. Without more explanation, figure 1 doesn't make much sense to me. The box  SOA
Framework contains boxes with terms that not familiar to me in a SOA context (presentation and encoding, component service *tier*
etc). The point here is that without more explanation it is only meaningful to the authors of the document, and thus is usefulness
is limited. What is really important is the list starting on 107, and I don't think Figure 1 helps with understanding the list.

Section 3.1: I do not understand the issue being raised in this section. What standard(s) are perceived to be inadequate and why?
Note that ESB is loosely defined term without a single standard, so it is hard to grasp the requirement. Reading ahead to 3.2.5 I
think I understand what is being said here, but this section could be more explicit about the use of ws-addressing, what the
intermediary is etc. See comment on 3.2.5 as well.

Section 3.2.3: While I agree with the conclusion, so what? What can this TC do to solve the problem? In other words, just
highlighting this to a broader community, who will probably agree with you anyway, doesn't move anything along. Is there a proposed
next step?

Section 3.2.5 WS-addressing is intended to be used to address a single target. If during the processing of an event or request sent
to such a target results in other  messages being sent to other addressable targets  it is the responsibility of the software at the
original target to maintain the correlation, such that a correct response can be sent. Ws-addressing was not designed for this,
however other standards may exist (e.g. BPEL) to help solve this problem. 

Section 4.1.2. I think there is confusion here between the general concept of an intermediary and a SOAP intermediary. As far as
understand the concept of soap intermediary, the goal is to allow SOAP stack vendors to be able to manipulate security/reliability
type headers without any need to understand the body i.e very much independent of the application. To require a general purpose soap
vendor to be able to manipulate the body  to enrich data in an application specific way, or to understand the contents of a body to
extract data to do routing violates the basic separation of concerns on which SOAP and many other protocols are built. In this case
the "ESB" layered on top of SOAP must have this knowledge and cannot expect a general purpose SOAP layer to do this. 

Section 4.1.3. line 403 says, "the ESB cannot forward the SOAP Header to the appropriate Service provider." This is correct at the
soap level, but nothing prevents the ultimate recipient from creating a new soap request. Note I think assuming the ESB is a SOAP
intermediary is incorrect as noted under comment for 4.1.2 above, since in this scenario it is not working on pure SOAP headers. 

Section 5. I am not a security expert so cannot comment on this section.

Section 6.3.1 Para at line 889, and the rest of the section. "Following these documents it seems to be impossible to have two or
more interfaces for a SOA Service." The problem with this sentence is that it jumps to a technical conclusion where I think the
problem is terminology, and the same terms being used in different contexts with different meanings. At least in SCA, an SCA
COMPONENT (e.g. representing an SDF Service) may indeed have multiple interfaces of the same or of different types, such as a
functional interface and a management interface. Thus I can only conclude that an SDF Service can offer multiple WSDl/SOA services,
if the definition of SDF service allows this! Therefore this whole section should be rewritten to warn of the issue of using an
overloaded term.

Section 6.5. "TM Forum SDF Team is seeking reconciliation..." " what is OASIS's Advice..." Isn't this the purpose of this TC, and
shouldn't this deliverable be helping achieve this goal rather than pose a question to OASIS? I really don't know why a deliverable
like this is talking in terms of the "TMF Forum SDF TEAM is seeking", pleas remove this wording and focus on issue and gaps that
need to be resolved and who you think should be resolving them.

Section 7.1.3. It is not clear to me why this, and indeed all of section 7, is in the document as it doesn't seem to raise any
issues or identify gaps.

Appendix C. Who do you expect to define the proposed extension, the SOA-Tel Tc, W3C, ???? 





 
Martin Chapman | Standards Professional
Mobile: +353 87 687 6654 

ORACLE Ireland 
 "Please consider your environmental responsibility before printing this e-mail"