RE: [soa-tel-comment] Feedback on t-soa-us-pr-01

Estefan –

Our response is below> also can be found in the 12-15 SOA-TEL meeting notes on the OASIS site.

First, we want to take the time to thank you for responding to the submission and look forward to working with you to address some of these issues.

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.

Response:

We realize the scope was large but it is too late in the process to change. The scope of the group was to look at issues presented by external parties and put those problems on the 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.

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.

Response:

We tried not to “cherry pick” standards. Again, we only addressed those issues presented and realized from the start that we would not be able to address 99.9 % of the space. Our 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 SOA.

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.

Response:

You hit the point exactly, the documents was not meant to be a standards-based reference but an architectural document describing issues in any/ all standards not meeting the long 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.)

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.

Response:

Will consider looking further at this issue and consider using the RA/RM model in our requirements document. It is our hope that the SOA RM group will specifically look at how 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 so we can discuss the issue, the requirements and address how to apply these concepts in the RA model

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.

Response:

We only used specific standards to describe the patterns relating to the issues that were presented. Specific standards and technologies were used to describe the issue and NOT designed and not solve the technical points. We recommended solutions in some cases only to further clarify for the reader the issue but not prescribe a solution to the problem. WSDM is in fact mentioned. We will take an action to reference to WSDM in the normative (requirements section) release. We will also go back to the author of section 6 to discuss further actions.

Lastly, this document is not a formal standard, merely a reference document to help drive standards development. This was done by design.

Regards,

Mike Giordano

soa-tel-comment message