SOA-Tel Colleagues,

Please accept the following comments as my feedback against the Telecom SOA Use
Cases and Issues (t-sos-us-pr-01) v1.0 document that was out for public review.
The first two comments have to do with the scope of the TC. The remaining
comments address the published technical work itself, i.e,. t-soa-us-pr-01.

Note that I am a voting member of the SOA-RA TC, the SOA-RAF SC, and the
SCA-Assembly TC. I am also the corporate representative to OASIS for NASA/Jet
Propulsion Laboratory.

If you have additional questions, please contact me at
Jeff...@jpl.nasa.gov<mailto:Jeff...@jpl.nasa.gov>. I look
forward to further collaboration with your TC.

Regards...

- Jeff Estefan, NASA/JPL

Comments:

1. 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
http://www.opengroup.org/onlinepubs/7699909399/toc.pdf)? 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.

2. 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 work.

3. 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.

4. 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 approach.

5. 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.