[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [soa-tel-comment] Feedback on t-soa-us-pr-01
|
SOA-RA Colleagues, Below is a response from the
SOA-Tel TC on a few feedback comments I provided. Passing these along as
an FYI. Also note the request for collaboration on the Mgmt topic (#4
& #5 below). Regards…. - Jeff From: Giordano, Michael
(Michael) [mailto:giordano@avaya.com] 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]