Feedback on t-soa-us-pr-01

["Estefan, Jeff A (3100)" <jeffrey.a.estefan@jpl.nasa.gov>]

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 Jeffrey.A.Estefan@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.