OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: FW: [soa-rm] Help in Sending this Note: Feedback on SOA-RM Spec (09)




-----Original Message-----
From: Jeffrey A Estefan [mailto:Jeffrey.A.Estefan@jpl.nasa.gov] 
Sent: Monday, October 10, 2005 4:14 PM
To: Matt MacKenzie
Subject: Fw: [soa-rm] Help in Sending this Note: Feedback on SOA-RM Spec
(09)

Hello Matthew,

I have not heard back from Duane regarding my comments below.  Do you
know
if Duane on travel at this time or how we can follow-up on this issue
and my
feedback comments on the draft (rev 0.9) of the spec?  It appears that
my
attempts to send Group e-mail is getting rejected.

Thanks for your assistance,

Regards...

 - Jeff

Jeff A. Estefan
Jet Propulsion Laboratory
Office: (818) 393-5280

----- Original Message ----- 
From: "Jeffrey A Estefan" <Jeffrey.A.Estefan@jpl.nasa.gov>
To: <dnickull@adobe.com>
Sent: Thursday, October 06, 2005 10:19 PM
Subject: [soa-rm] Help in Sending this Note: Feedback on SOA-RM Spec
(09)


> Duane,
>
> My attempts to send an e-mail note to the soa-rm e-mail list keeps
getting
> thwarted by the mail server.  I'm wondering if it's because I am
currently
> Applicant status.  In the meantime, I wanted to send the following
feedback
> on the spec.
>
> Thanks...
>
>  - Jeff
>
> ------------------
>
> Editors,
>
> I will try and officially get these comments into the issues list but
I
know
> the deadline for response was soon and I needed to provide some
attachments.
> Please see my feedback comments below.
>
> Regards...
>
>  - J.A.E.
>
> Jeff A. Estefan
> Jet Propulsion Laboratory
> (818) 393-5280
>
> -------
>
> Editorial Suggestions:
> 1. Make first instance of each concept definition in the Reference
Model
> subsections be of bold face type (e.g., 2.2.1 Service, 2.2.2 Service
> description).
>
> 2. Consistent use of service-oriented architecture vs. service
oriented
> architecture (with/without hyphen).  Is there an agreed upon
convention?
>
> Observation:
> There is no notion of "architectural style" in the definition of SOA.
Nor
> is there a definition of Architectural Style in the glossary.  An SOA
is
an
> example of an IT architectural style (just as there are other
architectural
> styles, e.g., event-driven architecture (EDA), client/server
architecture,
> information-centric architecture).  One definition for Architectural
Style
> is as follows:
> "A coordinated set of architectural constraints that restricts the
> roles/features of architectural elements and the allowed relationships
among
> those elements within any architecture that conforms to that style."
>
> Finally, a few words about illustrations:
>
> 1. At a minimum, there should be a version of the illustration that
Duane
> has been using in his briefing slides and in the FAQ depicting SOA as
it
> relates to a larger SOA framework (e.g., reference architectures, SOA
> implementations, etc.).  [First attachment.]  A future revision of the
> SOA-RM document should show this diagram in UML 1.x or UML 2 format.
>
> 2. The object diagram that has been suggested depicting the key
concepts
of
> the SOA-RM and their relationships covers primarily the functional
elements
> of SOA.  They do not cover the non-functional elements, i.e.,
> quality-of-service (QoS) elements (e.g., security, transaction, system
> management, etc.). In a future revision of the SOA-RM document, the
QoS
> concept elements and their relationship (as well as the any
relationship
to
> the functional elements, typically through Policy) should be included.
>
> 3. One illustration that could be of great service to the community
and
> related to item 2 above would be a SOA stack diagram depicting the
primary
> functional and non-functional (QoS) elements.  An example drawn from
and
IBM
> Redbook I served on the review committee for early last year is
attached.
> This graphic would need to be updated to reflect the SOA-RM concepts.
Stack
> diagrams can indeed be contentious to develop, however, keeping
simplicity
> in mind , an example such as this has the benefit of a) serving as a
> reference model on which implementation-specific specifications and
> standards can be easily mapped (e.g., WSDL, SOAP, UDDI, SAML, XACML,
WSRP,
> etc.), and b) is extensible.  It is probably too late to incorporate
this
> into the near term release of the SOA-RM specification document, but
I'm
> hoping to hear more input on this subject and whether serious
consideration
> should be given by the TC on adopting such a model for future
revisions.
>

framework.gif

SOA_stack.jpg



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]