Document Sample
comments Powered By Docstoc
					Issue # Source          Date
       1 Jeff Estefan   Dec. 10, 2009

      2 Jeff Estefan    Dec. 10, 2009

      3 Jeff Estefan    Dec. 10, 2009
4 Jeff Estefan   Dec. 10, 2009

5 Jeff Estefan   Dec. 10, 2009

6 Martin         Jan. 15, 2010

7 Martin         Jan. 15, 2010

8 Martin         Jan. 15, 2010
9 Martin     Jan. 15, 2010

10 Martin    Jan. 15, 2010

11 Martin    Jan. 15, 2010
12 Martin    Jan. 15, 2010

13 Martin    Jan. 15, 2010

14 Martin    Jan. 15, 2010

15 Martin    Jan. 15, 2010

16 Martin    Jan. 15, 2010
17 Martin      Jan. 15, 2010

18 Martin      Jan. 15, 2010

19 Martin      Jan. 15, 2010

20 Dave Ings   Jan. 18, 2010

21 Dave Ings   Jan. 18, 2010

22 Dave Ings   Jan. 18, 2010
The charter of the SOA-Tel TC to identify gaps in standards for
using SOA techniques in telecommunications is a good one
although the scope of the activity is not particularly clear despite the
scope description in the TC charter. For example, are we only
talking about gaps in technology-based specifications and standards
as specific technologies used to "implement" the paradigm of SOA
(e.g., WSDL, SOAP, UDDI, WS-*, XML-*, REST, CORBA, etc.)?; or
are we talking about gaps in specifications and standards in
"architecting" SOA solutions and the SOA paradigm (see It is
very important to adequately scope the effort and upon review of t-
soa-us-pr-01, there appears to be a mix of the two. I will elaborate
more in another comments 4 and 5 below.

Also with respect to scope, there are a plethora of implementation-
related specifications and standards that span several open
standards organizations (e.g., W3C, OASIS, OMG, The Open
Group, IETF). Your document t-soa-us-pr-01 barely scratches the
surface. This is not intended to be a nit as much as just the
recognition of the sheer volume of work that would be required to
adequately address the various implementation technologies alone.
It is not sufficient to just "cherry pick" a few WS-* specs and a few
SOA architecture-related and programming model specs like SOA-
RA and SCA-Assembly to
identify gaps in the standards. This hardly paints a clear, complete,
and unambiguous picture. Just the sheer volume of WS-specs as
you identified on pg. 52 of t-soa-us-pr-01 from the innoQ graphic
suggests setting yourselves up for a potentially huge volume of

Turning to the document t-soa-pr-01 itself, in Section 1, we would
have preferred to see reference to the paradigm of SOA leverage
the OASIS SOA-RM, a formally adopted OASIS standard since
2006 and your organization is, after all, an OASIS TC. The SOA-RM
is only reference in Sect 6 on the discussion of Issues on
Management, which isn't even on the radar of the SOA-RM
standard; however, the SOA-RA is and more on that subject next.
The introductory material seems to be a freeform discussion on the
SOA paradigm rather than a standards-based reference.
With respect to Section 6 and Issues on Management, those of us
participating in the SOA-RA (now referred to as the SOA-RAF
(Reference Architecture Foundation)) have also struggled with
modeling the management aspects of the SOA paradigm. We
recognize this is the weakest link in our spec and we are trying to
address that by hopefully recruiting additional members to the
Subcommittee (SC) to assist us. I have shared the material provided
in Section 6 with current members of the SC to investigate the TM
Forum SDF program in more detail; however, it is imperative that
our efforts be in concert with the development of an open standards
Also on the subject of Section 6, I did not see except in passing any
technical details in terms of use cases that address a specific
implementation technology standard for service management,
namely, WSDM-*. There is only brief mention of WSDM-* and no
reference called out to WSDM-* in the Normative References
section (1.2). It would seem that to be consistent with the
implementation technology specific gaps that were addressed in the
other sections related to addressing and notification, communication
protocols, and security, which did focus on specific technology
specs and standards (i.e., WS-Addressing/WS-Notification, SOAP,
SAML, etc.), that a similar approach be used for WSDM-* and any
other open specs and standards related to service management.

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

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

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 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",
please 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, ????

IBM recommends that the OASIS SOA for Telecom TC consider
engaging with the Web Services Test Forum (WSTF, The WSTF mission is to discuss and address
interoperability and general WS* issues. The membership consists
of most of the WS* vendors which will provide you a broad unbiased
community to work with. We suggest you bring your business
requirements and scenarios to the WSTF and allow the members to
help determine an appropriate solution. This may lead to testing of
intermediaries, which are today largely untested, and/or profiling of
intermediary, security, and management concerns. This forum is
free to join.
We also recommend that you engage with the OASIS SAML TC
on the SAML issues directly or with the WSTF.

If you'd like to discuss WSTF, SAML, or your issues further, we're
happy to set up a call, please contact myself (Dave Ings).
SOA-TEL answer                                                     Agreed Action Substantive Change
We realize the scope was large but it is too late in the process   No changes on No
to change. The scope of the group was to look at issues            Use Cases and
presented by external parties and put those problems on the        Issues doc.
table. The document reflects problems/ issues that were
presented to us. The scope was deliberative set large as we
did not know what was going to be presented nor did we want
to put constraints on the issues presented.

We tried not to "cherry pick" standards. Again, we only         No changes on No
addressed those issues presented and realized from the start Use Cases and
that we would not be able to address 99.9 % of the space. Our Issues doc.
work was contribution centered and the use cases only used
specifications as examples unless the issue was reflecting a
specific standard. In this case we used the standard as a
reference but made deliberate attempts to apply it to general
patterns in SOA space irrespective of different standards. This
was an architectural design document for guidance and was
never meant to address detailed technical implementations or
standards but more of identify issues that any detailed
implementation needs to factor in when addressing the goals of

You hit the point exactly, the documents was not meant to be a No changes on No
standards-based reference but an architectural document         Use Cases and
describing issues in any/ all standards not meeting the long    Issues doc.
term objective of SOA. The idea was to use real world
examples on what users are experiencing as a guidance to
support standards development. The OASIS SOA reference
model is fine and in hindsight should have looked at this. With
this said, we received ten contributions and the model was
deliberately kept simple because its purpose was to associate
for the readers the uses cases not try to promote one model
over the other. There were many approaches to this but we did
not want to engage into a discussion on SOA RM but just give
the readers a general model to understand where these issues
were in relation to "general" SOA areas (i.e. at the interface,
within security or profile area.).
Will consider looking further at this issue and consider using No changes on No
the RA/RM model in our requirements document. It is our hope Use Cases and
that the SOA RM group will specifically look at how            Issues doc.
management issues, inter domain federation can be addressed
with the reference model and subsequent standards. We would
like the SOA RA/RM to join us in Jan. Feb. 2010 so we can
discuss the issue, the requirements and address how to apply
these concepts in the RA model.

We only used specific standards to describe the patterns             Add WSDM in No
relating to the issues that were presented. Specific standards       Reference
and technologies were used to describe the issue and NOT             section (1.2),
designed and not solve the technical points. We recommended          and verify
solutions in some cases only to further clarify for the reader the   possibility to
issue but not prescribe a solution to the problem. WSDM is in        mention WSDM
fact mentioned. We will take an action to reference to WSDM          in section 6
in the normative (requirements section) release. We will also        without altering
go back to the author of section 6 to discuss further actions.       the content of
Lastly, this document is not a formal standard, merely a             section 6
reference document to help drive standards development. This
was done by design.

At the time the document was edited we used the only                 No changes on No
available template. The aim of the group is to get this              Use Cases and
document approved as Committee Specification and not as              Issues doc.
OASIS Standard, so no major problems should occur with the
Moreover as Martin correctly identifies, Section 8 statement
protect SOA-TEL TC from conformance issues.
SOA-TEL TC considers all issues presented in the document            No changes on No
as effective issues or gaps. Each issue associated with a use        Use Cases and
case has been drafted, presented, reviewed, commented and            Issues doc.
agreed. So the document presents the position of the TC on
the specific issues highlighted. Nevertheless the terms
“possible” and “potential” are explicitly used since SOA-TEL
members are working in good faith and are open to the
possibility that some other TCs, within OASIS or other SDOs,
when they will analyze the highlighted issues, could
demonstrate that those are effectively not issues, but SOA-
TEL’s misunderstandings or misinterpretations of the
SOA-TEL is acting in conformance to its Charter, which clearly       Addition of a     No
states the objectives of the TC as to 1) identify possible issues    sentence in the
and gaps, 2) specify requirements to address those issues.           intro saying that
SOA-TEL’s responsibility is not to solve the problems. It will       the Telecom MS
then be responsibility of the OASIS Telecom Member Section           SC will liaise
Steering Committee to identify the best path to possibly solve       with selected
the issues, and plans are already been made to approach the          TCs or WGs to
“owners” of the issues (such as OASIS SAML TC, W3C WS-               present issues
Addressing WG, etc.) to propose them issues and                      and possibly
requirements, and to let them identify appropriate solutions, if     have problems
any.                                                                 solved.
We can delete Diagram 1 out and just use Diagram 2, where           Delete figures 1 No
we position the numbers identifying the received issues (via        and 2 and just
contributions) onto the diagram to give the user an idea as to      present the list
where within a "generalized" stack the use cases apply. or we       of issues.
could only present the list at row 107.    Moreover any model
is an abstraction and our intent was not to create a new model.
These terms we used are generic on purpose and reflect high
level normalized terms used in the industry in creation of an
application. The diagram was only meant to help position the
user as to where this issue applies in within a generalized,
normalized stack and was not meant to be complex or in the
least confrontational. ·     Moreover it is clearly stated that
“Figure 1 is an attempt to provide a context rationalization of
items related to SOA: it was built not with the intent of being
rigorous, but rather to provide a possible classification schema
for the readers of this document”.

We are considering a federation example, which in the real          No changes on No
world may be given by a series of domains or cross domain           Use Cases and
level interactions, involving logical transactions, some of which   Issues doc.
may be long running.
In such a case we are merely stating that there should be a
standardized way to identify the ultimate endpoint of across this
series of invocations (constituting a composite), for which
specialized code does not have to be developed but is
identified in the original request.
For the time being (the following nay be confuted by following
proofs) this beaviours does not appear to be covered by an
existing standard and the specification which can address this
issue is W3C WS-Addressing, as stated in our document at
row 195 within the “perceived issue section”.
In relation to the ESB, it was introduced because it was
meaningful to describe and characterize the proposed use
case: the ESB helps to describe a specific situation but is not
itself the core of the problem. In this specific use case the
intermediary is the ESB but the requirement equally valid if the
ESB is substituted by a generic intermediary.
The comment can be agreed since the issue is related to the         No changes on No
scarce application of the standard by the development               Use Cases and
community. Nevertheless SOA-TEL is convinced that the use           Issues doc.
case is valid and can be included in this document, since a
scarce adoption of this specification is anyhow a problem for
the Telecom operators community.
For this reason it was brought to the attention of OASIS. the
use case does not imply a requirement, but nevertheless
OASIS SOA-TEL is convinced that the use case is valid.
SOA-TEL agrees that current WS-Addressing specification is No changes on No
designed for interactions with one single target. Nevertheless Use Cases and
the multi-target issue is still to be solved, and it would be    Issues doc.
opportune to have the solution with a standard specification
and not by means of costly software customizations.
SOA-TEL believes that WS-Addressing can evolve in order to
support more complex scenarios such as those with multi-
In any case SOA-TEL’s position is that a gap in SOA
specifications still exists since using BPEL, mentioned by
Martin, makes sense for long-term type processes, while it
does not for simple stateless itineraries involving few nodes at
the middleware level.
This last statement should anyway be checked with the specific
TC owner of BPEL.
If SOAP specifications are utilized in their current version, the No changes on No
concrete problem highlighted in the use case must necessarily Use Cases and
be solved with customizations. This results in having “weak”       Issues doc.
specs, covering only limited cases.
SOA-TEL is convinced that to allow a "specialized"
intermediary to inspect the body, determine subsequent
operations to be performed, then make a decision as to where
to send the result (including the original header) is not a
violation of the “separation of concerns” principle, and, more, is
a means to allow greater federation in real world examples.
The new “functional intermediary” proposed by SOA-TEL can
act as exactly a “SOAP Intermediary” when dealing with the
header independently from its actions on the body, and, in
addition, it can handle the body if necessary.

Martin states: “nothing prevents the ultimate recipient from   No changes on No
creating a new soap request”.                                  Use Cases and
SOA-TEL answers that the solution proposed involves code       Issues doc.
writing and customization, which, as previously stated,
“weakens” the SOAP standard: the aim is to have a standard
which is widely applicable on such a “common” use case
without massive customizations.
No response on this since this is not a comment.               No changes on No
                                                               Use Cases and
                                                               Issues doc.

We are well aware of SCA and it ability to support multiple    No changes on No
interfaces. We also assume that there are many conceptual      Use Cases and
similarities between the TM Forum SDF Service and the          Issues doc.
"OASIS SOA service". For this reason we point the issue of
needed clarity in a SOA service having mor than one interface.
Since these terms (i.e. Service) are effectively overloaded, a
plea to the OASIS SOA-RM team to consider this issue would
help in resolving issues and problems, which may not only be
generated due to terminology.
The contibution came from TM Forum SDF team and as such it        Change end of No
has been dicussed in OASIS SOA-TEL. The sentence reflects         section 6,
TM Forum SDF's position and was accepted by SOA-TEL               putting evidence
since the issues contained in section 6 are considered relevant   on single
for the Charter of SOA-TEL. OASIS's adivce is asked, since        affected TCs,
the affected specifications, OASIS SOA-RM, OASIS SOA-RA,          and request to
OASIS SCA are specifications delivered by OASIS TCs.              OASIS TCs to
                                                                  consider issues
                                                                  presented by
                                                                  TM Forum
The problem is basically that in order to deliver ubiquitous     No changes on No
mobility and interoperability to users, applications can not be  Use Cases and
bound by a single network provider nor underlying assumptions Issues doc.
on the real-time protocols used. This is clearly stated. To do,
we need to adopt a universal means to set up a
communications context across applications domains. This
implies a set of standard of which we are recommending one
being created. Is that not the goal of a standard? To create a
standard especially this larger in scope was outside of our
charter - our charter was to identify gaps in standards in real
world contexts. Lack of a standard in this context is the
problem further, lack of standards that inter-operate is the
secondary problem.
The workaround presented is in a non normative appendix.         No changes on No
The Telecom MS SC could decide to present it to W3C as a         Use Cases and
possible workaround, but it is not a decision to be made in SOA- Issues doc.
SOA-TEL is happy to follow Dave's suggestion and will report No changes on No
to the Telecom MS SC in order to possibly set a link with        Use Cases and
WSTF.                                                            Issues doc.

SAML surely is a candidate to refer to for the solution od        No changes on No
security related issues - refer to SOA-Tel's requirements         Use Cases and
document. Telecom MS SC will keep this into account.              Issues doc.
SOA-TEL thanks Dave for his availability wnd will surely          No changes on No
contact him to have assistance                                    Use Cases and
                                                                  Issues doc.

Shared By: